rechnet Calc falsch?

[newbie-01]

moin,

mein zweiter Name wäre ja 'Fehlerfinder', aber auf dem Standesamt wollten sie das nicht eintragen ...

ich finde gerne mal Fehler wo andere Leute das für ausgeschlossen halten ...

ich bin bei Problemen mit Filterungen darauf gestoßen daß diverse Werte die bei mir in der Tabelle 'sauber' mit zwei Dezimalstellen angezeigt werden 'im Hintergrund' 'länger' sind (Anzeige z.B. 19,50 - wenn man die Dezimalstellen erweitert wird daraus 19,499999999999997 oder so ähnlich)

nun wollte ich den Mist 'wegmachen', kann mir die Zahlen auch per autofilter suchen, und Ursachen wie Teilungen durch 9, vergessenes Runden usw. beheben.

Aber den Fehler in den anhängenden Tabellen kriege ich nicht begriffen

calc_ulationsfehler.ods

(11.88 KiB) 361-mal heruntergeladen

calc_ulationsfehler.xls

(7.5 KiB) 362-mal heruntergeladen

Es werden mehrere 'glatte' Beträge miteinander verrechnet, und plötzlich taucht in Zelle C1 an der elften Nachkommastelle eine 1 auf ...

also normal ist das nicht ... oder?

meine Analyse bisher:

die Werte ringsum sind! glatt,

man kann den Fehler auf ein anderes Blatt kopieren, er bleibt erhalten, es ist also kein Fehler in der Datei,

auch bei Speichern und Neuaufrufen bleibt der Fehler, kann also kaum an defekten Speicher oder sonstwo an meinem Rechner liegen?

Wenn man die Datei aus LO als .xls abspeichert bleibt der Fehler,

wenn man die .xls mit Excel (2010) aufruft ist er weiter da,

wenn man die .ods mit Excel aufruft erkennt Excel 'unlesbaren Inhalt', 'repariert' die Datei, ersetzt alle Formeln durch Zahlen und schreibt in C1 das korrekte!!! Ergebnis ... ????

Überlegung Rundungsfehler ... es werden 'nur' drei auf 17 Nachkommastellen glatte Werte aufaddiert, da könnte ich mir versteckte 'Reste' in der 18 Nachkommastelle und ein Auftauchen in der 17-ten vorstellen, aber nicht in der 11.

Noch lustiger: wenn ich in LO und der .ods Datei die Summe in C1 ändere und z.B. 'D1' weglasse wird das Ergebnis richtig ... wenn ich das gleiche in Excel und mit der .xls Datei mache bleibt es falsch ... da kann man mir zum Storch den Frosch gleich mitbraten ...

der Fehler ist für das Ergebnis meiner Berechnungen eher 'Portokasse', aber es nervt daß er z.B. in Filterungen 'hineingrätscht', und daß ich mich auf mein System nicht verlassen kann solange ich nicht weiß woran dieses merkwürdige Verhalten liegt ...

kann eine(r) mal so lieb sein und gucken ob der Fehler auf anderen Systemen reproduzierbar ist?

und hat jemand eine Idee wie man das Problem eingrenzen bzw. analysieren kann?

vielen Dank im Voraus ...



newbie-01

System:

LibreOffice:
Version: 5.4.6.2 (x64)
Build ID: 4014ce260a04f1026ba855d3b8d91541c224eab8
CPU threads: 2; OS: Windows 6.1; UI render: default;
Locale: de-DE (de_DE); Calc: group

unter:
Win7 home premium SP1

auf :
einem alten thinkpad T500,
Intel(R) Core(TM)2 Duo CPU P8600 @2.40GHz 2.40 GHz,

Hintergründe (für die dies interessiert):

