µ$ Desktop-Calculator Bug

[H.A.R.R.Y.]

Hallo Zusammen,

tief in der Nacht, wenn mein solarbetriebener TI-30 nutzlos ist, muss der Desktop-"Taschenrechner" herhalten. Irgendetwas war aber seltsam an dem Ergebnis. Und so wollte ich schnell mal etwas überprüfen indem ich den Grenzwert ein einen kritischen Teilterm eingesetzt habe:



Grenzwert:

Den Grenzwert habe ich vorab berechnet und dem "Memory" anvertraut um ihn öfter nutzen zu können.

Rauskommen muss 0, aber was der µ$-Murks sich erlaubt ist ein Armutszeugnis: Der Versuch die Wurzel aus Minus-Eins-Komma-Ebbes-Mal-Zehn-Hoch-Minus-Siebenundvierzig zu ziehen. Wenn es denn wenigstens Zweiundvierzig gewesen wäre. Irgendwie erinnert mich das an die alten Pentium-Ver-Rechner aus dem letzten Jahrtausend! Damals war das Problem schon auf dem PC-Gehäuse deutlich eingekreist
Wenigstens macht Excel diese Rechnung (noch?) richtig.

Grüße
H.A.R.R.Y.
PS: Zum Glück ist es draussen wieder hell und mein TI-30 "online" ...

[steffalk]

Tach auch!

Bei meinem Windows-Taschenrechner kommt da halt "ungültige Eingabe". Was genau tippst Du denn und was genau kommt raus?

Gruß,
Stefan

[MasterOfGizmo]

Ich hab's so verstanden, dass nach Wurzel und folgendem Quadrat Rundungsfehler auftreten und er als Zwischenergebnis dann eben eine minimal negative Zahl statt der Null bekommt.

Aber: Der Trick ist, dass er das in den Zwischenspeicher legt. Dort tritt dann ggf. der Rundungsfehler auf. Speicherst Du das beim TI-30 auch zwischen?

[H.A.R.R.Y.]

Hallo Zusammen,

Ich hab's so verstanden, dass nach Wurzel und folgendem Quadrat Rundungsfehler auftreten und er als Zwischenergebnis dann eben eine minimal negative Zahl statt der Null bekommt.

Exakt. Das Problem zeigt sich wenn ich den numerischen Wert für in einsetze.

Bei meinem Windows-Taschenrechner kommt da halt "ungültige Eingabe".

Ja, bei mir auch. Die Diskriminante in ist halt dezent negativ.

Der Trick ist, dass er das in den Zwischenspeicher legt. Dort tritt dann ggf. der Rundungsfehler auf. Speicherst Du das beim TI-30 auch zwischen?

Es ist egal, ob ich es aus dem Speicher hole oder direkt weiterrechne. Beim TI-30 gibt es hier keine Probleme, weder direkt noch mit Zwischenspeichern. Vermutlich verwendet der TI-30 intern mehr Stellen Genauigkeit und hat deswegen in seinen Grenzen keine Probleme damit. Mit einem alten Casio FX-(fragmichnicht) geht es aber auch problemfrei. Na gut, das sind auch echte wissenschaftliche Taschenrechner, der µ$ tut nur so als ob. Immerhin weiß ich nun, dass ich bei dem Ding aufpassen muss.

Grüße
H.A.R.R.Y.

[steffalk]

Tach auch!

Der Windows-Taschenrechner hat *viel* mehr Nachkommastellen als der TI-30. Der hatte 10, intern vielleicht 12 Stellen. Aber das ist nicht der Punkt: Was wir hier sehen, ist kein Bug. Es ist die unvermeidliche Konsequenz von Runden bei - wie tief auch immer - begrenzter Stellenanzahl. Und es kommt offenbar bei einem 10 (12)stelligen Runden zufällig gerundet auf 0 heraus, aber bei mehr Stellen kommt halt irgendwas winziges <> 0 raus. Das zum Quadrat scheint gerundet ein bisschen mehr zu sein, und wenn Du das dann von was abziehst, kommt halt was winzig negatives raus.

Nimm mal einen echten 10stelligen Taschenrechner (einen älteren HP z.B.). Da rechne mal 2, sqrt, x². Da kommt nicht 2 raus, sondern was knapp kleineres. Das ist kein Bug. Das sind Rundungseffekte, die da zum Vorscheinkommen, und die hast Du immer, wenn Du mit begrenzt vielen Stellen rechnest. Und beim einen Beispiel werden sie bei (sqrt(2))² sichtbar, und beim anderen eben woanders.

Gruß,
Stefan

[H.A.R.R.Y.]

Ah ich sehe, Danke schön.

Grüße
H.A.R.R.Y.