OpenOffice.info

Hallo,

ich habe zu dem Thema schon andere Foreneinträge gefunden, jedoch noch nicht zu meiner speziellen Frage.

Calc kann ja anscheinend nur mit 15 signifikanten Stellen umgehen, so weit so gut. Bei einer Zahl mit mehr sign. Stellen sollte man dann aber doch erwarten, dass mathematisch korrekt gerundet wird.

Folgendes habe ich festgestellt:

In eine Zelle habe ich den Wert 42840 eingetragen (der 15.04.2017 00:00:00 in Zahlenschreibform)
Zu diesem Wert möchte ich nun 0,00694444444444444 (10 min, so genau wie calc es eben kann) aus einer anderen Zelle addieren.
Man sollte doch nun das Ergebnis 42840,0069444444 erwarten. Stattdessen gibt calc aber das Ergebnis 42840,0069444445 heraus. Das ist doch ganz klar ein Rundungsfehler. Warum wird hier die letzte Stelle auf- statt abgerundet?

Danke für jede Hilfe!

Hey,

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?

42840 + 0,000694444444444444 -> 42840,00069444444
42840 + 0,00694444444444444 -> 42840,00694444445
42840 + 0,0694444444444444 -> 42840,06944444444

Ist halt echt Pech. Jetzt müsstest Du in den Prozessor einsteigen, wie der die Bit-Zahlen addiert - und den Fehler dort suchen;)

Aber ich glaube, Du findest einen Weg, mit solchen "Ungenauigkeiten" umzugehen.

VG
Tom

Du kannst Deine Fehler itterieren - und wirst feststellen, dass der Fehler lediglich exakt in Deiner Konstellation auftritt. Was soll ich sagen? Pech gehabt?

Hmm, das finde ich nicht gerade zufriedenstellend. Gerade bei der EDV hatte ich gedacht, dass diese (wenn keine Schnitzer in der Software stecken) absolut fehlerfrei arbeiten sollte. Es gibt in der Mathematik schließlich nicht "ein bisschen richtg".

Ich danke dir für deine Antwort aber vielleicht hat jemand anderes ja noch eine andere Erklärung. Ansonsten würde ich tatsächlich auf eine schlampige Programmierung bei OpenOffice tippen...

drbrode hat geschrieben: ↑Do, 07.12.2017 15:42 Ansonsten würde ich tatsächlich auf eine schlampige Programmierung bei OpenOffice tippen...

Und was hat das mit OpenOffice zu tun? Ich denke, dass diese Rundung eher auf elementareren Eigenschaften beruht (aber gebe zu, ich bin kein Informatiker oder Mathematiker).

aber vielleicht hat jemand anderes ja noch eine andere Erklärung

Meine Erklärung ist die das Du die Situation falsch beurteilst, denn nicht mit mehr als 15 signifikanten Stellen umgehen zu können, heisst doch auch genau das Selbige, und ich sehe keinen Grund zu meinen das hiesse das alles falsch sein dürfte nur das Runden nicht, denn Runden selbst ist bereits eine Art des Rechnens.

Hmm, das finde ich nicht gerade zufriedenstellend. Gerade bei der EDV hatte ich gedacht, dass diese (wenn keine Schnitzer in der Software stecken) absolut fehlerfrei arbeiten sollte. Es gibt in der Mathematik schließlich nicht "ein bisschen richtg".

In der Tat, Mathematik ist genau.

EDV hingegen ist eher nicht so genau, insofern es nahezu keine fehlerfreien Programme gibt. Wenn Du bei EDV etwas besonders genau haben willst bist Du eher stets auf spezialisierte Programme angewiesen, wobei ich Dir bei Calc nun auch keine genaue Definition geben könnte für welcher Art Berechnungen Du das einsetzen kannst und für was nicht.

Wenn Du hingegen in Tabellenkalkulation mit Zahlen mit sehr vielen Stellen rechnen willst lässt sich das auch sehr genau machen wenn Du mittels Strings Berechnungen durchführst. Per händisch eingegebener Formeln ist das etwas kompliziert, weshalb es für MS Excel dafür spezialisierte AddIns gibt, z.B.:
http://www.excel-ticker.de/in-excel-mit ... uer-excel/

