if-Abfrage mit Extended - Trotz gleichheit False

[himitsu]

CompareValue wurde doch schon genannt.
Da gibt es einen zweiten Parameter, wo man die maximal erlaubte Differenz einstellen kann.
Und nun rate man, was man dort angeben muß, wenn man 5 Nachkommastellen vergleichen will.

'ne Zahl mit mindestens 5 Nullen nach dem Komma.

[Captnemo]

Das mit CompareValue habe ich auch verwendet, und das liefert mir jetzt genau, dass was ich haben wollte.
Letztlich hätte ich auch

if (Trunc(wert1*100)=Trunc(wert2*100)) then ...

machen können, wäre auf's gleich rausgekommen. (Welche Veriante jetzt mehr Rechenzeit beansprucht sei mal dahingestellt).

In meinem Fall ist es so, dass keiner der beiden zu vergleichenden Werten berechnet ist.

Der erste Wert wurde aus einer Textdatei gelesen und in Extended umgewandelt, also explizit mit 2 Nachkommastellen zugeweisen. Dann eine einem Float-Feld einer DB gespeichert.
Danach wird er wieder gelesen.
Der zweite Wert wird auch aus der gleichen Textdatei gelesen, und mit dem aus der DB zurückgelesenen verglichen.

Also wurde, nach meinem Empfinden keiner der beiden Werte "berechnet" bzw. mittels Rechneroperationen bearbeitet. Es sei denn der Transport durch die ADO-Komponenten beinhaltet irgendwelche Rechenoperationen, dass weiß ich natürlich nicht.

Also stellt sich mir die Frage, ob eine Zuweisung ala

Delphi-Quellcode:

var
  wert: Extended;
  s: String;
begin
  s:='-29.90';
  wert:=StrToFloat(s)

auch evtl. abweichende Nachkommastellen hinterläßt.

[Sir Rufo]

Entschuldige, aber diese Fragestellung ist doch wohl Unfug.

Das Problem kommt doch von einer anderen Stelle. Du hast 2 Systeme im Einsatz von wo du die Daten bekommst.

Um dieses Phänomen wirklich zu untersuchen, solltest du Die Zahl von String in ein Extended und dann in die Datenbank schreiben. Dann aus der Datenbank wieder auslesen und mit dem Wert wieder vergleichen.

Auch wenn es hier jetzt zu einer Gleichheit kommt, kannst du dich aber niemals darauf verlassen, weil du nicht wissen kannst, wie der Wert in die Datenbank gekommen ist (direkte Zuweisung oder durch eine Berechnung oder woher auch immer).

Zudem sollte dieses Problem bei Fließkommazahlen bekannt sein. Und wenn man mal genau darüber nachdenkt, dann kommt man auch darauf, dass man ja nur endlich Informationen zu einem Wert speichern kann, es aber ganz prominent die Zahl PI gibt, die aus einer unendlichen Folge von Nachkommastellen besteht. Wie soll man also etwas unendliches in einem endlichen System speichern können ohne eben so eine Annäherung zu benutzen? Es kommt eben auf die Genauigkeit an, die ich benötige und diese bestimmt, welche Ungenauigkeit ich verkraften kann.

[jfheins]

Zitat von Captnemo:

Also stellt sich mir die Frage, ob eine Zuweisung ala
...
auch evtl. abweichende Nachkommastellen hinterläßt.

Ganz klar ja. Denn die 0.9 lassen sich nicht exakt als Zweierpotenz schreiben.
Der Computer macht daraus bei der Umwandlung sowas wie

Code:

29.9  =  11101.111001100110011

Und das ergibt jetzt 0.9001464844 im Dezimalsystem. Mit mehr Stellen wird es noch genauer, aber es deutet sich bereits an dass der Nachkommaanteil periodisch ist und somit durch eine endliche Anzahl an Bits nur angenähert werden kann

[Furtbichler]

Vielleicht noch eine Anmerkung zu dem Thema: Früher wurde in Computersystemen anstatt mit Floating Point mit BCD-Arithmetik gerechnet. Dabei wird jede Ziffer durch 4 Bits dargestellt. Das führt dazu, das man 0.9 exakt so darstellen kann, und PI eben nicht. Irgendwie einfach zu verstehen, das Ganze: Genau aufschreibbar = Genau gespeichert.

