Der Taschenrechner (Calc.exe) ist seit ewigen Zeiten in Windows dabei und hat einen Bug, der sich durch die Versionen schleppt. Nun hat Microsoft sich bequemt, diesen Bug zu beseitigen.
Anzeige
Der Bug lässt sich im wissenschaftlichen Taschenrechner beobachten. Gibt man den Wert 4 ein und lässt daraus die Wurzel ziehen, ergibt dies den Wert 2. Zieht man den Wert 2 ab, sollte als Ergebnis 0 erscheinen. Das ist aber nicht immer der Fall, wie der nachfolgende Screenshot zeigt.
Eine tiefergehende Analyse, warum Fehler bzw. Abweisungen auftreten, hat Raymond Chen von Microsoft in diesem Entwickler-Blog-Beitrag analysiert. Hier ist nun aufgefallen, dass Microsoft diesen Bug im Taschenrechner in Windows 10 Redstone 5 build 17639 behoben hat.
Anzeige
Günter Born: "Hier ist nun aufgefallen, dass Microsoft diesen Bug im Taschenrechner in Windows 10 Redstone 5 build 17639 behoben hat"
der fehler wurde wohl schon vorher behoben: unter der 32-bit version von win10 1709 16299.334 – vor der ich gerade sitze – kann ich ihn nicht mehr nachvollziehen, beide modi (siehe unten) liefern hier 0 als resultat.
PS: es scheint vorher ja noch sonderbarer gewesen zu sein, denn, wie aus den userkommentaren von chens windows kolumne hervorgeht, produzierte der taschenrechner von windows – je nach modus – unterschiedliche ergebnisse: sqrt(4)-2 war entweder -1.068281969439142e-19 (standardmodus) oder -8.1648465955514287168521180122928e-39 (wissenschaftlicher modus).
sorry fuer das sprachliche durcheinander in meinem postskriptum.
2. versuch:
PS: wie aus den userkommentaren von chens windows kolumne hervorgeht, scheint es vorher ja noch sonderbarer gewesen zu sein, denn der taschenrechner von windows produzierte – je nach modus – unterschiedliche ergebnisse: sqrt(4)-2 war entweder -1.068281969439142e-19 (standardmodus) oder -8.1648465955514287168521180122928e-39 (wissenschaftlicher modus).
auf jeden Fall ein sehr geiler Fehler.
Wie man sowas allerdings hinbekommt, ein Rätsel.
wurzel 16 -4 oder -3 -1 ergibt zB. -4,561669785727164e-20 (win7-32).
absurd. nichma richtich rechnen könnse in rotmond… :D
Tja, war bei der Wurzel ein Periodenproblem (ähnlich 10/3). Obendrein fällt mir ein, dass Leute, welche 2-2 mit 'nem Taschenrechner rechnen, eher böse Absichten haben ;-)
Und weil wir gerade dabei sind:
– teilt mal 888.888.888 durch 72
– es kommt die Zahlenreihe 1 bis 9 raus, aber die 8 fehlt
Das waren meine 2 cent zum Wochenende :-)
zu "war bei der Wurzel ein Periodenproblem (ähnlich 10/3)":
nein, war ein praezisionsproblem. nur fuer die grundrechenarten und das potenzieren ganzer zahlen wurde eine programmbibliothek mit beliebiger genauigkeit verwendet. die anderen mathematischen operationen benutzten eine bibliothek mit begrenzter genauigkeit. was man hier sehe, schreibt windows-urgestein raymond chen, sei die übliche tücke der fliesskomma-arithmetik im zusammenspiel mit der tatsache, dass kein spezieller auf praezision zugeschnittener quadratwurzelalgorithmus verwendet wurde, sondern statt dessen so etwas:
if(x>0) sqrt(x)=exp(ln(x)/2)
else if(x<0) sqrt(x)=error
else sqrt(x)=0
Vielen Dank, Hr. Born, für die Info.
Der Fehler lässt sich auf Windows 10 1803 auf der Taschenrechner UWP und dem klassischen Rechner nachvollziehen.
Ja kann man unter Windows XP SP3 mit allen Windows Point of Service 2009 Updates gut reproduzieren.
Ergebnis kommt wie beschrieben. Taschenrechneransicht —> Standard
Ergebnis:
-8,1648465955514287168521180122928e-39