Calc rechnet falsch!?

Hallo Listige

Ich bin auf ein Problem mit Calc gestossen, das doch erstaunlich ist: Calc rechnet falsch!

Zunächst die Beschreibung der Situation: Seit langer Zeit mache ich täglich Sudoku und notiere mir in einer Calc-Tabelle die Ergebnisse, u.a. die Zeit, die es dauert, bis ich die erste Zahl finde. In der Zwischenzeit sind so 1077 Datensätze entstanden, von denen u.a. der Mittelwert berechnet wird (mit der Calc-Funktion =MITTELWERT()). Die zugehörige Calc-Datei befindet sich auf einem USB-Stick. Während der Woche erfolgt die Auswertung mit LO 6.1.6.3 auf einem Windows-Desktop-PC unter Windows 10, am Wochenende mit LO 6.2.7 auf einem Windows-Laptop unter Windows 10. Die Datei selbst bleibt – da auf einem Stick – immer genau die gleiche (Daten, Formeln, Formate, ...), nur die LO-Version ändert. Die Eintragungen werden also abwechselnd mit dem Desktop-PC oder dem Laptop in die gleiche Datei gemacht.

Jetzt zu meiner Beobachtung: Ich habe beim Mittelwert der ersten beobachteten Zahlenreihe festgestellt, dass bei der älteren Version der Wert 00:07 angezeigt wird, was 7 Sekunden entspricht (da meine „Werte“ immer unter einer Stunde liegen, habe ich per Format-Befehl die Anzeige von Stunden unterdrückt). Bei der neueren Version wird aber 00:06 angezeigt. Ich habe dann die Zeit-Formatierung entfernt und die beiden Werte
7.93189797604294E-05 (alte Version)
7.93496985357449E-05 (neue Version)
erhalten. Verwandle ich sie nach den Regeln der Mathematik wieder in Zeiten, indem ich diese Zahl mit 24 x 3600 multipliziere, so erhalte ich 6.85 [s] (Wert der älteren LO-Version) bzw. 6.86 [s] (Wert der neueren LO-Version). Dies suggeriert, dass der ältere Wert eigentlich der richtige ist, denn gerundet auf ganze Sekunden (was in der „normalen“ Anzeige meines Tabellenblattes der Fall ist bzw. sein sollte) ergeben beide Ergebnisse 7 [s]. Trotzdem bleibt die Tatsache bestehen, dass unabhängig von offenbar falscher Rundung auch die Ergebnisse zumindest in der einen Version falsch gerechnet werden: Mit exakt den gleichen Daten und exakt den gleichen Formeln kommen die beiden Versionen nicht auf das gleiche Ergebnis – zwar „nur“ ein Fehler (eine Abweichung?) von 0.4‰, trotzdem in meinen Augen nicht akzeptierbar.
Mit meinen Mitteln kann ich nicht entscheiden, welche Version „falsch“ rechnet – die Rundung weist eher auf die neuere Version als „Übeltäter“ hin, aber das muss nicht das gleiche Verdikt für die Rechnung an sich bedeuten.

Obschon es sich um eine spezielle Situation handelt, die nicht leicht zu reproduzieren ist, meine Frage an die Runde: Hat jemand ähnliche Erfahrungen gemacht?

Liebe Grüsse aus der bewölkten Schweiz

Ernst

Hallo Ernst,

die Abweichung in der Berechnung muss nicht unbedingt auf LO
zurückzuführen sein. Das könnte auch an unterschiedlichen Prozessoren
liegen im Desktop und im Laptop. Was die Rundung betrifft so sieht es
danach aus, dass die Ausgabe in LO 6.2.7 nicht gerundet sondern
abgeschnitten wird. Ich habe deine Zahlenwerte gerade mal in LO 6.2.8.2
auf Linux eingegeben und erhalte in beiden Fällen bei Formatierung als
Zeit 00:06, was für das Abschneiden spricht. Leider habe ich gerade kein
6.1 Version verfügbar, um es zu vergleichen.

Aus meiner Sicht ist dies ein Fehler und du solltest es als Bug melden.

Liebe Grüße vom Bodensee ebenfalls in Wolken und mit Regenschauern

Ulrich

Ich bin auf ein Problem mit Calc gestossen, das doch erstaunlich ist:
Calc rechnet falsch!

Zunächst die Beschreibung der Situation: Seit langer Zeit mache ich
täglich Sudoku und notiere mir in einer Calc-Tabelle die Ergebnisse,
u.a. die Zeit, die es dauert, bis ich die erste Zahl finde. In der
Zwischenzeit sind so 1077 Datensätze entstanden, von denen u.a. der
Mittelwert berechnet wird (mit der Calc-Funktion =MITTELWERT()). Die
zugehörige Calc-Datei befindet sich auf einem USB-Stick. Während der
Woche erfolgt die Auswertung mit LO 6.1.6.3 auf einem Windows-Desktop-PC
unter Windows 10, am Wochenende mit LO 6.2.7 auf einem Windows-Laptop
unter Windows 10. Die Datei selbst bleibt – da auf einem Stick – immer
genau die gleiche (Daten, Formeln, Formate, ...), nur die LO-Version
ändert. Die Eintragungen werden also abwechselnd mit dem Desktop-PC oder
dem Laptop in die gleiche Datei gemacht.

