I’ve been updating my old programs to use the MATH unit in freepascal and while testing things I came across a runtime error 217 Invalid floating point operation. Here is my test program

Uses math;
var
   variable1:double;
   variable2:double;
Begin
variable1:= Infinity;
variable2:= -1*Infinity;
Writeln(variable1,' ',Variable2,' ',Variable1+Variable2);
End.

My output is:

Running "i:\programming\test\testmath.exe "

An unhandled exception occurred at $004015F6:

EInvalidOp: Invalid floating point operation

$004015F6 main, line 8 of i:/programming/test/testmath.pas

+Inf -Inf

According to the link here: https://en.wikipedia.org/wiki/NaN

NaN should be produced:

The additions (+∞) + (−∞), (−∞) + (+∞) and equivalent subtractions (+∞) − (+∞) and (−∞) − (−∞).

I can do things like +infinity*2 and +infinity-3 and even sqr(infinity) and power(infinity,10) the results are still +Inf which is expected… but I can’t do anything involving subtracting infinity from infinity. Here is another test program that illustrates this more clearly:

Uses math;
var
   variable1:double;
   variable2:double;
Begin
variable1:= 1/0;
variable2:= -1/0;
Writeln('          V1',variable1);
Writeln('          V2',variable2);
Writeln('    SQRT(-1)',Sqrt(-1));
Writeln('       V1*V1',variable1*variable1);
Writeln('       V1*V2',variable1*variable2);
Writeln('        V1+3',variable1+3);
Writeln('       V1+V1',variable1+variable1);
Writeln('        V1-3',variable1-3);
Writeln('     Sqr(V1)',Sqr(Variable1));
Writeln('     Sqr(V2)',Sqr(Variable2));
Writeln('    Sqrt(-1)',Sqrt(-1));
Writeln('    Sqrt(V1)',Sqrt(Variable1));
Writeln('Power(V1,10)',Power(Variable1,10));
Writeln('     ABS(V2)',ABS(Variable2));
Writeln('    Sqrt(-1*V1)',Sqrt(-1*Variable1));//runtime error 217  Should be NAN
Writeln('    Sqrt(V2)',Sqrt(Variable2));      //runtime error 217  Should be NAN
Writeln('       V1-V1',variable1-variable1);  //runtime error 217  Should be NAN
Writeln('       V1+V2',variable1+variable2);  //runtime error 217  Should be NAN
End.

Running "i:\programming\test\testmath.exe "

V1 +Inf

V2 -Inf

SQRT(-1) Nan

V1*V1 +Inf

V1*V2 -Inf

V1+3 +Inf

V1+V1 +Inf

V1-3 +Inf

Sqr(V1) +Inf

Sqr(V2) +Inf

Sqrt(-1) Nan

Sqrt(V1) +Inf

Power(V1,10) +Inf

ABS(V2) +Inf

An unhandled exception occurred at $00401A43:

EInvalidOp: Invalid floating point operation

$00401A43 main, line 22 of I:/Programming/Test/testmath.pas

Sqrt(-1*V1)

It seems to me that the whole purpose of +Inf, -Inf, and NaN was so you could evaluate complex formulas and NOT get a runtime error… Is this behavior just a bug that should be reported? Testing was done with V3.0.4

James

This is compatible with IEEE-754. Section 7.2 says

<quote>
7.2 Invalid operation

For operations producing results in floating-point format, the default result of an operation that signals the
invalid operation exception shall be a quiet NaN that should provide some diagnostic information (see 6.2).
These operations are:

...
b) multiplication: multiplication(0, ∞) or multiplication(∞, 0)

...

d) addition or subtraction or fusedMultiplyAdd: magnitude subtraction of infinities, such as:
addition(+∞, −∞)

e) division: division(0, 0) or division(∞, ∞)

...

g) squareRoot if the operand is less than zero
</quote>

You get the expected quite NaN results if you add the line

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

to your test programs.

