Weiterer Fehler in Calc bei einfacher Rechnung

de-users
#1

Hallo Leute,

ich bin vor einiger Zeit über einen Fehler in Calc gestolpert. Obwohl es sich um einfache (im Dualsystem gut darstellbare) Zahlen handelt, führt bereits eine Reihe simpler Addition zu Ungenauigkeiten – siehe Anhang (einmal als ODS, einmal als PDF).

#2

Anhang klappt nicht, also direkt:

A1: 702,1

A2: -200

A3: -300

A4: -200

A5: =SUMME(A1:A4) — liefert: 2,10000000000002

#3

Hallo Andre,

die Liste akzeptiert keine Anhänge - die werden abgeschnitten.

Allerdings ergibt Deine unten angegeben Berechnung in einer Zeile exakt 2,1 - also wie erwartet. Egal, ob Du sie als eine Zeile eingibst (=702,1 – 200 - 300 - 200) oder jeden Wert in eine Zelle eingibst und dann die Zellen summierst.

Du musst allerdings auch bedenken, dass ein Computer nie korrekt rechnen kann - es wird also immer zu Rundungsfehlern kommen. Meist sind die aber so gering und werden durch die Darstellung wieder aufgehoben. Da Deine erste Zahl eine Dezimalzahl ist, wird intern mit einem Double-Wert gerechnet - und der kann nie exakt sein.

Aber darüber gibt es schon soooo viele Diskusionen und Artikel - einfach mal in Google suchen.

Und ja, das dargestellt Ergebnis deiner 2. Mail (2,1000000002) ist eben ein Ergebnis der wieder zurückgewandelten Double-Zahl - und nie mathematisch exakt.

Ist übrigens keine Besonderheit von Calc... kann kein Kalkulationsprogramm besser.

Prüfe übrigens mal die Einstellung in den Optionen: Extras - Optionen - LO Calc -> Berechnen. Die Option "Genauigkeit wie angezeigt" sollte aktiviert sein - dann wird ein solcher Effekt nicht direkt sichtbar sein.

VG

Thomas

#4

Zahlen wie die hier angegebenen lassen sich problemlos (und selbst mit einfacher Genauigkeit) problemlos als Fließpunktzahl darstellen. Es liegt also definitiv ein Fehler vor, und der ist bei mir reproduzierbar. Die Frage ist nun, woran es liegt: Calc oder ein Fehler im Microcode des Prozessors …

Das mit der Darstellung ist mir klar, beseitigt aber nicht das Problem, wenn man exakte Werte bestimmen will. Bei der hier gebildeten Summe aus vier niedrigen Werten mit maximal einer Stelle hinter dem Komma darf es da auch keine Differenzen geben.

Wenn es bei Dir funktioniert, ist es möglicherweise dann doch ein Problem des Prozessors …

#5

Hmm... das aktuelle Excel liefert 2,100 000 000 000 02 und LibreOffice
6.0.4 exakt das gleich Ergebnis 2,100 000 000 000 02. Also nach einem
Fehler von Calc schaut mir das nicht aus.

LG Günther

#6

Zahlen wie die hier angegebenen lassen sich problemlos (und selbst mit
einfacher Genauigkeit) problemlos als Fließpunktzahl darstellen. Es
liegt also definitiv ein Fehler vor, und der ist bei mir reproduzierbar.
Die Frage ist nun, woran es liegt: Calc oder ein Fehler im Microcode des
Prozessors …

Evtl. würde es weiterhelfen, wenn wir wüssten, was statt dessen denn bei Dir
herauskommt.

Das mit der Darstellung ist mir klar, beseitigt aber nicht das Problem,
wenn man exakte Werte bestimmen will. Bei der hier gebildeten Summe aus
vier niedrigen Werten mit maximal einer Stelle hinter dem Komma darf es
da auch keine Differenzen geben.