Die Tabelle teilt Buchungen in Nettobetrag und Steuer auf und errechnet den neuen Kontostand, das ganze wächst von unten nach oben. Nervig ist daß Calc - etwas zusammengeraten - beim Filtern aus einem Makro heraus den angezeigten! Stringwert der Zelle als Kriterium nimmt, dieses Kriterium aber mit dem 'Wert' in der Zelle vergleicht, und damit Zellen bei denen Anzeige und 'echter Inhalt' voneinander abweichen falsche Filterungsergebnisse liefern ...

[Lupo]

https://de.wikipedia.org/wiki/Gleitkomm ... Gleichheit
http://scienceblogs.de/von_bits_und_byt ... en-teil-2/
(und sicher viele besser verständliche Links)

... eines der häufigsten Unverständnisse auch in Excel-Foren.

[Pit Zyclade]

Es geht um die "Portokasse" ? Also Geldbeträge? Dann arbeite doch mit der Funktion RUNDEN(...;2) und summiere hinterher. Nicht zu verwechseln mit ABRUNDEN() und AUFRUNDEN() . Das Resultat ist dann sehr genau und stimmig vor allem.

[newbie-01]

moin,

hat irgendjemand den Fehler bei sich auch sehen können? Oder ist es eine 'Eigenart' meines Rechners?

Gleitkommazahlen - kenne ich eigentlich, auch daß sie nur gestufte diskrete Werte darstellen können etc.

Runden - habe! ich überall eingebaut wo krumme Werte entstehen könnten.

(ich könnte jetzt natürlich einfach auch die Ergebnisspalte runden lassen ... aber irgendwie ist mir nicht nach unnötig vielen Formeln in einer Tabelle, und irgendwie möchte ich gerne genauer begreifen wie diese Tabellenkalkulation tickt)

Die aufaddierten Zahlen C2, D1 und G1 sind! alle glatt bis 17 Stellen nach dem Komma.

Es macht keinen Sinn Zahlen in derartiger Genauigkeit anzuzeigen wenn im Hintergrund so verhältnismäßig gröbere Fehler lauern bzw. möglich sein sollten. Der Fehler mit der 1 an der 11. Stelle ist 1 Million mal größer als die Anzeige der Zahlen angibt die addiert werden.

Weder Gleitkommaungenauigkeiten noch Rundungsfehler - oder fehlendes Runden - erklären für mich irgendwie plausibel diese Fehler.

Sie erklären auch nicht warum genau dieser Fehler - 1 zuviel oder zuwenig an der 11. Nachkommastelle - in meiner Tabelle zigfach auftritt, während größere Abweichungen oder Abweichungen an anderen Stellen kaum vorkommen - geschätzt 100:1 'für' die 11. Stelle.

Und auch nicht warum Excel beim 'reparieren' der .xls Tabelle den Wert richtig berechnen kann.

Und auch nicht warum der Fehler verschwindet wenn ich in LO den Summanden D1 weglasse, und verschwunden bleibt wenn ich ihn wieder hinzufüge. Er müßte ja mindestens wieder entstehen wenn ich danach über <ctrl-z> den Ausgangszustand wieder herstelle. Tut er aber auch nicht, er bleibt hartnäckig verschwunden.

Eiegntlich wäre damit ja alles ok, Fehler weg, so wollen wir das haben, aber 'manchmal taucht Fehler auf den man nicht begreift' ... so will ich! das nicht haben.

Da ist noch irgend etwas anderes ungenau, ein Fehler drin den ich noch nicht kapiere, eine Schraube locker die nicht locker sein sollte.

[Lupo]

Eigentlich rundet man nur. Mehr tut man nicht! Schon gar nicht fragen, wenn man die Gleitkomma-Abhandlungen nicht verstehen möchte ...

Noch'n Tipp: Du kannst um das Runden auch herumkommen: Extras Optionen Calc Berechnen [x] Genauigkeit wie angezeigt.

Und bitte nicht darüber lästern, was 95% aller selbsternannten Fachleute tun! Es ist gerade für kfm. Dinge eine schöne Sache, weil RUNDEN dort nervt wie Kropf. Und wer nicht weiß, wie er trotzdem genauer berechnet, als man anzeigt, hat schlicht keine Fantasie ...

