Zwischen 41,999999999999100 und 42,000000000001400

Tabellenkalkulationsprogramme schummeln manchmal und leisten dann weniger als das UI suggeriert. Auch das, mit dem ich neulich die binomischen Formeln bespielt habe. Die von mir verwendete Software kann nämlich anscheinend nur um die 15 Stellen handhaben. Rundungs- und andere Fehler führen zu Ungenauigkeiten, die sich unter Umständen aufaddieren, sodass am Ende möglicherweise nicht einmal diese 15 Stellen korrekt sind.

Außerdem zeigt die Software nicht immer genau das an, womit sie rechnet, was die angezeigten Rechenergebnisse noch unzuverlässiger macht (näheres hier, leider nur auf Englisch). So oder so ist die vorgespiegelte Exaktheit in Wirklichkeit nicht gegeben.

Die Ergebnisse meiner Kontrollrechnungen für die 3. binomische Formel oszillieren beispielsweise um den erwarteten Wert 42 (genauer: zwischen 41,99999 99999 99100 und 42,00000 00000 01400), obwohl es ja eigentlich jedesmal genau und nichts anderes als genau 42 ergeben müsste, sonst wären die errechneten Werte für a und b keine Lösungen der Gleichung sondern nur so ungefähre Näherungen.

Es muss genau 42 ergeben – das Leben, das Universum und der ganze Rest lassen sich nicht beschummeln. Zweiundvierzig Komma Null sozusagen, 42,0. Ich habe die Ergebnisse der Tabellenkalkulation von Hand mit einem Taschenrechner nachrechnet, der 30 Nachkommastellen beherrscht. Die Kontrollrechnung mit diesem Taschenrechner hat für den von der Tabelle ermittelten Wert für b nie genau 42 ergeben. Die Kontrollrechnung mit dem Taschenrechner für die mit dem Taschenrechner selbst berechneten Werte für b ergibt dagegen jedesmal genau 42. Die von der Tabellenkalkulation für b ermittelten Werte selbst sind also nicht korrekt, und die Streuung der Kontrollergebnisse um den erwarteten Wert 42 resultiert aus den oben angesprochenen Ungenauigkeiten und Rundungsfehlern, erstens bei der Berechnung von b und zweitens bei der Verrechnung von b in der Kontrollrechnung.

Zur Illustration der Tragweite hier zwei Beispiele aus meiner binomischen Spielerei:

Für a=100 ergibt die 15-stellige Tabellenkalkulation nach der 3. binomischen Formel den Wert b=99,78977 90357 30900, der 30-stellige Taschenrechner aus demselben Haus liefert 99,78977 90357 30908 86754 69566 45224. Die Kontrollrechnung in der Tabellenkalkulation ergibt 42,00000 00000 01400 statt 42. Der Taschenrechner liefert für das b aus der Tabelle 42,00000 00000 01769 78110 27851 9, für das selbst berechnete b aber genau 42 ohne Komma und Dezimalrattenschwanz.

Für a=99 ergibt die Tabellenkalkulation nach der 3. binomischen Formel den Wert b= 98,78765 10501 18600, der Taschenrechner liefert 98,78765 10501 18607 42335 15542 84573. Die Kontrollrechnung in der Tabellenkalkulation ergibt 41,99999 99999 99100 statt 42. Der Taschenrechner liefert für das b aus der Tabelle 42,00000 00000 01466 67092 59340 4, für das selbst berechnete b aber wieder genau 42.

Weil diese Aufzählung von vielstelligen Zahlen im Fließtext etwas unübersichtlich ist, habe ich das nochmal in Tabellenform aufbereitet:

(Die beiden Nullen am Ende kommen daher, dass ich das Feld als Zahlenfeld mit 15 Nachkommastellen formatiert hatte. Die errechneten Werte für b werden deshalb immer mit 15 Nachkommastellen angezeigt. Da schon vor dem Komma zwei Stellen stehen, bleiben für nach dem Komma nur 13 übrig, danach wird augenscheinlich mit Nullen aufgefüllt. Deshalb ist hier auch die letzte angezeigte Nachkommastelle für die b-Werte falsch, und deshalb können die Nullen am Ende der statt 42 kontrollberechneten Werte falsch sein. Die angezeigten Stellen entsprechen offenbar nicht immer den im Hintergrund berechneten bzw. verwendeten Zahlen, man kann sich also zumindest auf die letzten angezeigten Nachkommastellen nicht wirklich verlassen.)

(Die Kontrollrechnungen für b₂ der 1. und 2. binomischen Formel ergeben durchgängig 42-1,02912470212324E-14i, eine Zahl, die ich so aus dem Stand nicht verstehe und deren genaue Bedeutung zu recherchieren ich derzeit zu faul bin, ich habe genug in dem Kalkulationsprogramm herumgefiedelt, das reicht erstmal. Sie ist wahrscheinlich sehr, sehr nahe an 42.)

** * **

Diese Fehler sind natürlich sehr, sehr klein. Wenn man diese Abweichungen auf die Zahl der Reiskörner anrechnet, die der weise Mann für die Erfindung des Schachbretts in Rechnung gestellt hat, ergibt sich für a=100 eine Abweichung von 614.891,47 Reiskörnern. Das sind 12,297 l oder 9,715 kg. Für a=99 erhalte ich eine Abweichung von 395.287,37 Reiskörnern, das sind 7,906 l oder 6,245 kg.

In beiden Fällen dürfte die Abweichung deutlich geringer als die zu erwartenden Zählfehler sein, die bei der Verarbeitung solcher unvorstellbaren Reismengen mit einiger Sicherheit auftreten würden.

