Genauigkeit von String to Single Konvertierung

[Uwe Raabe]

Nein, Currency kennt nur 4 Nachkommastellen.

[Andreas13]

Es stellt sich die Frage, was für einen wichtiger ist: "Schnell" ein "bißchen falsches" Ergebnis zu bekommen, oder etwas langsamer ein Korrektes. Ich persönlich ziehe für meine numerischen Berechnungsroutinen immer den korrekten Weg vor und benutze durchweg die Multipräzisions-Arithmetik-Bibliotheken von Wolfgang Ehrhardt. Diese arbeiten intern mit zusammengesetzten, "sehr langen" Integer-Zahlen, wodurch die hohe Genauigkeit gewährleistet wird. Diese kostet allerdings oft viel Rechenzeit. Aber die heutigen Prozessoren merken das gar nicht…
Gruß, Andreas

[himitsu]

Ähnlich dem BCD, wo eine Ziffer in 4 Bit gespeichert ist, kann man auch gern mit Strings rechnen, also wo die Ziffern dann als Char jeweils 8 Byte belegen,
aber von der Mathematik dahinter gibt es praktisch keinen Unterschied.

https://www.delphipraxis.net/135492-...-math-lib.html
In Bezug auf die Speicherung von Dezimalzahlen gibt es da natürlich keine Probleme,
aber auch im 10er-System gibt es die selben Beschränkung, wie im 2er.

1 / 3 lässt sich nicht "genau" speichern, selbst wenn man hierfür eine Milliarde Dezimalstellen nach dem Komma verwendet. (2 GB)

0.333333333.................



Aber man könnte hier mit Exponenten arbeiten, wenn die Exponenten beliebig groß sind und man die Basis nicht auf Biegen und Brechen normieren muß, dann ließe sich praktisch alles Speichern.
Ebenfalls könnte man Bruchzahlen speichern, also direkt z.B. die 1 und die 3 von dem ⅓.

[Harry Stahl]

Zitat von Andreas13:

Es stellt sich die Frage, was für einen wichtiger ist: "Schnell" ein "bißchen falsches" Ergebnis zu bekommen, oder etwas langsamer ein Korrektes. Ich persönlich ziehe für meine numerischen Berechnungsroutinen immer den korrekten Weg vor und benutze durchweg die Multipräzisions-Arithmetik-Bibliotheken von Wolfgang Ehrhardt. Diese arbeiten intern mit zusammengesetzten, "sehr langen" Integer-Zahlen, wodurch die hohe Genauigkeit gewährleistet wird. Diese kostet allerdings oft viel Rechenzeit. Aber die heutigen Prozessoren merken das gar nicht…
Gruß, Andreas

Gibt es hier irgendwo eine fertige Funktionssammlung (frei oder käuflich) zu beziehen?
Brauch ich im Moment zwar nicht, aber falls mal doch, wär es gut zu wissen.... (Tante Google hat da nichts ausgespuckt)

[jaenicke]

Zitat von Harry Stahl:

Gibt es hier irgendwo eine fertige Funktionssammlung (frei oder käuflich) zu beziehen?
Brauch ich im Moment zwar nicht, aber falls mal doch, wär es gut zu wissen.... (Tante Google hat da nichts ausgespuckt)

Das liegt daran, dass der Autor leider verstorben ist und seine Webseite nicht mehr online ist.
Es gibt aber einen Snapshot von der Seite:
https://github.com/moe123/www.wolfgang-ehrhardt.de
Und dort auch die entsprechende Bibliothek:
https://github.com/moe123/www.wolfga...2018-11-27.zip

[jfheins]

Und es liegt auch daran, dass für geschätzt 99,999% aller Anwendungsfälle die normalen Gleitkommazahlen ausreichen (ggf. mit Rundung). Es macht einfach keinen Unterschied, ob die Linie genau 3 Pixel breit ist oder ob sie erst 3,00000015 pixel breit sein sollte und dann gerundet wird.

Was mir so als use case in den Sinn kommt ist typischerweise Finanzen, Kryptographie und Tschenrechner.

Soweit ich mich erinnere, haben die Leute sich bei WinXP ein bisschen über den Taschenrechner lustig gemacht, weil der eben auch solche Ungenauigkeiten hatte. Dann hat MS dem Taschenrechner in Win7 einen ordentliche, arbitrary precision Kern verpasst. Fast keiner hat's gemerkt oder gelobt (Aber inzwischen kann der TR auch sowas wie 1200000000000000000047 - 1200000000000000000000 rechnen)

