Google Taschenrechner ungenau?

3 Antworten

Vom Fragesteller als hilfreich ausgezeichnet

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

Java: Rechenoperatoren und Zahlen in einem String --> Ergebnis ausrechnen

Hallo zusammen,

bei einem Java-Projekt, das ich seit einigen Tagen programmiere, stehe ich nun kurz vor der Vollendung. Es fehlt aber noch ein kleiner letzter Schritt. Und zwar habe ich einen String, in dem eine komplizierte Rechnung (bestehend aus + - * / und Klammern) steht. Ich möchte nun das Ergebnis dieser Rechnung ausgeben. Leider kann ich es nicht einfach hintereinander (von links nach rechts) rechnen, da ja Klammern und Punkt vor Strich beachtet werden müssen. Könnt ihr mir da helfen?

Also, theoretisch ist folgendes möglich:

rechnung = 1234+56.78*23/(139-827)+745*12-6
ergebnis = ???

Wie gesagt, rechnung ist ein String und ergebnis ist ein double. Das Ergebnis müsste bei diesem Beispiel am Ende 10166.10183 sein.

Vielen Dank im Voraus für eure Hilfe!

...zur Frage

Hat ∞ * 0 bzw. 0 * ∞ unendlich viele Lösungen?

Und ist die Zahl 10 ist auch dabei ?

Ich kann mir das nicht vorstellen.

Meine Meinung dazu :

1.) Wolfram Alpha sagt, dies sei gar nicht definiert, offenbar deshalb, weil ∞ keine Zahl ist, mit der man rechnen kann.

2.) Und selbst wenn man für ∞ stellvertretend eine sehr hohe Zahl nimmt mit der man rechnen kann, 0 * Eine sehr hohe Zahl = 0 und nichts anderes, auch nicht 10 als Ergebnis.

Ich stelle diese Frage, weil das mir gegenüber jemand behauptet hat, ∞ * 0 habe unendlich viele Lösungen und die Zahl 10 sei als Ergebnis auch dabei.

...zur Frage

kann man mit dem Taschenrechner mit hohen Potenzen rechnen?

z.B. 6,220 * 10 hoch 23

mal

6,220 * 10 hoch -19

kann man solche Zahlen mit dem Taschenrechner ausrechnen?

...zur Frage

Chemie atommasse berechnen Unit?

Ich habe eine Frage, undzwar wie berechnet man die atommasse? Ich weiß, dass 1g = 6•10 hoch 23 u ist und 1u= 1,66•10 hoch -24. Aber wie berechnet man dann zB. die Masse eines Kohlenstoff Atoms? (Hat ja 12u) Muss man da 12•(6•10 hoch 23) rechnen ?

...zur Frage

Drehstrom! P = Wurzel(3) * U * I * cos(phi)

Muss ich für U 230 V oder 400 V einsetzen?^^

Auf dem Motorschild steht: Spannung = 230/400V

...zur Frage

Rechnen mit Uhrzeiten // =REST

Hallo!

Ich möchte messen, ob ein Prozess pünktlich ausgeliefert wurde. Dazu hab ich - in Spalte B die Sollzeit - in Spalte E die Zeit, zu der der Prozess fertig war - in Spalte F die errechnete Differenz mit der Formel =REST(E-B;1). Das Ergebnis ist perfekt, wenn es eine Verspätung gab oder der Prozess statt um 23 Uhr um 1 Uhr fertig wurde (also das Rechnen über Mitternacht). Was NICHT funktioniert ist die korrekte Darstellung, wenn E kleiner B ist. Also Sollzeit ist 19 Uhr, fertig war es um 18:30, dann ist das Ergebnis 23:30 Std.

Weiß jemand eine Lösung?

Danke, wurschtbrot

...zur Frage

Was möchtest Du wissen?