Trunc liefert falschen Wert

[devidespe]

Hallo,

irgendwie scheint Trunc bei mir nicht ganz korrekt zu rechnen. Wenn ich einen Real-Wert von 9.7 x 10 multipliziere und daraus einen Integer mache, sollte es 97 sein, Trunc macht daraus aber 96:

Delphi-Quellcode:

var ErgTemp : Real;
    ErgTempInt : Integer;
begin
  ErgTemp:=9.7;
  ErgTempInt:=Trunc(ErgTemp * 10);
  ShowMessage(IntToStr(ErgTempInt));
end;

Hat jemand eine Idee, woran das liegen könnte? Vielen Dank.

[Medium]

floats ungenauigkeit

-> Nimm besser Round()

[Mavarik]

Deswegen:

Delphi-Quellcode:

var ErgTemp : Real;
     ErgTempInt : Integer;
begin
   ErgTemp:=9.7;
   ErgTemp := ErgTemp * 10;
   ErgTempInt:=Trunc(ErgTemp);
   ShowMessage(IntToStr(ErgTempInt));
end;

Mavarik

[Der schöne Günther]

Also ich kriege wie erwartet 97 raus 8-)

[mm1256]

Komisch...

Delphi-Quellcode:

var ErgTemp : Real;
    ErgTempInt : Integer;
begin
  ErgTemp:=9.7;
  ErgTempInt:=Trunc(ErgTemp * 10);
  ShowMessage(IntToStr(ErgTempInt));
end;

...gibt bei mir auch 96. Warum das bei dir 97 sind, ist mir ein Rätsel :roll:

[Der schöne Günther]

Oh, es wird wieder lustig. Herzlich Willkommen zu einer neuen Ausgabe von

Compiler - Magic

Auf Win64 kommt bei mir 97 heraus. Bei Win32 kommt 96 heraus. Wer probiert iOS und Android aus?

[Insider2004]

9.7*10=96.999999999999999 -> trunc -> 96.

stimmt doch! bitte lesen: Dezimalsysten <-> Binärsystem

[mm1256]

Und warum dann mit Win32 und Win64 zwei unterschiedliche Werte. Hab es soeben auch nachvollziehen können.

[p80286]

Darf ich mal dezent auf #2 hinweisen?
oder anders herum trunc(96.9999999999999999999) ist nun mal 96 und trunc(97.0000000000000000001) ist 97!

Gruß
K-H

[Insider2004]

Zitat:

Zitat von mm1256 (Beitrag 1284420)

Und warum dann mit Win32 und Win64 zwei unterschiedliche Werte. Hab es soeben auch nachvollziehen können.

Real darfst du nicht nehmen. Nur Double. Auch nich Extended.

[mkinzler]

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

[Uwe Raabe]

Zitat:

Zitat von mkinzler (Beitrag 1284426)

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:

Zitat von Dejan Vu (Beitrag 1284453)

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:

Zitat von Uwe Raabe (Beitrag 1284462)

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

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:

Zitat von himitsu (Beitrag 1284480)

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 (:gruebel: was soll uns dieses Gleichnis kurz vor Weihnachten sagen?)

[Uwe Raabe]

Zitat:

Zitat von Dejan Vu (Beitrag 1284482)

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.