Single -> Extended

[Gruber_Hans_12345]

Blöde frage wie weise ich eine Float Zahl am einfachsten in eine Extended zu, aber ich möchte gerne die zusätzliche Genauigkeit die ich dadurch erhalte mit 0 er füllen.

Delphi-Quellcode:

procedure test;

    function ShowExtended(value : extended) : string;
    begin
        Result  := FloatToStrF(value, ffGeneral, 18, 0);
    end;

var
    myFloat     : Single;
    myExtended  : Extended;
begin
    myFloat     := 12.4;
    myExtended  := myFloat;

    showmessage(FloatToStr(myFloat)+' ... '+ShowExtended(myExtended));

    myExtended  := 12.4;
    showmessage(FloatToStr(myFloat)+' ... '+ShowExtended(myExtended));
end;

Ausgabe1:

Zitat:

12,3999996185303 ... 12,3999996185302734

Ausgabe2:

Zitat:

12,3999996185303 ... 12,4

[jaenicke]

Das Problem ist, dass Zahlen intern nicht im Dezimalsystem gespeichert werden. Deshalb funktioniert dein Gedankengang leider nicht, denn im Binärsystem sind die Nachkomma-Nullen eben keine Nullen, sondern die Zahl wird im Binärsystem so weit angenähert dargestellt wie eben möglich. Vielleicht wäre eine direkte Konversion der Zahl als Dezimalstring in Extended noch ein wenig näher dran, aber trotzdem gibt es weiter hinten bei den meisten Dezimalzahlen immer noch Abweichungen.

Sinnvoller wäre übrigens Double statt Extended, denn Extended gibt es z.B. im 64-Bit Kompiler nicht mehr in der Form, so dass man besser gleich bei Double bleibt oder bei echtem Bedarf spezielle Bibliotheken mit höherer Genauigkeit verwendet.

Die interne binäre Darstellung und die daraus resultierende Ungenauigkeit muss man beim Handling natürlich beachten, aber dann gibt es normalerweise auch keine Probleme damit. Für höhere Genauigkeit gibt es wie eben geschrieben spezielle Bibliotheken.

[Andreas13]

Hallo Hans,
wie Sebastian bereits geschrieben hat, gibt es wegen der binären Kodierung bei allen RealTypen unvermeidbare Rundungsfehler. Das liegt in der Natur der Sache, denn es gibt unendlich viele Reelle Zahlen, die wir mittels Single, Real48, Double oder Extended auf eine endliche Menge binärer Darstellungen mit endlichen Ziffern abbilden.
Selbst die Dezimalzahl 0,1 läßt sich binär nicht exakt darstellen, wodurch bereits bei der Eingabe ein Rundungsfehler entsteht.

Dein Vorhaben läßt sich daher leider nicht realisieren. Wenn es Dir lediglich um die Anzeige der Ergebnisse mittels ShowMessage(..) geht, dann hilft nur das "Verstecken" der falschen Ziffern durch Runden der Zahlen bzw. der Anzeige...

Wenn Du ausschließlich für Windows programmierst und ein 32-Bit-Kompilat verwenden wills, würde ich Dir allerdings Extended empfehlen, nicht Double: Damit hast Du einen wesentlich größeren Zahlenbereich, 3..4 Stellen mehr und damit weniger Rundungsfehler als bei Double.

Grüße, Andreas

[himitsu]

Wenn es ganz genau sein soll, dann Currency oder BCD.

Oder eben bei/nach dem Convertieren und sowieso beim Verwenden entsprechend der maximal nötigen Nachkommastellen runden.

[Andreas13]

Zitat von himitsu:

Wenn es ganz genau sein soll, dann Currency oder BCD ...

Sorry, aber das ist nur bei Addition und / oder Subtraktion exakt. Nicht bei Multiplikation, schon gar nicht beim Dividieren und überhaupt nicht bei transzendenten Funktionen wie exp(x), Ln(x), sin(x) etc.
Grüße, Andreas

[TurboMagic]

Dieser Artikel könnte dem einen oder anderen evtl. beim Verständnis von Fließkommazahlen helfen:
http://rvelthuis.de/articles/articles-floats.html

[Redeemer]

Das ist jetzt so 'ne Frage wie: „Ich habe meine JPEGs letztens mit 0% Qualität gespeichert. Jetzt hab ich die dabei erstellten Dateien mit 100% Qualität erneut gespeichert und sie sehen trotzdem noch scheiße aus.“

Informationen, die einmal verloren gegangen sind, können nicht wiederhergestellt werden, selbst wenn genug Platz dafür wäre.

[Dennis07]

Im Grunde kannst du das schon machen (mithilfe eines Rundungskoeffizienten, auch "Epsilon" genannt).
Das führt allerdings dazu, dass dein Extended intern weiterhin als Single gerundet wird, was sicher auch nicht das ist, was du willst.
Es gibt nur einen Weg, keine Rundungsfehler bei Gleitkomma zu haben. Und das ist, einfach kein Gleitkomma zu benutzen. Ggf reicht ja ein Currency-Wert aus?

[Frickler]

Zitat von Andreas13:

Zitat von himitsu:

Wenn es ganz genau sein soll, dann Currency oder BCD ...

Sorry, aber das ist nur bei Addition und / oder Subtraktion exakt. Nicht bei Multiplikation, schon gar nicht beim Dividieren und überhaupt nicht bei transzendenten Funktionen wie exp(x), Ln(x), sin(x) etc.
Grüße, Andreas

Kommt auf die Operanden an: 1/4 ist bei BCD genau 0,25. Currency hat nur 4 Nachkommastellen, da kann es schon eng werden, aber BCD hat prinzipiell keine Längenbeschränkung.

[Dennis07]

Zitat von Frickler:

Kommt auf die Operanden an: 1/4 ist bei BCD genau 0,25. Currency hat nur 4 Nachkommastellen, da kann es schon eng werden, aber BCD hat prinzipiell keine Längenbeschränkung.

Jo, ist halt nur (um ein vielfaches) langsamer. Ansonsten kann man das schon mal benutzen. Wenn du aber ausgehend einen Float/Extended-Wert hast, dann bringt dir das natürlich auch nicht viel; runden musst du dann trotzdem.