Hallo Leute, ich habe eine Frage bezüglich der Konversion von binären Floating-Point-Zahlen in Dezimalzahlen. Das Schema ist mir klar, es existiert ein VZ-Bit, dann folgt der Exponent, der um den Biaswert noch verschobene werden muss. Die Mantisse gibt die Nachkommastellen an, wobei durch die Normierung noch +1 addiert werden muss. Multipliziert mit 2^exponent erhalte ich die Dezimalzahl. So weit so gut. Allerdings habe ich Schwierigkeiten diese normierte Darstellung mit den allgemeineren Formeln in der Literatur in Einklang zu bringen. Bspw. heißt es in "Accuracy and Stability of Numerical Algorithms", dass eine FP-Zahl folgendermaßen darstellbar ist: y = m * ß^(e-t), wobei m die ganzzahlige Mantisse, e der Exponent und t die Anzahl signifikanter Stellen in der Mantisse ist. Für die Mantisse gilt ß^(t-1) <= m <= ß^t - 1, damit das System normiert ist. Ich schaff es jedoch nicht, den korrekten Dezimalwert mit dieser Formel zu berechnen. Beispiel: 4 Bit Exponent, 10 Bit Mantisse (VZ ist hier weggelassen): 0xD6BC 1.) herkömmliche Konversion * Der Exponent ist 0xD = 13, abzgl. Biaswert (2^(4-1)-1=7) ergibt 6 * Mantisse ist 0110101111 (die weiteren Nullen habe ich weggelassen), entnormiert lautet sie 1.0110101111 = 1 + 2^-2 + 2^-3 + ... = 1.4208984375 * Das Endergebnis ist dann 1.4208984375 * 2^6 = 90.9375 und das ist korrekt 2.) Konversion mit der Formel * Exponent bleibt gleich, e = 6 * Mantisse: 10 Bit werden gespeichert, 11 Bit besitzt die "reale" Mantisse, die führende 1 wurde weggelassen und ist quasi implizit gespeichert. Also gilt real 0110101111 => 10110101111 = 1455 im Dezimalsystem, das passt zu den oben genannten Grenzen für das normierte System * y = 1455 * 2^(6-11) = 1455 * 2^(-5) = 45.46875, also genau die Hälfte des obigen Ergebnisses Was übersehe ich dabei?
Andi schrieb: > Was übersehe ich dabei? Wikipdia https://de.wikipedia.org/wiki/Gleitkommazahl https://en.wikipedia.org/wiki/Floating-point_arithmetic
Andi schrieb: > Was übersehe ich dabei? Da kann man auch das Heronsche Verfahren nehmen, meine Ich mich zu erinnern.
Falls Du auf die vereinfachte Konversion anspielst, die in den 80ern in den Computer-Spielen entwickelt wurde: Dabei handelt es sich konkret um einen Wurzel-Algorithmus / Logarithmus und es war die Sonderform des Heron, nämlich der Newton. Stichwort Schätziteration. CORDIC geht genau so.
Andi schrieb: > ich habe eine Frage bezüglich der Konversion von binären > Floating-Point-Zahlen in Dezimalzahlen. Das Schema ist mir klar, es > existiert ein VZ-Bit, dann folgt der Exponent, der um den Biaswert noch > verschobene werden muss. Die Mantisse gibt die Nachkommastellen an, > wobei durch die Normierung noch +1 addiert werden muss. Multipliziert > mit 2^exponent erhalte ich die Dezimalzahl. Na, so ganz klar ist dir das wohl doch noch nicht. Also: Eine GK-Zahl muß folgendes enthalten: 1. die Mantisse als Betrag 2. ein Vorzeichen 3. den Exponenten (zur Zahl 2) An welcher Stelle was in der GK-Zahl steht, ist relativ egal, ebenso die Wertigkeiten der Mantissenbits. Es gibt zwar ISO-Normen dazu, aber die berühren das grundlegende Prinzip nicht. Zum Prinzip: a) die Mantisse Diese ist im Grunde eine gebrochene aber normierte Zahl, also deren MSB habe zum Beispiel den Wert 0.5, das nächste dann 0.25, dann 0.125 und so weiter bis zum LSB. Die Mantisse ist normiert, das heißt, sie wird IMMER so groß gemacht, daß das MSB eben (in diesem Beispiel) 0.5 groß ist. Damit kann man dann Zahlen von 0.5 bis 0.9999997 oder so darstellen. Auffällig ist, daß das MSB bei all diesen Zahlen IMMER gesetzt ist. Man kann es daher beim Speichern auch weglassen und stattdessen an dieser Stelle das Vorzeichen speichern. Nach ISO wird das etwas anders gemacht, da wird der Exponent um 1 Bit rechtsverschoben, sein LSB kommt an die Stelle des MSB dr Mantisse und die freie Stelle wo zuvor das MSB des Exponenten war, dient zum Speichern des Vorzeichens. Das Rechenwerk, was mit GK-Zahlen dann tatsächlich rechtet, muß das alles natürlich auseinanderfuddeln und das weggelassene MSB der Mantisse von sich aus wieder dazusetzen. b) der Exponent Der sollte ja von -127 bis +127 gehen, aber das ist unschön, da mit Vorzeichen behaftet. Also addiert man 127 und speichert dieses in der GK-Zahl. Auch hier muß das Rechenwerk diesen Offset kennen und berücksichtigen. c) die gesamte Zahl die ist eben Mantisse * 2^(Exponent-127) groß. Je nach Implementation kann sich das um 1..2 Zweierpotenzen unterscheiden: zum einen trifft man für den Exponenten auch 128 an, zum anderen trifft man für das MSB der Mantisse auch 1 anstelle 0.5 an. Für die ganze Rechnerei innerhalb der GK-Welt ist das belanglos. Nur wenn man eine Integer-Zahl nach GK oder umgekehrt konvertieren will, wird das aktuell. Aber das ändert die Algorithmen nur um 1 in den nötigen Schiebeoperationen. W.S.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.