Konversion von dezimal zu binär

[diavy]

Hallo zusammen, ich hab mal wieder ein Problem.

Meine Aufgabe ist es, ein Programm zu schreiben, das ein Zahl(<>0) liest und diese dann in binär tranformiert.

Sprich: 43 --> 101011 wegen 1*2^5+0*2^4...

Vorneweg, ich habe delphi 6, da war die math.pas nicht dabei. Diese musste ich downloaden, da die Funktion n^i nicht funktionniert hat. Ich hab es dort gespeichert: C:\Program Files (x86)\Borland\Delphi6\Source\Rtl\Sys, um die Funktion 'power' verwenden zu können.

Als "Information" kommt nach Eingeben der Zahl '...raised too many consecutive exceptions....process stopped. use step or run to continue.'

Zum Script:

Delphi-Quellcode:

program Project2;

{$APPTYPE CONSOLE}

uses
  SysUtils,math;

var
number:extended;
i,k:integer;
square:array of integer;

begin
  { TODO -oUser -cConsole Main : Insert code here }
readln(number);
i:=0;
while number>power(2,i) do
        inc(i);
k:=i;
while (number<>0) do
        begin
        while number>power(2,i) do
                inc(i);
        i:=i-1;
        number:=(number-(power(2,i)));
        square[i]:=1;
        end;
for i:=k downto 0 do
        writeln(square[i]);
readln;
end.

Wär sehr nett wenn wer mir sagen könnte was ich falsch gemacht habe.
LG

[DeddyH]

Abgesehen davon, dass mir das unnötig kompliziert erscheint gegenüber einem Binärvergleich hast Du vergessen, das Array zu dimensionieren (SetLength).

[himitsu]

Zitat von DeddyH:

Abgesehen davon, ... hast Du vergessen, das Array zu dimensionieren (SetLength).

Für sowas schadet es nie, wenn man mal die Bereichsprüfung aktiviert.
{$Q+} => oder über die Projektoptionen und neuerdings auch via {$OVERFLOWCHECKS ON}
Dann wäre das fehlende SetLength sofort aufgefallen.


Und wenn du so wild rumrechnest, dann eventuell auch noch die Überlaufprüfung.
{$R+} => oder über die Projektoptionen und neuerdings auch via {$RANGECHECKS ON}



Und wegen dem "kompliziert":
Können sich auch ein paar Nachteile (Rechenfehler) ergeben, wenn man "Binäroperationen" (Auslesen der Bits für einen "Integer") über Fließkommazahlen und -Fließkommaperationen abwickelt (Extended), wo es diese gewünschten "Bits" so eigentlich nicht gibt.

[diavy]

Zitat:

Abgesehen davon, dass mir das unnötig kompliziert erscheint gegenüber einem Binärvergleich hast Du vergessen, das Array zu dimensionieren (SetLength).

Aber ich weiß doch nicht im Vorraus bis wohin der array geht oder? Die Größe ist doch abhängig von der eingegebenen Zahl?

Zitat:

Für sowas schadet es nie, wenn man mal die Bereichsprüfung aktiviert.
{$Q+} => oder über die Projektoptionen und neuerdings auch via {$OVERFLOWCHECKS ON}
Dann wäre das fehlende SetLength sofort aufgefallen.


Und wenn du so wild rumrechnest, dann eventuell auch noch die Überlaufprüfung.
{$R+} => oder über die Projektoptionen und neuerdings auch via {$RANGECHECKS ON}

Ich habe beides in den Afang des Codes eingefügt und ich bekomme trotzdem eine Fehlermeldung.

Zitat:

Und wegen dem "kompliziert":
Können sich auch ein paar Nachteile (Rechenfehler) ergeben, wenn man "Binäroperationen" (Auslesen der Bits für einen "Integer") über Fließkommazahlen und -Fließkommaperationen abwickelt (Extended), wo es diese gewünschten "Bits" so eigentlich nicht gibt.

Wenn ich number als integer eintrage erhalte ich: [Error] ex69.dpr(28): Incompatible types: 'Integer' and 'Extended'

[himitsu]

Es ist egal ob du vorher weißt wie lang es wird.
Spätestens wenn es benutzt werden soll, muß du die Größe anpassen, denn was es nicht gibt, das kann man nicht benutzen.
Notfalls eben mehrmals, wenn man es vorher nicht weiß.

Zitat:

und ich bekomme trotzdem eine Fehlermeldung.

Schön daß wir wissen welche.

Nja, dieses Kompilerschalter baut Prüfcodes ein, welche z.B. prüfen ob man auf "nichtvorhandenen" Array-Felder zugreifen will
und erzeugt dann Exception mit einer "ordentliche" Fehlermeldung.
Ohne diese Prüfung passiert sonstewas, wenn man nicht auf ein existierendes Feld zugreift. (z.B. ein Buffer Overrun)




