Das Deutsche Casio-Taschenrechner Forum wurde zum 31.12.2013 geschlossen und kann weiterhin als Nachschlagewerk verwendet werden.
Wer mehr erfahren möchte: Ein sehr guter Beitrag von Elias

Frage zu Genauigkeit des Casio fx-9750G

Ideen sammeln, umsetzen, Fehler ausmerzen, Tipps holen und geben, Fragen stellen, Programmierprobleme lösen...

Frage zu Genauigkeit des Casio fx-9750G

Beitragvon gast » Sa 5. Jul 2008, 18:31

Hallo,
ich wundere mich gerade über die Genauigkeit meines Casio fx-9750G.
Im Handbuch steht, er hätte eine 15stellige Mantisse, der binäre Eingabebereich ist deshalb auch bis 0111111111111111 angegeben (15 stellige Mantisse + 1VZbit). Allerdings geht der Eingabebereich bei Dezimalzahlen bis (+/-)2147483648. Eine binäre 15-stellige Mantisse, kann aber nur Zahlen bis 32767 speichern. Wie schafft der GTR diesen großen Eingabebereich?

Dann hätte ich noch eine Frage zum Umgang des GTR mit Wurzeln und Brüchen. Ziehe ich die Wurzel von 2 erhalte ich als Ergebnis 1,4142... . Multipliziere ich dieses Ergebnis wieder mit der Wurzel von 2 erhalte ich 2. Eigentlich dürfte doch die Rundung bewirken, dass 0,99999... oder ähnlich als Ergebnis heruaskommt, oder? Daraus ist zu schließen, dass der GTR nicht mit 1,4142... sonder mit sqrt(2) weiterrechnet, wie ein CAS. Hat jemand Ahnung ob das bei
diesem Modell so ist, und wie sqrt(2) intern gespeichert ist?

0,4 wird doch beim Umwandeln von einer Dezimal- zu einer Binärzahl (damit rechnet ja auch der GTR intern) zu einer unendlichen Zahl. Wie schafft es der Rechner beim Rückkonvertieren wieder die 0,4
herzustellen, es müsste doch 0,39... (oder ähnlich) herauskommen.

Zum Schluss noch eine Frage: Mit welcher Schrittgröße berechnet
FMin (OPTN -> CALC -> |> -> FMin) im RUN Menü den Tiefpunkt?

Im Vorraus schon mal vielen Dank für die Antworten!
gast
 

Re: Frage zu Genauigkeit des Casio fx-9750G

Beitragvon elias.koegel » Sa 5. Jul 2008, 19:51

Der Taschenrechner rechnet nicht binär, sondern mit Binary Coded Decimal. Zum Beispiel 48,03 wäre in BCD 0100 1000,0000 0011 , also in genau zwei Bytes speicherbar. Es wird praktisch jede Zehnerstelle in Binär umgewandelt und nicht die Zahl als ganzes. Das sollte die Frage beantworten, wie der GTR mit 0,4 rechnen kann. Die Zahlen in BCD zu speichern hat den Vorteil, dass eben solche Fälle wie mit 0,4 nicht undefiniert werden und somit Rechenfehler minimiert werden. Der Nachteil ist aber, dass die Rechengeschwindigkeit abnimmt, und das vermutlich gar nicht mal so gering.

Desweiteren speichert der GTR nicht die ganzen Zahlen einfach so, wie sie kommen, also zum Beispiel 21432293846, sondern immer als Gleitkommazahl. Diese Zahlen bestehen aus 3 Komponenten: Mantisse, Exponent und Basis. Die Basis ist beim GTR 10. Die Zahl hat dann die Form: Mantisse * Basis ^ Exponent. Die Basis muss nicht gespeichert werden, da sie im GTR immer gleich ist. Die o.g. Zahl würde dann so aussehen: 2,1432293846 * 10 ^ 10. Mit Kommazahlen geht das natürlich auch: 0,000234 entspricht 2,34 * 10 ^ -4. Ich denke, das sollte deine Frage beantworten, wie der GTR so große Zahlen speichern kann.

Interessant ist jetzt noch, wie eine Zahl abgespeichert wird. Wer schonmal beobachtet hat, wird festgestellt haben, dass eine Variable immer 10 Byte belegt. Ein Listenfeld ebenfalls. Nun kann man überlegen, wie der Speicher zusammengebaut ist. Durch den BCD-Code sind immer nur 4 Bit pro Ziffer nötig. Die Mantisse hat 16 Ziffern, also werden genau 8 Byte gebraucht. Der Exponent ist zweistellig, braucht also noch ein Byte. Das 10. Byte enthält dann weitere Informationen, wie zum Beispiel die Vorzeichen von Mantisse und Exponent.

