Google Taschenrechner ungenau?

...komplette Frage anzeigen

3 Antworten

Ein genaueres Ergebnis bekommst du bei Wolfram Alpha

http://www.wolframalpha.com/input/?asynchronous=false&equal=Submit&i=917+%2F+23

Die Ungenauigkeit liegt nicht daran, dass du dich verrechnet hast (du bist also leider keiner großen Verschwörung auf der Spur ;)), sondern daran, wie Gleitkommazahlen im Computer abgespeichert werden.

https://de.wikipedia.org/wiki/IEEE_754

Die Zahl wird also quasi als Vorzeichen * Mantisse * 2^Exponent abgespeichert, wobei Mantisse und Exponent ganze Zahlen mit einer begrenzten maximalen Größe sind. Somit ist klar, dass auf diese Weise nicht jede beliebige Dezimalzahl gespeichert werden kann.

Dadurch ergeben sich logischerweise Ungenauigkeiten, vor allem, wenn man am Ergebnis noch hin- und herrechnet. Und dass man auf die exakte 16. Nachkommastelle noch Wert legt, ist schon extrem genau.

Habs ja nicht für irgendeine Aufgabe oder so gemacht, sondern nur weil mir langweilig war. Und da rechne ich immer bis die Periode neu anfängt, wenn es denn eine gibt ;) Trotzdem vielen Dank für die Erklärung und den besseren Rechner, werde ich gleich mal ausprobieren :)

1

Besser nicht auf wolframalpha.com verlassen ;). Es könnte auch da vorkommen, dass schon die ersten paar Stellen grob falsch sind.

0

Computer rechnen immer ungenau...Menschen, wenn sie sich auf ein Zahlensystem festlegen, ja auch. Wenn Du 1/3 rechnest und die '0.333...' bis zum Ende schreiben wölltest, geht Dir irgendwann das Papier aus. Dem Computer passiert sinngemäß das gleiche...

Die Systeme werden deshalb so ausgelegt, dass sie für den üblichen Anwendungsfall passend sind - die Ingeneure bei Google haben sich offenbar gedacht, dass 14 Nachkommastellen für ein kostenloses Angebot ausreichend sind.

Problematisch kann das bei Software werden, die auf "Gleichheit" prüft. So könnte es zb durchaus sein, dass Du bei der Frage "Ist 1/3 + 1/3 +1/3 = 1" ein "falsch" herausbekommst...

Tatsächlich rechnen manche Online-Rechner falsch. Das Problem liegt darin, dass mit Binärzahlen gerechnet wird, die ihrerseits nicht exakt dezimal-Zahlen wiedergeben können.

Ausserdem sind viele Standarddatentypen nach 15 Stellen hinter dem Komma mit der Ganauigkeit erschöpft. Auch wenn das Endergebnis durch Multiplikation die Kommastellen nach vorne schiebt, gegen Informationen verloren, wenn zwischendurch die Kommastellen mehr als 15 betragen.

Es gibt eine Lösung: "binary coded decimals" das machen aber viele Rechner nicht.

Deine exakte Lösung lautet:

39,(PERIODE) 869652173913043478260

Hier ist ein Rechner, der das alles kann:
http://www.wolframalpha.com/input/?i=917%2F23

Jup, das Ergebnis hatte ich auch raus, habe es nur nicht ganz aufgeschrieben, weil ja der Fehler schon davor drinne war (also der Fehler beim Rechner). Aber gut zu wissen, dass ich noch im Kopd rechnen kann und dass die Taschenrechner "schon" ab 16 Nachkommastellen ungenau werden, hätte ich auch nicht gedacht

1
@Abstauba

Das ist im Bezug aufs Finanzwesen Quatsch. Gerade im Finanzwesen wird eben nicht gerundet, sondern gerade dort muss ganz genau gerechnet werden. Wenn ich tanken fahre, hat der Kraftstoff einen Preis mit 3 Nachkommastellen (die letzte Stelle ist immer eine "9"). Es wäre schon doof, wenn die Anzeige an der Zapfsäule nicht den richtigen Preis anzeigt, weil sich bei einer Rundung auf 4 Stellen ziemlich bald Rundungsfehler einschleichen. Und das ist nur ein kleines Beispiel. Ein Notar (bzw. seine Software), die mit Millionenbeträgen hantiert, darf sich nicht verrechnen, auch nicht um ein paar Cent. 

Entweder wird dann ein anderer Datentyp genommen, der nicht IEEE 754-konform ist (z.B. Decimal in C#, für viele andere Programmiersprachen gibt es Libraries) oder Vor- und Nachkommastellen werden komplett getrennt als Ganzzahlen abgespeichert.

Bei dem GPS-Tracker aus dem verlinkten Kommentar hingegen ist eine all zu hohe Genauigkeit nicht nötig (weil GPS aus physikalischen Gründen nicht so genau ist), aber auch dort sind es mehr als 4 Nachkommastellen.

0
@ceevee

Anscheinend schreibst du aus der Theorie heraus. Denn die 4 Nachkommastellen sind Fakt im Bankensektor.

Natürlich ist die Aussage zu pauschal um auf alle Prozesse im Finanzwesen angewendet werden zu können.

Die entstehenden Rundungsfehler werden deswegen akzeptiert, weil die sich auf beiden Seiten genügend rausmitteln.

0
@Abstauba

Gibt es für den "Fakt im Bankensektor" auch eine Quellenangabe? Was ich gefunden habe, war, dass bei Währungsumrechnungen 6 Nachkommastellen relevant sind, die "auf keinen Fall gerundet oder gekürzt werden dürfen".

http://www.bankazubi.de/wissenspool/artikel.php?opid=2&fachgebietid=1&katid=5&artikelid=81

Und ich halte die 4 Nachkommastellen für unrealistisch niedrig, da schon die IEEE-Gleitkommazahl genauer rechnet, und diese läuft auch auf alten Computern beinahe in Echtzeit, womit Performance in dem Fall kein Argument ist. 

1
@ceevee

Deine Quelle bin ich, da ich für eine zentrale IT im Bakensektor arbeite. Aber natürlich (wie gesagt) darf das nicht als pauschal gelten. Die Fehler rechnen sich aber nach und nach für beide Seiten raus. Die Statistik der großen Zahlen. ;-)

0
@ceevee

Zu der Frage, wie viele Nachkommastellen im Finanzwesen mitgenommen werden, kann ich leider auch nichts sinnvolles beitragen. Allerdings hatte ich in meiner Ausbildung einen kleinen Einblick in die Host-Welt der Banken, die noch immer zu großen Teilen auf Cobol laufen. Wenn ich mich richtig erinnere war es da so, dass für die relevanten Nachkommastellen jeweils 4(?) Bit verwendet wurden, um die Probleme bei der Float-Darstellung zu umgehen. Das erkauft man sich natürlich mit einem gewissen Performanceverlust...

(Ob das "kein Argument" ist würde ich im Übrigen mal bezweifeln...bei der Anzahl an Buchungen, die große Banken heutzutage haben, macht Kleinvieh ganz schön viel Mist...)

0
@oelbart

Wenn bei einem Zins von 0,0001% für einen Wert von 0,01 Euro die Werte am Ende 0,0000 Euro sind und beide Seiten mit diesem Verfahren einverstanden sind, dann gibt es kein Problem.

0

Was möchtest Du wissen?