ob inzwischen auch bereits für Calc, weiß ich garnicht.
Hier im Forum kommt das Thema alle 1-2 Jahre auf und jedesmal sage ich mir ich müsste mal eine Extension programmieren, gemacht habe ich das aber bisher nicht. Vielleicht kennt ja jemand eine entsprechende Extension?

Ansonsten schau Dir diese Beispielarbeitsmappe an:
http://www.excelformeln.de/tips.html?welcher=24


Gruß
Stephan

Moin,
ich verstehe das Problem nicht, bin da eher der Pragmatiker.
Wenn ich in Zelle A1 genau heute, Tag 43076 der Calc-Zeitrechnung eintrage und in Zelle B1 die 10 Min mit 1/144 eintrage, dann diesen Wert bis in Zeile 1.048.576 jeweils vom Vorgänger abziehe, also quasi alle 10 Min seit heute durch Subtraktion vom Vorgängerwert darstelle, lande ich am Ende beim 30.12.1997 05:30:00, also vor knapp 20 Jahren und der Rechenfehler liegt bei 73,2419081032276 /1000 Sekunden.
Eigentlich wollte ich eine Beispieldatei anhängen, die ist jedoch bei 1.048.576 Zeilen bereits größer als 10 MB, was für das Forum zu viel ist.
Gruß R

Hallo drbrode,

Es gibt in der Mathematik schließlich nicht "ein bisschen richtg".

Oh doch! Das gibt es!
Wie? Du glaubst mir nicht?

Beispiele:
In der Metallverarbeitende Industrie ist es richtig, das Maßangaben bis zu 3 Stellen nach dem Komma angegeben werden können, manchmal reichen auch 2, aber das hängt vom Bearbeitungsverfahren ab.

So und nun das Non-Plus-Ultra Paradebeispiel schlechthin dafür das "auch ein bischen richtig" richtig ist.

"Ab wann ist es richtig eine unendlich Lange Nachkomazahl verkürzt darzustellen?"

Ich sage nur ein Wort Pi (π)!

Der momentan aktuelle Weltrekord liegt bei 22,4 Billionen Stellen nach dem Komma. Es ist aber wohl nicht verkehrt, also es ist wohl richtig, das man Pi nicht unbedingt auf dem aktuellen Weltrekord-Niveau ausschreiben muss um mit π zu rechnen. Und dadurch ist es ein "bisschen" richtig, das z.B. 6 Stellen nach dem Komma ausreichen, obwohl π unendlich ist. Und mit diesen 6 Stellen nach dem Komma kann man sehr genaue Berechnungen anstellen, ohne das das Ergebniss Falsch ist, weil es ja nicht mit Zich-Millionen, oder sogar mit Sextillion Stellen berechnet wurde.

Aber je nach gefordeter Genauigkeit kann man sich aussuchen ob 6, oder 12 Stellen zur Berechnung herangezogen werden müssen.

Was mich jetzt aber verwirrt, ist folgendes.
Stört dich das mit dem "ungenauen Runden" allgemein, oder geht es dir doch nur um den speziellen Fall mit der Zeit-Addition?



Gruß
balu

Oh doch! Das gibt es!
Wie? Du glaubst mir nicht?

Beispiele:
In der Metallverarbeitende Industrie ist es richtig, das Maßangaben bis zu 3 Stellen nach dem Komma angegeben werden können, manchmal reichen auch 2, aber das hängt vom Bearbeitungsverfahren ab.

Entschuldigung Balu, aber Du missverstehst Deinen Vorredner, Mathematik ist so genau weil man theoretisch etwas genau beschreiben (berechnen, darstellen ...) kann, im Gegensatz zur Praxis wo man das eben nicht kann. Mathematisch kann man eine exakte Kugel berechnen, aber niemand kann eine exakte Kugel bauen, aus keinem Material der Welt, denn spätestens wenn Du Dir die Oberfläche unter einem Elektronenmikroskop ansieht siehst Du irgendwann die 'Huckel' der einzelnen Atome und die kannst Du nicht 'glattschleifen'.