Leider muss ich dich enttäuschen, denn der GTR hat definitiv kein CAS. Was du vermutest ist schon richtig. Es sind aber alles Rundungsfehler oder besser Glücksrundungen. Mache mal folgenden Versuch:
sqrt(2)
sqrt(Ans)
sqrt(Ans)
...
sqrt(Ans) (Bis nur noch 1 da steht)
Ans-1
Es wird plötzlich eine Zahl angezeigt und nicht wie zu erwarten Null. Der GTR zeigt von seinen 15 Stellen nur 10 an. Die restlichen 5 nutzt er für die Genauigkeit. Die kann man sich nur mit einigen mathematischen Tricks anzeigen lassen.
sqrt(2) wird als 1,4142... im Speicher abgelegt.

Die Genauigkeit für FMin im Run-Menü ist die gleiche, wie im Graph-Menü. Ich verstehe jetzt leider nicht genau, was du mit Schrittgröße meinst. Ich nehme an, dass du an ein anderes Verfahren denkst, wie das Minima bestimmt wird. Meines Wissens (oder besser nach meiner Vermutung) wird das Minima mithilfe des Newtonverfahrens ermittelt. Hier wäre die Anzahl der Interationen interessant. Aber da kann ich dir leider keine Auskunft geben. Ich weiß nur, dass das Ergebnis meist auf ausreichend viele Nachkommastellen genau ist, und bei weiteren Berechnungen keine Probleme macht.

Zum Newton-Verfahren, zur Gleitkommazahl und BCD kann dir Wikipedia noch ein ganzes Stück weiterhelfen.

Ansonsten hoffe ich, dass ich deine Fragen annähernd beantwortet habe. Wenn nicht, einfach nachhaken.
elias.koegel
 

Re: Frage zu Genauigkeit des Casio fx-9750G

Beitragvon gast » Sa 5. Jul 2008, 21:17

Danke für die Antwort, leider kann ich nicht alles nachvollziehen.

Das eine Gelitkommazhl in Mantisse, VZbit und Exponent gespeichert wird ist mir klar. Die eigentliche Ziffern werden trotzdem in der Mantisse gespeichert. 9999999999 ist die höchste Zahl die eingegeben werden kann (ohne Potenz), im Bin Modus wie gesagt 1111111111111111 (15 Mantisse+1VZBit). Wird nun, wie du sagst, im BCD Format gespeichert, müssten also für eine Mantisse 4*10=40 Bit reserviert sein. Aber die Mantisse ist nun nur 15 Bit groß, sonst könnte man ja mehr als 15 binäre Ziffern in einer binären Zahl verwenden. Ich weiß nicht wieso du davon ausgehst, dass er 15 Ziffern speichert. Das macht er nur im Binärmodus, von Dezimalzahlen können maximal 10 Stellen in der Mantisse gespeichert werden. Beweis:9999999999999 (EXE) Ans-9999900000000 (EXE) =99999000, oder auch 8888888888999 (EXE) Ans+1 (EXE) =8888888888. Das wiederlegt auch deine Behauptung, dass sqrt(2)*sqrt(2)=2 nur ein Rundungszufall ist. Zumal auch sin(3,1415926535897932384626433832795) nicht 0 ergibt.

EDIT: OK, der GTR rechnet wirklich nur mit Gleitkommazhalen. Mein Problem war, dass er nur die ersten 10 Ziffern der Zahl annimmt, die restlichen 5 wirklich nur für Zwischenergebnisse nutzt.
Allerdings habe ich noch eine Frage: Die Wertebereiche von Dec und Comp Modus unterscheiden sich. Comp Modus: max. 9999999999 [*10^99], Dec: 2147483647. Im Dec wird d. h. scheinbar nicht im BCD, sondern im normalen Binärformat gespeichert, BCD ist auch unnötig da im DEC Modus nur Ganzzahlen vorkommen. Die Frage: Variert die Bitzahl der Mantisse nach Modus? Im Comp beträgt sie ja wie du angegeben hast 64 Bit, im DEC Modus (nach meinen Berechnungen) 32Bit (inkl. VZBit) (2147483647(DEC)=1111111111111111111111111111111(BIN)).

[geändert von gast am [TIME]1215296458[/TIME]]
gast
 

Re: Frage zu Genauigkeit des Casio fx-9750G

Beitragvon gast » So 6. Jul 2008, 16:16

Sehr selten (oder wann man es mutwillig provoziert) findet der GTR den Hochpunkt im Graph Menü nicht. Ruf ich die FMax Funktion im RUN Menü auf findet er ihn aber.
Konkretes (konstruiertes) Beispiel:
Y1=(x+0,15)(x+0,1)(x+0,05)
V-Window:
XMax: 10
XMin: -10
Schrittgröße: 20/126=1,5873...

-> Logischerweise findet er den Maximalpunkt nicht; im Run Menü dagegen findet er ihn. Ich dachte immer die Berechnungsweise sei überall gleich.
gast
 

Re: Frage zu Genauigkeit des Casio fx-9750G

Beitragvon elias.koegel » So 6. Jul 2008, 20:41

