Wozu ist die CompilerVersion vom Typ Extended ?

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