Ich finde leider gerade kein Bild einer Metalloberfläche, aber hier im Bild siehst Du eine Graphitoberflöche und die verschwommenen 'Berge' sind die einzelnen Kohlenstoffatome des Graphits:




das geht also nicht glatter zu bearbeiten. Mathematik hingegen kann die Oberfläche natürlich vollkommen glatt beschreiben mittels einer Formel.


Gruß
Stephan

Hallo Stephan,

Entschuldigung Balu, aber Du missverstehst Deinen Vorredner, Mathematik ist so genau weil man theoretisch etwas genau beschreiben (berechnen, darstellen ...) kann,

Entschuldigung bitte, aber im Kontext "Rundungsfehler und EDV" ergibt die Aussage

drbrode hat geschrieben: Es gibt in der Mathematik schließlich nicht "ein bisschen richtg".

einen anderen Sinn, als den Du darlegst. Denn für mich heißt das, das an der richtigen, und nicht an einer willkürlichen Stelle gerundet werden muss und dazu auch noch nach der richtigen Rundungsmethode: 0 bis 4 Abrunden und 5 bis 9 Aufrunden.

Ich finde leider gerade kein Bild einer Metalloberfläche

Das brauchst Du mir doch nicht zu zeigen , bin doch schließlich Metaller. Egal wie stark und wie oft man z.B. eine Aluminium Oberfläche schleift und poliert, sie wird nie wirklich Glatt. Und das kann man sogar mit einem speziellen Gerät messen, und das Ergebnis wird z.B. in Ra ausgegeben,.... Aber lassen wir das, das geht sonst zu sehr ins unverständliche (für Laien) Off-Topic.


Fakt ist: Man kann mit den was man hat nicht genauer arbeiten/rechnen, als es möglich ist. Und ob sich ein wie gezeigter Rundungsfehler überhaupt bemerkbar macht, zeigt sich erst in der Praxis. Will man es genauer, dann muss man z.B. mindestens eine andere Software einsetzen.

Meine persönliche Meinung. Man kann es auch mit der Genauigkeit übertreiben. Denn es bringt mir doch nix, wenn ich weis das meine Armbanduhr in 100 Jahren 0,5 Sekunden nachgeht, ich aber nur 73 Jahre alt werde.



Gruß
balu

Hallo Balu,

aber im Kontext "Rundungsfehler und EDV"

Man kann mit den was man hat nicht genauer arbeiten/rechnen, als es möglich ist

Genau das ist richtig, aber genau das ist EdV und Praxis und dem gegenüber stehen Mathematik und Theorie.

Es ist der Fehler Deines Vorredners gewesen zu glauben EdV sei so genau wie Mathematik, nur Du (Balu) hattest Dich, meiner Meinung nach, missverständlich ausgedrückt, denn zitiert hattest Du Mathematik gemeint aber EdV.

Meine persönliche Meinung. Man kann es auch mit der Genauigkeit übertreiben.

Das ist sogar mehr als Deine Meinung, nämlich ein Faktum, denn es wird in Praxis richtigerweise immer so genau gearbeitet wie nötig und nicht wie möglich, gleichzeitig hat in Praxis jedes Maß seine Toleranz.

z.B. ist es in Praxis unmöglich eine Tomatenspirale von absolut genau 1,80 m herzustellen und aber gleichzeitig auch unnötig Selbige mit einer Genauigkeit von 1800 +- 0,001 mm herstellen zu wollen, sondern es genügt beispielsweise 1800 +- 5 mm (wobei Toleranzen nicht immer symmetrisch sein müssen)

Gut so?

in Ra ausgegeben

Nö, "Ra" sagt mir spontan nichts (außer ein Papyrusboot von Heyerdahl hieß "Ra" ). Auch wollte ich Dich wirklich nicht belehren.
Ich selbst bin aber auch nicht nur ein 'Studierter' sondern weiß als Autodidakt auch viel über Praxis. Was Metallbearbeitung betrifft habe ich z.B. viel von einem Formenbauer (Metallformen für Plastspritzguss) gelernt und beispielsweise in meiner Jugend selbst Kolben für Modellmotoren gedreht.


Gruß
Stephan

