Seltsames Verhalten von Calc, Rundungsfehler
Moderator: Moderatoren
-
- Beiträge: 1
- Registriert: Fr, 29.12.2017 18:11
Seltsames Verhalten von Calc, Rundungsfehler
Hallo,
ich habe heute eine Rechnung in Calc geschrieben und dabei festgestellt das zwei Rechnungen mit der gleichen Nettosumme eine unterschiedliche Mehrwertsteuer aufweisen. Die Berechnung der Werte erfolgt in beiden Tabellen identisch.
Zuerst wird eine Summe gebildet, diese dann mit 0,19 multipliziert.
Dabei kommt Calc auf ein unterschiedliches Ergebnis, je nach dem ob ein Betrag in der "Mitte" der Summe steht, oder am "unteren Rand".
Ich habe dieses Verhalten mit einer neuen Tabelle überprüft und rekonstruiert.
Zum besseren Verständnis habe ich zwei Screenshots angehängt.
Einmal steht der "Betrag" 33,08 am Ende der Summe, die Summe ergibt 17,50... Die errechnete Mehrwertsteuer liegt bei 3,32 (falsch).
Im zweiten Bild habe ich die 33,08 in die Mitte der Summe geschrieben, diese ergibt ebenfalls 17,50... Die errechnete Mehrwertsteuer liegt nun bei 3,33 (richtig).
Hat irgendjemand eine Erklärung dazu?
Grüße,
Parallax
ich habe heute eine Rechnung in Calc geschrieben und dabei festgestellt das zwei Rechnungen mit der gleichen Nettosumme eine unterschiedliche Mehrwertsteuer aufweisen. Die Berechnung der Werte erfolgt in beiden Tabellen identisch.
Zuerst wird eine Summe gebildet, diese dann mit 0,19 multipliziert.
Dabei kommt Calc auf ein unterschiedliches Ergebnis, je nach dem ob ein Betrag in der "Mitte" der Summe steht, oder am "unteren Rand".
Ich habe dieses Verhalten mit einer neuen Tabelle überprüft und rekonstruiert.
Zum besseren Verständnis habe ich zwei Screenshots angehängt.
Einmal steht der "Betrag" 33,08 am Ende der Summe, die Summe ergibt 17,50... Die errechnete Mehrwertsteuer liegt bei 3,32 (falsch).
Im zweiten Bild habe ich die 33,08 in die Mitte der Summe geschrieben, diese ergibt ebenfalls 17,50... Die errechnete Mehrwertsteuer liegt nun bei 3,33 (richtig).
Hat irgendjemand eine Erklärung dazu?
Grüße,
Parallax
- Dateianhänge
-
- calcFehler2.JPG (36.81 KiB) 1379 mal betrachtet
-
- calcFehler1.JPG (36.67 KiB) 1379 mal betrachtet
Re: Seltsames Verhalten von Calc, Rundungsfehler
Hallo Parallax,
ich habe arg den Verdacht das deine Ergebnisse nicht alle an der 2. Stelle nach dem Komma enden, sondern das die Fehler durch Rundungsfehler entstehen.
Das lässt sich aber nur in der Calc-Datei überprüfen.
Daher auch hier noch mal den Hinweis, das Bilder nur suboptimal sind.
Besser mal die Beispiel-Datei hier hoch laden
Gruß Holger
ich habe arg den Verdacht das deine Ergebnisse nicht alle an der 2. Stelle nach dem Komma enden, sondern das die Fehler durch Rundungsfehler entstehen.
Das lässt sich aber nur in der Calc-Datei überprüfen.
Daher auch hier noch mal den Hinweis, das Bilder nur suboptimal sind.
Besser mal die Beispiel-Datei hier hoch laden
Gruß Holger
Re: Seltsames Verhalten von Calc, Rundungsfehler
Ich teile die Ansicht von @ echo, Habe mit den in deinem Screenshot sichtbaren Daten eine Tab. gefüttert und in zwei Spalten eingegeben. In Spalte D wird auf Spalte C verwiesen, also ist nur die Position des "inkriminierten" Wertes von - 33,08 vertauscht. Ergebnis scheint mir ok zu sein. Daher schau doch mal nach ob es sich nicht um Rundungsfehler aus vorhergehenden Berechnungen handelt?
Gruß, HelmutopenSUSE Leap 42.3 / Linux Mint 18.3 / Win 10-64
LO 6.02.1
LO 6.02.1
Re: Seltsames Verhalten von Calc, Rundungsfehler
Hi,
ich konnte das Verhalten nachstellen.
Diese Einstellung hat das Problem behoben Wird mit dem Dokument gespeichert.
Gruß R
ich konnte das Verhalten nachstellen.
Diese Einstellung hat das Problem behoben Wird mit dem Dokument gespeichert.
Gruß R
- miniKasse MMove 1.0.6 Base Videotutorial
- Windows 7: OOo, AOO, LO Linux Mint: OOo, AOO, LO
Re: Seltsames Verhalten von Calc, Rundungsfehler
In der ursprünglichen Tabelle werden die Werte tatsächlich aus Berechnungen erzeugt.
Bei meinem Test jedoch habe ich die Werte händisch eingetragen, ergo ist ein Rundungsfehler aus vorheriger Rechnung auszuschließen.
Desweiteren konnte der User "F3K Total" das Problem ja nachstellen.
Ergo rechnet Calc aus unbekannter Ursache anders, wenn der Wert am Ende der Summe steht, als wenn er mitten drin auftaucht. Dies ist definitiv ein Bug. Warum die Funktion Genauigkeit wie angezeigt das Problem behebt, ist mir auch nicht schlüssig, da es ja hier definitiv keine Rundungen gibt.
Der genaue Betrag der MwSt. wäre 3,325 was gerundet nach gängigen mathematischen Regeln 3,33 ergibt, was Calc ja auch richtig tut, wenn deiner der Betrag 33,08 nicht am Ende, sondern in der Mitte der Summe steht. Dies darf definitiv nicht sein.
Kann man irgendwie ein Ticket an den Entwickler der Software schreiben?
Grüße,
Andre
Bei meinem Test jedoch habe ich die Werte händisch eingetragen, ergo ist ein Rundungsfehler aus vorheriger Rechnung auszuschließen.
Desweiteren konnte der User "F3K Total" das Problem ja nachstellen.
Ergo rechnet Calc aus unbekannter Ursache anders, wenn der Wert am Ende der Summe steht, als wenn er mitten drin auftaucht. Dies ist definitiv ein Bug. Warum die Funktion Genauigkeit wie angezeigt das Problem behebt, ist mir auch nicht schlüssig, da es ja hier definitiv keine Rundungen gibt.
Der genaue Betrag der MwSt. wäre 3,325 was gerundet nach gängigen mathematischen Regeln 3,33 ergibt, was Calc ja auch richtig tut, wenn deiner der Betrag 33,08 nicht am Ende, sondern in der Mitte der Summe steht. Dies darf definitiv nicht sein.
Kann man irgendwie ein Ticket an den Entwickler der Software schreiben?
Grüße,
Andre
Re: Seltsames Verhalten von Calc, Rundungsfehler
Hallo Andre,
viewtopic.php?f=27&t=54231&sid=7238a1a8 ... b7#p207702
klar, die Antwort steht seit einigen Jahren im Unterforum "FAQs"Kann man irgendwie ein Ticket an den Entwickler der Software schreiben?
viewtopic.php?f=27&t=54231&sid=7238a1a8 ... b7#p207702
Re: Seltsames Verhalten von Calc, Rundungsfehler
Hey Andre,
In LibreOffice sind beide Zahlenspalten gleich... egal wie angeordnet. Also die Summen etc. Hier gibt es keine Rundungsdiffernezen.
Meine gestestet Version: LO 5.3.1.2 - Win 10.
VG
Tom
In LibreOffice sind beide Zahlenspalten gleich... egal wie angeordnet. Also die Summen etc. Hier gibt es keine Rundungsdiffernezen.
Meine gestestet Version: LO 5.3.1.2 - Win 10.
VG
Tom
Unterstützer LibreOffice, zertifizierter Trainer und Berater
Bücher: LibreOffice 6- Einstieg und Umstieg
Makros Grundlagen - LibreOffice / OpenOffice Basic
Bücher: LibreOffice 6- Einstieg und Umstieg
Makros Grundlagen - LibreOffice / OpenOffice Basic
Re: Seltsames Verhalten von Calc, Rundungsfehler
Hallo
das einzige was wir haben sind deine Bilder und die Tabelle von Helmut der so frei war und die Tabelle mit deinen sichtbaren Werten nachgestellt hat. Ich kann es auch für Calc bestätigen das es bei der Tabelle keinerlei Unterscheide bei den Ergebnissen gibt, egal in welcher Reihenfolge die Werte stehen. Für mich ist der Fehler daher auch nicht in der Position der Werte sondern in dem Ursprung der berechneten Werte zu suchen.
Die Suche können wir hier aber auch nur führen, wenn diese auch zur Verfügung stehen.
Gruß Holger
Re: Seltsames Verhalten von Calc, Rundungsfehler
Das ist ein interessanter Effekt und ich erlaube mir, Toxitom vom 7.12.2017 zu zitieren:
viewtopic.php?f=2&t=68763#p272712
Das Verhalten ist bei mir in LO 4.4.7 und in LO 5.3.7 reproduzierbar!
1. Die Multiplikation mit der MwSt. ist nicht nötig. Der Fehler tritt schon in der Addition auf.
2. Das Phänomen wird sichtbar, wenn die Stellenanzeige auf 14 Stellen eingestellt wird.
3. Das Phänomen zeigt sich auch, wenn die Addition nur in einer einzigen Zelle stattfindet.
4. Das Phänomen hängt von der Stellung der »-33,08« ab (andere Konstellationen habe ich nicht ausprobiert).
Zum Nachstellen:
Schreibe in eine einzige Zelle und stelle 14 Nachkommastellen ein.
=945+17,5+157,5-1069,42-33,08 ergibt 17,49999999999990
=945-33,08+17,5+157,5-1069,42 ergibt 17,50000000000000
Gruß Andreas
"[...] ist wahrscheinlich kein Calc-Problem. Computer können nicht exakt rechnen .. da wird es immer Rundungsfehler geben. Hängt mit der Bitweisen Verarbeitung zusammen... und gerade bei Fliesskomma-Zahlen tritt das Problem öfter auf.
Du kannst Deine Fehler itterieren - und wirst feststellen, dass der Fehler lediglich exakt in Deiner Konstellation auftritt. Was soll ich sagen? Pech gehabt?
Ist halt echt Pech. Jetzt müsstest Du in den Prozessor einsteigen, wie der die Bit-Zahlen addiert - und den Fehler dort suchen [...]"
viewtopic.php?f=2&t=68763#p272712
Das Verhalten ist bei mir in LO 4.4.7 und in LO 5.3.7 reproduzierbar!
1. Die Multiplikation mit der MwSt. ist nicht nötig. Der Fehler tritt schon in der Addition auf.
2. Das Phänomen wird sichtbar, wenn die Stellenanzeige auf 14 Stellen eingestellt wird.
3. Das Phänomen zeigt sich auch, wenn die Addition nur in einer einzigen Zelle stattfindet.
4. Das Phänomen hängt von der Stellung der »-33,08« ab (andere Konstellationen habe ich nicht ausprobiert).
Zum Nachstellen:
Schreibe in eine einzige Zelle und stelle 14 Nachkommastellen ein.
=945+17,5+157,5-1069,42-33,08 ergibt 17,49999999999990
=945-33,08+17,5+157,5-1069,42 ergibt 17,50000000000000
Gruß Andreas
Re: Seltsames Verhalten von Calc, Rundungsfehler
Da muss ich mich korrigieren. Das seltsame Rundungsverhalten tritt schon wie vom TE beschrieben auf, aber erst wenn man die Nachkommastellen auf 2 reduziert. Bei 3 Nachkommastellen werden in den Zellen D12 + E12 in beiden Fällen 3,325 angezeigt.
Eine weitere Kuriosität sieht man wenn man in Zelle E11 die Nachkommastellen erhöht. Bei 2 Kommastellen wird 17,5 angezeigt; erst bei der 13. Kommastelle springt die Zahl um auf 17,4999999999999.
In allen Fällen war dabei unter Extras --> Optionen --> "Genauigkeit wie angezeigt" AUSgeschaltet.
Schon sehr seltsam. Gruß Helmut
Eine weitere Kuriosität sieht man wenn man in Zelle E11 die Nachkommastellen erhöht. Bei 2 Kommastellen wird 17,5 angezeigt; erst bei der 13. Kommastelle springt die Zahl um auf 17,4999999999999.
In allen Fällen war dabei unter Extras --> Optionen --> "Genauigkeit wie angezeigt" AUSgeschaltet.
Schon sehr seltsam. Gruß Helmut
openSUSE Leap 42.3 / Linux Mint 18.3 / Win 10-64
LO 6.02.1
LO 6.02.1
Re: Seltsames Verhalten von Calc, Rundungsfehler
Guten Abend,
das Problem bei der Sache ist, glaube ich, letztendlich das, was der User Lupp aus München im englischen Forum schreibt,
da tobt nämlich gerade auch die Diskussion.
Hier der Link dazu: https://forum.openoffice.org/en/forum/v ... 3&start=30
Es ist so, dass Informatiker lernen müssen, wie oft Schleifen (das ist ein Berstandteil von Programmiertechniken, für den es nicht weiß) durchlaufen; und bei Datentypen wie Float z.B. oder Single, Double gibt es die irrwitzigsten Fehler und Fehlannahmen seitens der Schüler. Du hast nämlich dann ganz oft eine Endlosschleife programmiert, oder ebend eine Schleife, die erst gar nicht anfängt, weil die Zahl im Computer intern nicht exakt getroffen werden kann. Man unterliegt da oft irrwitzigen Fehlkalkulationen, denkt, sie müsse 100 mal durchlaufen, läuft aber kein einziges Mal durch.
Denkt in diesem Zusammenhang bitte auch an Pi; es gibt Zahlen, die brechen nie ab und haben eine "chaotische" Nummernfolge (willkürlich, nicht so wie z.B. die Periode bei 1/7). Ich denke, damit hat es auch irgendwie zu tun.
Der Rechner ist nicht in der Lage, Brüche exakt darzustellen, die gehen immer ins Unendliche, weil nur 0 und 1 - Zustand gekannt wird.
Puh, also Leute, jetzt bloß nicht alle zu "Chaos-Fans" werden, woll? :-)
Oft sind die Postings von clag sehr interessant in solchen Fragen. Vielleicht meldet er sich ja mal über die freien Tage.
Wie gesagt, ich kann mich dunkel erinnern, dass Lupps Posting das entscheidende dazu ist.
"0.0101010101 + 0.0101010101 + 0.0101010101 = 0.1111111111 <> 1 " etc.
Es ist sehr schwierig bis unmöglich, eine Kommazahl im Computer realistisch abzubilden mit dem Bit, das wir haben, und das nur zwei Zustände kennt
Vielleicht ist es eine Lösung, alle Rechnungen mit 100 zu multiplizieren, damit das vermaledeite Komma wegfällt?
Gruß, ChristianAC
das Problem bei der Sache ist, glaube ich, letztendlich das, was der User Lupp aus München im englischen Forum schreibt,
da tobt nämlich gerade auch die Diskussion.
Hier der Link dazu: https://forum.openoffice.org/en/forum/v ... 3&start=30
Es ist so, dass Informatiker lernen müssen, wie oft Schleifen (das ist ein Berstandteil von Programmiertechniken, für den es nicht weiß) durchlaufen; und bei Datentypen wie Float z.B. oder Single, Double gibt es die irrwitzigsten Fehler und Fehlannahmen seitens der Schüler. Du hast nämlich dann ganz oft eine Endlosschleife programmiert, oder ebend eine Schleife, die erst gar nicht anfängt, weil die Zahl im Computer intern nicht exakt getroffen werden kann. Man unterliegt da oft irrwitzigen Fehlkalkulationen, denkt, sie müsse 100 mal durchlaufen, läuft aber kein einziges Mal durch.
Denkt in diesem Zusammenhang bitte auch an Pi; es gibt Zahlen, die brechen nie ab und haben eine "chaotische" Nummernfolge (willkürlich, nicht so wie z.B. die Periode bei 1/7). Ich denke, damit hat es auch irgendwie zu tun.
Der Rechner ist nicht in der Lage, Brüche exakt darzustellen, die gehen immer ins Unendliche, weil nur 0 und 1 - Zustand gekannt wird.
Puh, also Leute, jetzt bloß nicht alle zu "Chaos-Fans" werden, woll? :-)
Oft sind die Postings von clag sehr interessant in solchen Fragen. Vielleicht meldet er sich ja mal über die freien Tage.
Wie gesagt, ich kann mich dunkel erinnern, dass Lupps Posting das entscheidende dazu ist.
"0.0101010101 + 0.0101010101 + 0.0101010101 = 0.1111111111 <> 1 " etc.
Es ist sehr schwierig bis unmöglich, eine Kommazahl im Computer realistisch abzubilden mit dem Bit, das wir haben, und das nur zwei Zustände kennt
Vielleicht ist es eine Lösung, alle Rechnungen mit 100 zu multiplizieren, damit das vermaledeite Komma wegfällt?
Gruß, ChristianAC