Fehler bei der Division durch sehr kleine Zahlen?

On 05.11.2009, at 18:46, Gottwalt wrote:

> ... wenn ich das als Mathematiker betrachte, dürfte der Fehler gar
> nicht auftreten, solange q noch größer 0 ist.

Doch wohl nur, solange q grösser als 1 ist!

> (1/(C3^B4))*(((C3^B4)-1)/(C3-1))
>
> Dabei steht in "B4" ein Wert größer 1 (z. B. 1,0000000000057) und
> in C3 ein Wert zwischen 1 und 99.

Demnach kann aber q = 1 sein, dann ist also der zweite Nenner (q-1)
gleich Null, was zu Div0 führt.

Grüße, Peter Krajacic

Am 07.11.2009 um 00:18 schrieb Peter Krajacic:

>
> On 05.11.2009, at 18:46, Gottwalt wrote:
>
>> ... wenn ich das als Mathematiker betrachte, dürfte der Fehler gar
>> nicht auftreten, solange q noch größer 0 ist.
>
> Doch wohl nur, solange q grösser als 1 ist!

Du hast recht, ich muß das vielleicht aufdröseln: Durch vorhergehende
Berechnungen erhalte ich ein q1, das sehr klein, aber größer 0 ist.
Dem addiere ich dann eine 1 hinzu und schreibe es in das Feld B3. Das
Ganze ist ja ein etwas größeres Formular. Und somit ist "q1" zwar
immer größer 0, "q" dadurch zwangsläufig größer 1.

>
>> (1/(C3^B4))*(((C3^B4)-1)/(C3-1))
>>
>> Dabei steht in "B4" ein Wert größer 1 (z. B. 1,0000000000057) und
>> in C3 ein Wert zwischen 1 und 99.
>
> Demnach kann aber q = 1 sein, dann ist also der zweite Nenner (q-1)
> gleich Null, was zu Div0 führt.

Nein, q bleibt immer größer 1, denn das oben genannte q1 ist immer
größer 0. Und dem Ragtime dürfte es doch völlig egal sein, wieviel
größer das ist?

Lieben Dank und Gruß

Gottwalt

Hallo Jacques,

Taschenrechner waren diesbezüglich immer limitiert, das versteht sich
von selbst.

Ich ging beim Computer allerdings davon aus, daß dies nicht schon bei
noch nennbaren Teilern geschieht (also hier sind wir ja erst bei den
Billionsteln, auf deutsch, französisch kann ich so große Zahlen nicht).

Und es ist irgendwie nicht logisch, denn manchmal kommt die
Fehlermeldung DIV0! schon bei Teilern, die an der zwölften oder
dreizehnten Stelle keine 0 mehr haben, manchmal auch später.

Insofern einfach unlogisch ... werde mich wohl weiter mit der
Erweiterung des ganzen Vorganges behelfen müssen.

Lieben Gruß

Gottwalt

Hallo Gottwalt,
mit excel kann man mit höchstens 14 Stellen nach dem Komma rechnen,
mit RT nur mit 13 Stellen :
probiere :
in A1 : 1,000 000 …1
in A2 : 1
in A3 : A1-A2
in B3 : 1/A3
weiss nicht warum, muss aber feststellen …und akzeptieren ;-)
@+
jacques

Le 7 nov. 2009 à 12:52, Gottwalt a écrit :

>
>
> Taschenrechner waren diesbezüglich immer limitiert, das versteht
> sich von selbst.

Hallo Jacques,

danke für Deine Antwort!

Dann komme ich um ein Abfangen der Zahl und die Erweiterung des
Bruches nicht herum.

Jetzt wüßte ich allerdings gerne, ob auch sonst entsprechend gekürzt
oder wenigstens intern mit den richtigen Zahlen gerechnet wird (z. B.
bei "endlosen" Dezimalzahlen wie 1/3 oder e etc.).

Herzlichen Gruß

Gottwalt

Hallo Gottwalt,

es wird intern gekürzt :

in A1 : 1
in A2 : 3
in A3 : A1/A3
in B3 : 0,333 333 333 333 33
in C3 : A3-B3 ergibt 0
in D3 : C3*10^20 ergibt 0

oder :

E1 : Pi
E2 : 3,141 592 653 589 8
E3 : E1-E2
E4 : 1/E3 ergibt DIV/0!

herzlich jacques

Le 7 nov. 2009 à 16:03, Gottwalt a écrit :

>
>
> Jetzt wüßte ich allerdings gerne, ob auch sonst entsprechend gekürzt
> oder wenigstens intern mit den richtigen Zahlen gerechnet wird (z.
> B. bei "endlosen" Dezimalzahlen wie 1/3 oder e etc.).