Jetzt zu meiner Beobachtung: Ich habe beim Mittelwert der ersten
beobachteten Zahlenreihe festgestellt, dass bei der älteren Version der
Wert 00:07 angezeigt wird, was 7 Sekunden entspricht (da meine „Werte“
immer unter einer Stunde liegen, habe ich per Format-Befehl die Anzeige
von Stunden unterdrückt). Bei der neueren Version wird aber 00:06
angezeigt. Ich habe dann die Zeit-Formatierung entfernt und die beiden Werte
7.93189797604294E-05 (alte Version)
7.93496985357449E-05 (neue Version)
erhalten. Verwandle ich sie nach den Regeln der Mathematik wieder in
Zeiten, indem ich diese Zahl mit 24 x 3600 multipliziere, so erhalte ich
6.85 [s] (Wert der älteren LO-Version) bzw. 6.86 [s] (Wert der neueren
LO-Version).

Genau genommen 6,853159851301100000 bzw. 6,855813953488360000; die
Differenz beträgt also nicht, wie du fälschlich vermutest, 0,01 (6.85
vs. 6.86), sondern eine ganze Zehnerpotenz weniger, nämlich
0,002654102187259260 Sekunden, oder genauer gesagt
0,00000003071877531550 Tage, denn in dieser Einheit werden Zeit- und
Datumswerte gespeichert. Abweichungen in der *8* *Stelle* hinter dem
Komma klingen für mich aber eher nach einem *Rundungsfehler*, nicht nach
einem /Rechenfehler/.

