Seltsames Verhalten von Calc, Rundungsfehler

[MrParallax]

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

[echo]

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

[Helmut_S]

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?

Rundungsfehler.ods

(8.76 KiB) 36-mal heruntergeladen

Gruß, Helmut

[F3K Total]

Hi,
ich konnte das Verhalten nachstellen.
Diese Einstellung hat das Problem behoben

G1.PNG (19.42 KiB) 1884 mal betrachtet

Wird mit dem Dokument gespeichert.
Gruß R

[Gast]

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

[freedom]

Hallo Andre,

Kann man irgendwie ein Ticket an den Entwickler der Software schreiben?

klar, die Antwort steht seit einigen Jahren im Unterforum "FAQs"
viewtopic.php?f=27&t=54231&sid=7238a1a8 ... b7#p207702

[Toxitom]

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

[echo]

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

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

[Gast Andreas]

Das ist ein interessanter Effekt und ich erlaube mir, Toxitom vom 7.12.2017 zu zitieren:

"[...] 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

[Helmut_S]

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.

Rundungsfehler02.ods

(9.02 KiB) 34-mal heruntergeladen

Gruß Helmut

[ChristianAC_]

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