Wozu ist die CompilerVersion vom Typ Extended ?

[Rollo62]

Hallo zusammen,

ich habe gerade in der Dokumentation nachgesehen,

Zitat:

CompilerVersion CompilerVersion: Extended = 34;

weil ich mich über die Angaben mal 34, mal 34.0 wundere.

Wer um Alles in der Welt hat für die CompilerVersion den Typ Extended ausgesucht,
gibt es dafür irgendeinen rationalen Grund ?

Gut, Extended ist meiner Meinung nach das komplette Gegenteil eines präzisen numerischen Wertes,
deshalb wäre Integer * 100 oder sowas MEINE Wahl gewesen ( so wie es auch bei VER340 gezählt wird).

Bei ungünstigen Abfragen auf = 34.0 könnte man sich üble Rundungs-Fehler einhandeln
( OK, ich mache sowieso bei Vergleichen immer >= 34.0, dann ist es schon machbar ).

Auf der anderen Seite könnte Embarcadero denken das Delphi ewig bestehen wird,
und dass dann mit Extended die Version näher am Unendlichen ist :stupid:

Was hat sich der Meister dabei nur gedacht :gruebel: ?

[hoika]

Hallo,
http://docwiki.embarcadero.com/RADSt...iler-Versionen

D2007 ist 18.5

"Beachten Sie bitte, dass für Delphi 2007 zwei VERxxx-Symbole (VER180 und VER185) definiert sind. Delphi 2006 und 2007 sind binär kompatibel, sodass 180 mit beiden arbeitet. Verwenden Sie VER185, wenn Sie nur 2007 benötigen"

[Rollo62]

Ja ist schon klar.
Nur ist Extended für Vergleiche eben extrem schlecht, weil floating point.
Ausserdem hätte Single dann wohl auch gereicht.

Was solls, ich muss das ja nicht verstehen :stupid:

[Uwe Raabe]

Da sowohl CompilerVersion als auch die 34.0 Konstanten vom gleichen Typ sind, sollte ein Vergleich auf Gleichheit schon passen.

[Rollo62]

Zitat:

Zitat von Uwe Raabe (Beitrag 1470858)

Da sowohl CompilerVersion als auch die 34.0 Konstanten vom gleichen Typ sind, sollte ein Vergleich auf Gleichheit schon passen.

Ist ja wohl ein ähnliches Thema, vor einer Minute
https://www.delphipraxis.net/205093-...ml#post1470857

Nur leider kann man SameValue in der bedingten Compilierung nicht nutzen weil nicht intrinsisch, soweit ich weiss.


Das 34.0 = 34.0 gleich ist will ich mal hoffen,
wobei natürlich Abfragen auf exakt = 34.0 auch extrem selten vorkommen dürften.
Es könnte mal angenommen sein, dass nur eine bestimmte Version ein bestimmtes Problem hat,
dann würde man aber besser statt "= 34.0" doch eher ">=" und "<=" nehmen.

Also ich würde zum Beispiel statt "= 34.0" <===> das nehmen "( >=34.0 ) and ( < 34.1 )",
um ganz sicher zu sein.

[Andreas13]

Hallo Rollo62,
in diesem Fall ist ein unscharfer Vergleich nicht notwendig, weil die typisierte Konstante

Delphi-Quellcode:

 
CONST 
  CompilerVersion: Extended = 34;

per Deklaration und nicht als das Ergebnis einer Berechnung zustande kommt. Damit gibt es keine Rundungsfehler. Wenn Du Deine Compiler-Version ähnlich deklarierst

Delphi-Quellcode:

 
CONST 
  MyCompilerVersion: Extended = 34;

Dann hast Du dieselbe Bitcodierung, also eine wirklich identische Extended-Zahl. Bei Single oder Double wäre das nicht der Fall. Daher ist die eindeutige Typangabe

Delphi-Quellcode:

 Extended

erforderlich, damit ein Vergleich auf exakte Gleichheit hinhaut.
Gruß, Andreas

[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). :stupid:

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

Zitat von Andreas13 (Beitrag 1470882)

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.
Anhang 52869

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 :stupid:

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

Zitat von Rollo62 (Beitrag 1470951)

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

Delphi-Quellcode:

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

[himitsu]

Ja, für Berechnungen, aber zur "Speicherung" war es eigentlich nie gedacht.

PS: Auch wenn der Extendet in einigen Plattformen 16 Byte groß ist, hat er dennoch nur die bekannte 10 Byte an Nutzdaten und der Rest ist eine eher sinnlose Speicherausrichtung.
auf 4 Byte (12 Byte gesamt), hätte doch bestimmt auch gereicht. (wäre nun die Frage, ob man dort auch packed benutzen kann, um die ungenutzten 6 Byte loszuwerden ... aber egal, weil man den Typ ja eigentlich sowieso nicht benutzt)

Auf "neueren" Plattformen nutzt daher Delphi auch Double, selbst wenn man Extended angibt.
Aber man hätte dort dennoch besser den "Typ" ganz weglassen können/sollen, anstatt den Typ mit einem anderen, kleinen oder gar bösartig größerem Typ intern zu ersetzen.
Böse, wenn da jemand mit Pointern und "fest" 10 Byte arbeitet und nun keine Fehlermeldung bekommt, weil es ja den "Typ" dennoch gibt, obwohl es ihn nicht mehr gibt.
Auch hätte man gern das deprecated ans Extended hängen dürfen.