Nochmal zu Graph und Run-Menü: Beide verwenden im Hintergrund die gleichen Methoden, auch wenn sie anders verpackt werden. Wobei ich bei dir gerade nicht nachvollziehen kann, wo im Run-Menü ein Maxima gefunden wird? Wenn ich FMax(Y1,-10,10) eingebe, erhalte ich als Lösung [10,1030,2] und das auch nur, weil dieser Punkt im Intervall den größten Wert hat. Das ist kein globales Maximum, sondern nur ein Lokales!
Deswegen ist es auch nicht verwunderlich, dass im Graph keins gefunden wird, da dort anscheinend noch geprüft wird, ob die Werte nach dem Maxima wieder geringer werden. Und natürlich kann der GTR ein Maxima nur im gegebenen Intervall finden. Im Graph wird das Intervall durch den ViewWindow angegeben, im Run-Menü muss es im Befehl angegeben werden.

Das mit dem Comp-Modus ist eine einfache Beschränkung durch die Software. Wenn ein bestimmter Modus (außer Comp) gewählt wurde, dürfen die Zahlen nur eine gewisse Länge haben. Bei Dec eben 10 Ziffern, bei Binär 16, und octal und Hexadezimal haben auch eine Vorgabe. Diese Beschränkung wurde wahrscheinlich nur gewählt, damit die Umwandlungen zwischen den 4 Zahlensystemen problemlos stattfinden kann. Denn die Zahl 9081234*10^5 würde sich nicht ohne weiteres in Binär umwandeln lassen.
Die Sache mit den Zahlensystemen ist eh etwas scheinheilig, da viel getrickst wird. Wenn man zwei Binäre Zahlen addieren will, werden zuerst beide Zahlen in das normale Gleitkommazahl-System in BCD umgewandelt, dann wird die Rechenoperation ausgeführt und das Ergebnis dann wieder zurückgewandelt. Das hat aber den Vorteil, dass man problemlos eine binäre Zahl mit einer octalen Zahl addieren kann. (Vorausgesetzt, man hält die höchstlängen ein)
Das im Dec-Modus keine Kommazahlen vorkommen, ist eine einfache Beschränkung vom System (um eben die Umwandlungen zu gewährleisten) und macht mathematisch keinen Sinn.
Das eine Binäre Zahl als BCD gespeichert wird, kannst du ganz einfach testen: Gehe in den Bin-Modus und speichere 11011010101 in A ab. Nun wechselst du in den Comp-Modus und lässt dir den Inhalt der Variable A anzeigen. Er wird dir 1749 ausgeben, was dem Wert der binären Zahl angibt. Wenn du eine definierte Zahl in A ablegst (zum Beispiel -1024) und dir A im Bin-Modus anzeigen lässt, wirst du diese Zahl plötzlich auch umgewandelt vorfinden. Das ist an sich Blödsinn, die Zahlen so zu speichern (Speicherverschwendung), verringert aber den Programmieraufwand für die Casio-Entwickler.
elias.koegel
 

Re: Frage zu Genauigkeit des Casio fx-9750G

Beitragvon gast » Mo 7. Jul 2008, 18:28

Vielen Dank für die Antwort. Aber eine Frage hätte ich noch: Wenn der GTR wirklich nur Fließkommastellen speichert, wieso schafft er dann meine Brüche zu kürzen und unterscheidet ob ich 58[Bruchzeichen]67 Eingebe (gibt es mir als Bruch aus) oder ob ich 58/67 eingebe (gibts als Dezimalzahl aus und wandelt diese auch nicht in Bruch um)???
gast
 

Re: Frage zu Genauigkeit des Casio fx-9750G

Beitragvon elias.koegel » So 13. Jul 2008, 13:55

Deine Frage kann ich leider nicht richtig beantworten, sondern nur eine vage Vermutung formulieren. Wie der GTR einen Bruch wie 1/9 abspeichert ist mir ein kleines Rätsel. Möglicherweise kann er das nur mit kleinen Brüchen. Dann könnte er die ersten 8 Stellen für den Zähler und die letzten 8 Stellen für den Nenner nehmen. Das das ein gespeicherter Bruch ist, könnte über ein Bit vermerkt werden, was ganz am Anfang der Zahl steht, in dem Byte, wo auch das Vorzeichen gespeichert wird. Das ist aber reine Spekulation. (Man könnte das herausfinden, indem man den Datentransfer zwischen GTR und PC mitschneidet und Variablen, in denen Brüche gespeichert sind, analysiert.)

Ich kann auch nicht sicher den Unterschied zwischen [Bruchzeichen] und / erklären. Ich denke, dass er dabei ganz anders zur Berechnung vorgeht. Bei [Bruchzeichen] wird der GTR wahrscheinlich mathematisch korrekt den Nenner und Zähler berechnen (und das bei allen Operationen), und das Ergebnis am Ende kürzen. Dagegen könnte es sein, dass der GTR bei / die Lösungen irgendwie numerisch ermittelt. Aber eine richtige Erklärung kann ich nicht liefern.
elias.koegel
 


Zurück zu Graphikrechner (CFX 9850 G/GB/GC; FX 9860 G/ GSD; FX 9750G; FX 7400G) ohne CAS

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 8 Gäste