Hallo Besucher, der Thread wurde 10k mal aufgerufen und enthält 90 Antworten
letzter Beitrag von BASIC-FAN am
Boolean Problem - spinn ich oder spinnt C64 EDIT: als Fließkomma-Problem identifiziert
- TheRyk
- Erledigt
-
-
der ist ja geil :o) das problem liegt in der darstellung der floats... http://de.wikipedia.org/wiki/G…_mathematische_Grundlagen
-
-
Das ist aber eigentlich bekannt. Ich hatte damals [tm] mal das Problem, dass 3^4 plötzlich 81.00000001 war. Solche Fehler können sich im wahrsten Sinne des Wortes multiplizieren.
-
-
-
Ich meine, das C64-Fließkommeformat basiert nicht auf 10er-Potenzen, sondern auf 2er-Potenzen. Das tut zwar im konkreten Falle nichts zur Sache, erklärt aber, warum es auch mit hübsch aussehenden Brüchen Probleme gibt.
Das Format ist aber glaube ich allgemein die Regel, Fließkomma auf Basis von 10er-Potenzen ist eher die Ausnahme.
-
Ja, habe mir des Sauhunds Link nochmal angesehen, scheint in der Tat ein im Binärmodus liegendes Problem zu sein, da können Sachen problematisch sein, die in dezimal total glatt aussehen.
-
Jaja, der Horror jedes Computers: 1/10
-
Wenn es nur das Format wäre, dann wäre aber 7*7 auch 49.00001. Ist es aber nicht, sondern 49 !
-
Wieso? 10*10 ist doch auch 100, 10^2 haut hier nicht so ganz hin. Aber das liegt (eventuell/möglicherweise/warscheinlich) nicht am Format, sondern an der Art der Berechnung.
-
so meinte ich das
-
Wenn ich als Nicht-Quantenmathematiker das Ganze richtig verstehe, liegt es in etwa daran:
ohne Rest teilbare Zahlen in DEZ sind nicht ohne Rest teilbare Zahlen in BIN
--> Rundungen in BIN --> Fehler/"Artefakte" bei Rückumwandlung in DEZTückisch ist eben, dass dezimal auf dem C64 (in Basic 2.0) 10.0000000001 als 10 dargestellt(!= gespeichert --> 10.0000000001) wird und man erst bei BOOLEAN-Operation (oder womöglich beim Weiterrechnen mit dem Wert) drüber stolpert und denkt "Mein Schwein pfeift!"
-
Zitat
Wenn ich als Nicht-Quantenmathematiker das Ganze richtig verstehe, liegt es in etwa daran:
ohne Rest teilbare Zahlen in DEZ sind nicht ohne Rest teilbare Zahlen in BIN
--> Rundungen in BIN --> Fehler/"Artefakte" bei Rückumwandlung in DEZ
genau so -
hat bloß wenig mit 10 und 100 zu tun:
10 = (binär) 1.01 * 2^3
100 = (binär) 1.1001 * 2 ^ 6Das ist in Float noch sehr gut darstellbar. Das Problem ist die Polynomnäherung.
-
Stimmt.
"...ohne Rest teilbar in Dez..." ist unglücklich ausgedrückt. "Kommaverschieben in Dez, um eine ganze Zahl zu bekommen" passt besser. Denn erst kommt die Umrechnung ins Binäre, dann das Verschieben des Kommas in dieser binären Zahl.
Ganze Zahlen lassen sich prima als Float darstellen, Brüche nur, wenn der Nenner keine anderen Primfaktoren als 2 enthält. So eine einfache Zahl wie 0,1, bei der man im Zehnersystem nur das Komma verschieben müsste, lässt sich im Zweiersystem nur als Bruch mit Periode darstellen.
-
Tatsache!
Mit
verhält sich alles, wie man es erwartet.
Danke! Man lernt nie aus, nichtmal in Basic.
Da würde ich sagen: Glück gehabt!
Es gibt Fälle, da hilft die INT-Funktion auch nichts. Ich kann da jetzt nicht mehr das passende Beispiel zu liefern, ist zu lange her, aber ich bin damals schier verzweifelt, weil trotz INT zwei "identische" Zahlen nicht gleich waren. Ich musste dann erst die Zahlen in Strings umwandeln. Dann war gleiches plötzlich wírklich gleich. Im Übrigen verhalten sich da Compiler manchmal anders als der Interpreter ...Gruß WTE
-
Hallo, hier ist er wieder der Basicfan,
probiert es doch einfach einmal mit1e2
Schönen Gruß, Dirk
-
@BASIC-FAN: Da kann man auch gleich 100 für schreiben. Ich denke mal das bei den realen Programmen wo das Problem auftrat nicht einfach 10^2 im Quelltext stand, sondern mindestens einer der Operanden eine Variable war.
-
So ist es natürlich Das 10^2 diente hier nur der Veranschaulichung.
Das E kann mal helfen, um Basicstarts/SYS-Zeilen abzukürzen, SYS57E3 statt SYS57000, hat mir Enthusi mal "beigebracht"