[Helmut_S]

Hallo "Fehlerfinder", bei mir mit LO 6.0.2.1 unter Win10-64 HP sehe ich keine "1" an der 11. Stelle von Zelle C1

und plötzlich taucht in Zelle C1 an der elften Nachkommastelle eine 1 auf ...

soviel zu deiner Fesstellung. Oder brauche ich eine neue Brille?

hat irgendjemand den Fehler bei sich auch sehen können? Oder ist es eine 'Eigenart' meines Rechners?

Zur Problematik Genauigkeit von Tabellenkalkulationsprogrammen hat dir ja Lupo schon Anregungen zur Lektüre gegeben.

Calc_Fehler.jpg (70.21 KiB) 8745 mal betrachtet

Grüße, Helmut

[newbie-01]

hi all,

@Lupo: danke, allgemeine Infos über floats hatte ich, ich war aufgrund oben mehrfach wiederholter logischer Überlegungen überzeugt daß der bei mir auftretende Fehler nicht! daran liegt, insbesondere auch weil calc ja nach der Fehlerstelle noch lauter nette Nullen darstellt ... etwas herumprobieren brachte nun folgende konkrete Erkenntnis:

!!!Calc rechnet wohl richtig, aber zeigt falsch an!!!

(bzw. täuscht eine Genauigkeit vor die nicht existiert)

und zwar sind die Zahlen die bei mir in der Tabelle auftauchen - ohne daß ich etwas besonderes dazu bestimmt hätte - in Ihrer Genauigkeit auf 15 bis 16 'signifikante Stellen' beschränkt. Die darüberhinaus anzeigbaren Dezimalstellen sind 'verloren', bzw. Quatsch, bzw. Augenwischerei.

Die 15 bis 16 Stellen gelten für Vor- und Nachkommastellen zusammen, d.h. bei 12.3456,78901234567 wird in der 9-ten Nachkommastelle zu 12.3456,789012346 gerundet, während bei 1,2345678901234567 'erst' die 15-te Nachkommastelle rausfliegt und 1,23456789012346 daraus wird.

Daß das dann bei Anzeige mit 20 Dezimalstellen als 1,23456789012346000000 angezeigt wird ist ... irritierend.

Es hat! aber einen gewissen Sinn daß Calc mehr Dezimalstellen für die Anzeige zuläßt als es in diesen Beispielen rechnet, man kann ja auch Zahlen wie 0,00001234567890123456 ... verarbeiten wollen, das müßte möglich sein und braucht die 20 Dezimalstellen. Ist probiert, ist möglich.

Es scheint daß bei Zahlen >=1 nur 15 Stellen funktionieren, unter 1 aber 16 Stellen gehen ... und könnte sein daß bei negativen Zahlen die Beschränkungen noch etwas anders sind ... ???

Noch'n Tipp: Du kannst um das Runden auch herumkommen: Extras Optionen Calc Berechnen [x] Genauigkeit wie angezeigt.

das scheint's 'zu bringen'!

@Helmut_S: danke, das war die Sorte Hilfe die ich brauche, wenn du dir meinen screenshot

calc_ulationsfehler.jpg (26.67 KiB) 8727 mal betrachtet

anschaust wirst du verstehen daß ich 'leicht irritiert' war ... warum ein Fehler aus der Schwierigkeit mit 'gestuften Zahlen' Werte dazwischen darzustellen nicht überall gleich auftritt ist mir vorerst nicht klar ... vllt. ... siehe unten ...

@Entwickler: vielleicht ... vielleicht ... vielleicht ... macht es Sinn beim Verrechnen von Zahlen auf die letzten - 5? - berechneten Ziffern zu gucken, und wenn die entweder 00001 sind, oder 99999, davon auszugehen daß der Anwender eigentlich mit glatten Werten rechnen wollte, und daß die Abweichung aus einem Rundungsfehler resultiert, und die dann einfach 'plattzumachen ... aber vielleicht - wahrscheinlich - ist die Lösung von Lupo einfacher und allgemeingültiger ...

