FloatBug in Proceduren

[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

[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

[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.

[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

[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?

[#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?

[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

[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.

[Kaeru Gaman]

is ja gruselig...


> wurde vor kurzem im englischen Board besprochen

na hoffentlich wird auch was unternommen.

[Falko]

Ich hoffe auch. Wir hatten ja an anderer Stelle ähnliches Problem mit Floats und Quads innerhalb einer Procedure.