[himitsu]

[deleted]

[Andreas13]

Zitat von himitsu:

Zitat:

typischerweise Finanzen, Kryptographie und Tschenrechner

in Bezug auf Finanzen reichen die Festkommatypen (ala Currency) meistens aus,
so lange Einem die hunderstel Cent (4 Nachkommastellen) und einige 100 Billion Euro ausreichen.

Das stimmt nicht ganz: Rundungsfehler durch die binäre Zahlenkodierung, die begrenzte Wortlänge des Prozessors etc. lauern auf uns fast überall. Hier habe ich ein anschauliches kaufmännisches Beispiel (= recht einfache Berechnungen) aus dem Buch: Muller + Brisebarre + de Dinechin et al.: Handbook of Floating-Point Arithmetic. Boston: Birkhäuser, 2010, (ISBN 978-0-8176-4 704-9) S. 10 - 11:

Das Angebot der "Chaotic Bank Society":
Sie zahlen zunächst e - 1 $ auf Ihr Konto ein, wobei e = 2. 7182818… ist die Basis der natürlichen Logarithmen. Im ersten Jahr nehmen wir 1 $ von Ihrem Konto als Bearbeitungsgebühren. Das zweite Jahr ist besser für Sie: Wir multiplizieren Ihr Kapital mit 2, und wir nehmen 1 $ Bearbeitungsgebühren von Ihrem Konto. Das dritte Jahr ist sogar noch besser: Wir vervielfachen Ihr Kapital durch 3, und wir nehmen immer nur noch 1 $ an Bearbeitungsgebühren. Und so weiter: Im n-ten Jahr wird Ihr Kapital mit n multipliziert, und wir nehmen nur 1 Dollar Gebühren. Interessant, nicht wahr?
Wie hoch wäre Ihr Kapital nach 25 Jahren?

Versucht mal obiges Angebot mit Single-, Double-, Currency- und Extended-Genauigkeit zu testen. Und dann können wir uns gemeinsam wundern.
Gruß, Andreas

[freimatz]

Zitat von jfheins:

Und es liegt auch daran, dass für geschätzt 99,999% aller Anwendungsfälle die normalen Gleitkommazahlen ausreichen (ggf. mit Rundung).
...
Was mir so als use case in den Sinn kommt ist typischerweise Finanzen, Kryptographie und Tschenrechner.

Und geschätzt 99,8% aller Anwendungsfälle benötigen gar keine Gleitkommazahlen. (Wenn nicht TDateTime als double definiert wäre )

Und wer bei Finanzen Fließkomma nimmt gehört virtuell ...

[Andreas13]

Zitat von freimatz:

Zitat von jfheins:

Und es liegt auch daran, dass für geschätzt 99,999% aller Anwendungsfälle die normalen Gleitkommazahlen ausreichen (ggf. mit Rundung).
...
Was mir so als use case in den Sinn kommt ist typischerweise Finanzen, Kryptographie und Tschenrechner.

Und geschätzt 99,8% aller Anwendungsfälle benötigen gar keine Gleitkommazahlen. (Wenn nicht TDateTime als double definiert wäre )

Und wer bei Finanzen Fließkomma nimmt gehört virtuell ...

Ja, aber es kommt wirklich darauf an, für welche Zielgruppe man programmiert. Aber in der Technik, der gesamten Industrie, Ingenieur- und Naturwissenschaften braucht man zuverlässige Fließkomma-Berechnungen.
Mir fällt dazu ein Zitat vom "The Father of Floating Point" Prof. Dr. William Kahan (University of California, Berkeley) ein, der bekanntlich der Hauptarchitekt der Standards IEEE 754, IEEE 854 und IEEE 754r für die binären Gleitkommazahlen ("floating-point") ist, nach welchen die meisten unserer heutigen Prozessoren arbeiten. Er schrieb bereits im Jahre 1998 in einem Workshop-Beitrag über Dr. James Gosling (= "Dr. Java"), den Entwickler der Programmiersprache Java:
We agree with James Gosling about some things like ...
...
"95% of the folks out there are completely clueless about floating-point."
(James Gosling, 28 Feb. 1998)
(Maybe more than 95% ?: 1 March 1998, W. Kahan)
...
Das ist schon 22 Jahre her. Vielleicht wären heutzutage 99 % treffender...
Andreas