Hey drbrode,

Hmm, das finde ich nicht gerade zufriedenstellend. Gerade bei der EDV hatte ich gedacht, dass diese (wenn keine Schnitzer in der Software stecken) absolut fehlerfrei arbeiten sollte. Es gibt in der Mathematik schließlich nicht "ein bisschen richtg".

Genauer? Fehlerfrei? Offensichtlich bist Du in keinem der Themen wirklich drin. "Genauer" und "Fehlerfrei" gibt es in beiden Disziplinen nicht. "annäherung" ist das Thema:)

Ganz einfaches Beispiel:

Ein ganzes wird in drei gleicheTeile aufgeteilt - ein ganz einfaches Problem des Alltags. Die drei gleichen Teile werden wieder zum Ganzen zusammengefügt. Logisch, für jeden nachvollziehbar. Und wir lernen schon in der Grundschule:
Das Ganze in drei gleiche Teile: ein Teil = 1/3 -> 3* 1/3 oder genauer 1/3 + 1/3 +1/3 = 3/3 = 1. Passt und ist logisch:)

Und nun setze es in ein Zahlensystem um:

1 dividiert durch 3 = 0,333333 ---- und je mehr stellen Du berechnest - jede wird immer 3 sein. Unendlich.

Jetzt addieren wir die 3 Teile wieder : 0,33 + 0,33 + 0,33 = 0,99 egal wieviel Stellen du berechnest. 1 kommt nie wieder raus.

Ein Prozessor auf Transitorbasis macht auch nix anderes (EDV) - nur mehr und schneller;) Trotzdem kommt da nie wieder 1 raus ... es sei denn, man rundet. UNd da beginnt halt die "Unschärfe" - wann runden? Wie runden? Nimm nicht die einfache Rechnung sondern komplexe - 100000fache Additionen und Subtraktionen - da vervielfältigst Du auch die Fehler.

Für gute Programmierer heisst das dann auch: Nie glatte Zahlen als Grenzen (Bedingungen) direkt zuweisen... das wird immer zu Fehlern führen.

Nimm das obrige Beispiel:

n = 1 / 3 ' n wird eine Fliesskommazahl mit dem WErt 0,33333.....
n2 = 0,0 'auch eine Fließkommazahl

do while not n2=1
n2 = n2 + n
loop

Wird die Abbruchbedingung nie erreichen - Rechner hängt sich auf....

Hier müssen dann "unscharfe" Bedingung geprüft werden, etwa soetwas wie

do while not n2>= 1
....

