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.
-----Original Message----- From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of g...@wolfgang-ehrhardt.de Sent: Thursday, June 21, 2018 2:46 AM To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org> Subject: Re: [fpc-pascal] math with infinity and NaN Quoting James Richters <ja...@productionautomation.net>: > 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? 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); _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
