1.0 * Float oder Double?

[es_91]

Hi.

Mir ist gerade aufgefallen, dass ich gar nicht weiß, ob folgende Rechnungsanweisung von PureBasic als Float oder mit doppelter Genauigkeit berechnet wird:

Code: Alles auswählen

Debug 1.0 * 2/3

Könnt Ihr mir da aushelfen? Als Programmierer kommt man doch oft an den Punkt, wo man doppelte Genauigkeit braucht und dann währe es ja sinnvoll, zu wissen, ob man durch einfaches Voranschreiben von "1.0 * " eine doppelte oder einfache Genauigkeit bewirkt.

So sieht die Debugger-Ausgabe in dem Beispiel aus:

0.66666666666666663

Das sieht mir zwar nach doppelter Genauigkeit aus, aber ich frage lieber mal nach.

Danke!

[NicTheQuick]

Im Normalfall nutzt du ja Variablen zum Rechnen. Dann ist ja klar mit was gerechnet wird, da du einen Typ angeben musst.
Wenn du eine konstante Rechnung über den Debugger ausgibst, kann es ja sogar sein, dass der Compiler das schon berechnet und das Ergebnis einfach hinter die Debug-Anweisung schreibt.

Also wenn du wirklich sicher gehen willst, dann nutze korrekt Typen:

Code: Alles auswählen

f.f = 1.0 * 2/3
Debug f

d.d = 1.0 * 2/3
Debug d

Debug 1.0 * 2/3

Ergibt bei mir:

0.66666668653488
0.6666666666666666296592325
0.6666666666666666296592325

[STARGÅTE]

Code: Alles auswählen

1.0*2/3

hat ein bisschen von Schrödingers Katze.
Bis zur Verwendung, ist dieser Ausdruck weder Float noch Double, denn er taucht im ASM-Code garnicht als Rechnung auf.

Erst bei der Verwendung in Rechnungen wird vom Kompiler entschieden, welchen Typ gebraucht wird.
Bei folgendem Code:

Code: Alles auswählen

#Test = 1.0*2/3
d.d = #Test
f.f = #Test

ist es sogar so, dass im ASM Code zwei "verschiedene" Konstanten verwendet werden.
für f.f wird die Float-Konstante genutzt,
für d.d wird die Double-Konstante genutzt.

Der Debugger also "Debug" benutzt immer Doubles oder Quads für Rechnungen.

[Regenduft]

hat ein bisschen von Schrödingers Katze.

Gerade am Quantenmechanik studieren?

Is' ja doof, dass PB nicht erst am Ende beim pushen nach Float wandelt... Gibt (manchmal) unnötige Rundungsfehler...

Ich habe das mal mit "extra krummen Werten simuliert" (keine Konstanten, damit PB nicht durch vorberechnen optimiert)

Code: Alles auswählen

EnableASM

a_d.d = 1.123
b_d.d = 2.345
c_d.d = 3.678

a_f.f = 1.123
b_f.f = 2.345
c_f.f = 3.678

f.f


; via Doubles nach Float
f = a_d * b_d / c_d
Debug f

; via Floats nach Float
f = a_f * b_f / c_f
Debug f

Debug ""


; So sieht der erzeugte FASM-Code aus:
; (hier aber Inline-Syntax für bessere Lesbarkeit)

; via Doubles nach Float
FLD   a_d
FMUL  b_d
FDIV  c_d
FSTP  f
Debug f

; via Floats nach Float
FLD   a_f
FMUL  b_f
FDIV  c_f
FSTP  f
Debug f

[kernadec]

Hallo
Ich hatte dieses Problem auf dem französischen forum
Das kommt von der Debugger die Ergebnisse abschneidet
die Ergebnisse sind gut mit dem Befehl StrD() oder StrF():
Herzliche Grüße

[Regenduft]

Falls Du Dich auf meinen Code beziehst: Da gibt's trotzdem (kleine) Rundungsfehler. Aber grundsätzlich hast Du schon recht, dass das eine Falle ist!