Round gibt unterschiedliche Nachkommastellen zurück

[messie]

Moin,

ich habe einen View, in dem ich mit Round die Nachkommastellen für die Darstellung optimieren möchte.
Aber mir gibt z.B.

Code:

select Round(TABLE.OUTPUT,2) FROM TABLE

statt der erwarteten 0.30 im Flamerobin 0.300000 zurück. Im Programm stehen dann sogar 15 Nachkommastellen.

Beide rufe ich mit

Code:

select * from VIEW

auf.

Kann mir jemand erklären, wie das zusammen hängt?

Grüße, Messie

[Morphie]

Ist laut Doku doch genau so gewollt:
http://www.firebirdsql.org/refdocs/l...unc-round.html

Zitat:

ROUND(123.654, 1) returns 123.700 (not 123.7)
ROUND(8341.7, -3) returns 8000.0 (not 8000)
ROUND(45.1212, 0) returns 45.0000 (not 45)

Edit: du könntest uns noch verraten, was TABLE.OUTPUT für einen Wert hat

[Neutral General]

Ist es nicht total egal wie viele Nachkommastellen du hast wenn eh alle weiteren Stellen Nullen sind? 0,3 und 0,300000000000 sind der gleiche Wert. Und darstellen kannst du den Wert nachher ja wie du willst.

[messie]

Zitat:

Zitat von Neutral General (Beitrag 1192002)

Ist es nicht total egal wie viele Nachkommastellen du hast wenn eh alle weiteren Stellen Nullen sind? 0,3 und 0,300000000000 sind der gleiche Wert. Und darstellen kannst du den Wert nachher ja wie du willst.

Ja, aber ich bekomme 0,300000011920929 :pale:

Für die Darstellung: gibt es so etwas wie ein FormatFloat?

Grüße, Messie

[p80286]

Zitat:

Zitat von messie (Beitrag 1191998)

statt der erwarteten 0.30 im Flamerobin 0.300000 zurück. Im Programm stehen dann sogar 15 Nachkommastellen.

?Ja und?

Interessant wird das doch erst, wenn Du diesen Wert darstellen willst, und da gibt es Format.

Zitat:

Zitat von messie (Beitrag 1191998)

Ja, aber ich bekomme 0,300000011920929

Und dann nochmal gefragt, was ist der Ausgangswert?


Gruß
K-H

[messie]

Zitat:

Zitat von p80286 (Beitrag 1192006)

Interessant wird das doch erst, wenn Du diesen Wert darstellen willst, und da gibt es Format.

Ich habe gelesen, dass es das nicht mehr gibt. Wo müsste ich denn suchen?

Ausgangswert ist 0.3 gewesen (gelesen als String '0.3' aus einer Datei).

Grüße, Messie

[p80286]

Zitat:

Zitat von messie (Beitrag 1192008)

Zitat:

Zitat von p80286 (Beitrag 1192006)

Interessant wird das doch erst, wenn Du diesen Wert darstellen willst, und da gibt es Format.

Ich habe gelesen, dass es das nicht mehr gibt. Wo müsste ich denn suchen?

Äh in Delphi?

Zitat:

Zitat von messie (Beitrag 1192008)

Ausgangswert ist 0.3 gewesen (gelesen als String '0.3' aus einer Datei).

die Frage ist, was ist der Inhalt von Table.Output und was ist der Typ?

Gruß
K-H

[user0815]

Delphi-Quellcode:

procedure TDatenmodul.QueryAfterOpen(DataSet: TDataSet);
begin
  (DataSet.FieldByName('FELD') as TFloatField).DisplayFormat := '0.00';
end;

[messie]

Table.Output ist ein Float.

Ich habe (in anderen Programmen) öfter mit Iterationen zu tun und da bin ich schon häufiger über das Nachkommastellengeraffel gestolpert. Deshalb würde ich es gerne exakt gerundet in die DB einlesen.

Im Moment ist die Datenmenge direkt an ein TCRDBGrid angebunden, da ist kein Delphi zwischen. Ob es in dem Grid selbst Formatstrings gibt? Oder ist die 0815-Lösung (:-D) die einzige?

Grüße, Messie

[p80286]

Schade da kann ich Dir nicht weiter helfen, aber angeblich wird der Source Code mitgeliefert, vielleicht wirst Du da fündig.

Gruß
k-H

