Hallo Zusammen,

ich habe jetzt mit dem bekannten Problem von 0.1 bei Extended Zahlen zu kämpfen.

Zur Entwurfszeit steht der Cursor auf AIMINGRESULT und hat de Wert 24.1 * 10 sollte eigentlich 241 ergeben. Mit Trunc möchte ich danach den Extended in ein Integer umwandeln um die 241 als Integer in die DB zu schrieben. Doch aus 24.1 * 10 ergibt nicht 241 sondern 240.

Hat jemand eine Idee ich ich zuverlässig aus einem Extended mit 10 multiplizieren kann und danach evl. vorhandene Nachkommastellen abschneiden kann so dass ich einen Integer bekomme?

Also bei mir ergibt 24.1 * 10.0 genau 241

markieren

Code:

var iDummy: Integer;

iDummy := (24.1 * 10.0);

Also müsstest du (AIMINGRESULT * 10.0).AsInterger in die Datenbank schreiben.

ja, bei mir auch wenn ich es so teste.

Die 24.1 werden aus mehreren Werten zusammen addiert und genau das führ zu diesem Seiteneffekt.
Es hängt damit zusammen wie Float Werte verarbeitet werden.

markieren

Code:

var a,b,c:extended;
begin
  inherited;
  a := 8.0;
  b := 8.4;
  c := a + b + 7.7;
  ShowMessage(Trunc(c * 10).ToString);


[Edit] ich könnte für meinen Fall anstelle von extended auch real verwenden. Dann würde zumindest dieser Fall funktionieren aber es muss doch eine zuverlässige Lösung dafür geben oder?

[Edit2]

markieren

Code:

var a,b,c,d,e:extended;
    i:integer;
begin
  inherited;
  a := 8.0;
  b := 8.4;
  c := 7.7;
  d := a + b + c;
  e := d * 10.0; // hier ist der Wert immer noch richtig e=241.
  i := Trunc(e); //Trunc schneidet nicht ab sondern Rundet oder konvertiert.
  ShowMessage(i.ToString);

Bei mir geht das, wenn man das TRUC weg lässt:

markieren

Code:

var a,b,c:extended;
begin
  a := 8.0;
  b := 8.4;
  c := a + b + 7.7;
  ShowMessage((c * 10.0).ToString);    // <-- Ergibt bei mir 241;
end;

es könnten eben Nachkommastellen entstehen je nachdem was addiert wird. Ich benötige nach der Addition NUR die vor Kommastellen abgeschnitten nicht gerundet.

Du schreibst du willst nicht runden. Darum kommst du nicht rum, wenn du mit trunc arbeitest. trunc rundet immer gegen 0: Wenn der in e:extended gespeicherte Wert zwar nahe einer integer Zahl i liegt, aber etwas unter i, dann liefert trunc(e) den Wert i-1 zurück.
Du schreibst weiter oben im Code // e := d * 10.0; // hier ist der Wert immer noch richtig e=241. - Das stimmt nicht; da "betrügt" dich die IDE.
Fall A: In e.frac ist nach e := d * 10.0;
1111000011111111111111111111111111111111111111111111111111 111111 gespeichert (gespeicherter Wert in e 240.höchstdarstellbare Nachkommazahl)
Fall B: Wohingegen nach e := 241; in e.frac
1111000100000000000000000000000000000000000000000000000000 000000
gespeichert ist - also genau 241.

Da trunc gegen 0 rundet, wird im Fall A 240 (11110000) ausgegeben, im Fall B 241 (11110001).

Es gibt diverse Möglichkeiten, das Problem zu lösen (und viele Beiträge dazu in DP).

Data.FmtBcd
Currency (Im "Mischbetrieb" mit extended und Co treten natürlich ähnliche Probleme auf)
Daran denken, dass extended unter Win32 genauer ist als unter Win64 (extended=double) und damit nicht die gleichen "Rundungsprobleme" aftreten.
setroundmode - Rundungsverhalten der FPU steuern - zum Beispiel: setroundmode( rmUp );

Zitat von Kostas:

Hat jemand eine Idee ich ich zuverlässig aus einem Extended mit 10 multiplizieren kann und danach evl. vorhandene Nachkommastellen abschneiden kann so dass ich einen Integer bekomme?

markieren

Delphi-Quellcode:

So vielleicht?
var
   Value:Extended;
   IntValue:Integer;
Value:=24.1 * 10;
IntValue:=Trunc(Value+0.5);

Zitat:

+0.5

Bei 0.9 würde dann aber +1 rauskommen.

Trunc(1.9) = 1
Trunc(1.9+0.5) = 2


Aber ja, ein +0.00…001 und dann Trunc, wäre eine mögliche Lösung, allerdings nur, wenn es kleiner ist, als real vorkommende Nachkommastellen.
Oder vielleicht auch ein RoundTo mit einem passenden SetFPURoundMode.
Oder ...

Es kommt halt drauf an, wie hoch der Nachkommastellenwert gehen kann bevor er abgeschnitten werden soll. Wir wissen ja noch nichts über die Bedeutung dieser Werte und was mit dem Abschneiden erreicht werden soll. Wenn ein Wert z.B. ungefähr 4.999999999 entspricht, soll das dann wirklich 4 werden oder gilt das dann eher als 5?

Abgesehn davon, dass Extended "ursprünglich" nie dafür gedacht war von Entwicklern zur Speicherung genutzt zu werden,
weswegen es das anfangs in vielen anderen Sprachen (C++) garnicht gab, bzw. teilweise immernoch nicht gibt.

Merkt man jetzt, dass es in Bezug auf Win64 und Multiplatform (Android/iOS) wieder nicht mehr gibt.

Kann man von der Verwendung von Extended sowieso nur ausdrücklich von abraten.

markieren

Delphi-Quellcode:

Value := 24.1 * 10; // löst der Compiler auf und nimmt direkt 241.0


Value := 24.1;
Value := Value * 10; // wird erst zur Laufzeit gerechnet (mit den aktuellen Möglichkeiten und Einstellungen der FPU)

Schon erklärt sich, warum vermeintlich "Identisches" eigentlich nur annähernd gleich ist
und sich somit doch unterscheiden kann,
vor allem in Bezug darauf, wann und wie bezüglich der Ungenauigkeiten von Fließkommazahlen es sich leicht abweichen muß.

241.00000000…001
241.00000000…000
241.99999999…999