Round gibt unterschiedliche Nachkommastellen zurück

[Medium]

Wieder ein mal die Ungenauigkeit von Floats. Die DP ist voll davon

Ob du in der Query rundest oder nicht ist quasi egal: Zur Übergabe in dein Programm muss der Wert ja doch wieder in einen Float gepackt werden, wodurch die prinzipbedingte Ungenauigkeit wieder zuschlägt. Die einzig sinnvolle Stelle für die Rundung ist genau der Zeitpunkt der Darstellung, d.h. entweder DisplayFormat bei DataSets oder mittels FloatToStrF() oder Format() wenn du den String selber bauen möchtest.

[DanielJ]

Hallo,

0.3 ist eben in eime Float nich speicherbar.
Alternativ währe hier eventuell ein Festkommaformat angebracht - In Firebird z.B Numeric(18,4) und in Delphi z.B. Currency.

LG,
Daniel

[messie]

Moin,

Numeric ist eine gute Idee. Das erklärt mir zwar noch nicht, warum das Round doch das Rundungsgeraffel liefert aber für den Alltagsgebrauch ist das ok

Danke, Messie

[DanielJ]

Zitat von messie:

as erklärt mir zwar noch nicht, warum das Round doch das Rundungsgeraffel liefert aber für den Alltagsgebrauch ist das ok

Das Round liefert dir exakte 0.3, aber das Speichern in einem Float macht es wieder zu nichte. Wie gesagt, ein Float kann nicht jeden Wert exakt repräsentieren - das ist auch der Grund warum Delphi dir CompareValue und SameValue anbietet.
Willst du exakte Dezimalwerte, brauchst du ein Festkommaformat.

Wissenschafliche Abhandlung zu dem Thema Klick

Dies sollte man zumindest in Grundzügen verstehen, sonst verzapft man schnell einige Bugs!

[himitsu]

Bezüglich des Currency in Delphi ist die Erklärung auch ganz einfach.

Currency ist in Wirklichkeit ein Int64, bei welchem die understen 4 Dezinalstellen als Nachkommastellen angesehn werden ( i / 1000 ),
womit es innerhalb aller Dezimalstellen keine Rundungsfehler geben kann.

Darum nennt sich das auch Currency aka "Währung", weil gerade dort besser nicht falsch gerechnet werden sollte.

[DanielJ]

Zitat von himitsu:

Darum nennt sich das auch Currency aka "Währung", weil gerade dort besser nicht falsch gerechnet werden sollte.

Das ist auch nur Begrenzt richtig: Currency ist halt, wenn man mit dem Ergebnis noch weiterrechnen will, unglaublich ungenau. Das kann, gerade wenn´s um´s Geld geht, auch Fatal sein!
Man sollte sich also gut überlegen wo man welche Genauigkeit braucht.
Es hat einen Grund warum es beide Datentypen gibt.

[himitsu]

Wieso ungenau?

Es ist auf die definierten 4 Nachkommastellen zu 100% ganz genau.

[messie]

Zitat von DanielJ:

Das Round liefert dir exakte 0.3, aber das Speichern in einem Float macht es wieder zu nichte

Ich glaube, da ist der Weg zur nächsten Frage: wo stehen meine Daten aus dem View genau? Werden die irgendwo zwischengespeichert oder hortet meine Query nur einen Pointer auf das Ergebnis?
Und es sieht ja dann so aus, als würde das TCRDBgrid tatsächlich eine Kopie im Speicher einrichten, denn das hat ja die Nachkommastellen. Ich weiß nicht, was in Flamerobin verwendet wird, aber da habe ich den Effekt ja nicht.
Da ich ja recht neu im DB-Thema bin: wie wird das denn im Allgemeinen von den Komponenten gehandhabt? Werden die Queryergebnisse jeweils kopiert oder sind das Pointer/Verweise?

Danke, Messie

[ibp]

Zitat von himitsu:

Wieso ungenau?

Es ist auf die definierten 4 Nachkommastellen zu 100% ganz genau.

ich könnte mir vorstellen, dass bei der Finanzmathematik durchaus mehr stellen relevant sein könnten. Gerade für Banken mit tausenden Transaktionen könnte eine Beschränkung auf 4 NK-Stellen sehr schnell ein größerer Verlust bedeuten.

[DanielJ]

Zitat von himitsu:

Wieso ungenau?

du gibst dir im nächsten Satz die Antwort ja schon selber:

Zitat von himitsu:

Es ist auf die definierten 4 Nachkommastellen

die Genaugikeit bei z.b. € beträgt damit ein Hundertstel Cent.
Wenn ich Jezt Heizölhändler bin und sagen wir von meinem Großhändler Öl Kaufe für 0,63145 € / Liter.
Ich ordere also 100.000 Liter ... wieviel Kostet das dann?
63.145 € oder 63.140 €?
Wer zahlt meinem Großhändler die Fehlenden 5 €?
Du der du mir das Programm Programmiert hast?