Seite 2 von 3
Verfasst: 15.08.2006 12:31
von HeX0R
Nur sind es eben nicht nur Zweierpotenzen...
Siehe:
Code: Alles auswählen
#Start = 2147483647*2
z.q = #Start
s.l = 1
Repeat
f.f = z
If IntQ(f) = z
Debug Str(s) + "." + StrQ(z)
s + 1
EndIf
z + 1
Until z = #Start + 20000
40 Zahlen von 20000 überlonggrössen getesteten sind fehlerfrei speicherbar.
Aber wir sollten das jetzt so langsam lassen
Verfasst: 15.08.2006 12:36
von Helle
100%-ig sicher kann eine Integer-Zahl mit
- Float : auf 7 Stellen
- Double : auf 15 Stellen
- Extended : auf 19 Stellen (Extended = die 80-Bit der FPU)
dargestellt werden.
Her mit 80-Bit-Variablen in PB
!
Gruss
Helle
Verfasst: 15.08.2006 12:42
von Kaeru Gaman
ja, ist mir auch grad aufgefallen, dass es nicht nur die zweierpotenzen sind.
[edit]
@Helle
> - Float : auf 7 Stellen
> - Double : auf 15 Stellen
signifikante Stellen.
[/edit]
es müssten alle sein, bei denen nur 23 signifikante bits hintereinander stehen.
das sind dann also 2^23 zahlen für die signifikanten bits, und die
multipliziert mit der bitzahl um die ich sie shiften kann, also 42 (0-41)
also sind es 42*(2^23) = 352321536
für meinen geschmack immer noch ein verschwindend geringer teil von 18trillonen.
mir geht es auch nicht darum, mit dir zu streiten.
ich störe mich nur daran, dass in der Help "unlimitiert" steht bei floats,
und die meisten glauben das einfach so.
aber es ist schlicht und einfach unlogisch, dass man in 32bit mehr daten speichern kann, wenn man eine andere formatierung wählt.
in 32bit passen genau 32bit informationen.
mit float kann ich zwar einen wesentlich größeren zahlenbereich abdecken,
aber dafür habe ich auch einen rasant zunehmenden ungenauigkeitsbereich
wenn die zahlen größer werden.
das gleiche gilt analog für Double.
man muss sich dessen einfach bewußt sein beim programmieren,
sonst wird man bestimmte bugs niemals nicht finden.
Verfasst: 15.08.2006 12:55
von Helle
Na sicher meine ich signifikante Stellen
!
Hier noch ein paar Zahlen:
Code: Alles auswählen
;Float
a.l=16777216
b.l=1
c.l=a+b
Debug c
a1.f=16777216 ;Bei Float (Single) grösste sicher darstellbare Zahl
b1.f=1
c1.f=a1+b1
Debug c1
;Double
a2.q=9007199254740992
b2.q=1
c2.q=a2+b2
Debug c2
a3.d=9007199254740992 ;Bei Double grösste sicher darstellbare Zahl
b3.d=1
c3.d=a3+b3
Debug c3
Gruss
Helle
Verfasst: 15.08.2006 20:48
von NicTheQuick
Hab den selben oder so einen ähnlichen Fehler auch gerade bekommen.
Code: Alles auswählen
Procedure test()
q.q = 12345678
d.d = q
EndProcedure
a = test() ;diese Zeil auch mal auskommentieren
Debug test()
Am besten mit Debugger starten und dann auch mal die eine Zeile
auskommentieren.
Einmal entsteht ein "Invalid memory acces.", einmal bleibt das Programm
einfach stehen.
Kann mir jemand eine Lösung dafür zeigen?
Verfasst: 15.08.2006 20:54
von #NULL
vielleicht bin ich ja nicht ganz auf der höhe, aber eine lösung für unfug?
wieso kein procedurereturn wenn einem der rüchgabewert lieb ist?
Verfasst: 15.08.2006 21:05
von remi_meier
@NTQ
wurde vor kurzem im englischen Board besprochen:
Code: Alles auswählen
Procedure test()
q.q = 12345678
d.d = PeekQ(@q )
EndProcedure
a = test() ;diese Zeil auch mal auskommentieren
Debug test()
Workaround
Verfasst: 15.08.2006 21:05
von NicTheQuick
Fakt ist, das der Fehler nicht auftreten sollte. Wenn ich keine Quads und
Doubles in der Procedure verwende, gibt es auch keinen Fehler. Und ein
[c]ProcedureReturn[/c] bringt den selben Fehler.
Verfasst: 15.08.2006 21:09
von Kaeru Gaman
is ja gruselig...
> wurde vor kurzem im englischen Board besprochen
na hoffentlich wird auch was unternommen.
Verfasst: 15.08.2006 21:35
von Falko
Ich hoffe auch. Wir hatten ja an anderer Stelle ähnliches Problem mit Floats und Quads innerhalb einer Procedure.