FormatFloat 32bit / 64bit

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