Zur Orientierung: Beim Auffüllen des Schachbretts hat man für die ersten 18 Felder (also zwei Reihen und zwei Felder) 262.143 Reiskörner gezählt, für das 19. Feld kommen 262.144 dazu, dann liegen insgesamt 524.287 Reiskörner auf dem Brett. Die Füllung der ersten zwei bis drei Reihen auf dem Schachbrett ist also ziemlich egal und fällt als eine Art Grundrauschen in die erreichbare Toleranz.

Das mit den 15 Stellen der Tabellenkalkulation gilt übrigens auch für vor dem Komma. Wenn man versucht, die Zahl der Reiskörner für jedes Feld des Schachbretts zu berechnen, sind die Zahlen nur vollständig, solange sie weniger als 15 Stellen haben. Zahlen mit mehr als 15 Stellen werden unvollständig und falsch angezeigt. Auf dem 50. Feld liegen 562.949.953.421.312 Reiskörner mit 15 Stellen, auf dem 51. doppelt so viel, nämlich 1.125.899.906.842.624, auf dem 52. Feld liegen 2.251.799.813.685.248 Reiskörner. Ab dem 51. Feld braucht man aber 16 Stellen für die Zahl der Reiskörner, mehr als die Tabellenkalkulation kann. Die Tabelle zeigt deshalb für das 51. Feld 1.125.899.906.842.620,  für das 52. Feld 2.251.799.813.685.250 statt 2251799813685248.

So geht es weiter, die Ungenauigkeit wächst mit jeder Verdoppelung. Für das 64. Feld werden 9.223.372.036.854.780.000 Reiskörner angegeben dabei liegen tatsächlich 9.223.372.036.854.775.808 Reiskörner dort. Hier ist die Abweichung mit 4.192 Reiskörnern (66,2 g oder 83,8 ml) deutlich geringer als bei der verfehlten 42 oben, vermutlich weil hier nur eine Zahl dargestellt werden soll, während sich oben die Ungenauigkeiten vielstelliger Zahlen in mehreren Rechenschritten verstärken.

Egal, so ärgerlich solche Ungenauigkeiten für den Perfektionisten auch sein mögen, für den Alltagsgebrauch dürfte das gerade noch akzeptabel sein…


9 Kommentare on “Zwischen 41,999999999999100 und 42,000000000001400”

  1. gnaddrig sagt:

    Man muss es eben manchmal ein bisschen überspitzen. Aber es ist schon wichtig: Spätestens wenn es um die Verteilung von, sagen wir, beim Karneval oder zu Halloween eingesammelten Süßigkeiten geht, hört der Spaß auf, da zählt jedes Molekül!

    Gefällt mir

  2. Pfeffermatz sagt:

    Mich begeistert deine Begeisterung. Beim TR vermute ich, dass er intern mit noch mehr als 30 Stellen rechnet, um die 30 Stellen exakt angeben zu können.

    Gefällt mir

  3. gnaddrig sagt:

    Das würde ich auch vermuten. Immerhin scheint die Reserve groß genug zu sein, dass zumindest in meinen Rechnungen keine Rundungsfehler zum Tragen gekommen sind. Oder die Maschine ist so schlau, dass sie verstanden hat was ich da vorhabe und einfach 42 ausgegeben hat, damit Ruhe ist 😉

    Gefällt 1 Person

  4. Yadgar sagt:

    Also, mit arbitrary.h in C++ wäre das nicht passiert – diese Library erlaubt nämlich Fließkommazahlen beliebiger (!!!) Genauigkeit, nur durch die Größe des Arbeitsspeichers begrenzt… bis meine 24 GiB dann mit zwei zu addierenden Meta-Hypergoogolplexen (keine Ahnung, wie Zahlen mit mehreren Milliarden Stellen heißen…) zugeorgelt sind! Aber es wäre natürlich mal interessant, die Permutationen (in Planck-Längen-Intervallen und unter Berücksichtung quantenmechanischer Gesetze) sämtlicher Elementarteilchen im Universum zu berechnen, um endlich mal herauszufinden, wieviele verschiedene Weltälle eigentlich physikalisch überhaupt möglich sind…

    Gefällt 1 Person

  5. Pfeffermatz sagt:

    Ausserdem musst du bedenken, dass die binomische Formel eine Wurzel beinhaltet, und Wurzelrechnen geht ja nur näherungsweise über Iteration.

    Gefällt mir

  6. gnaddrig sagt:

    Hm, dann ist mein Einstieg mit Tabellenkalkulationsprogramme schummeln manchmal und leisten dann weniger als das UI suggeriert. selbst auch nicht ganz akkurat, weil es kaum Schummeln ist, wenn man eine unendlich fortführbare Rechnung an einer nach irgendwelchen Kriterien gewählten Stelle abbricht. Man muss da vermutlich eine Art Kosten-Nutzen-Rechnung anstellen, und in den allermeisten Anwendungsfällen werden die 15 (oder meinetwegen auch 30) Stellen ausreichen. Aber damit passt dieser Beitrag noch besser zum vorigen mit der Rechenspielerei 🙂

    Gefällt 1 Person

  7. Pfeffermatz sagt:

    Echte KI, sinnvoll eingesetzt 😁

    Gefällt 1 Person

  8. gnaddrig sagt:

    Ja, das ist die lange gesuchte Killeranwendung, die der KI endlich zum Durchbruch verhilft…

    Gefällt mir


In den Wald hineinrufen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.