Trunc liefert falschen Wert

[mkinzler]

Extended ist das Selbe wie Double bei 64Bit. Kann man also schon nehmen.

[Uwe Raabe]

Zitat von mkinzler:

Extended ist das Selbe wie Double bei 64Bit. Kann man also schon nehmen.

In der Standardeinstellung gilt das auch für Real: Real48-Kompatibilität (Delphi)

[himitsu]

Extended sollte man besser nicht verwenden ... es war eigentlich nur für's Rechnen vorgesehen und zum Speichern Single oder Double.

Real ist sowas wie Integer/NativeInt und String und ist nur ein Alias auf den "aktuellen" Typen.

Der uralte Real48-Typ sollte besser auch nicht mehr verwendet werden, außer für Abwärtskompatibilitäten, genauso wie Comp.

[Dejan Vu]

Wieso sollte man Extended nicht nehmen? Und wofür 'nicht'?

[Uwe Raabe]

Zitat von Dejan Vu:

Wieso sollte man Extended nicht nehmen? Und wofür 'nicht'?

Da Extended unter Win64 einem Double gleichkommt, bekommst du ab und an unterschiedliche Ergebnisse zu einem Win32 Compilat. Solange man nur für Win32 compiliert oder die Berechnungen unempfindlich gegebüber diesen Änderungen gestaltet, kann man Extended natürlich verwenden.

[Medium]

Es ist aber an sich auch völlig Hupe welchen Float man jetzt nimmt, da prinzipiell alle irgendwann solche Ergebnisse produzieren. Vielleicht nicht bei 9,7*10, aber dann eventuell bei 3,1*20 oder wann auch immer. Trunc() ist, wenn man eigentlich runden will, einfach die falsche Funktion. Und dann ist es auch schon wieder fast egal welchen Float-Typen man wählt (zumindest für diesen Schritt).

Wenn es dennoch keine Rundung sein soll, sondern ein Floor(), und es kommt wirklich darauf an, dass es immer wirklich genau richtig wird, dann wird Fixpunktarithmetik eigentlich schon fast zur Pflicht.

[Dejan Vu]

Zitat von Uwe Raabe:

Da Extended unter Win64 einem Double gleichkommt, bekommst du ab und an unterschiedliche Ergebnisse zu einem Win32 Compilat. Solange man nur für Win32 compiliert oder die Berechnungen unempfindlich gegebüber diesen Änderungen gestaltet, kann man Extended natürlich verwenden.

Die Unterschiede sind in den letzten Stellen zu finden, also der 14-16 Stelle. Und selbst in Iterationen blubbert der Fehler in die maximal 12 Stelle. Ich kann mir kein ernsthaftes Programm vorstellen, dass sich auf die letzten Stellen einer Berechnung verlässt, i.a. werden max. 6-8 Stellen verwendet.

Klar, auf dem Papier kommt ab und an etwas unterschiedliches heraus, aber das als Grund zu nehmen, auf Extended lieber zu verzichten, geht dann doch etwas zu weit. Das klingt nach Schlangenöl.

[himitsu]

Wenn ich das richtig verstanden hab, dann war Extended nie für den öffentlichen Gebrauch gedacht,
drum trifft man das in anderen Programmiersprachen auch so selten an.

http://docwiki.embarcadero.com/Libra...ystem.Extended

Diese Rundungsfehler muß man bei allen Größen beachten und immer nur das größte zu verwenden ist auch keine Lösung.

[Dejan Vu]

Zitat von himitsu:

Diese Rundungsfehler muß man bei allen Größen beachten und immer nur das größte zu verwenden ist auch keine Lösung.

Nein, aber es gibt Berechnungen, bei denen die Double Genauigkeit nicht ausreicht, ich aber noch nicht auf eine BCD-Lösung ausweichen muss, die dann einen erheblichen Geschwindkeitsnachteil mit sich bringt.

Ich müsste in meinen Unterlagen stöbern, aber es gab einige Fälle, bei denen ich ganz froh war, Extended verwenden zu können.

Weiterhin mag es sein, das Extended mal nur intern gedacht war, aber ... WTF. Teflon wurde ursprünglich auch nur für die Raumfahrt entwickelt und heute brätst Du deine Spiegeleier drauf ( was soll uns dieses Gleichnis kurz vor Weihnachten sagen?)

[Uwe Raabe]

Zitat von Dejan Vu:

Nein, aber es gibt Berechnungen, bei denen die Double Genauigkeit nicht ausreicht, ich aber noch nicht auf eine BCD-Lösung ausweichen muss, die dann einen erheblichen Geschwindkeitsnachteil mit sich bringt.

Ich müsste in meinen Unterlagen stöbern, aber es gab einige Fälle, bei denen ich ganz froh war, Extended verwenden zu können.

Natürlich darfst du Extended verwenden, um die erhöhte Genauigkeit auszunutzen. Es ist manchmal ganz praktisch, wenn man Double-Werte speichert, intern aber mit Extended rechnen kann. Ich verwende das selbst auch für meine CAD/CAM-Anwendungen.

Mit der Genauigkeit ist das allerdings so eine Sache. Gerade bei trigonometrischen Berechnungen muss man seine Genauigkeitsfenster beim Wechsel von Double zu Extended etwas weiter machen. Das hatte z.B. den Effekt, daß meine Unit-Tests für diese Berechnungen beim Umstieg von 32 auf 64 Bit zunächst nicht mehr durchliefen. Ist nichts Unlösbares, aber man muss halt darauf eingehen.