is_nan/inf

Definition:	bool res = is_nan(object a, bool b64=false) -- or -- bool res = is_inf(object a, integer sgn=0, bool b64=false)
Description:	Determine whether a is one of the special values [+/-]NaN or infinity. a: the number to test - automatically yields false(0) if a is an integer or not an atom. sgn: check for a specific +/- infinity. default: either, -1: -infinity, +1: +infinity. b64: use 32-bit compatible methods/limits when running on 64-bit, ignored on 32-bit. returns true(1) if a is one of the specified special values, false(0) otherwise.
pwa/p2js:	Supported. is_nan() is mapped directly to Number.isNaN(), while is_inf() uses Number.isFinite() and implements sgn handling on top. Neither pay any heed to b64, since Javascript is inherently 32-bit.
Comments:	The file builtins/infnan.e (an autoinclude) contains efficient low-level code to check for special floating point values. Unlike some programming languages, Phix specifically traps division by zero, making these values less likely to occur. In fact the only way I know of generating a nan is to first generate an inf (eg 1e3081e308), then divide that by itself. Note that is_nan(a) answers the question "is it the special value [+/-]NaN?" rather than "is it not a number?", and of course the latter is better answered in Phix by "not atom(a)", aka "not number(a)" [number being a simple alias of atom]. b64 has no effect on 32-bit, but when set to true on 64-bit it replicates the 32-bit test, by storing the normal 80-bit float in 64 bits, which should help obtain identical results whether the program is run on 32 or 64 bits (rarely needed). One case where it probably will help is in generating JSON, another may be developing on 64bit desktop/Phix with a mind to later transpiling the finished program to JavaScript. Lastly note that Phix goes against the grain in that nan==nan, a somewhat incorrect decision I made many many years ago, mainly since back then I thought it would be a good idea to allow (say) find(nan,s), though it would not exactly be the end of the world to have to replace any such with a longhand is_nan() loop. I am (now) aware that nan!=-nan [in both proper terms and Phix as it stands], which kinda proves that ancient decision was indeed rather wrong (is_nan() completely ignores the sign, just as it should, btw). The specific code is in builtins\VM\pJcc.e, marked "--DEV this may be the wrong thing to do entirely" (4 aka cmp/eq * 32/64) That behaviour may be altered in a future release - there are several dependencies on it in sprintf(), of my own making, plus it needs/deserves a full hunt through all source code for any other such abuses in /demo, /test, etc.
Example:	?is_inf(1e3081e308) -- prints 1 aka true, for more see test/t69infnan.exw*
Implementation:	See builtins\infnan.e (an autoinclude), or pwa\p2js.js, for details of the actual implementation (the former includes both inline assembly and the earlier hll code it was originally based on, which made its development much simpler/actually achievable).