[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 :thumb:

Danke, Messie

[DanielJ]

Zitat:

Zitat von messie (Beitrag 1192211)

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

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:

Zitat von himitsu (Beitrag 1192223)

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:

Zitat von DanielJ (Beitrag 1192220)

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:

Zitat von himitsu (Beitrag 1192233)

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:

Zitat von himitsu (Beitrag 1192233)

Wieso ungenau?

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

Zitat:

Zitat von himitsu (Beitrag 1192233)

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?

[p80286]

Na dann arbeite ich eben mit 6 Nachkommastellen, oder dem BCD-Format.
Wenn ich mich richtig erinnere, konnte Cobol vor 40 Jahren schon mit 8 Nachkommastellen umgehen.
Man braucht eben für jede Arbeit das richtige Werkzeug.

Gruß
K-H

[BUG]

Zitat:

Zitat von DanielJ (Beitrag 1192251)

Wer zahlt meinem Großhändler die Fehlenden 5 €?
Du der du mir das Programm Programmiert hast?

Wenn es solche Anforderungen gibt, muss man das vorher wissen.

Man sollte die Lösung halt nach Problem auswählen:

• Gleitkommazahlen (Abstand der darstellbaren Zahlen ist abhängig von Absolutbetrag)
• Fixkommazahlen (Abstand der darstellbaren Zahlen über ganzen Wertebereich gleich)
• Bruchrechnung (mit beliebiger Genauigkeit für Addition/Subtraktion/Multiplikation/Division)
• Symbolisches Rechnen (mit beliebiger Genauigkeit)

Fixkommazahlen neigen halt nicht so zur Instabilität wie Gleitkommazahlen (zB. keine Auslöschung + Assoziativität) und man kann die Genauigkeit besser abschätzen.
Trotzdem kann man relativ schnell mit ihnen Rechnen. Für Standardaufgaben ist das wohl einfach der beste Kompromiss.

Ich könnte mir auch vorstellen, dass Rechnen mit rationalen Zahlen / Brüchen (mit beliebig großem Zähler/Nenner) viele Sonderfälle abdecken wird, wenn man nur Buchhaltung macht.

Zitat:

Zitat von ibp (Beitrag 1192249)

Gerade für Banken mit tausenden Transaktionen könnte eine Beschränkung auf 4 NK-Stellen sehr schnell ein größerer Verlust bedeuten.

Ich würde meinen, Banken führen nur Transaktionen mit vorgegebener Genauigkeit aus.
Wie im Zweifelsfall (zB. beim Zins oder bei Transaktionsgebühren) gerundet wird, ist sehr wahrscheinlich genau in Verträgen festgehalten.

[Medium]

Zitat:

Zitat von messie (Beitrag 1192247)

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.

[Sir Rufo]

Zitat:

Zitat von DanielJ (Beitrag 1192251)

Zitat:

Zitat von himitsu (Beitrag 1192233)

Wieso ungenau?

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

Zitat:

Zitat von himitsu (Beitrag 1192233)

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?

Und wenn ich 100 Liter kaufe, dann steht auf der Rechnung 63,145€?
Wie soll ich das bezahlen, oder wie soll der das rausgeben? Indem er einen Cent durchschneidet?

Irgendwann muss gerundet werden, spätestens beim Berechnen des Rechnungsbetrages, denn dort können nur ganze Cent stehen.
Zudem gibt es fast jede WaWi her mengenabhängige Preise zu hinterlegen (und die sind idR bei größeren Mengen günstiger). Bei deinem Beispiel wären es dann z.B. 631,45€/100l und schon sind wieder alle glücklich.

[Furtbichler]

Das Problem des Rundens tritt naturgegebenermaßen auch in der Finanzwelt auf. Es werden Zinsen, Steuern erhoben, Rabatte gewährt und in andere Währungen umgerechnet.

Da man nicht mit unendlich vielen Stellen rechnen kann, muss also gerundet werden. Wird nur aufgerundet, stimmt die Balance nicht. Wird nur abgerundet auch nicht. Also wurde das bankers rounding erfunden, das mal ab- und mal aufrundet (50:50). Unterm Strich gleicht sich das aus.

Die vier Stellen in der Finanzwelt sind meines erachtens nach dazu da, um bei mathematischen Umrechnungen im 1. oder 2. Schritt das Bankersrounding hinter den Kulissen, also in 4. Stelle ablaufen zu lassen.

Das Finanzamt gibt im Übrigen bei der Berechnung des Bruttobetrages genaue Vorgaben. Auch lustig: Bei 1/10tel Cent sind sie pingelig, aber wenn es um Steuerbetrug in Milliardenhöhe geht, schauen sie nicht so genau hin und würden sich mit einer Flatrate begnügen.

[DanielJ]

Zitat:

Zitat von Sir Rufo (Beitrag 1192285)

Und wenn ich 100 Liter kaufe, dann steht auf der Rechnung 63,145€?
Wie soll ich das bezahlen, oder wie soll der das rausgeben? Indem er einen Cent durchschneidet?

Irgendwann muss gerundet werden, spätestens beim Berechnen des Rechnungsbetrages, denn dort können nur ganze Cent stehen.

Du hast wohl noch nie getankt was?

Klar, wird am ende gerundet, dann kannst du aber auch nur max einen halben Cent verlieren oder gewinnen.
Das war auch nur eine Beispiel da himitsu mein Aussage das die Genauigkeit (von 1/10.000) schnell zu gering wird scheinbar vorher nicht verstanden hatte.
Rechnet man selbiges Beispiel mit einem Double hat man kein relevantes Genauigkeitsproblem!