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