LibreOffice-Forum

Nimmet man die Zahl 1234
Addiert in jeder der folgenden 28 (oder mehr) Spalten jeweils 0,12
Und summiert diese Zahlen auf, erhält man ein falsches Ergebnis :

35834,7199999999 statt 35834,72

LO Version Win 4.x -5.x
unabhängig von Berechnungeinstellungen
unabhängig von der Zellenformatierung

Hallo,

das ist das Problem der numerischen Mathematik. Intern werden die Rechnungen natürlich dual ausgeführt und (das verheerende) mit einer endlichen Stellenanzahl. Das führt dann genau zu diesen Ergebnissen und (leider) ein Grundproblem des Arbeitens mit jedweder Rechenmaschine ...

@mikele
Das habe ich auch zuerst gedacht, bis ich den Fehler näher analysiert habe.
Es kommen jetzt nur noch binär vollständig korrekt darstellbare Zahlen zum Einsatz.
Der Fehler muß bei der Addition der Einzelwerte entstehen, nicht bei der Umrechnung
in binäre Zahlenwerte. (MS Excel macht den Fehler nicht)

Nachtrag :
MS Excel macht den Fehler in den Versionen 4 bis 2013 genauso.
Er wird nur durch geschickte Rundung in der Standard Darstellung nicht angezeigt.

Für alle, die das Problem einfach nachvollziehen wollen , die Tabelle als Anhang

Hallo Mr. Hobbybyte,

MS Excel macht den Fehler nicht

Ich hab grad kein Excel zum Testen, aber könnte es daran liegen dass du in Excel nur bis A28 summierst, in Calc aber bis A29?
paljass

Hallo paljass,
beide Tabellen sind mit LO gemacht und beide Tabellen sind in Excel fehlerfrei.
Das einmal bis A28 und einmal bis A29 ist ein Versehen, ändert aber an dem Problem nichts.
Erst , wenn man nur bis A27 addiert, verschwindet das Problem in LO, aber der Wert
in der letzten Zeile ist uninteressant, dafür aber nicht der Wert darüber.
Das Phänomen ist schon etwas seltsam, beruht aber wahrscheinlich auf einer fehlerhaften
Zwischensumme, die nicht korrekt berechnet wird.
Ich hatte ursprünglich eine sehr große Tabelle, bei der durch ungünstige Umstände im Endergebnis
Fehler im Prozentbereich entstanden sind. Ich habe es dann mit viel Arbeit auf diese kleine
Tabelle reduziert, um den Fehler einfacher reproduzierbar zu machen.

Hallo,

Es kommen jetzt nur noch binär vollständig korrekt darstellbare Zahlen zum Einsatz.

gestatte, dass ich widerspreche.
Die Zahl 0,12 ist leider im Dualsystem ein periodischer Bruch (mit einer 20-stelligen Periode) und zwar:
0,00011110101110000101 (diese 20 Nachkommastellen wiederholen sich auf ewig)
Rechnet man das ganze zurück so ergibt sich
(mit 20 Nachkommastellen): 0,00011110101110000101 (dual) = 1,1999988555908203125 (dezimal)
(mit 40 Nachkommastellen): 0,0001111010111000010100011110101110000101 (dual)=1,199999999998908606357872486114501953125 (dezimal)
Genug des akademischen Geschwafels.
An irgendeiner Stelle muss das Rechensystem abbrechen bzw. runden. Wie das Ganze passiert hängt von den internen Algorithmen ab (das ist dann schon ziemlich hohe Mathematik). Falsch, im streng mathematischen Sinn, rechnen sie alle, aber manche runden besser.
Das gleiche Problem tritt umgekehrt auch mit sehr großen Zahlen auf.
Die interne Darstellung als Gleitkommazahl mit doppelter Genaugkeit (also 52 duale Ziffern) bedeutet letztlich, dass eine Dezimalzahl höchstens mit 16 genauen Ziffern dargstellt wird. Der Rest wird abgeschnitten.
Die Zahl 1234567801234567890 wird so zu 1,23456789012346E+019 (unter LO)
edit: Unter Excel wird 1234567801234567890 zu 1,23456789012347E+019! (was auf die internen Vorgänge beider System schließen lässt)

@mikele
Da muss ich Dich leider korrigieren, wenn Du gestattest.
Die Werte werden natürlich nicht im Binärcode gespeichert,
sonst wäre ja der Umgang mit großen Zahlen überhaupt
nicht möglich. Meine Aussage binär bezog sich auf digital und damit
ist 0,12 perfekt und absolut genau als Floting Point 12/-2 zu speichern.
Problematisch sind Werte wie 1/3 , da diese bei der Speicherung in
digitaler Form eine Ungenauigkeit erfahren müssen, nicht aber die
Werte, die ich benutzt habe.
Alle in den oberen Tabellen aufgeführten Werte und Zwischenwerte sind
sogar noch als 32 Bit Floating Point mit absoluter Genauigkeit abzubilden.
(mit 64 Bit Floating Point natürlich auch). In der jetzt angehängten Testdatei
werden diese Werte natürlich absichtlich überschritten.

Weiterhin sagt die Anzeige nichts über die Genauigkeit der internen
Berechnung aus. Meine Versionen von Excel und Calc sind sehr ähnlich,
was die Genauigkeit der Speicherung von Werten angeht.
Hier ein Test, bei dem besonders die Zeile 50 interessant ist, da hier
zwischen Excel und Calc ein Unterschied besteht.

Hallo,
ich bin zwar nicht 100%ig sicher, ob Tabellenkalkulationen eine eigene Arithmetik integriert haben (was ich bezweifle), aber spätestens auf Prozessorebene erfolgt die Rechnung dual.
Die größte Zahl, die als 8-Byte-Fließkommazahl (doppelte Genauigkeit) darstellbar ist, ist etwa 1,798·10^308 und damit groß genug. Mittlerweile wird aber auch mit vierfacher Genauigkeit gearbeitet.
In deiner Tabelle bleibst du imer noch im Bereich der einfachen Genauigkeit (4 Byte).
Versuche mal, die Zahl 1,5E309 einzugeben ...
Ich kann mich aber auch irren.

Hallo,

ich habe mal etwas probiert.
Bei folgender Rechnung erwartet man natürlich 0,12 als Ergebnis. LO zeigt dieses Ergebnis in der Standardformatierung auch an. Lässt mann sich das Ergebnis aber mit ein paar mehr Kommastellen anzeigen (was ja eigentlich Quatsch ist) so erhält man: 0,119999999999891.
Der einzige workaround, der mir einfällt, wäre, das Ergebnis mittels Runden() zwingend zu runden.
Ist insgesamt nicht schön, wenn man solche Genauigkeiten benötigt.
Wie dieses numerische Problem unter Excel umgangen wird, weiß ich nicht. Es wäre bestimmt eine Herausforderung an die Entwickler von LO, die Calc-Engine dahingehend zu verbessern (grundsätzlich lösen kan man es aufgrund der endlichen Zahldarstellung natürlich nicht).