Btw., Rundungsfehler hängen auch stark davon ab, wie sehr die
Ausgangsdaten bereits vorher verarbeitet wurden (sprich welche
Rundungsfehler sich /vorher/ schon eingeschlichen haben. Das kann sich
derart potenzieren, dass der Fehler durchaus mehrere Zehnerpotenzen hoch
wandern kann.

Was die Abweichung der beiden Werte an geht, würde ich spontan darauf
tippen, dass entweder eines der beiden eingesetzten Geräte nur ein
32bit-System ist, oder möglicherweise die Daten auf den beiden Systemen
doch nicht ganz sooo exakt bis in die letzte Stelle hinter dem Komma
überein stimmen (und da reicht im Prinzip schon ein einziger Wert). Erst
/danach/ würde ich, wenn überhaupt, (und auch nur minimale) Unterschiede
beim Rundungsverhalten der beiden Softwareversionen in Betracht ziehen.
Einen Rechenfehler würde ich jedenfalls definitiv ausschließen wollen.

Obschon es sich um eine spezielle Situation handelt, die nicht leicht zu
reproduzieren ist, meine Frage an die Runde: Hat jemand ähnliche
Erfahrungen gemacht?

Och, solche Fragen bezüglich als Rechenfehler fehlinterpretierte
Rundungsfehler kommen immer wieder mal hier rein; derartige Erfahrungen
sind also durchaus vorhanden ... :wink:

Wolf 'aber soweit ich mich erinnern kann, saß der Fehler bisher doch
jedes mal /vor/ dem Bildschirm <duck>' gang

Hallo Listige

Genau genommen 6,853159851301100000 bzw. 6,855813953488360000; die
Differenz beträgt also nicht, wie du fälschlich vermutest, 0,01 (6.85
vs. 6.86), sondern eine ganze Zehnerpotenz weniger, nämlich
0,002654102187259260 Sekunden, oder genauer gesagt
0,00000003071877531550 Tage, denn in dieser Einheit werden Zeit- und
Datumswerte gespeichert. Abweichungen in der *8* *Stelle* hinter dem
Komma klingen für mich aber eher nach einem *Rundungsfehler*, nicht nach
einem /Rechenfehler/.

Btw., Rundungsfehler hängen auch stark davon ab, wie sehr die
Ausgangsdaten bereits vorher verarbeitet wurden (sprich welche
Rundungsfehler sich /vorher/ schon eingeschlichen haben. Das kann sich
derart potenzieren, dass der Fehler durchaus mehrere Zehnerpotenzen hoch
wandern kann.

Was die Abweichung der beiden Werte an geht, würde ich spontan darauf
tippen, dass entweder eines der beiden eingesetzten Geräte nur ein
32bit-System ist, oder möglicherweise die Daten auf den beiden Systemen
doch nicht ganz sooo exakt bis in die letzte Stelle hinter dem Komma
überein stimmen (und da reicht im Prinzip schon ein einziger Wert). Erst
/danach/ würde ich, wenn überhaupt, (und auch nur minimale) Unterschiede
beim Rundungsverhalten der beiden Softwareversionen in Betracht ziehen.
Einen Rechenfehler würde ich jedenfalls definitiv ausschließen wollen.

Obschon es sich um eine spezielle Situation handelt, die nicht leicht zu
reproduzieren ist, meine Frage an die Runde: Hat jemand ähnliche
Erfahrungen gemacht?

Och, solche Fragen bezüglich als Rechenfehler fehlinterpretierte
Rundungsfehler kommen immer wieder mal hier rein; derartige Erfahrungen
sind also durchaus vorhanden ... :wink:

Wolf 'aber soweit ich mich erinnern kann, saß der Fehler bisher doch
jedes mal /vor/ dem Bildschirm <duck>' gang

Ich habe Wolfgang per PM mitgeteilt, dass sein Beitrag nichts zur Thematik beiträgt, weil er am Problem vorbeigeht. Also bitte unbeachtet lassen.

Ernst

Hallo Ernst, *,

> Genau genommen 6,853159851301100000 bzw. 6,855813953488360000; die
> Differenz beträgt also nicht, wie du fälschlich vermutest, 0,01 (6.85
> vs. 6.86), sondern eine ganze Zehnerpotenz weniger, nämlich
> 0,002654102187259260 Sekunden, oder genauer gesagt
> 0,00000003071877531550 Tage, denn in dieser Einheit werden Zeit- und
> Datumswerte gespeichert. Abweichungen in der *8* *Stelle* hinter dem
> Komma klingen für mich aber eher nach einem *Rundungsfehler*, nicht nach
> einem /Rechenfehler/.
> […]
> Was die Abweichung der beiden Werte an geht, würde ich spontan darauf
> tippen, dass entweder eines der beiden eingesetzten Geräte nur ein
> 32bit-System ist, […]

Ich habe Wolfgang per PM mitgeteilt, dass sein Beitrag nichts zur
Thematik beiträgt, weil er am Problem vorbeigeht. Also bitte unbeachtet
lassen.

Im Gegenteil - der hat sehr wohl etwas damit zu tun.
Ich tippe genauso wie er auf eine 32bit vs 64bit Version - denn da
gibt es einen Unterschied bei der floating-point berechnung zwischen
x87 auf 32bit vs Berechnung via SSE2-Erweiterungen auf 64bit

Die haben unterschiedliche Präzision / unterschiedlich große interne
Register und somit unterschiedliche Rundungsfehler bei der Berechnung.

Und auch mit dem Hinweis, dass Datums/Zeitwerte in einer
Tabellenkalkulation in Einheiten von Tagen repräsentiert werden ist
hier wichtig:
Denn dadurch hast du bei Werten im Sekundenbereich eben kleine Fließkommazahlen.

Würdest Du anstattdessen mit den Sekundenwerten selbst rechnen, also
mit Ganzzahlen kommt es bei Berechnung des Mittelwerts nur einmal zu
einer Fließkommazahl (bei der Division durch die Anzahl der Werte),
während bei Datumswerten selbst die Summe mit Fließkommazahlen
berechnet werden muss) - und da treten einfach prinzipiell
Rundungsfehler auf. Abhängig von den konkreten Werten heben die sich
ggf. auf oder summieren sich.
Wolfgangs Antwort also als "am Problem vorbei" zu bezeichnen ist für
mich nicht nachvollziehbar.
Er hat nur insofern "unrecht" als dass die 32bit FPU mehr bits für die
Berechnung hat und somit theoretisch genauer rechnet als die SSE2
Instruktionen, die können dafür mehr auf einmal/sind um ein vielfaches
schneller...

ciao
Christian

Hallo Ernst,

mit LO 6.2 gab es Änderungen bei der Zeitberechnung (Rundungen), vgl. z.B.:

Bug 127143 - Time addition short of one second in calc
https://bugs.documentfoundation.org/show_bug.cgi?id=127143

Bug 125099 - Rounding of durations displayed as wall clock time.
https://bugs.documentfoundation.org/show_bug.cgi?id=125099

Bug 125580 - Wrong value when adding two dates
https://bugs.documentfoundation.org/show_bug.cgi?id=125580

Bug 127477 - Incomplete description of date & time functions in the help information
https://bugs.documentfoundation.org/show_bug.cgi?id=127477

Gruß
Oliver

Hallo Oliver

Hallo Ernst,

mit LO 6.2 gab es Änderungen bei der Zeitberechnung (Rundungen), vgl. z.B.:

Bug 127143 - Time addition short of one second in calc
https://bugs.documentfoundation.org/show_bug.cgi?id=127143

Bug 125099 - Rounding of durations displayed as wall clock time.
https://bugs.documentfoundation.org/show_bug.cgi?id=125099

Bug 125580 - Wrong value when adding two dates
https://bugs.documentfoundation.org/show_bug.cgi?id=125580

Bug 127477 - Incomplete description of date & time functions in the help information
https://bugs.documentfoundation.org/show_bug.cgi?id=127477

Gruß
Oliver

Vielen Dank für Deine Hinweise - dabei handelt es sich mit ziemlicher Sicherheit zumindest teilweise um Fehler, wie ich sie in meiner Anwendung gefunden habe (und für einmal sind es halt wirklich Fehler der Software, auch wenn es nicht alle Antwortenden wahr haben wollen ...). Ich werde die von Dir zitierten Links konsultieren und bei Bedarf meine Beobachtungen ergänzen, wenn es irgendwo passt.

Einen schönen Abend wünsche ich Dir

Ernst