Berechnungen mit Gleitkomma Werten

[Jens01]

Damit umzugehen ist eben die Kunst.

Bei Vergleichen nutzt man sowas wie Samevalue, CompareValue usw. Ggf muss man auch runden.

[itblumi]

Beim Single schien mir die Abweichung etwas zu hoch zu sein, aber nach weiterem forschen bin ich auf die folgende Seite gestoßen die es wirklich gut erklärt.

https://bernd-leitenberger.de/genaui...omputern.shtml

[Sinspin]

Generell solltest Du versuchen überall den gleichen Typ zu verwenden. Beim Umrechnen zwischen Typen kommt es zu Fehlern.
Oder Du verwendest einen Numeric Typen bei dem intern gar keine Gleitkommazahlen verwendet werden. Ich habe das vor Jahren mal probiert, fand es aber fürchterlich langsam.

[himitsu]

Bei bis zu 4 Nachkommastellen Currency (ist intern ein Int64, der durch 10000 geteilt ist).
http://docwiki.embarcadero.com/RADSt...hi)#Real_Types

Ansonsten gäbe es noch BCD-Typen
und Anderes.

Oder eben vor Anzeige immer auf die gewünschten Stellen runden/formatieren,
sowie Vergleiche niemals mit = , sondern z.B. IsZero, SameValue, ComparaValue usw.
Und für das Dictionary einen passenden Comparer schreiben, falls die "Floats" als Key benutzt werden sollen.

Auch nicht fortlaufend draufrechnen ... damit vervielfacht man nur noch die Rundungsfehler.
z.B. so for i := 0 to 200 do begin AExtended := -1.0 + (0.01 * i); bzw. := -1.0 + (i / 100); ist der Fehler nur zweieinmal enthalten.

Zitat:

AExtended -0,42

PS: Extended ist garantiert auch nicht genau 0,42
dort wird die Ungenauigkeit nur aktuell gerade zufälig erst irgendwo nach der 15. Nachkommastelle liegen (er hat schließlich 19-20 signifikante Stellen, ab der ersten Ziffer, welche nicht 0 ist)

[noisy_master]

Moinsen,

gerade bei Farbwerten würde ich eher auf "RGB" kodierte Integerwerte gehen. Dann hast du keine Probleme mit "Abweichungen" durch Fliesskommadarstellung.
Vielleicht kannst du nochmal dein Problem mit der "Klassifizierung von Farbwerten" etwas näher erläutern...

Gruß

[gubbe]

Schon die Konstante 0.01 aus dem Beispielcode lässt sich binär nicht exakt darstellen. Durch das Aufaddieren in der Schleife wird die Abweichung dann immer größer.
Deshalb sollte man genau das vermeiden. Es ist kein spezifisches Delphi-Problem.

Vielleicht kannst Du darstellen, was Du eigentlich vorhast, dann lässt sich besser beurteilen, wie man die Abweichungen minimiert.

[itblumi]

Danke für eure zahlreichen antworten, mir war nicht bewusst das die Abweichung beim Single so groß ist. Für das Erstellen des Dictionaries(Farb und Werte Zuordnung) runde ich einfach nach jeder Addition und das reicht erstmal aus. Mir ging es hier hauptsächlich um die Daten Typen und ich kann jetzt je nach Fall meine internen Berechnung darauf anpassen. Das wird darauf hinaus lauf das ich nur mit Integer/Int64 rechne und erst am Ende auf eine Gleitkomma Zahl um schwenke, denn so sollte sich der Fehler reduzieren lassen.

[himitsu]

Eigentlich sollte Extended auch nie zum Speichern verwendet werden (war nur für Zischenschritte von Berechnungen gedacht).
Außerdem ist der Typ nicht überall verfügbar, z.B. nicht unter Win64 oder iOS/Android ... dort ist es intern ein DOUBLE (und belegt überall auch noch unterschliedlich viel Speicher > SizeOf)

Zitat:

Dieser Zustand tritt im 64-Bit sowie ... auf

Dort sollten also Double und Extended das Gleiche anzeigen.