Problem bei addition von Kommazahlen

[Lawliet]

Hallo,
Ich beschäftige mich gerade mit GDIPlus und diesbezüglich mit Parabeln usw.
Dabei habe ich eine Schleife nach diesem Schema:

$x = -100
do
	$x+=0.01
	ConsoleWrite($x & @CRLF)
Until $x >= 100

Warum entstehen nun Zahlen mit mehr als 2 Nachkommastellen?

 Spoiler

-99.99
-99.98
-99.97
-99.96
-99.95
-99.94
-99.93
-99.92
-99.91
-99.8999999999999
-99.8899999999999
-99.8799999999999
-99.8699999999999
-99.8599999999999
-99.8499999999999
-99.8399999999999
-99.8299999999999
-99.8199999999999
-99.8099999999999
-99.7999999999999
-99.7899999999999
-99.7799999999999
-99.7699999999999
-99.7599999999999
-99.7499999999999
-99.7399999999999
-99.7299999999999
-99.7199999999999
-99.7099999999999
-99.6999999999998
-99.6899999999998
-99.6799999999998
-99.6699999999998
-99.6599999999998
-99.6499999999998
-99.6399999999998
-99.6299999999998
-99.6199999999998
-99.6099999999998
-99.5999999999998
-99.5899999999998
-99.5799999999998
-99.5699999999998
-99.5599999999998
-99.5499999999998
-99.5399999999998
-99.5299999999998
-99.5199999999998
-99.5099999999997
-99.4999999999997
-99.4899999999997
-99.4799999999997
-99.4699999999997
-99.4599999999997
-99.4499999999997
-99.4399999999997
-99.4299999999997
-99.4199999999997
-99.4099999999997
-99.3999999999997
-99.3899999999997
-99.3799999999997
-99.3699999999997
-99.3599999999997
-99.3499999999997
-99.3399999999997
-99.3299999999997
-99.3199999999997
-99.3099999999996
-99.2999999999996
-99.2899999999996
-99.2799999999996
-99.2699999999996
-99.2599999999996
-99.2499999999996
-99.2399999999996
-99.2299999999996
-99.2199999999996
-99.2099999999996
-99.1999999999996
-99.1899999999996
-99.1799999999996
-99.1699999999996
-99.1599999999996
-99.1499999999996
-99.1399999999996

[xNopex]

Liegt wohl an der internen Speicherung. Da nur begrenzt Speicherplatz zur Verfügung steht, muss man Abstriche bei der Genauigkeit machen. Bedenke nur: Zwischen 0 und 1 liegen unendlich viele Kommzahlen! Man trennt den Speicherbereich ungefähr folgendermaßen auf:

vorzeichenbit | exponent | mantisse

Jetzt finden intern noch Normierungsverfahren statt, damit mehr Zahlen abgespeichert werden können und zum leichteren Rechnen für das Rechenwerk. Das alles verändert die Zahl natürlich. Sprich: Du erhälst mehr als zwei Nachkommastellen wegen der internen Speicherung der Zahl.
Lösung: Runde nach zwei Stellen.

[Freddy​]

^
Aber zum Runden der Zahl kannst du Round() benutzen

[jacky919]

Originally Posted by xNopex

Liegt wohl an der internen Speicherung. Da nur begrenzt Speicherplatz zur Verfügung steht, muss man Abstriche bei der Genauigkeit machen. Bedenke nur: Zwischen 0 und 1 liegen unendlich viele Kommzahlen! Man trennt den Speicherbereich ungefähr folgendermaßen auf:

vorzeichenbit | exponent | mantisse

Jetzt finden intern noch Normierungsverfahren statt, damit mehr Zahlen abgespeichert werden können und zum leichteren Rechnen für das Rechenwerk. Das alles verändert die Zahl natürlich. Sprich: Du erhälst mehr als zwei Nachkommastellen wegen der internen Speicherung der Zahl.
Lösung: Runde nach zwei Stellen.

Bei einer nativen Sprache wie C++ mag das stimmen. Aber da AutoIt dynamische Typen verwendet könnte es sein, dass alle Zahlen als Strings abgespeichert werden und je nach Verwendung intern in Zahlen umgewandelt werden.

[xNopex]

Bei einer nativen Sprache wie C++ mag das stimmen. Aber da AutoIt dynamische Typen verwendet könnte es sein, dass alle Zahlen als Strings abgespeichert werden und je nach Verwendung intern in Zahlen umgewandelt werden.

Trotzdem müssen die Dezimalzahlen abgespeichert werden. Und das Rechenwerk schließlich mit den Zahlen rechnen. Sie werden eben erst zur Laufzeit dann umgewandelt.

[lolkop]

um dem entgegen zu wirken kannst du dir über stringfunktionen aber durchaus eine eigene funktion schreiben, welche nachkommastellen und vorkommastellen seperat als integer handelt, und somit der ungenauigkeit der floatingpoint operation entgegen wirken.

[xNopex]

um dem entgegen zu wirken kannst du dir über stringfunktionen aber durchaus eine eigene funktion schreiben, welche nachkommastellen und vorkommastellen seperat als integer handelt, und somit der ungenauigkeit der floatingpoint operation entgegen wirken.

Oder einfach die Zahlen jeweils mit 100 Multiplizieren und am Schluss wieder durch 100 teilen.

[lolkop]

Originally Posted by xNopex

Oder einfach die Zahlen jeweils mit 100 Multiplizieren und am Schluss wieder durch 100 teilen.

in diesem falle mag das funktionieren, bei unbekannter bzw varrierender anzahl der nachkommastellen hingegen kann man so nicht an das problem gehen, zumal bei hoher anzahl von nachkommastellen durch die division ja auch wieder rundungsfehler entstehen könnten.

[xNopex]

bei unbekannter bzw varrierender anzahl der nachkommastellen hingegen kann man so nicht an das problem gehen

Eigentlich ist das gängige Praxis. Natürlich geht das nicht immer, aber in sehr sehr vielen Fällen. Es gibt dabei auch Möglichkeiten so bei unbekannter oder variierender Anzahl an Nachkommastellen zu verfahren.
Man wird dabei auch immer genauere Ergebnisse erzielen als bei der gleichen Rechnung in Gleitkommarithmetik. Je mehr Rechenschritte notwedig sind, desto genauere Ergebnisse wird dieses Verfahren liefern. Rundungsfehler treten dann wenn überhaupt im letzten Schritt bei der Rücktransformation auf.

[Lawliet]

Naja, in meinem Falle hat das Runden auf 2-4 Kommastellen vollkommen gereicht
Danke