Die neuen delphi Versionen verwendet ein anderes extended als die alten soviel ich weiß, welches delphi benutzt du?

Moderiert von Martok: Abgetrennt von [url=www.entwickler-ecke....?t=111901]hier[/url]

Hallo,

IhopeonlyReader hat folgendes geschrieben :

Die neuen delphi Versionen verwendet ein anderes extended als die alten ...

Ist schon etwas komisch. In der Delphi 5-Hilfe steht

Zitat:

Extended 3.6 x 10^–4951 .. 1.1 x 10^4932

was auch funktioniert.
Unter www.delphibasics.co....TL.asp?Name=Extended steht

Zitat:

It supports approximately 19 digits of precision in a range from 3.37 x 10^-4932 to 1.18 x 10^4932.

Und zur Krönung steht bei docwiki.embarcadero....Interne_Datenformate

Zitat:

Der Typ Extended Auf 64-Bit-Plattformen ist der Typ Extended ein Alias für den Typ Double, der nur 8 Byte groß ist. (Siehe oben den Abschnitt Der Typ Double). Weitere Informationen finden Sie unter Gesichtspunkte für plattformübergreifende Delphi-Anwendungen. Auf 32-Bit-Plattformen wird eine Extended-Zahl mit 10 Byte (80 Bit) dargestellt.

Nun überlege ich, was mit 64-bit-Plattformen gemeint ist, wahrscheinlich der Compilertyp, denn mein Win8 hat ja 64 bit und da funktioniert es mit dem "richtigen" Extended.

Beste Grüße
Mathematiker

Nachtrag: Später heißt es

Zitat:

Gleitkommaoperationen mit einer "extended"-Genauigkeit werden in 32-Bit-Anwendungen, aber nicht in 64-Bit-Anwendungen unterstützt. Unter Win64 ist die Genauigkeit von Gleitkommaoperationen mit Extended-Variablen auf eine doppelte Genauigkeit reduziert.

Es betrifft also 64bit-Anwendungen.
Da werden sich aber einige Entwickler freuen , wenn ihr 32bit-Code unter 64bit "Merkwürdiges" liefert.
Ich liebe mein Delphi 5.

Natürlich Compiler fertige Anwendung ist fertige Anwendung oder?
Extended ist double..
Derselbe mist wie mit integer bzw. Pointern

Mathematiker hat folgendes geschrieben:

Der Typ Extended Auf 64-Bit-Plattformen ist der Typ Extended ein Alias für den Typ Double, der nur 8 Byte groß ist. (Siehe oben den Abschnitt Der Typ Double). Weitere Informationen finden Sie unter Gesichtspunkte für plattformübergreifende Delphi-Anwendungen. Auf 32-Bit-Plattformen wird eine Extended-Zahl mit 10 Byte (80 Bit) dargestellt. Gleitkommaoperationen mit einer "extended"-Genauigkeit werden in 32-Bit-Anwendungen, aber nicht in 64-Bit-Anwendungen unterstützt. Unter Win64 ist die Genauigkeit von Gleitkommaoperationen mit Extended-Variablen auf eine doppelte Genauigkeit reduziert.

Interessante Wortwahl: auf Doppelte Genauigkeit reduziert. Wer sich das ausgedacht hat, darf nie Finanzminister werden, denn der reduziert dann unsere Staatschulden auf das Doppelte.

Aber im Ernst, warum bitte muss eigentlich ein Variablentyp verändert werden, nur weil der Adressraum vergrößert wurde? Kann mir das mal einer erklären? Und wenn das Ganze ein Alias auf den Double-Typ ist, dann müsste Extended doch auch den Wertebereich von Double haben, und der geht doch nicht bis 10^-4932/10^-4951!!, sondern nur bis 10^-308/10^-328. Oder sehe ich das falsch?

Da gibt es eine einfache Erklärung für. Unter 64Bit wird die x87-FPU mitsamt MMX nicht mehr unterstützt (ist als deprecated markiert). Alle Floatingpoint-Geschichten werden folglich nur noch mit SSE abgewickelt - oder müssen eben emuliert werden. Ohne direkte FPU gibts aber die 80-Bit-Floats nicht mehr, ergo wird alles auf 64-Bittige doubles umgemünzt.

Beschwert euch bei Microsoft.

Schön, wird wie immer alles besser. Wenn ich mir vorstelle, dass eine Berechnung emuliert wird, dann denke ich sofort daran, dass diese Berechnung dann mit fast 100%iger Sicherheit länger dauert.