Das ist bei Floating Point nicht der Fall, aber dafür kann man mit FP viel viel schneller rechnen. Ich persönlich habe ca. 10 Jahre meiner Programmiertätigkeit ausschließlich mit BCD gearbeitet und empfinde daher die unnatürliche Problematik "1.1 <> 1.1" als dem 21. Jahrhundert nicht würdig. Mit BCD wäre man in der Lage, viel genauer zu rechnen, da es die Rundungsfehler durch falsche interne Darstellung nicht gibt. Natürlich gibt es Rundungsfehler durch Rechnerei, aber das ist ein anderes Thema.

Aber letztendlich ist diese Problematik so mit der einzige Nachteil von FP ggü BCD mit vergleichbarer Genauigkeit, soweit ich informiert bin.

[Medium]

Die Vorteile von Floats der direkten Vergleichbarkeit zu opfern wäre glaube ich auch nicht der goldene Weg. Was Floats gerade so nett macht ist, dass man einen irren Wertebereich damit abdecken kann, da es nur eine Anzahl signifikanter Stellen gibt - es ist aber egal wo dabei das Komma sitzt. Dass dabei dann non-uniforme Lücken zwischen den einzelnen Werten entstehen, deren Werte man folglich auch nicht genau darstellen kann, ist eine Notwendigkeit dabei. Sowas muss ich als Informatiker einfach lernen, der Maurer weiss ja auch um die richtigen Einsatzgebiete von Gummihammer und Kelle.

Am Rande: Ich empfinde BCD irgendwie als "unnatürlich" und "bloaty", weil eben Dezimalziffern in 4 Bit dargestellt werden. Da bleiben Kapazitäten ungenutzt, und Binärrechner zu zwingen in Hardware dezimal zu rechnen... würg Und letztlich ist der Genauigkeitsgewinn nur dort vorhanden, wo vornehmlich von Menschen eingegebene Zahlen eine Rolle spielen. Und schlussendlich ist es auch nur ein seltsam kodiertes Festkommaformat; da doch lieber gleich Currency.

[Blup]

Für Werte die ohne Rundungsdifferenzen gespeichert werden müssen, kann das Feld in der Datenbank als "Numeric(a,b)" (a Anzahl Vorkommastellen, b Anzahl Nachkommastellen) deklariert werden. Problemtisch ist eventuell das Auslesen, da die verwendeten Komponenten in der Regel in ein Fließkommaformat konvertieren.

[Bummi]

@Blup
schön wäre es, Ado interpretiert es als TFMTBCD oder TBCD und ein cxGrid explodiert damit, also muss hier der Feldtyp manuell ausgetauscht werden. (sorry füt OT)

[DanielJ]

Hallo,


2 Anmerkungen:
1. für einfache vergleiche SameValue verwenden, gibt dann auch eine Bool zurück wie in

Code:

//if x=y then DoSth;
//stattdessen
if SameValue(x,y) then DoSth;

CompareValue ist etwas unhandlicher (und verwendet intern selber SameValue) wenn einen nicht interresiert ob ungleich-kleiner oder ungleich-größer.

2. Kleiner Artikel zur Problematik: What Every Computer Scientist Should Know About
Floating-Point Arithmetic

LG,
Daniel

[Captnemo]

Zitat von Sir Rufo:

Entschuldige, aber diese Fragestellung ist doch wohl Unfug.

Warum so unfreundlich? Was ist Unfug daran, einen Frage zu etwas zu stellen um sich eine Problematik zu verdeutlichen?

Zitat von Sir Rufo:

Um dieses Phänomen wirklich zu untersuchen, solltest du Die Zahl von String in ein Extended und dann in die Datenbank schreiben. Dann aus der Datenbank wieder auslesen und mit dem Wert wieder vergleichen.

Genauso mache ich es ja, dadurch bin ich ja überhaupt auf die Frage gestoßen.

Zitat von jfheins:

Zitat von Captnemo:

Also stellt sich mir die Frage, ob eine Zuweisung ala
...
auch evtl. abweichende Nachkommastellen hinterläßt.

Ganz klar ja. Denn die 0.9 lassen sich nicht exakt als Zweierpotenz schreiben.
Der Computer macht daraus bei der Umwandlung sowas wie

Code:

29.9  =  11101.111001100110011

Und das ergibt jetzt 0.9001464844 im Dezimalsystem. Mit mehr Stellen wird es noch genauer, aber es deutet sich bereits an dass der Nachkommaanteil periodisch ist und somit durch eine endliche Anzahl an Bits nur angenähert werden kann

Das leuchtet mir natürlich ein.