vielen Dank,



newbie-01

[Wanderer]

Hallo,

@Entwickler: vielleicht ... vielleicht ... vielleicht ... macht es Sinn beim Verrechnen von Zahlen auf die letzten - 5? - berechneten Ziffern zu gucken, und wenn die entweder 00001 sind, oder 99999, davon auszugehen daß der Anwender eigentlich mit glatten Werten rechnen wollte, und daß die Abweichung aus einem Rundungsfehler resultiert, und die dann einfach 'plattzumachen ...

NEIN!!!

Calc kann nicht wirklich autoomatisch entscheiden, wann ein Wert gerundet werden muß, das ist DEINE Aufgabe.
Ich habe eher eine naturwissenschaftliche Ausbildung und was mir zu der Idee einfällt, daß meine Meßwerte gelegentlich (aber nicht immer)
"plattgemacht" werden, weil das jemandem hilft, der nicht mehr als 2 Stellen nach dem Komma kennt, möchte ich lieber nicht
schriftlich fixieren.
(Wenn das irgend ein Justizministerium als Gesetz formuliert, habe ich natürlich nichts dagegen; Pi=3 gab es wohl schon mal)

Für Dein Problem gibt es 2 Lösungen:
Genauigkeit, wie angezeigt, wie schon beschrieben und
generelles Rechnen mit ganzzahligen Pfennig-/Cent-Beträgen, da dann definiert ist daß immer gerundet werden muß.

MfG, Jörn

PS: Solange Du als Newbie-01 schreibst, solltest Du vielleicht mal überlegen, ob einige von den Dingen, die dir gerade als
Weisheit durch den Kopf gehen nicht vielleicht von diversen Leuten vor 20 bis 40 Jahren schon ausführlich diskutiert
und eventuell sogar mit guten Gründen anders entschieden wurden.

[Helmut_S]

Hallo newbie-01 alias "Fehlerfinder", zu deiner weiteren Be(un)ruhigung anbei Tabelle auf der du durch Eingeben verschiedener Werte bei Exponent und/oder (+/-1) nachvollziehen kannst, ab welchen Zahlen Calc "falsch" rechnet.
Für dein

@Entwickler: vielleicht ... vielleicht ... vielleicht ...

ist dieses Forum aber die falsche Adresse, da liest kein Entwickler mit. Wenn du deine vermeintlich gefundenen Fehler "an den (richtigen) Mann oder Frau" bringen willst, musst du schon direkt einen Bugreport bei den Machern von LO einreichen.
Vorher empfehle ich dir aber, über das Thema zu googlen oder bei Wikipedia nachzulesen was es mit der Rechen-Genaugkeit von Tabellenkalkulationsprogrammen auf sich hat.
Es gibt übrigens auch Methoden, mit denen man, zumindest für die 4 Grundrechnungsarten, Calc oder Excel die doppelte, also 28-stellige Genaugikeit beibringen kann. Wahrscheinlich nützlich für betuchte Herrschaften mit einem dicken Bankkonto ?

Genauigkeit_Calc.ods

(28.33 KiB) 352-mal heruntergeladen

Gruß Helmut

[Lupo]

Was sagt uns die Datei von Helmut_S?

• Keine 28stellige Genauigkeit dort dargestellt. Aber hier: http://www.rendar.de/
• (16stellige) Kreditkartennummern, die nicht mit 9 anfangen, können als Zahl dargestellt werden (in Excel geht das nicht). Falls es aber welche mit 9 gibt, bringt einem das auch nichts! Unter https://www.kreditkarte.net/ratgeber/kr ... tennummer/ findet man da aber nur welche mit "Nationalen Anwendungen"