FormatFloat 32bit / 64bit

[Thomas Feichtner]

Hallo zusammen,

ich bekomme beim FormatFloat unterschiedliche Werte angezeigt zwischen 32 und 64bit.

Ich habe folgenden Code:

Code:

procedure TFunctionsTestForm.Button1Click(Sender: TObject);
var
  LvTemp: Variant;
  LsTemp: string;
begin
  LvTemp := 405.405;
  LsTemp := FormatFloat('#,0.00;-#,0.00', LvTemp);
  ShowMessage(LsTemp);
end;

Es wird unter 32 405,40 und unter 64 405,41 was meiner Meinung nach richgig ist angezeigt. Hat jemand schon mal das gleiche Problem gehabt?

[jaenicke]

Hilft vielleicht:
SetRoundMode(TRoundingMode.rmUp);

[rabatscher]

Soweit ich weiss wird ein Variant als "Extended" Datentyp abgespeichert.

Das ist in Win32 10Byte extended und in Win64 wird dieser in ein Double (8Byte) gemappt.

-> daher wird es definitiv unterschiede geben, da auch die interne Darstellung der Zahl anders ist.

zur Info: Win64 baut vor allem auf SSE Befehle auf, die alle bis max double funktionieren, während
Win32 die "alte" FPU benutzt.

Eventuell kann es helfen, die Win32 Genauigkeit von 10Byte Extended auf 8 Byte herunterzusetzen (keine Ahnung obs funktioniert...):

procedure SetDoublePrecission;
var fpuCtrlWord: word;
begin
// set only double precission for compatibility
fpuCtrlWord := Get8087CW;
// set bits 8 and 9 to "10" -> double precission calculation instead of extended!
fpuCtrlWord := fpuCtrlWord or $0300;
fpuCtrlWord := fpuCtrlWord and $FEFF;
Set8087CW(fpuCtrlWord);
end;

[himitsu]

Zitat:

Variant

Nein, Single oder Double.

Und ja, unter Win64 gibt es kein Extended (bzw. ist dort ein Alias für Double)

[Uwe Raabe]

Zitat von rabatscher:

Soweit ich weiss wird ein Variant als "Extended" Datentyp abgespeichert.

Interessanterweise wird hier Currency verwendet, was bei diesem Wert keine Differenz in der internen Darstellung aufweist.

Allerdings verwendet FormatFloat einen Extended Parameter und rechnet intern auch damit. Das führt häufig zu Unterschieden zwischen den Plattformen, da unter Win32 ein AssemblerCode ausgeführt wird, unter Win64 aber nicht. Es gibt zwar schon einige IFDEFs auf EXTENDEDHAS10BYTES, aber offenbar bleiben da trotzdem noch Unterschiede. Ich empfehle einen QP Report mit dem beschriebenen Testcase.

[rabatscher]

Zitat von Uwe Raabe:

Interessanterweise wird hier Currency verwendet, was bei diesem Wert keine Differenz in der internen Darstellung aufweist.

Ah ja, das scheint sich dann seit Delphi 2010 geändert zu haben... Extended wurde also "gecancelt"....
Interessant, dass Delphi hier auf den unwahrscheinlichsten Datentypen zurück greift...

Das Setzen des CPU control words würde übrigens funktionieren:

zwei buttons auf ne form

Code:

procedure SetDoublePrecission;
var fpuCtrlWord: word;
begin
     // set only double precission for compatibility
     fpuCtrlWord := Get8087CW;
     // set bits 8 and 9 to "10" -> double precission calculation instead of extended!
     fpuCtrlWord := fpuCtrlWord or $0300;
     fpuCtrlWord := fpuCtrlWord and $FEFF;
     Set8087CW(fpuCtrlWord);
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  LvTemp: Variant;
  LsTemp: string;
  orig : word;
begin
  orig := Get8087CW;
  if Sender = Button1 then
     SetDoublePrecission;
  LvTemp := Extended(405.405);
  LsTemp := FormatFloat('#,0.00;-#,0.00', LvTemp);
  ShowMessage(LsTemp);

  Set8087CW(orig);
end;

[himitsu]

Offiziell war das nie zur direkten Verwendung vorgesehn, für die Entwickler, sondern nur für interne Zwischenberechnungen.
Tja, und dann hatten sich die Hersteller auch keine Mühe gegeben es in den 64 Bit-CPUs-Befehlssätzen einzubauen.

Viele höhere Programmiersprachen hatten/haben deswegen diesen Typen garnicht erst in der Sprache.

[Michael II]

Wie bereits erwähnt worden ist läuft unter Win32 FloatToTextFmt() via asm und Win64 PUREPASCAL via InternalFloatToTextFmt(). Win64s extended ist ein Alias für double.

jaenicke hat vorgeschlagen via Set8087CW() so zu runden, dass immer dann, wenn ein Dezimalwert z nicht exakt gespeichert werden kann binär die nächsthöhere Zahl gespeichert wird. (Wenn der Delphi Teil korrekt rechnet, sind wir damit bei in der Aufgabe verwendeten Stellenzahl auf der sicheren Seite.) rabatscher schlägt vor via Set8087CW() extended auch Win32 auf double zu zwingen. Weil Win32 und Win64 voneinander verschiedenen Code nutzen, sind wir durch die Beeinflussung der FPU Berechnung immer noch nicht sicher ob am Ende in allen möglichen Fällen immer exakt gleiche Werte berechnet werden.

Aber ich glaube das Grundproblem bei der Win32 Implementierung liegt v.a. beim Casten und gar nicht bei der Berechnung des formatierten Strings.
Wenn man sich die Win32 Berechnung ansieht, dann wird zuerst ein Variant in currency, später in double und danach in extended gecastet (bevor dann der formatierte String berechnet wird). Wenn man direkt currency in extended castet, dann erhält man sehr häufig andere Werte (ist ja klar, da beim Umweg über double Stellengenauigkeit verloren geht und u.a. Rundungsfehler drohen) - und einige dieser Unterschiede wirken sich dann auf FormatFloat aus. var c: currency; d : double; e, edirekt : extended; Dann führt d := double(c); und danach e := extended(d); nicht zum gleichen Ergebnis wie edirekt := extended(c);


Nebenbei: Vorsicht bei currency ([-922337203685477.5808.. 922337203685477.5807]). Currency verwendet fest 4 Nachkommastellen. Das ist im vorliegenden Fall (405.405) also kein Problem. Wenn aber auch Zahlen mit mehr Nachkommastellen als Input möglich sind, dann solltest du den Variant VOR dem Aufruf von FormatFloat() nach extended casten.

Und da es offensichtlich ein Problem wegen dem wiederholten Casten gibt (Datenverlust) solltest du den Variant eh selbst nach extended casten.

Fazit: Der Delphi Source Code gehört in diesem Bereich angepasst.