floating point invalid operation: 10.1 vs. 10.2

[striderx]

Vielen Dank für die weiteren Vorschläge - die werde ich morgen in Ruhe ausprobieren.

Allerdings scheinen auch diese darauf abzuzielen, das mathematisch richtige Ergebnis zu erzielen, ich brauche aber dummerweise das falsche Ergebnis, das eines Überlaufs.

Anders ausgedrückt: Ich brauch eine Funktion, welche bei dem Beispielswert 64536 dann 184,17 als Ergebnis auswirft und nicht 91267,69.


Und nach den gegebenen Erklärungen wird es für mich immer mysteriöser, warum unter 10.1 keine Eception kommt - selbst bei eingeschalteter Bereichsprüfung.


Gute Nacht miteinander!

[bcvs]

Habe mal ein bischen rumprobiert:

Es sieht so aus, dass in 10.2 der Rückgabewert von

Delphi-Quellcode:

SQR(AWord)

kein Word, sondern ein Integer ist. Wenn der Rückgabewert ein Word wäre, könnte der Überlauf-Wert ja nicht negativ werden und es gäbe keine Exception beim SQRT.

Man kann das schön nachvollziehen, wenn man den Rückgabewert von SQR entsprechend castet:

Delphi-Quellcode:

var
  AWord: Word;
  ADouble: Double;
  temp :Integer; // <----
begin
  AWord := 64536;
  temp  := SQR(AWord); // -130072000
  ADouble := SQRT(temp + temp); // floating point invalid operation
end;

Delphi-Quellcode:

var
  AWord: Word;
  ADouble: Double;
  temp :Word; // <----
begin
  AWord := 64536;
  temp  := SQR(AWord); // 16960
  ADouble := SQRT(temp + temp); // 184,17
end;

So bekommst du auch deinen richtigen falschen Wert 184,17.

Anscheinend gibt D10.1 im Gegensatz zu 10.2 hier bei SQR gleich den Word-Wert 16960 zurück.

[striderx]

Super, das erzeugt genau die Werte, die ich brauche!

In der Ecke scheint sich auch noch mehr getan zu haben. So funktionieren in 10.2 anscheinend

Delphi-Quellcode:

{$FINITEFLOAT OFF}

und

Delphi-Quellcode:

Math.SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow, exUnderflow, exPrecision]);

nicht mehr.