Feld enthält falschen Wert

[bwolf]

Hi,

ich habs folgendes Problem:

Ich weise einer TQuery einen Wert zu:

Code:

qQuery.FieldByName('Feld').AsFloat := (Wert1 + Wert2 - Wert3); //

Die Variablen Wert1 Wert2 und Wert3 sind alle vom Typ Double und haben laut Debugger die Werte 3,9, 0 und 4.
Nach der Zuweisung enthält qQuery.FieldByName('Feld') den Wert -0.1.
Nach dem Post allerdings steht in der Datenbank Der Wert -0,0999999999999996

Was ich festgestellt habe:
Die Variable Wert1 bekommt ihren Wert aus der Datenbank zugewiesen:

Code:

Wert1 := Query.FieldByName('Feld').asFloat

Der zugewiesen Wert aus der Datenbank ist tatsächlich 3.9 (zeigt mit zumindest die Datenbank an)

Wenn ich den Wert von Variable Wert1 im Code auf 3.9 setze, dann funktioniert stimmt alles:

Code:

Wert1 := 3.9;
qQuery.FieldByName('Feld').AsFloat := (Wert1 + Wert2 - Wert3);

Ich stehe da grad ziemlich auf dem schlauch, irgendjemand zeigt mir hier doch falsche Werte an :?
Hat jemand eine Idee?

danke euch!

[DeddyH]

Das sind doch ganz normale Rundungsungenauigkeiten im Zusammenhang mit Fließkommazahlen. Wenn Du es genauer brauchst, käme evtl. eine Änderung des Feldtyps in Currency in Betracht?

[mkinzler]

Fließkommazahlen haben implementationsbedingt eine Ungenauigkeit. Um dies zu vermeiden, schreibe am Besten auf x Stelle gerundete Werte in die DB.

Btw. der Cast mit .asFloat ist unnötig. Nimm besser .Value

[bwolf]

Hi und danke für die schnellen Antworten.
Ich frage mich trotzdem warum der Debugger mit nicht die exakten Werte anzeigt? Das ist ziemlich verwirrend wenn man es nicht weiß... :oops:

[mkinzler]

Der Debugger rundet. Ich kenne mich mit ADS nicht so aus. In anderen DBMS gibt es neben Float noch NUMERIC/DECIMAL. Hier kann man die Anzahl der relevanten Stellen festlegen

[bwolf]

Ah ok gut zu wissen...
Ja der ADS bietet auch den Datentyp numeric bei dem die Stellen festgelegt weren können.

Das Feld war fälschlicher Weise als Double angelegt was natürlich falsch war, das wird nun geändert.

Thx!

[himitsu]

Der Debugger nutzt sowas wie FloatToStr für die Anzeige und das nicht mit der maximalen möglichen Anzahl an signifikanten Stellen.
Man dachte sich wohl "lieber etwas gerundet, aber dafür leichter zu lesen".

PS: Darum gibt es Typen wie Currency und in DBs Felder mit festen Nachkommastellen, um die Rundungsprobleme zu minimieren/abzuschaffen.

[bwolf]

So ich muß nun doch nochmal blöd nachfragen:

In der Datenbank stehen ja definitiv die Werte 3,9, 0 , 4 die ich den Variablen in Delphi zuweise.
Wie kann es dann sein das bei der Berechunung (Wert1 + Wert2 - Wert3) dann -0,0999999999999996 und nicht -0.1 rauskommt?

[jobo]

Wer berechnet das denn?
Dein Code oben hat mit DB nichts zu tun, die Rechnung macht der Client. Und hier greifen dann Effekte, die ja schon angedeutet wurden, eben Fließkommaarithmetik. Die Typen zu ändern wurde ja bereits vorgeschlagen.

Hast Du das Problem auch, wenn Du es mit einem Update Statement in einer SQL Console durchführst? Wenn nicht, dann führ doch die Op auf dem Server aus.

[Luckie]

Hier ist die Erklärung: http://www.michael-puff.de/Programmi...esskomma.shtml

[bwolf]

Super vielen Dank!

[sx2008]

Zitat:

Zitat von mkinzler (Beitrag 1162460)

In anderen DBMS gibt es neben Float noch NUMERIC/DECIMAL. Hier kann man die Anzahl der relevanten Stellen festlegen

Das Problem ist nur, dass es in Delphi keinen dazu passenden Datentyp gibt.
"Currency" (64Bit) hat genau 4 Nachkommastellen.
Leider gibt es keinen "Decimal"-Datentyp mit 128Bit wie z.B. in dot-Net.

Eine Kunde von uns handelt mit Elektronikbauteilen.
Nun ist ein einzelner SMD Widerstand so billig, dass 5 Nachkommastellen benötigt werden.
Tja, geht halt nicht; Double bzw. Extended machen Rundungsfehler und Currency reicht nicht aus.
Hier sollte Embacadero unbedingt mit den Mitbewerbern gleichziehen.

[himitsu]

Currency ist ein nativer Typ in der FPU, so wie Single, Double und teilweise auch Extended.
Darauf hatte Borland/Codegear/Embarcadero keinen Einfluß.
Und die 64 Bit entsprechen auch der Auflösung (signifikante Stellen) des Extended, welches in der FPU die größte Auflösung darstellt.

Was da die 64-Bit-CPU oder sowas wie MMX bieten, weiß ich allerdings nicht genau.

[mkinzler]

Zitat:

Das Problem ist nur, dass es in Delphi keinen dazu passenden Datentyp gibt.

Das ist hier auch irrelevant. Es ging ja auch um den Typ des Datenbankfeldes

[Iwo Asnet]

Zitat:

Zitat von mkinzler (Beitrag 1162612)

Zitat:

Das Problem ist nur, dass es in Delphi keinen dazu passenden Datentyp gibt.

Das ist hier auch irrelevant. Es ging ja auch um den Typ des Datenbankfeldes

Bedingt, denn wie bekommt man die vom Feld gebotene Genauigkeit mit Delphi hinein? Soll man dann zu den Sprachen wechseln, die BCD o.ä. können?

[mkinzler]

Das Problem liegt an der Ungenauigkeit der Fliesskommazahlen. In seinem Fall würde sein Problem so vermieden.

[himitsu]

Mir ist so, als wenn ich im Delphi mal einen BCD-Typen gesehen hätte, aber bei seinem kleinen Wert absolut unnötig. (da würde sogar Single reichen)

[BoolString]

Klassiker auf dem Gebiet der Gleitkomma-Arithmetik sind die Arbeiten von Goldberg, Monniaux und die eigentliche Spezifikation IEEE 754.

Alle findet man relativ häufig frei im Netz. Z.B.:

Goldberg, What every computer scientist should know about floating point arithmetic.
Monniaux, The pitfalls of verifying floating point computations.
IEEE754 in der deutschsprachigen Wikipedia.

Ich kenn mich mit Datenbanken nicht so aus, aber entsprechende Ungenauigkeiten kommen oftmals zustande, wenn Variablen unterschiedlichen Typs miteinander verrechnet werden, Zwischenergebnisse in anderen Variablen gespeichert werden, etc.

Jan