Das sind die Themen, mit denen Du Dich beschäftigen musst - ist kein Programmierfehler in AOO(LO.

Viele Grüße
Tom

Na da hab ich jetzt ja anscheinend eine Grundsatzdiskussion ausgelöst.

Auch wenn es ein wenig am ursprünglichen Thema vorbei geht möchte ich auch nochmal kurz darauf eingehen.

Ich bleibe bei meiner Aussage: Mathematik ist eine exakte (genaue) Wissenschaft! In der Praxis müssen wir selbstverständlich des Öfteren auf "ungenaue Modelle" zurückgreifen und dagegen ist auch nichts einzuwenden, solange das Ergebnis mit einer für uns ausreichenden Genauigkeit erreicht wird. (Stichwort Kreisberechnung: natürlich brauche ich pi nicht mit 2,4 Billionen stellen verwenden, wenn ich den Kreisumfang eines Bierdeckels auf 1 mm genau ausrechnen möchte, nichtsdestotrotz könne die Mathematik es leisten, ein exaktes Ergebnis mit unendlich vielen Nachkommastellen zu errechnen)

Es ist der Fehler Deines Vorredners gewesen zu glauben EdV sei so genau wie Mathematik

Vielleicht habe ich mich in der Eile da ein wenig missvertändlich ausgedrückt. Ich wollte nicht behaupten, dass die EDV genauso exakt wie die Mathematik ist. (Das habe ich mit meinem obigen Beispiel glaube ich dargelegt.) Ich wollte eher ausdrücken, dass die EDV die Regeln der Mathematik exakt anwenden muss und hierzu gehört auch das Runden. Hier gibt es dann tatsächlich nicht ein "bisschen richtig". 3x3 ergibt 9 und nicht "ungefähr 10" (auch wenn das für den ein oder anderen vielleicht "ausreichend genau" sein könnte ) und 1,4 wird auf 1 abgerundet! Das muss die EDV doch leisten können...

Nun aber zurück zum Thema.

Woran ich mich gestört habe ist die Tatsache, dass in meinem beschriebenen Beispiel offenbar eine fehlerhafte mathematische Operation von calc durchgeführt wurde. Wie Toxitom auch schon aufführte:

42840 + 0,000694444444444444 -> 42840,00069444444
42840 + 0,00694444444444444 -> 42840,00694444445

Das ist irgendwie nicht einzusehen. Wenn calc nur mit 15 signifikanten Stellen umgehen kann ist das ja in Ordnung und selbstverständlich muss dann auch an irgendweinere Stelle gerundet werden aber man sollte doch erwarten können, dass diese Operation dann korrekt ausgeführt wird. Und wenn die relevante Stelle einer zu rundenen Zahl auf die Ziffer "4" lautet, dann bedeutet das mathematisch korrekt, dass abgerundet wird. Da gibt es doch nichts dran zu rütteln. Ob der Fehler jetzt im Prozessor oder im Code von OpenOffice zu suchen ist sei mal dahingestellt, bin kein Informatiker. (Ich bin allerdings der laienhaften Meinung, dass eine solche "Rundung" nicht durch die Hardware begrenzt ist... )

Nochmal zum Hintergrund meines Problems:

Ich habe in einer Tabelle eine Spalte mit Zeitstempeln im 5-Minuten-Abstand. Diese habe ich so generiert, dass ich zu einem variablen Startwert in jeder neuen Zeile immer der Wert 1/288 addiere. Die Tabelle enthält dann in den weiteren Spalten Einträge zu den jeweiligen Zeitpunkten.
An einer anderen Stelle führe ich jetzt eine Abfrage dieser Tabelle durch und benutze hier für den Befehl "SVERWEIS". Wenn ich in das Abfragefeld nun ein "Datum+10 min" (also z.B. 42840,0069444444) eigebe, findet er den dazugehörigen Eintrag nicht, da in meiner Liste ja der fehlerhaft gerundete Wert 42840,0069444445 steht.

Ich weiß auch, dass ich mir hier im Rahmen einer bestimmten Genauigkeit durch weitere Rundungen weiterhelfen kann. Allerdings ging es mir schon ein wenig um den Grundssatz meiner Feststellung.

Ich wollte eher ausdrücken, dass die EDV die Regeln der Mathematik exakt anwenden muss und hierzu gehört auch das Runden.

Und was nutzt diese Feststellung wenn das ein bestimmten Programm einfach nicht tut, weil da ein Programmfehler oder eine Begrenzung ist?



Gruß
Stephan

Und was machte man früher, in der Anfangszeit des Computers? Man multiplizierte anfangs mit einer so großen Zahl, so dass die Dezimalzahl zur Ganzen wurde, dann rechnete man und schließlich teilte man durch den Eingangsmultiplikator. So wurde aus der Dezimalarithmetik (die sowieso keine im Prozessor war) wieder eine Ganzzahlarithmetik mit abschließender Umrechnung. Hierdurch trat ein Rundungsfehler nur einmal auf.
Ob das bei deinem Problem allerdings jetzt hilfreich ist, habe ich nicht geprüft.

Das ist irgendwie nicht einzusehen.

Stimmt, aber wohl weil Du viel zu viel reininterpretierst, wohingegen sich die Programmierer überhaupt nicht soviele Gedanken gemacht haben.
Zumindest ich nehme jedenfalls an der Hintergrund ist banal: man sah (oder wusste) das Calc nur bis 15 Stellen richtig rechnete und erklärte das als garantierte Grenze bis zu der Calc richtig rechnet. Das dann Calc bei höheren Stellenzahlen plötzlich doch wieder richtig rechnet interessierte niemanden mehr, weil das ja quasi schon oberhalb der (willkürlich) festgelegten Stellenobergrenze ist.


Gruß
Stephan