Delphi 64bit NaN and invalid floating point

Question

I am working on Delphi application in Delphi 10.1. I have compiled successfully for 32 bit, now I am compiling for 64 bit.

In some function, NaN is assigned to its Result variable.
In 64 bit, -1.#IND is assigned instead of NaN. An error occurs, later, when comparing it like 1 < Result

abc = Nan;  //so abc = -1.#IND
if 1 < abc then  // invalid floating point error here  for 64bit
begin
end

an exception

Invalid floating point operation

is raised.

To 1: What exact error occurs further? To 2: An integer zero division should result in an exception. Where is the problem? — René Hoffmann, May 08 '17 at 06:05
**What** error? Please include this information in the question. — René Hoffmann, May 08 '17 at 06:10
The `/` operator returns a floating point type (Double or Extended, depending on the platform). That is why you get point 2. — Rudy Velthuis, May 08 '17 at 06:23
Comparing a NaN with anything, even with another NaN, is an error, in IEEE-754. — Rudy Velthuis, May 08 '17 at 06:25
@RudyVelthuis, if I recall correctly, to determine if a value is a NaN is done by testing `IsNaN := x <> x;` (At least thats what many c libraries use). "A crude but usually effective test for NaN can be written based on the fact that IEEE NaN's never compare equal to anything, even themselves; therefore a number that doesn't compare equal to itself must be a NaN" — LU RD, May 08 '17 at 06:34
One question at a time. MCVE for question 1 please. And as for question 2 there is no integer division, that uses div. — David Heffernan, May 08 '17 at 06:56
@David: if 1< abc then begin end where abc is assigned to Nan in a function. So abc = -1.#IND for 64bit. And error message occurs at 1< abc — poonam, May 08 '17 at 07:11
Don't ask in comments. One question at a time. Include a MCVE. As it stands, this should be closed. Fix it quick. — David Heffernan, May 08 '17 at 07:16
yes edited question, removed second question as well...thanks — poonam, May 08 '17 at 07:25
@LURD: Yes, you are right: http://stackoverflow.com/a/1573715/95954 — Rudy Velthuis, May 08 '17 at 07:39
I cannot put my code here..even if i execute above mentioned code in delphi..then you can reproduce error... — poonam, May 08 '17 at 07:56
You can produce a [mcve]. Why can't you make some effort? There is possibly a good question in here. You seem to be indicating that the 32 bit version of your program behaves differently from the 64 bit version. The code in the question at the moment behaves the same for 32 and 64 bit. Please make the required effort to ask the question. It's the same effort that is required to solve the problem. Stop flailing around. — David Heffernan, May 08 '17 at 07:59
The 64 bit debugger reports a NaN as `-1.#IND`. Your code will behave the same way in both compilers. And `<` and `>` leads to FP error when one arg is NaN in both 32 and 64 bit. If you would only do the decent thing and make a [mcve] we could give you a nice answer. — David Heffernan, May 08 '17 at 08:01

score 2 · Answer 1 · answered May 08 '17 at 07:23

If you know or suspect that a floating point number is NaN. Then you need to test for NaN or be prepared to handle exceptions.

Any operation on a NaN number will trigger an exception.

You can test for NaN using the IsNaN function

uses Math;
.....
if isNaN(x) then ......

Unlike c which forces division with integers to be treated as integer division, Delphi has separate operators.

/ always produces a floating point result. div always produces an integer result.

Finally, any operations with floating point values are subject to IEEE-754.

IEEE 754 specifies that a quiet NaN variable will test false for a equality test with itself. Delphi throws an exception when a NaN is put into the FPU, so that test cannot be done. — LU RD, Oct 14 '17 at 11:00

Delphi 64bit NaN and invalid floating point

1 Answers1