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: 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 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: 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: 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, 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
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
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
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