Am 07.11.2009 um 16:34 schrieb Jacques Villars:

> Hallo Gottwalt,
>
> es wird intern gekürzt :

Danke Jacques für Deine Untersuchungen!

Herzlichen Gruß

Gottwalt

Die genaue RagTime-Implementation kenne ich auch nicht, aber hier ein
bisschen allgemeines:

Fließkommazahlen werden auf Rechnern in der Form
Signifikant * 2^Exponent
repräsentiert.

Signifikant und Exponent haben eine feste Anzahl von Dualstellen.
Ihr habt also einmal eine Anzahl von Stellen, die die Präzision oder
Stellengenauigkeit der Berechnungen festlegt und zweitens (mit dem
Exponenten) eine Angabe, wo das Komma steht.

Der gängigste Typ für Fließkommazahlen auf Rechnern ist "double". Ein
double hat 64 bit. Davon sind typischerweise 11 bit der Exponent und die
Stellengenauigkeit beträgt 53 bit inklusive Vorzeichen. Damit bleiben 52
"echte Stellen" für die Zahl.

2^52 hat dezimal 15 Stellen.

("Dezimalstellen ≈ Dualstellen / 10 * 3" ist eine gute Daumenregel für
die Genauigkeit.)

Im Dezimalsystem kennt Ihr das Problem: (10 / 3) * 3 gibt nicht 10, wenn
Ihr mit endlich vielen Stellen rechnet. Die normalen Algorithmen aus der
Grundschule führen auf 9,9999999999999999...

Den Effekt gibt es dual auch, nur bei anderen Zahlen.
Ganzzahl((0,1+0,7)*10)
würde normalerweise bei endlicher Stellenzahl auf Rechnern 7 und nicht
(rechnerisch korrekt) 8 ergeben. Im Dezimalsystem ist das verblüffend,
aber der Effekt entspricht dem dezimalen 1/3 + 1/3 + 1/3. (0,1 und 0,7
führen auf periodische Dualbrüche, sind also in der Technik "Signifikant
* 2^Exponent" nie genau darstellbar.)

(Wer es auf dem Mac testen will: Gebt mal im Terminal die Zeile
php -r "print (int) ((0.1+0.7)*10);"
ein und tippt Return. Die Scriptsprache PHP liefert 7 zurück.)

Ganzzahl((0,1+0,7)*10) liefert in RagTime aber 8, in OpenOffice auch,
Excel hab ich nicht probiert. Die Entwickler der Tabellenkalkulationen
benutzen eine Reihe von Tricks, um die drastischsten Probleme beim
Rechnen mit periodischen Dualbrüchen in einer endlich genauen Welt zu
minimieren. Dazu gehört auch, dass Rundungen benutzt werden. Deshalb
liegt die Stellengenauigkeit bei diesen Programmen typischerweise bei
weniger als 15 Dezimalstellen.

Gruß, Jürgen

Jacques Villars schrieb:
> Hallo Gottwalt,
>
> es wird intern gekürzt :
>
> in A1 : 1
> in A2 : 3
> in A3 : A1/A3
> in B3 : 0,333 333 333 333 33
> in C3 : A3-B3 ergibt 0
> in D3 : C3*10^20 ergibt 0
>
> oder :
>
> E1 : Pi
> E2 : 3,141 592 653 589 8
> E3 : E1-E2
> E4 : 1/E3 ergibt DIV/0!
>
> herzlich jacques
>
> Le 7 nov. 2009 à 16:03, Gottwalt a écrit :
>
>>
>>
>> Jetzt wüßte ich allerdings gerne, ob auch sonst entsprechend gekürzt
>> oder wenigstens intern mit den richtigen Zahlen gerechnet wird (z. B.
>> bei "endlosen" Dezimalzahlen wie 1/3 oder e etc.).
>
>
>

Hallo Jürgen,

herzlichen Dank für Deine Ausführungen!

Ich gebe zu, daß mir das einfach nicht (mehr) gewärtig war bzw. ich
davon ausging, daß dies heutzutage nicht mehr gelte.

Insofern: Ich komme wohl nicht um geeignete Erweiterungen drumrum, um
den Fehler zu vermeiden.

Gruß

Gottwalt

Hallo Jürgen,
und wann erscheint *dein* Buch über RagTime ?
;-)
herzliche Grüsse
jacques

Le 7 nov. 2009 à 17:48, Jürgen Schell a écrit :

> hier ein bisschen allgemeines: