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

[Medium]

Zitat von messie:

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?

Die Frage kann ich zwar nicht beantworten, da aber eine Fülle von DBMS existieren, die über eine noch größere Menge von Treibern und Schichten angesprochen werden, die teilweise auch gerne mal aneinandergereiht werden, deren genauste Interna man alle kennen und berücksichtigen müsste, ist diese Frage auch nicht wirklich beantwortungswürdig:

- Runden im SQL macht man, wenn man im SQL selbst mit den Werten rechnen will

- Will man Werte gerundet darstellen, rundet man nur zum Zwecke der Darstellung ganz genau zum Zeitpunkt der Umwandlung in die Darstellung (üblicherweise einen String)

Welches Zahlenformat sich für eine Aufgabe am besten eigent, ist von obigem völlig losgelöst, und hängt nur vom Einsatzzweck ab, niemals von einer gewünschten Darstellung.