Da dies wohl so ist, besteht aber immer noch die Frage: Wieso? Hat der größere Adressraum eine solch eingreifende Wirkung, dass der Co-Prozessor nicht mehr ordnungsgemäß angesteuert werden konnte? Problem wird nur sein, dass die 64bit Double einen sehr viel kleineren Wertebereich haben. Da hat man dann wohl nur die Möglichkeit, die Emulation zu nutzen. Konsequenterweise werden wohl, wenn das so weiter geht, die Coprozessoren auf den Motherboards dann wohl der Vergangenheit angehören, oder?

Tranx hat folgendes geschrieben :

Schön, wird wie immer alles besser. Wenn ich mir vorstelle, dass eine Berechnung emuliert wird, dann denke ich sofort daran, dass diese Berechnung dann mit fast 100%iger Sicherheit länger dauert. Da dies wohl so ist, besteht aber immer noch die Frage: Wieso? Hat der größere Adressraum eine solch eingreifende Wirkung, dass der Co-Prozessor nicht mehr ordnungsgemäß angesteuert werden konnte? ... Da hat man dann wohl nur die Möglichkeit, die Emulation zu nutzen. Konsequenterweise werden wohl, wenn das so weiter geht, die Coprozessoren auf den Motherboards dann wohl der Vergangenheit angehören, oder?

Also erstmal: Welche Coprozessoren? Der x87 ist inzwischen ein fester Teil der CPU und somit ein Teil des Prozessors.

Der Grund für das Support-Ende ist einfach, dass das Interface zum x87 ein bisschen staubig ist. Man kann Werte nur auf einen Stack Pushen, und Operationen mit den oberen Operanden erledigen. Es gibt noch ein paar Stack-umordnungs-Befehle. Aber viel praktischer ist es, einfach Zugriff auf alle register direkt zu haben. Genau das setzt SSE um. Dazu kommt noch die Vektorisierung, d.h. du kannst in einer Operation direkt 4 Werte verwurschteln.

Die Compiler sollten also mittelfristig besser für SSE optimieren können als für den x87. SSE Befehle sollten zudem schneller sein als x87 Befehle. Und spätestens wenn SSE auf quadruple precision erweritert wird, hört auch das Gejaule über die Präzision auf. Wobei auch heute die Situationen wirklich rar sind, in denen die Präzision von double nicht ausreicht.

Also nein, das hängt mit dem größeren Adressbereich überhaupt nicht zusammen. Vielmehr ging man unter Win64 den Weg, ein paar alte Zöpfe mit abzuschneiden. Unter Linux 64bit kann man den x87 nach wie vor nutzen.

Bezüglich der Emulation: Wenn du wirklich hohe Präzision brauchst, solltest du eh eine arbitary-precision Bibliothek hernehmen. Und dann hat sich das mit der Hardwarebeschleunigung eh erledigt. Kurz gesagt: Du musst jetzt nicht auf Emulation umsteigen. Entweder sollte dir double reichen, oder du hättest sowieso eine spezielle Bib hernehmen sollen.

jfheins hat folgendes geschrieben :

Wobei auch heute die Situationen wirklich rar sind, in denen die Präzision von double nicht ausreicht.

Richtig! Das setzt allerdings voraus. daß die Bibliotheksfunktionen sauber implementiert sind, am besten korrekt gerundet wie zB bei den Sun-Bibliotheken. Selbst das verbesserte Delphi 18 hat zb bei power(x,y) relative Fehler von 550 eps (10 <= x,y <= 100), sinh(x) relative Fehler von 5000 eps (0 <= x <=1, selbst in dem Bereich, wo nicht das total bescheuerte IsZero(X) jegliche Fehlerbetrachtung sinnlos macht). Für andere Funktionen siehe mein 64-Bit-kompatibles DAMath-Archiv.

jfheins hat folgendes geschrieben :

Vielmehr ging man unter Win64 den Weg, ein paar alte Zöpfe mit abzuschneiden. Unter Linux 64bit kann man den x87 nach wie vor nutzen.

Unter Win64 auch, man sollte es nur nicht tun...
Wenn du die entsprechenden Assemblerbefehle ausprobierst, wirst du sehen, dass das problemlos funktioniert. Aus Geschwindigkeitsgründen werden nur die entsprechenden Register usw. ansonsten nicht benutzt und du musst dich daher selber um diese kümmern (sichern, wiederherstellen, ...).