Re: Falschrechner
Hi, > Gibt es keine Möglichkeit solche Fehler zu vermeiden, wenn man =(A7=48,55) rechnet? mir fällt dazu nur folgendes ein: =Kürzen(...;2) bzw. =Runden(...;2) verwenden oder: Menü Extras - Einstellungen - OpenOffice Calc - Berechnen: -> [X] Genauigkeit wie angezeigt Gruß Oliver - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Falschrechner
Hallo, das ist nicht nur in Calc so, sondern das Problem tritt auch in Programmiersprachen auf. Man kann daher vernünftigerweise nie zwei berechnete Werte auf Gleichheit direkt überprüfen, sondern man muss sie vorher runden oder beim Vergleich eine minimale Abweichung akzeptieren - also wenn Absolutwert(VarA - VarB) < z.B. 0,1 dann als gleich werten. MfG Alois -- www.easy4me.info technik schrieb am 12.11.2015 um 15:58: Hallo, ich habe schon wieder so einen dummen Fehler, wo das Programm anscheinend falsch rechnet. a+b-c=d aber dann ist d<>d; Abweichung 10E-13 aber für die Überprüfung ergibt das eben ein Falsch. Kommt das bei Euch auch raus oder rechnet mein Rechner falsch? Gibt es keine Möglichkeit solche Fehler zu vermeiden, wenn man =(A7=48,55) rechnet? Wäre einfacher als =(A7-48,55)<0,001 oder gar =ABS(A7-48,55)<0,001 Ich weiß, dass es wohl ein Problem der Fließkommarundung ist, aber trotzdem ist da irgendetwas schief, wenn der Rundungsfehler von 10E-13 bei zwei Nachkommastellen nicht abgefangen wird. 48,55 -7,25E-013 510,46 + 22082,64 + 22544,55 - 48,55 =SUM -7,24753590475302E-013 =Sum-48,55 Formel in a6: =A4+A5-A6 Oder die Datei https://www.dropbox.com/s/pf372p4oo0rrf4s/falschrechner.ods?dl=0 Horst
Re: Falschrechner
Am 12.11.2015 um 15:58 schrieb technik: > > ich habe schon wieder so einen dummen Fehler, wo das Programm > anscheinend falsch rechnet. > a+b-c=d aber dann ist d<>d; Abweichung 10E-13 aber für die Überprüfung > ergibt das eben ein Falsch. > > Kommt das bei Euch auch raus oder rechnet mein Rechner falsch? Ja; nein. Das sind technisch bedingte Rundungsfehler. > Gibt es keine Möglichkeit solche Fehler zu vermeiden, wenn man > =(A7=48,55) rechnet? | =(Runden(A7;2)=Runden(48,55;2)) (ggf. auch AB~/AUF~; wichtig ist, immer *beide* Vergleichswerte auch *gleich* zu behandeln) > Wäre einfacher als =(A7-48,55)<0,001 Dumm nur, wenn A7 < 48,54 ist ... > Ich weiß, dass es wohl ein Problem der Fließkommarundung ist, aber > trotzdem ist da irgendetwas schief, wenn der Rundungsfehler von 10E-13 > bei zwei Nachkommastellen nicht abgefangen wird. *Du* denkst *dezimal*. Der *Rechner* denkt *binär* (und zwar immer mit voller Genauigkeit). Aber nicht jeder dezimal endliche Wert ist erstens auch *binär* als /endlicher/ Wert darstellbar (genauso wenig wie es im dezimalen Zahlenraum solche Werte gibt, z. B. 1/3), und zweitens muss bei Rechenoperationen manchmal die Genauigkeit beschnitten werden, so dass auch die Verknüpfung endlicher Werte manchmal einen nicht-endlichen Wert ergeben kann. Und bei der Subtraktion in A6 kommt halt nun mal 'nur' 48,54993 raus. Wolfgang -- - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Falschrechner
Hallo, > From: Wolfgang Jäth [mailto:jawo.ml.hams...@arcor.de] > *Du* denkst *dezimal*. Der *Rechner* denkt *binär* (und zwar immer mit > voller Genauigkeit). Sorry, aber genau das stimmt doch hier nicht. Die Rechenungenauigkeiten in Calc gehen darauf zurück das Calc das gerade nicht tut sondern nur mit einer Genauigkeit von (ich glaube) 15 Stellen rechnet. Excel übrigens auch. Tipps (für Excel die sich aber auf Calc übertragen lassen) siehe: http://www.excelformeln.de/tips.html?welcher=24 http://www.excel-ticker.de/in-excel-mit-sehr-grossen-zahlen-rechnen-teil-1-additio n/ Gruß Jörg - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Falschrechner
Auch mit unendlich vielen Nachkommastellen gibt es Ungenauigkeiten. Am 13.11.2015 um 08:02 schrieb Jörg Schmidt: > Hallo, > >> From: Wolfgang Jäth [mailto:jawo.ml.hams...@arcor.de] > >> *Du* denkst *dezimal*. Der *Rechner* denkt *binär* (und zwar immer mit >> voller Genauigkeit). > > Sorry, aber genau das stimmt doch hier nicht. Die Rechenungenauigkeiten in > Calc > gehen darauf zurück das Calc das gerade nicht tut sondern nur mit einer > Genauigkeit von (ich glaube) 15 Stellen rechnet. Excel übrigens auch. > > Tipps (für Excel die sich aber auf Calc übertragen lassen) siehe: > http://www.excelformeln.de/tips.html?welcher=24 > http://www.excel-ticker.de/in-excel-mit-sehr-grossen-zahlen-rechnen-teil-1-additio > n/ > > > Gruß > Jörg > > > - > To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org > For additional commands, e-mail: users-de-h...@openoffice.apache.org > > - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Falschrechner
Hallo, binär zu dezimal und umgekehrt führt in der Tat zu Fehlern. Hierfür gibt es ein berüchtigtes Beispiel: Python 3.2.3 (default, Feb 20 2013, 17:02:41) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 0.3+0.6 0.8999 >>> (0.3*10+0.6*10)/10 0.9 >>> (Neuere Python-Versionen haben diesen Fehler auch noch.) Wie man sieht kann Python3 mit einem Trick durchaus genau rechnen. Am problematischsten ist wohl der Umstand, dass Python 0.8999 von 0.9 sehr wohl unterscheidet: >>> 0.3+0.6 == (0.3*10+0.6*10)/10 False >>> Traut keinem Computer ungeprüft! Gruß Michael signature.asc Description: OpenPGP digital signature
Re: Falschrechner
Hallo an alle, danke für die ganzen Antworten. Ist alles nicht so befriedigend. Dass dieser Fehler beim Dividieren auftritt kann ich ja noch verstehen, aber beim Addieren von Zahlen mit 7 Stellen dürfte so ein Fehler eigentlich nicht auftreten. Ich hätte gedacht, dass inzwischen jemand eine bessere routine gefunden hätte, die Addition genau zu machen. Aber ich vermute, das läßt sich mit dem benutzten System nicht mehr verwirklichen. Vielleicht sollte ich meine Kasse auf Cent statt Euro umstellen, dann könnte ich Integers benutzen :-) Aber zumindest werde ich aufpassen und wenn ich genaue Werte brauche auf Integers setzen. Horst Am 13.11.2015 um 08:02 schrieb Jörg Schmidt: Hallo, From: Wolfgang Jäth [mailto:jawo.ml.hams...@arcor.de] *Du* denkst *dezimal*. Der *Rechner* denkt *binär* (und zwar immer mit voller Genauigkeit). Sorry, aber genau das stimmt doch hier nicht. Die Rechenungenauigkeiten in Calc gehen darauf zurück das Calc das gerade nicht tut sondern nur mit einer Genauigkeit von (ich glaube) 15 Stellen rechnet. Excel übrigens auch. - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Falschrechner
Hallo, > From: technik [mailto:technik_...@jrsch.de] > danke für die ganzen Antworten. Ist alles nicht so befriedigend. Dass > dieser Fehler beim Dividieren auftritt kann ich ja noch > verstehen, aber > beim Addieren von Zahlen mit 7 Stellen dürfte so ein Fehler > eigentlich > nicht auftreten. Ach, warum denn nicht (da Du ja augenscheinlich veerstehst warum er beim Dividieren auftritt)? > Ich hätte gedacht, dass inzwischen jemand eine bessere > routine gefunden > hätte, die Addition genau zu machen. Hierzu kenne ich die Absichten der OO und LO-Programmierer nicht. Bei OOo war bei Calc eine möglichst weitgehende Formelkompatibilität zu MS Excel das Ziel und das würde dann auch hier gelten, denn auch Excel hat diese Begrenzungen. > Aber ich vermute, das läßt sich mit dem benutzten System nicht mehr > verwirklichen. Doch, genau das ist möglich, ich hatte es doch extra verlinkt: http://www.excel-ticker.de/in-excel-mit-sehr-grossen-zahlen-rechnen-teil-1-additio n/ auch um dadurch deutlich zu machen das es sich bei dem Problem um eine Begrenzung der Implementierung handelt und um keine technische Grenze, denn die Lösung im Link braucht keine Zusatzsoftware sondern nutzt das vorhandene 'System', also Excel, es geht mit Caslc aber genauso. Im Übrigen gibt es für Excel auch fertige AddIns, für Calc weiß ich das monentan nicht. Gruß Jörg - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Falschrechner
On 16.11.2015 23:05, technik wrote: > Vielleicht sollte ich meine Kasse auf Cent statt Euro umstellen, dann > könnte ich Integers benutzen :-) > Diese Idee ist gar nicht einmal so falsch (jedenfalls wenn Du nicht mit Bruchteilen von Cents (Benzinpreise, Devisenkurse, Börsenkurse etc.) rechnen musst). Wenn man dann am Ende durch 100 teilt, was meist ohne "Unfälle" möglich ist, hat man ein Ergebnis, dem man etwas mehr vertrauen kann. Gruß Michael signature.asc Description: OpenPGP digital signature
Re: Falschrechner
On 17.11.2015 07:42, Jörg Schmidt wrote: >> Ich hätte gedacht, dass inzwischen jemand eine bessere >> routine gefunden >> hätte, die Addition genau zu machen. > > Hierzu kenne ich die Absichten der OO und LO-Programmierer nicht. Das Problem ist IMO, dass die Fehler schon in den grundlegenden Programmiersprachen auftreten. Sie sind wohl für binäre Computer fundamental. Man müsste also "Workarounds" mit allen "Risiken und Nebenwirkungen" schreiben. Gruß Michael signature.asc Description: OpenPGP digital signature
Re: Falschrechner
hallo, Am 17.11.2015 um 09:47 schrieb RA Stehmann: On 17.11.2015 07:42, Jörg Schmidt wrote: Das Problem ist IMO, dass die Fehler schon in den grundlegenden Programmiersprachen auftreten. Sie sind wohl für binäre Computer fundamental. Man müsste also "Workarounds" mit allen "Risiken und Nebenwirkungen" schreiben. Genau das meinte ich. Ich hatte früher mal in Assembler reingeschaut und auch mal was einfaches programmiert. Alles was wir heute haben basiert ja darauf. Jede Zahl ist genau auf 0 oder 1 am Ende. Nur die Umwandlung... Die damaligen Fehler wurden mitgenommen. Den Y2k Fehler hatte man ja damals in den Griff bekommen, aber an der Dekodierung einer Dezimalzahl kann man nichts mehr ändern, außer man beginnt ganz von vorne. Genau sind ja auch andere Standards praktisch festgelegt. Praktisch alle Schnittstellen, an denen Austausch stattfindet. Das heißt, man muss auf Anwenderseite den Fehler abfangen. Gut, das war mir bisher nicht wirklich klar. Als ich heute morgen meinem Sohn den Fehler erklärte, wurde mir klar, dass wir auch im Papierzahlenbereich einen ähnlichen Fehler haben. 1/3 +2/3 können wir rechnen. In Dezimal gibt es einen Fehler. 0,9_ <>1 Das denken wir uns weg. Horst - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Falschrechner
Hallo, > From: RA Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] > Das Problem ist IMO, dass die Fehler schon in den grundlegenden > Programmiersprachen auftreten. Das weiß ich nicht konkret und wollte deshalb (schon vor einigen Tagen) nichts dazu schreiben, weil genau das ein Aspekt ist der die Entscheidung der Programmierer beeinflusst haben könnte. > Sie sind wohl für binäre Computer > fundamental. > Man müsste also "Workarounds" mit allen "Risiken und > Nebenwirkungen" schreiben. Eigentlich nicht. Ich habe doch gerade deswegen betont das man die Berechnung auch mit Calc bzw. Excel-Bordmitteln richtig durchführen kann und weil das so ist ist es augenscheinlich eine Implementierungsfrage in Calc/Excel und nicht des, verkürzt gesagt, Kompilers oder der Betriebssystemumgebung allgemein. Gruß Jörg - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Falschrechner
Hallo, > From: technik [mailto:technik_...@jrsch.de] > Genau das meinte ich. Ich hatte früher mal in Assembler > reingeschaut und > auch mal was einfaches programmiert. Alles was wir heute > haben basiert > ja darauf. Aber das tut nichts Negatives zur Sache, denn nun zum Dritten Male: Calc kann mit Bordmitteln richtig rechnen, man muss es nur programmieren. Es gibt keine Begrenzung diesbezüglich, sondern es ist ein Implementierungsproblem. Wäre es anders brauchte es Zusatzsoftware (z.B. zusätzliche Programmbibliotheken) um innerhalb von Calc das ganz genaue Rechnen zu implementieren, aber die braucht es nicht, es ist alles vorhanden so wie Calc ist, einzig greift Calc nicht auf die Möglichkeiten zurück, jeder kann das aber selbst tun wenn er Makros schreiben kann. Jede andere Interpretation steht ungefähr auf denselben Füssen wie die Aussage man kann mit einem Taschenrechner nur Quadratzahlen berechnen wenn er dafür eine spezielle Taste hat (unter Ignorierung das man auch mit der *-Taste das Produkt zweier gleicher Zahlen berechnen kann und damit die Quadratzahl hat). Gruß Jörg - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Falschrechner
On 18.11.2015 08:24, Jörg Schmidt wrote: > Und ja, man kann echte Begrenzuungen einer verwendeten Programmiersprache > klar von > Sachverhalten unterscheiden die nur auf Implementierungsentscheidungen > zurückgehen. > "Implementierungsentscheidungen" sind immer eine Abwägung. Natürlich kann man in jeder Programmiersprache (Du hast es ja für Calc quasi "bewiesen") Routinen einbauen, die ein genaueres Rechnen mit Dezimalzahlen ermöglichen. Nur ist dies nicht nur Programmieraufwand, sondern die Ausführung dieser Routinen ist auch Rechenaufwand und kostet letztendlich Rechenzeit (oder anders ausgedrückt, es verlangsamt die Programmausführung). Dann stellt sich natürlich die Frage nach Aufwand und Ertrag. In wieviel Prozent der Fälle führen die Routinen tatsächlich zu relevant genaueren Ergebnissen und in wieviel Prozent der Fälle ist das dem Nutzer dann noch egal (entweder aus Ignoranz oder weil der errechnete Wert eh' jenseits aller Mess- oder sonstigen Genauigkeiten liegt)? Ich glaube daher, dass man zu dem Ergebnis gelangen kann, dass man denen, die auf genauere Berechnungen Wert legen, eigene diesbezügliche Vorsorge zumuten kann und muss. Gruß Michael My computer has no brain; so I have to use my own. signature.asc Description: OpenPGP digital signature
Re: Re: Falschrechner
Am Dienstag, 17. November 2015, 16:40:14 schrieb Jörg Schmidt: > Hallo, > > > From: RA Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] > > > > Das Problem ist IMO, dass die Fehler schon in den grundlegenden > > Programmiersprachen auftreten. > > Das weiß ich nicht konkret und wollte deshalb (schon vor einigen Tagen) > nichts dazu schreiben, weil genau das ein Aspekt ist der die > Entscheidung der Programmierer beeinflusst haben könnte. Das ganze ist nicht nur ein Problem der Programmiersprache _und_ der verwendeten Algorithmen (vor allem der Algorithmen), sondern auch ein Problem der Zahlendarstellung. Bei Binär-Computern (damit sind auch Taschenrechner gemeint) haben wir grundsätzlich das Problem, dass sich Gleitkommazahlen grundsätzlich nicht als Zweierpotenz, also binär, endlich abbilden lassen. Die ganz banale Zahl 2/3 ( zwei drittel) lässt sich analog als 0,666... darstellen. Wobei die drei Punkte andeuten sollen, dass unendlich viele 6 kommen. Mach das mal mit einer 52bit-Mantisse mit 11bit- Exponent. Kann uU ungenau werden. Das ganze nennt sich Maschinenungenauigkeit und Rechnen mit Gleitkommazahlen: https://de.wikipedia.org/wiki/Gleitkommazahl https://de.wikipedia.org/wiki/Maschinengenauigkeit -- Mit freundlichen Grüßen Matthias Müller (Benutzer #439779 im Linux-Counter http://counter.li.org) PS: Bitte senden Sie als Antwort auf meine E-Mails reine Text-Nachrichten! signature.asc Description: This is a digitally signed message part.
Re: Re: Falschrechner
Hallo, > From: Matthias Müller [mailto:matth_mueller_...@posteo.de] > Das ganze ist nicht nur ein Problem der Programmiersprache [...] Das ist es sogar am Allerwenigsten, was ich nun bereits mehrfach betont habe und zu verdeutlichen versucht habe. > Mach das mal mit einer 52bit-Mantisse mit 11bit- > Exponent. Warum sollte ich? Warum sollte ich mir Rahmenbedingungen für die Implementierung suchen wo ich von vornherein weiß ich werde bei der Genauigkeit scheitern? Wir (als Menschen) wissen wie man mit Brüchen genau rechnet und ich als Programmierer weiß wie ich sowas auch in einem Programm implementieren kann. Warum reden wir stattdessen immer über Dezimalzahlen um uns dann beruhigt zurückzulehnen weil es damit nicht genau geht? Kapiere ich nicht. Aber selbst das (warum das nicht umgesetzt wird) ist ja nicht das eigentliche Thema hier gewesen, sondern es geht (mir) eigentlich nur um die Klarheit das die rechnerischen Ungenauigkeiten in Calc eine Frage der Implementierungsentscheidung sind und eben nicht der Programmiersprache oder der Betriebssystemumgebung, etc. ... und das nicht nur in allgemeiner Aussage sondern gant konkret im 'Hier und Heute' denn Calc hat bereits alles an Bord um genau rechnen zu können. Anmerkung: Es geht mir auch garnicht darum das es in Calc anders gemacht werden soll, denn die heutige Implementierung ist aus Kompatibilitätsgründen sehr wahrscheinlich sinnvoll. Es geht mir nur darum das ich hier (im Thread insgesamt) viele Dinge zur Begründung gelesen habe die ich auf rein technischer Ebene für falsche Begründungen halte. Und ja, man kann echte Begrenzuungen einer verwendeten Programmiersprache klar von Sachverhalten unterscheiden die nur auf Implementierungsentscheidungen zurückgehen. Gruß Jörg - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
