Fragensteller
Bug im SUM Befehl?

Frage
-
Moin!wir haben hier eine seltsame Sache.Wir ziehen mit Hilfe des Sum Befehls eine Summe über die Gesammtpreise von Positionen in einem Cursor.Wenn sich die Summe geändert hat, dann machen wir irgendwas.ungefähr so:SUM posgesamtpreis FOR NOT PosAlternativ AND NOT Posfreilogisch3 AND posfreitext1 = ' 45601' TO lnSummeif lnSumme <> KopfDatensatz.GesammtSumme* machwasendifDie Spalte posgesamtpreis hat das Format N(15,5).In unserem Problemfall ist es nun so, dass Im Kopf als Summe steht 9732,50000.Der Sum Befehl kommt auf 9732,5000000000Und dann lnSumme <> KopfDatensatz.GesammtSumme trifft das zu!Warum das denn nun bitte?und warum ermittelt der SUM Befehl in diesem Moment 10 Nachkommastellen?Mit anderen Daten funktioniert das, nur wenn es exact um diese Summe geht spinnt der Sum Befehl.Wir haben uns nun mit round(,5) abgeholfen, würde das aber gerne verstehen!Anny tip wanted!Grüße aus der sonnig kalten PfalzJörg Schneider
Jörg SchneiderDonnerstag, 6. Dezember 2012 10:00
Alle Antworten
-
Foxpro vergleicht ja nicht auf der Ebene von Dezimalzahlen, sondern auf Ebene seinrr internen Double Float Representation. Alle Zahlen (sogar Integer) wandelt FoxPro für Variablen oder auch Ausdrücke im Speicher in Double Float. Da können zwei Double Floats durchaus mal je nach Genauigkeit, dasselbe in grün in der Dezimalausgabe sein, sich aber trotzdem unterscheiden. Man muss dazu noch wissen, daß Foxpro neben dem Double in seinem C Struct für numerische Werte auch noch eine Genauigkeit mitspeichert.
Siehe http://www.foxpert.com/knowlbits_201102.htm
zweiter Abschnitt über "significant digits"
Der entscheidende Satz ist: "Visual FoxPro keeps track of the number of digits every floating value has. This is an extra piece of information that is not part of the numeric value itself"
Visual Foxpro merkt sich die Zahl von Dezimalstellen, die eine Fließkommazahl hat. Das ist eine Nebeninformation, die nicht Teil des Zahlenwertes selbst ist.
Dein Fall ist da zwar nicht so dargestellt, aber die Einstellung von DECIMALS und FIXED auf maximum sollten den vergleich nicht mehr hinken lassen.
Hier liegt auch der Grund, warum man vor CAST mittels 1.000*Sum(field) o.ä. Ausdrücken die Felddefinition in Stellen und Genauigkeit beeinflussen konnte und noch kann, obwohl es rein theoretisch keinen Unterschied zu Sum(field) macht. Ist eine Foxpro Spezialität, die bei bewußtem Gebrauch auch die Präzision von Rechnungen verbessern kann.
Es macht z.B. gerade bei Fließkommazahlen ein Unterschied einer Summe aus, ob Du unsortierte Zahlen aufaddierst oder aufsteigend von nahe 0 bis hin zu großen Zahlen, denn hat ein Float erst einmal einen gewissen Exponenten ändern sehr kleine Werte die Summe gar nicht mehr, während sie zuerst aufsumiert den Endbetrag durchaus noch leicht ändern können.
Tschüß, Olaf.
- Bearbeitet Olaf Doschke Donnerstag, 6. Dezember 2012 13:46
Donnerstag, 6. Dezember 2012 13:41 -
Danke Olafich hatte das schon mal gehört, aber konnte nix mehr darüber finden!Das erklärt das natürlich.Dann sind wir soweit zufrieden, da erklärbar ;)Danke und grüßeJörgAm 06.12.2012 14:41, schrieb Olaf Doschke:> Foxpro vergleicht ja nicht auf der Ebene von Dezimalzahlen, sondern auf Ebene seinrr internen Double Float Representation. Alle Zahlen (sogar Integer) wandelt FoxPro für Variablen oder auch Ausdrücke im Speicher in Double Float. Da können zwei Double Floats durchaus mal je nach Genauigkeit, dasselbe in grün in der Dezimalausgabe sein, sich aber trotzdem unterscheiden. Man muss dazu noch wissen, daß Foxpro neben dem Double in seinem C Struct für numerische Werte auch noch eine Genauigkeit mitspeichert.>>> zweiter Abschnitt über "significant digits">> Der entscheidende Satz ist: "Visual FoxPro keeps track of the number of digits every floating value has. This is an extra piece of information that is not part of the numeric value itself">> Visual Foxpro merkt sich die Zahl von Dezimalstellen, die eine Fließkommazahl hat. Das ist eine Nebeninformation, die nicht Teil des Zahlenwertes selbst ist.>> Dein Fall ist da zwar nicht so dargestellt, aber die Einstellung von DECIMALS und FIXED auf maximum sollten den vergleich nicht mehr hinken lassen.>> Hier liegt auch der Grund, warum man vor CAST mittels 1.000*Sum(field) o.ä. Ausdrücken die Felddefinition in Stellen und Genauigkeit beeinflussen konnte und noch kann, obwohl es rein theoretisch keinen Unterschied zu Sum(field) macht. Ist eine Foxpro Spezialität, die bei bewußtem Gebrauch auch die Präzision von Rechnungen verbessern kann.>> Es macht z.B. gerade bei Fließkommazahlen ein Unterschied einer Summe aus, ob Du unsortierte Zahlen aufaddierst oder aufsteigend von nahe 0 bis hin zu großen Zahlen, denn hat ein Float erst einmal einen gewissen Exponenten ändern sehr kleine Werte die Summe gar nicht mehr, während sie zuerst aufsumiert den Endbetrag durchaus noch leicht ändern können.>> Tschüß, Olaf.>>
Jörg SchneiderDonnerstag, 6. Dezember 2012 15:43