Domino 9 und frühere Versionen > Entwicklung

Rechengenauigkeit INTEL ???

<< < (2/4) > >>

Marinero Atlántico:
Java:

--- Code: ---double zahl1 = 184.8;
double zahl2 = 184.5;
double result = zahl1 - zahl2;
return result;

--- Ende Code ---
ergibt:

Das hat etwas mit allgemeinen Ungenauigkeiten von double auf 32-bit Rechnern zu tun.

Kann das aber mit
http://java.sun.com/j2se/1.4.2/docs/api/java/text/NumberFormat.html
lösen.
Bei wirklich großen oder kleinen Zahlen gibt es immer noch:
http://java.sun.com/j2se/1.4.2/docs/api/java/math/BigDecimal.html

eknori:
ähhh ist es mit der Rechengenauigkeit von Holocomb auch nicht so weit her ??

184,8 + (-184,5).
(minus weils ne Gutschrift ist).
Herauskommen müsste 2,3

@Holocomb: gaaaanz sicher ??

Ich habe mal Adam Riese und Schürmanns Rechenbuch befragt; da kommt aber 0,3 raus ...

Möglicherwesie sehen das gewisse Herrschaften im Takonomi (Yakatomi oder wie auch immer ) Tower wieder als Beleidigung an; ist aber nicht so gemeint ;-)

Marinero Atlántico:
Float wird noch ungenauer:

--- Code: ---float zahl1 = 184.8f;
float zahl2 = 184.5f;
float result = zahl1 - zahl2;
return result;

--- Ende Code ---

Semeaphoros:
Leute, solange man binär rechnet und nicht mit BCD, sind die Rundungsfehler inhärent und haben nix mit Fehlern im Pentium oder was auch immer zu tun. Das hängt ganz einfach damit zusammen, dass sich die endlich darstellbaren Zahlen des Dezimalsystems nicht unbedingt mit endlichen Zahlen des Binärsystemes darstellen lassen, es gibt also keine 1 zu 1 Relation zwischen Dezimal und Binär, und damit kommt es zwangsläufig zu Rundungsfehlern, ob man will oder nicht. Das mit dem Abfangen hat auch seine Nase, jedes Runden vergrössert den sowieso schon vorhandenen Fehler und wir bekommen Probleme mit einem Ding, das sich Fehlerfortpflanzung nennt.

Da hatte ich mal einen Informatiker als Angestellten, der das Problem selber unterschätzt hat  Er hat es zwar aus der Ausbildung heraus gekannt, aber nie wirklch erlebt. Da musste man einen Wassertropfen am linken Rand des Bildschirmes herunterlaufen lassen. Um den nächsten Schritt zu berechnen, dividiere man die Höhe des Bildschirms durch die Anzahl Schritte, die man machen will, tönt ganz einfach. Der Mann hat dann bei jedem Rechenschritt schön brav gerundet. In der VGA-Auflösung, die damals noch üblich war, kam der Tropfen auch wie gewünscht unten am Bildschirm an. Wenn wir dann für die Produktion auf 800 x 600 umschalteten, da passierte etwas merkwürdiges: der Tropfen blieb nach 2/3 der Strecke einfach stehen. Ich hab gleich gefragt, hast Du zu früh gerundet? Er wollte mir das nicht glauben, dass das einen derart grossen Effekt haben könnte, so dass ich ihm nahelegte, ändere mal den Code, mach die Rundung erst ganz am Schluss ..... und siehe da, der Tropfen landete wie gewünscht bei beiden Auflösungen korrekt unten am Bildschirm.

AC:
Hallo Leute, erstmal allen danke für das feedback.

mehr später, weil ich erstmal was schnell für Chef machen muß.

@eknori
Die zweite Zahl war 182,50 und nicht 184,5.- Sorry mein Fehler.
Korrekt lautet es also 184,80 + (- 182,50).
Und dann kriegt man eben die Nachkommastelle.
Merci auch für das AMD Beispiel, hat mich auch interessiert.

Bis später, Holcomb,

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete