Doug McNutt wrote: >> - - Specify them to return some definite value. > Only on a machine that doesn't do it in hardware or in some special perl > function that's unlikely.
This question arises as different platform answer things differently for
the native calculation of eg. 1**Inf.
>
>> At this moment, Pugs defines them ad-hocly to:
>>
>> 0/0 == die "Illegal division by zero" <--- wrong. 1/0 should not
>> die either.
I personally like having 0/0 be NaN and 1/0 be Inf (as in JavaScript),
but all of Python/Perl/Ruby/Scheme/OCaml throws exceptions for them...
>> 0*Inf == NaN <--- reasonable but don't re-invent the NaN bit pattern
>> Inf/Inf == NaN <--- reasonable but don't re-invent the NaN bit pattern
>> Inf-Inf == NaN <--- reasonable but don't re-invent the NaN bit pattern
The NaN as used in Pugs is already a double-precision NaN bit pattern. :-)
>> 0**0 == 1 <--- Not indeterminate. Answer is correct.
>> Inf**0 == 1 <--- Not indeterminate. Answer is correct.
>> 1**Inf == 1 <--- Not indeterminate. Answer is correct.
On my machine (Pentium-M, FreeBSD), 1**Inf yields NaN, as demonstrated
by this Parrot program:
.sub main
$N1 = 1/0
print $N1 # inf
$N2 = 1 ** $N1
print $N2 # nan
.end
But putter on #perl6 reports "1" on his amd64. I'd be happy we spec it
has to have to return 1 always for boxed Num types, even though it means
additional cycles for boxed numeric types.
Audrey
signature.asc
Description: OpenPGP digital signature
