Mal aus der CPC-Sicht, weil ich da zufälligerweise das Format inzwischen kenne. Aber auch grundsätzlich zur Zahlendarstellung:
0,1 lässt sich binär nur sehr schlecht darstellen, ebenso 0,2.
Die Mantisse im CPC ist vier Bytes lang, und die Umrechnung von 0,1 ergibt (,=wie gehabt im Deutschen .=Trennzeichen zur besseren Darstellung):
0,1100.1100.1100.1100.1100.1100.1100.1101
Ja, 0,1 binär ist periodisch (!). Und die letzte Stelle ist auch noch gerundet.
Der Exponent - also das 5. Byte im CPC - ist 125. Von dieser Zahl muss 128 abgezogen werden, ergibt -3)
(Mantisse als Ganzzahl) dividiert durch 2^(Anzahl der Bits in der Mantisse) * 2^(Exponent - 128):
(3435973837 / 2^32) * 2^(125-128)
Das ergibt also für die diese Zahl alleine schon einen recht hohen Fehlerfaktor. Rückgerechnet ins Dezimalsystem ist das:
0,10000000000582076609134674072266
In der Schleife wird jetzt 100 mal auf 1 die Zahl 0,1 addiert, aber eben das fehlerhaft dargestellte 0,1. Das führt irgendwann zu einem Rundungsfehler, der nicht mehr ignoriert werden kann.
WANN der Fehler auftritt hängt von der internen Genauigkeit der Fließkommazahlen ab, und davon wie gerundet wird.
Beim CPC hast du ungefähr eine Genauigkeit von 9 Dezimalstellen nach dem Komma (mal besser, mal schlechter). Andere BASICs liegen da vielleicht in etwa gleich.
Die Formatierung von Octoate zwingt BASIC anscheinend dazu, bei den Zwischenschritten jedes Mal zu runden. Was dann dazu führt, dass die Abweichung in der internen Darstellung von 0,1 nicht kumuliert.
Ein Step von 0.25 zum Beispiel muss problemlos durchlaufen, weil da auch das interne binäre Format eindeutig bleibt. Und wenn nicht, dann geh ich jede Wette ein, dass dieses BASIC dann einen Bug hat.