Also Calc liefert hier das selbe Ergebnis, wie bei Thomas und Günther.
Passt man die Zellenformatierung an, also Dezimalzahl mit einer oder 2
Nachkommastellen, so wird daraus 2,1 bzw. 2,10.

Wenn es bei Dir funktioniert, ist es möglicherweise dann doch ein
Problem des Prozessors …

Defekter Ram ist auch ne Möglichkeit.

#7

Hallo Thomas,

Hallo Andre,

die Liste akzeptiert keine Anhänge - die werden abgeschnitten.

Allerdings ergibt Deine unten angegeben Berechnung in einer Zeile exakt
2,1 - also wie erwartet.

Das kommt auf die Darstellung an. Wenn du auf "Standard" stellst und die Spalte schmal genug ist, ja; wenn du mehr Ziffern anzeigen lässt, nein.

Du musst allerdings auch bedenken, dass ein Computer nie korrekt rechnen
kann - es wird also immer zu Rundungsfehlern kommen.

Da liegt auch der Fehler beim Poster. Die Zahl 2,1 lässt sich eben nicht 'gut im Dualsystem darstellen', sondern ist eine unendliche, periodische Kommazahl.

  Meist sind die aber

so gering und werden durch die Darstellung wieder aufgehoben.

Für die meisten Anwendungen reicht dies. Wenn es nicht reicht, sollte man sowieso überlegen, ob eine Tabellenkalkulation das richtige Werkzeug ist. Es gibt nur wenige Fälle, in denen die Genauigkeit unter 14 signifikante Stellen rutscht. Dazu gehören beispielsweise lineare Regression mit mehreren Variablen, so ab 10 Variablen ist es nicht mehr brauchbar.

  Da Deine

erste Zahl eine Dezimalzahl ist, wird intern mit einem Double-Wert
gerechnet - und der kann nie exakt sein.

Kann schon, 0,5 und 0,25 und 0,125 usw. sind exakt als Double darstellbar. Aber 0,1 leider nicht.

Es wird übrigens intern immer in Double gerechnet, egal wie die Zahlen lauten.

[..]

Prüfe übrigens mal die Einstellung in den Optionen: Extras - Optionen -
LO Calc -> Berechnen. Die Option "Genauigkeit wie angezeigt" sollte
aktiviert sein - dann wird ein solcher Effekt nicht direkt sichtbar sein.

Das würde ich nicht als generelle Regel empfehlen. Damit handelst du dir typische "3 * 1/3 ungleich 1" Probleme ein. Du musst schon wissen, ob deine Daten dafür geeignet sind. Eher würde ich für die Anzeige nicht "Standard" nehmen, sondern die Anzahl der anzuzeigenden Dezimalstellen explizit angeben.

Mit freundlichen Grüßen
Regina

#8

Hallo André

Zahlen wie die hier angegebenen lassen sich problemlos (und selbst mit
einfacher Genauigkeit) problemlos als Fließpunktzahl darstellen.

Nein, nur mit Runden
702,1 ist als Dualzahl
1010111110,00011001100110011001100 usw.
Es ist eine unendliche Kommazahl im Zweiersystem.

Mit freundlichen Grüßen
Regina

#9

Hallo Leute,

ich bin vor einiger Zeit über einen Fehler in Calc gestolpert. Obwohl es
sich um einfache (im Dualsystem gut darstellbare) Zahlen handelt,

Und hier irrst du. Bei *einer* der Zahlen handelt es sich um eine
Gleitkommazahl, und Gleitkommazahlen sind (bis auf ganz wenige spezielle
Ausnahmen[1]) praktische *nie* binär exakt darstellbar.

[1] nämlich wenn der Nachkommawert exakt dem Vielfachen des Kehrwerts
einer Zweierpotenz entspricht, also z. B. 0,25 (1/(2^2)), 0,625
(5/(2^3)) usw.; mit z. B. dem Wert 702,125 hättest du also keinen
Rundungsfehler bekommen.

führt
bereits eine Reihe simpler Addition zu Ungenauigkeiten – siehe Anhang
(einmal als ODS, einmal als PDF).

Schon die *erste* deiner Zahlen ("702,1") ist binär nicht exakt
darstellbar; das pflanzt sich natürlich bis zum Endergebnis fort. Wenn
du es nicht glaubst, prüf es selber nach auf
https://www.h-schmidt.net/FloatConverter/IEEE754de.html . Die Seite
stellt zwar nur 32-Bit-Werte dar, Calc verwendet dagegen ein
64-Bit-Format. Das ändert aber nix am grundsätzlichen Prinzip, sondern
verschiebt lediglich den Fehler um ein paar Stellen nach hinten.

Wolfgang

#10

@Regina und @Wolfgang: Für mich sehr erhellend, - vielen Dank!

#11

Am Prozessor liegt es auch nicht.

Ein vergleichbarer Versuch in PHP liefert exakt die eigentlich erwarteten Werte …

Eine Macke von Excel, aus Kompatibilitätsgründen 1:1 in Calc übernommen?

Ciao

André

#12

Eventuell ist das kein Fehler, sondern ein Abspeichern der Zahlen durch Excel (und Calc) in einem platzsparenden Spezialformat – mit vergleichsweise geringer Genauigkeit. Das muss man aber auch erst mal wissen …

#13

Hallo André,

Eventuell ist das kein Fehler, sondern ein Abspeichern der Zahlen durch
Excel (und Calc) in einem platzsparenden Spezialformat – mit
vergleichsweise geringer Genauigkeit. Das muss man aber auch erst mal
wissen …

Liest Du eigentlich überhaupt die sehr ausführlichen Erklärungen hier?
Das ist kein Platzsparendes Spezialformat. Und wenn PHP da zu anderen
Ergebnissen kommt, dann macht es das vermutlich so, dass die Werte eben
direkt gerundet werden. Das kannst Du mit Tabellenkalkulationen
natürlich auch anstellen.

Gruß

Robert

#14

Zahlen wie die hier angegebenen lassen sich problemlos (und selbst mit
einfacher Genauigkeit) problemlos als Fließpunktzahl darstellen. Es
liegt also definitiv ein Fehler vor, und der ist bei mir reproduzierbar.
Die Frage ist nun, woran es liegt: Calc oder ein Fehler im Microcode des
Prozessors …

Weder noch; wenn du so willst, liegt es an der von der IEEE
intermational genormten Darstellung von Gleitkommazahlen auf
Binärsystemen. Lies
http://www.iti.fh-flensburg.de/lang/informatik/ieee-format.htm .

Das mit der Darstellung ist mir klar, beseitigt aber nicht das Problem,
wenn man exakte Werte bestimmen will.

Es gibt Zahlen, die *kann* man nicht exakt bestimmen; im Dezimalsystem
wäre das z. B. die Zahl 1/3; oder Pi; usw. Und im Binärsystem ist das
eben u. a. die Zahl 2,1.

Bei der hier gebildeten Summe aus

vier niedrigen Werten mit maximal einer Stelle hinter dem Komma darf es
da auch keine Differenzen geben.

innerhalb des *Darstellungsbereiches* gültiger Zahlen tut (d. h. alles
was sich mit 64 Bit darstellen lässt) es das auch nicht.

Wenn es bei Dir funktioniert, ist es möglicherweise dann doch ein
Problem des Prozessors …

Nein; das Problem sitzt /vor/ dem Bildschirm.

Wolfgang

#15

Am Prozessor liegt es auch nicht.

Ein vergleichbarer Versuch in PHP liefert exakt die eigentlich
erwarteten Werte …

Dann hast du einen Fehler gemacht; HPH arbeitet auch nur mit 64 Bit.

Und wenn ich mal von http://php.net/manual/de/language.types.float.php
zitieren darf:

Additionally, rational numbers that are exactly representable as
floating point numbers in base 10, like 0.1 or 0.7, do not have an
exact representation as floating point numbers in base 2, which is
used internally, no matter the size of the mantissa. Hence, they
cannot be converted into their internal binary counterparts without a
small loss of precision. This can lead to confusing results: for
example, floor((0.1+0.7)*10) will usually return 7 instead of the
expected 8, since the internal representation will be something like
7.9999999999999991118....

So never trust floating number results to the last digit, and do not
compare floating point numbers directly for equality. If higher
precision is necessary, the arbitrary precision math functions and gmp
functions are available.

Eine Macke von Excel, aus Kompatibilitätsgründen 1:1 in Calc übernommen?

Ciao

André

Hmm... das aktuelle Excel liefert 2,100 000 000 000 02 und LibreOffice
6.0.4 exakt das gleich Ergebnis 2,100 000 000 000 02. Also nach einem
Fehler von Calc schaut mir das nicht aus.

LG Günther

Zahlen wie die hier angegebenen lassen sich problemlos (und selbst mit
einfacher Genauigkeit) problemlos als Fließpunktzahl darstellen. Es
liegt also definitiv ein Fehler vor, und der ist bei mir
reproduzierbar. Die Frage ist nun, woran es liegt: Calc oder ein
Fehler im Microcode des Prozessors …

Das mit der Darstellung ist mir klar, beseitigt aber nicht das
Problem, wenn man exakte Werte bestimmen will. Bei der hier gebildeten
Summe aus vier niedrigen Werten mit maximal einer Stelle hinter dem
Komma darf es da auch keine Differenzen geben.

Wenn es bei Dir funktioniert, ist es möglicherweise dann doch ein
Problem des Prozessors …

Hallo Andre,

die Liste akzeptiert keine Anhänge - die werden abgeschnitten.

Allerdings ergibt Deine unten angegeben Berechnung in einer Zeile
exakt 2,1 - also wie erwartet. Egal, ob Du sie als eine Zeile
eingibst (=702,1 – 200 - 300 - 200) oder jeden Wert in eine Zelle
eingibst und dann die Zellen summierst.

Du musst allerdings auch bedenken, dass ein Computer nie korrekt
rechnen kann - es wird also immer zu Rundungsfehlern kommen. Meist
sind die aber so gering und werden durch die Darstellung wieder
aufgehoben. Da Deine erste Zahl eine Dezimalzahl ist, wird intern mit
einem Double-Wert gerechnet - und der kann nie exakt sein.

Aber darüber gibt es schon soooo viele Diskusionen und Artikel -
einfach mal in Google suchen.

Und ja, das dargestellt Ergebnis deiner 2. Mail (2,1000000002) ist
eben ein Ergebnis der wieder zurückgewandelten Double-Zahl - und nie
mathematisch exakt.

Ist übrigens keine Besonderheit von Calc... kann kein
Kalkulationsprogramm besser.

Prüfe übrigens mal die Einstellung in den Optionen: Extras - Optionen
- LO Calc -> Berechnen. Die Option "Genauigkeit wie angezeigt" sollte
aktiviert sein - dann wird ein solcher Effekt nicht direkt sichtbar
sein.

VG

Thomas

ich bin vor einiger Zeit über einen Fehler in Calc gestolpert. Obwohl
es sich um einfache (im Dualsystem gut darstellbare) Zahlen handelt,
führt bereits eine Reihe simpler Addition zu Ungenauigkeiten – siehe
Anhang (einmal als ODS, einmal als PDF).

###

Mein System:

LinuxMint 18.3 auf einem Rechner mit i7-7700 und 8 GB Speicher.

###

702,1 – 200 - 300 - 200 != 2,10

###

Wolfgang

#16

Das muss natürlich "dem *ganzzahligen* Vielfachen des Kehrwerts einer
Zweierpotenz" lauten; sorry.

Nicht dass womöglich noch jemand auf die Idee kommt, mit "1,5/(2^2)" o.
ä. argumentieren zu wollen.

Wolfgang