My first reaction is that
SetExceptionMask([exDenormalized,exZeroDivide,exOverflow,exUnderflow,exPrecision]) would be required (I can't remember what the default is), but it doesn't stop the error (x86_64/linux). I suspect a bug, though I am slightly surprised it hasn't surfaced before.

Colin

Zitat von C Western :

You forgot the most important item: exInvalidOp! At least on Win7 the code works as exptected.

I suggest to file a bug report. It is very unfortunate that the Math unit doesn't conform to IEEE-758.

Regards,

Adriaan van Os

In our previous episode, C Western said:

> I can do things like +infinity*2 and +infinity-3 and even sqr(infinity) > and power(infinity,10) the results are still +Inf which is expected? > ??but I can?t do anything involving subtracting infinity from > infinity.?

Isn't that normal? Otherwise, what would inf+inf-inf be if you know that (inf+inf) =inf

No, that’s not normal, it's not supposed to give you a runtime error. Anything that results in an answer that is Not a Number is supposed to be set to NaN, not give you a runtime error 217 and terminate. Infinity minus itself is undefined and therefore Not a Number and should be set to NaN, but I don't get NaN, I get a fatal runtime error 217. To answer your question: if you know Inf + Inf = Inf and you know Inf - Inf = Nan then Properly evaluating from left to right: Inf + Inf - Inf = Inf - Inf = NAN or if you want to do it the other way: inf - inf + inf = NaN + Inf = NaN

(+inf) + (+inf) should and does give you (+inf)
(-inf) + (-inf) should and does give you (-inf)
(+inf) - (+inf) should give you (NAN) but it gives you Runtime Error 217 (-inf) - (-inf) should give you (NAN) but it gives you Runtime Error 217 (+inf) + (-inf) should give you (NAN) but it gives you Runtime Error 217 (-inf) + (+inf) should give you (NAN) but it gives you Runtime Error 217

Snip from refrence at: https://en.wikipedia.org/wiki/NaN Operations generating NaN:
There are three kinds of operations that can return NaN:

1. Operations with a NaN as at least one operand.

2. Indeterminate forms:
a. The divisions (±0) / (±0) and (±∞) / (±∞). b. The multiplications (±0) × (±∞) and (±∞) × (±0). c. The additions (+∞) + (−∞), (−∞) + (+∞) and equivalent subtractions (+∞) − (+∞) and (−∞) − (−∞). d. The standard has alternative functions for powers: The standard pow function and the integer exponent pown function define 0⁰, 1∞, and ∞⁰ as 1. The powr function defines all three indeterminate forms as invalid operations and so returns NaN.

3. Real operations with complex results, for example: The square root of a negative number.
The logarithm of a negative number.
The inverse sine or cosine of a number that is less than −1 or greater than 1.

#2c clearly defines that NaN is set for the above conditions that are failing with a runtime error 217

Also reference:
https://www.philforhumanity.com/Infinity_Minus_Infinity.html

James

No. The invalid operation is not masked by default. If you do so, FPC just write Nan.

Please read the standard, exceptions are part of it.

Is there a way to prevent getting the runtime error?

James

My initial testing indicates that, even with exceptions masked, the exception was raised: (or am I using the wrong routine?)

Uses math;
var
     variable1:double;
     variable2:double;
Begin
SetExceptionMask([exDenormalized,exZeroDivide,exOverflow,exUnderflow,exPrecision]);
variable1:= Infinity;
variable2:= -1*Infinity;
Writeln(variable1,' ',Variable2,' ',Variable1+Variable2);
end.

./t
An unhandled exception occurred at $00000000004002A1: EDivByZero: Division by zero
$00000000004002A1 main, line 9 of t.pas

+Inf -Inf

Colin

James Richters wrote

Is there a way to prevent getting the runtime error?

=== code begin ===

SetExceptionMask(GetExceptionMask + [exInvalidOp]);

=== code end ===

Regards,
Sven

Please read the standard, exceptions are part of it.

Not much of a 'standard' if it's full of exceptions so everyone just does it however they want and therefore nothing is actually standard.

Using:
SetExceptionMask([exDenormalized,exZeroDivide,exOverflow,exUnderflow,exPrecision,exInvalidOp]); gives:
+Inf -Inf Nan

though I would have to say the requirement to mask invalid operation when the exception reported is divide by zero is confusing....

Colin

SetExceptionMask(GetExceptionMask + [exInvalidOp]); Works! Thank you for the help!

I'm curious why things like SQRT(-1) just produce NAN without needing to change the exception mask and (+inf) - (+inf) does not behave the same way. They both are invalid, why treat one method of generating an invalid number one way and another method of getting just as invalid of a number another way? If there is flexibility in the standard, then why not choose to always be consistent? I have a lot of examples of things that do produce NAN without needing to change the exception mask... like ln(-1) or 0/0 why do some cause the exception and others do not?

If someone wanted to volunteer time to adjust the math unit to always behave the same way, would it be something that would be accepted or is there some fundamental reason why it is like this?

James

Quoting James Richters :

The case SQRT(-1) seems to be handled by the compiler, just like the definition
Nan = 0/0 in math.

If you have an expression, which is not handled at compile time you get the EInvalidOp exception, try

variable2 := Pi-4;
variable1 := sqrt(variable2);
Writeln(variable1);

Even with masked exceptions, runtime errors are produced in the Math unit. That is not conformant to the standard.

Regards,

Adriaan van Os

Zitat von Adriaan van Os :

Even with masked exceptions, runtime errors are produced in the Math unit. That is not conformant to the standard.

Even with masked exInvalidOp? Can you give an example?

For operations producing results in floating-point format, the default result of an operation that signals the invalid operation exception shall be a quiet NaN that should provide some diagnostic information (see 6.2).

If it shall be a quiet NaN doesn't that mean it would never cause the runtime error? To my understating signaling NaN raises the exception, and Quiet Nan does not.. it just quietly sets the variable to NaN and continues by default. It states that the DEFAULT result shall be this quiet NaN so if that's the case then setting SetExceptionMask([exInvalidOp]); should not be required to prevent the runtime error. The default behavior should be that it's a Quiet NaN.

The compiler does seem to be filtering out the conditions that hard coded to resolve to NaN. That explains the seemingly inconsistent results, when I set variables and try the operations that seemed to work before they now produce the error. Thanks for pointing that out.

Zitat von James Richters :

As far as I understand: if the exInvalidOp is masked the default result is a quiet NaN. If exInvalidOp is not masked the excption is thrown. (I do not know if a result is set to NaN and how this could be exploited).

The fact that it raises the exception at all makes it a signaling NaN not a quiet Nan, but they are supposed to be Quiet Nan which never throw the exception according to the specification which clearly states they are Quiet Nans, not Signaling Nans. Suppressing the exception makes them act like quiet nans, but the fact that they need suppressing of the exception makes them signaling nans.

Zitat von James Richters :

This is not correct. Signal and quit NaNs ar precisly defined:

Quote from
https://en.wikipedia.org/wiki/IEEE_floating_point#Interchange_formats

"For NaNs, quiet NaNs and signaling NaNs are distinguished by using the most significant bit of the trailing significand field exclusively (the standard recommends 0 for signaling NaNs, 1 for quiet NaNs, so that a signaling NaNs can be quieted by changing only this bit to 1, while the reverse could yield the encoding of an infinity), and the payload is carried in the remaining bits."

In the IEEE-754 standard it is "3.4 Binary interchange format encodings"

You can test, that the Nan is a quiet NaN with

Uses
   math, sysutils;
var
   variable1, variable2:double;
   iv1: int64 absolute variable1;
Begin
   SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide,
exOverflow, exUnderflow, exPrecision]);
   variable1:= sqrt(-1);
   variable2 := Pi-4;
   variable1 := sqrt(variable2);
   Writeln(variable1, '  ', IntToHex(iv1, 16));
End.

C:\TMP>fpc64304 xx1.pas

C:\TMP>D:\FPC304\bin\i386-win32\ppcrossx64.exe xx1.pas Free Pascal Compiler version 3.0.4 [2017/10/06] for x86_64 Copyright (c) 1993-2017 by Florian Klaempfl and others Target OS: Win64 for x64
Compiling xx1.pas
Linking xx1.exe
13 lines compiled, 0.2 sec, 71824 bytes code, 4964 bytes data

C:\TMP>xx1.exe
Nan FFF8000000000000

The 8 nibble shows that the highest bit of the mantissa is 1 and therefore you have a quiet NaN.

Math.power with a negative base would except, even with masked exceptions. That was with fpc-2.6.4. I can't reproduce it anymore with fpc-3.0.4, so it seems to be fixed.

Regards,

Adriaan van Os