<masak> p6: say 1 ** Inf # [RT #85750]
<camelia> niecza: OUTPUT«Cannot open assembly './run/Niecza.exe': No such file
or directory.»
<camelia> ..rakudo-jvm d60a8f: OUTPUT«Can't call method "syswrite" on an
undefined value at /home/p6eval/jvm-rakudo/eval-client.pl line 32.»
<camelia> ..rakudo-{parrot,moar} d60a8f: OUTPUT«1»
<masak> the RT ticket says there are tests expecting this to be 1, but it's NaN
on some systems.
<masak> I was curious to find out what IEEE 754 stands on the matter.
<masak> haven't found out yet.
<masak> my *expectations* of these regions of arithmetic, of the concepts
1/Inf/NaN, and of IEEE 754, though, tell me that either 1 or NaN are acceptable
answers, but I don't know which. I'm pretty sure IEEE 754 has an opinion, and
unless there's a really good reason to deviate, we shouldn't.
<masak> it's easy to argue for either:
<masak> (it should be 1) -- because 1 ** $anything is 1
<masak> (it should be NaN) -- because there's an inherent conflict between 1 **
$anything being 1 and $at_least_1 ** Inf being Inf, and so rather than resolve
that, the sysstem has to give NaN.
<masak> this could be more formally argued using limits, but my hand-wavy
argument shows the way, approximately.
<masak> fwiw, Python (both 2 and 3) has 1 ** Inf as 1.
https://gist.github.com/masak/675fbe68a6474a94b722
<masak> it doesn't have a reified symbol for Inf, hence the workaround with
1e3000.
<masak> http://steve.hollasch.net/cgindex/coding/ieeefloat.html lists a number
of "Special operations", which is something like I was looking for. pow(1, Inf)
-- or anything involving pow -- is notably absent.
<masak> ditto http://users.tkk.fi/jhi/infnan.html