Tja, Konsolenprogramme haben halt ein paar Nachteile. (die VCL initialisiert und benutzt ein paar nette Features, vorallem in Bezug auf die Fehlerbehandlung)

Bau mal Folgendes um deinen Code drumrum (zwischen "begin" und "end.").

Delphi-Quellcode:

try
  // hier dein Code
except
  on E: Exception do begin
    WriteLn('Error (', E.ClassName, ') : ', E.Message);
    ReadLn;
  end;
end;

(in "halbwegs" aktuellen Delphis ist sowas ähnliches schon direkt in der Vorlage für ein neues Konsolenprogram mit drin)

[diavy]

Zitat:

Es ist egal ob du vorher weißt wie lang es wird.
Spätestens wenn es benutzt werden soll, muß du die Größe anpassen, denn was es nicht gibt, das kann man nicht benutzen.
Notfalls eben mehrmals, wenn man es vorher nicht weiß.

Wie soll ich das verstehen spätestens die Größe anzupassen wenn man es benutzt? Kann ich eine variable mitten im Programm anders deklarieren?

Zitat:

Schön daß wir wissen welche.

Mir ist gerade aufgefallen dass nur bei manchen Eingaben die Fehlermeldung kommt(soweit ich das erkannt habe bei ungeraden Zahlen)(project raised exception class ERangeError with messade 'Range check error'. Process stopped. Use Step or Run to continue.). Bei geraden Zahlen bekomm ich ein Resultat, jedoch um eine Stelle falsch (12:01100 ;24:011000).

Zitat:

Delphi-Quellcode:

try
  // hier dein Code
except
  on E: Exception do begin
    WriteLn('Error (', E.ClassName, ') : ', E.Message);
    ReadLn;
  end;
end;

(in "halbwegs" aktuellen Delphis ist sowas ähnliches schon direkt in der Vorlage für ein neues Konsolenprogram mit drin)

Leider ist meine Delphi-Version nicht halbwegs aktuell. Ich kann dir leider nicht folgen was 'except' folgt, was ist das Ziel davon und was setzt es um?

[Amateurprofi]

Zitat von himitsu:

Und wegen dem "kompliziert":
Können sich auch ein paar Nachteile (Rechenfehler) ergeben, wenn man "Binäroperationen" (Auslesen der Bits für einen "Integer") über Fließkommazahlen und -Fließkommaperationen abwickelt (Extended), wo es diese gewünschten "Bits" so eigentlich nicht gibt.

Oh, doch, die gibt es.

[Furtbichler]

Zitat von Amateurprofi:

Zitat von himitsu:

wo es diese gewünschten "Bits" so eigentlich nicht gibt.

Oh, doch, die gibt es.

"So" gibt es sie "eigentlich" nicht.
Sie existieren nur in der Phantasie der floating Points, wobei sich die Funktion 'Power' Mühe gibt, ihre Phantasiebits für sich zu behalten.

Und wir müssen doch wohl nicht ernsthaft über floating point, Rundungsfehler etc. diskutieren, oder? Du weisst Doch genau, wie himitsu es meinte.

[Amateurprofi]

Zitat von Furtbichler:

Zitat von Amateurprofi:

Zitat von himitsu:

wo es diese gewünschten "Bits" so eigentlich nicht gibt.

Oh, doch, die gibt es.

"So" gibt es sie "eigentlich" nicht.
Sie existieren nur in der Phantasie der floating Points, wobei sich die Funktion 'Power' Mühe gibt, ihre Phantasiebits für sich zu behalten.

Und wir müssen doch wohl nicht ernsthaft über floating point, Rundungsfehler etc. diskutieren, oder? Du weisst Doch genau, wie himitsu es meinte.

Mag, sein, dass sie bei dir nur in der Phantasie existieren.
Bei mir ist ihre Existenz sehr real.
Wenn du dir mal die Mühe gemacht hättest den Code #12 anzusehen, dann wüßtest du, dass man auf die Bits eines Extendeds (wenn er im Bereich -2^64+1 bis 2^64-1 liegt) genau so einfach zugreifen läßt wie auf die eines Integers.
Wenn also jemand meint, beim Extended existieren diese Bits nur in der Phantasie, dann muss er eigentlich auch meinen, dass bei einem Integer die Bits nur in der Phantasie existieren.

Und zum "Und wir müssen doch wohl nicht ernsthaft über floating point, Rundungsfehler etc. diskutieren, oder?"
Ich habe mit keinem Wort Rundungsfehler angesprochen. Was soll also dieser Kommentar.

[Luckie]

Zitat von diavy:

Vorneweg, ich habe delphi 6, da war die math.pas nicht dabei.

Aber die dcu musst dabei sein und mehr brauchst du nicht.

Zitat:

da die Funktion n^i nicht funktionniert hat

"Funktioniert nicht" ist keine ausreichende Fehlerbeschreibung.