Wozu ist die CompilerVersion vom Typ Extended ?

[Rollo62]

Na schön, ich gehe halt immer gerne auf Nummer sicher.

Du meinst also bei

Delphi-Quellcode:

 
CONST
  CompilerVersion: Single = 34;
 
CONST
  MyCompilerVersion: Single = 34;

Result :=   CompilerVersion = MyCompilerVersion;  // Ok, weil gleiche Typen, gleiche Bitkodierung

wäre ein direkter Vergleich möglich ?
Ist ja auch die identische Bitkodierung.

Nur wenn ich direkte konstante Zahlen, und keine mit Typ deklarierten Konstanten, im Vergleich eingebe
dann könnte das den Unterschied ausmachen.

Delphi-Quellcode:

 
CONST
  CompilerVersion: Single = 34;

Result :=   CompilerVersion = 34.0;  // Möglicherweise OK, wenn intrinsische Typumwandlung 34.0 auf Extended
Result :=   CompilerVersion = 34;    // Problematisch weil womöglicherweise verschiedene Typen (Integer)

Es gibt ein paar interessante Links dazu:
http://www.delphibasics.co.uk/Article.asp?Name=Numbers
http://rvelthuis.de/articles/articles-floats.html

aber irgendwie finde ich gerade nicht welchen Typ ( ABC = 34.0) eine nicht-deklarierte Konstante eigentlich bekommt.
- nimmt die den Typ an, den ABC hat ? (davon gehe ich eigentlich aus (= der Compiler optimiert so dass keine Conversion nötig ist)
- wird die immer zu Extended (conversion könnte passieren) ?
- wird die immer zu Double (conversion könnte passieren) ?

Bei Embarcadero habe ich auf die Schnelle nichts dazu gefunden ( gibt es aber bestimmt).

[Andreas13]

Nicht jede Dezimal-Zahl ist binär exakt codierbar. Bereits hier könnte es ohne eindeutige Typangaben zu internen Rundungsfehlern kommen. Beispiel:

Delphi-Quellcode:

CONST
  CompilerVersion_e: Extended = 34.1;
  CompilerVersion_s: Single   = 34.1;
  CompilerVersion_d: Double   = 34.1;

  CompilerVersion_o = 34.1; // o: Ohne Typangabe

Begin
    WriteLn('Extended = Single:   Ist Gleich? = ', CompilerVersion_e = CompilerVersion_s);
    WriteLn;
    WriteLn('Extended = Double:   Ist Gleich? = ', CompilerVersion_e = CompilerVersion_d);
    WriteLn;
    WriteLn('Extended = Extended: Ist Gleich? = ', CompilerVersion_e = CompilerVersion_e);
    WriteLn;
    WriteLn('Extended = OHNE Typ: Ist Gleich? = ', CompilerVersion_e = CompilerVersion_o);
    WriteLn;

    WriteLn('SizeOf(CompilerVersion_e) = ', SizeOf(CompilerVersion_e)); 
    WriteLn('SizeOf(CompilerVersion_s) = ', SizeOf(CompilerVersion_s));
    WriteLn('SizeOf(CompilerVersion_d) = ', SizeOf(CompilerVersion_d));
    WriteLn('SizeOf(CompilerVersion_o) = ', SizeOf(CompilerVersion_o));
    
    ReadLn;
End;

Inndiesem Fall (34.1) ist:
(Extended = Single) ---> False
(Extended = Single) ---> False
(Extended = Double) ---> True
(Extended = Extended) ---> True
(Extended = Ohne Typ) ---> True // Der Compiler verwendet hier automatisch Double

Warum? Weil die Dezimalzahl 34.1 binär nicht exakt darstellbar ist und je nach Real-Type intern „ein bißchen“ anders aussieht.

Ändern wir die Konstanten jeweils auf 34, so sieht es ganz anders aus: Alle Vergleiche liefern True, aber für die nicht-typisierte Konstante hat der Compiler (XE5) den Datentype Byte gewählt.
Fazit: Um das Ergebnis des Vergleichs nicht dem Zufall & der Compilerversion zu überlassen, sollten wir die Konstante durch Typisierung eindeutig festlegen.
Gruß, Andreas

[himitsu]

Currency wäre hier bestimmt vollkommen ausreichend und "optimaler" gewesen.

Aber für ganze und halbe Versionen sollte es meisten kein Probleme bereiten.

[Uwe Raabe]

Zitat von Andreas13:

Nicht jede Dezimal-Zahl ist binär exakt codierbar.

Korrekt! Allerdings haben wir hier einen besonderen Fall: Die Compiler-Version bleibt in absehbarer Zeit vermutlich zweistellig und die Nachkommastelle ist wohl allenfalls eine 5 (=½) und sonst 0. Damit lässt sich diese Zahl auch immer exakt als Extended (vermutlich sogar Double oder Single) darstellen. Um alle ganzen und halben Versionen bis 127.5 darzustellen braucht es gerade mal die ersten 7 Bit in der Mantisse und die letzten 3 vom Exponent.

[Andreas13]

Vielleicht stimmt das nicht ganz: denn selbst die Dezimalzahl 0.1 läßt sich binär nur durch einen unendlich nichtperiodischen binären Wert darstellen, also nicht exakt, sondern nur gerundet. Und wenn ich nach 32 Bit, 64 Bit oder 80 Bit runde, kommen "ein bißchen" andere Werte raus, wodurch die absolute Gleichheit nicht mehr besteht, weil u. U. ein Bit anders gesetzt ist.
Andreas

[Andreas13]

Meine Vermutung – warum sich Mr. Turbo Pascal & Embarcadero für den DatenType Extended entschieden hat – ist, daß der inzwischen stets vorhandene mathematische Coprozessor (Intel/AMD) reelle Zahlen immer mit der vollen "Bandbreite" von 80 Bit (= Extended) verarbeitet, egal ob die Werte als 32 oder 64 etc. Bit vorliegen.
Andreas

[Rollo62]

Nicht nur das es für den Zweck der sinnloseste aller Typen ist,
es ist auch noch der Typ welcher auf jeder Platform anders ist.
Clipboard03.jpg

Das wird vielleicht nochmal interessant wenn RadStudio wirklich auf Win64, Macos und sonstwas portiert ist.

Selbst mit der kleinsten maximalen Versionsnummer von 1.79e+308 bleibt Embarcadero wohl noch genug Zeit für die Portierung

[samso]

Ich verstehe das Problem nicht.

Selbst wenn das auf jeder Plattform anders ist, dann bleibt ein typischer Vergleich {$if CompilerVersion>=35.5} auf allen Plattformen doch gültig, egal mit wie vielen Bits die Gleitkommazahl dargestellt wird. Das hat ja Uwe bereits sehr deutlich dargestellt.

Eine Diskussion über ein Problem das es mit der CompilerVersion 40.1 geben könnte, ist an den Haaren herbei gezogen. Ich würde diese Diskussion einfach auf den Tag verschieben, an dem es die CompilerVersion 40.1 o.ä dann gibt.

[Andreas13]

Zitat von Rollo62:

Nicht nur dass es für den Zweck der sinnloseste aller Typen ist, es ist auch noch der Typ welcher auf jeder Platform anders ist.

Könnte sein, daß es historisch gewachsen ist. Für numerische Berechnungen (= mein Schwerpunkt) ist Extended der sinnvollste Datentyp. Noch besser wäre eine noch höhere Genauigkeit (mindestens 256 Bit), die es leider nicht gibt. Und für die Zielplattform 64-Bit steht leider

Delphi-Quellcode:

Type
  Extended = Double;

was - für meine Aufgaben - ein absoluter Rückschritt ist. Deswegen bleibe ich weiterhin auf der 32-Bit-Zielplattform. Das war wahrscheinlich der kleinste gemeinsame Nenner, nachdem alle MicroSoft-Produkte & Compiler (C#, C++) und auch Fortran keinen Extended-Datentyp kennen. Muß wohl weiterhin Multipräzisions-Routinen verwenden, um meinen Genauigkeitsansprüchen gerecht zu werden...
Gruß, Andreas