[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: arithmetic issues

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.



> Aubrey Jaffer wrote:
> No, its expt as in EXPT, the Scheme procedure:
>
>  (expt +inf.0 0)    ==>  #<not-a-number expt>
>
>  (+ -inf.0 +inf.0)  ==>  #<not-a-number +>
>
>  (/ (* 0 -inf.0) 3) ==>  #<not-a-number *>
>
>  (+ 5 (/ 0.0 0.0))  ==>  #<not-a-number />

Personally I'd prefer the following as an alternative to an NAN,
where any function returning an exact 0 in lieu a typically less
useful NAN value may optionally signal an exception if desired:

 (/ 0.0 0.0) => 0 ; a sign-less exact 0 alternative to NAN

thereby correspondingly:

 (<= (/ -1.0 0.0) (/ 0.0 0.0) (/ +1.0 0.0)) => #t

and correspondingly

 (expt +inf.0 0)    => 1.0 ; as no other result is useful

 (+ -inf.0 +inf.0)  => 0

 (/ (* 0 -inf.0) 3) => 0

 (+ 5 (/ 0.0 0.0))  => 5

-------

With respect to exact integer precision, it seems that they only
should be required to be at least as great as an implementation's
corresponding inexact counterpart if implemented. i.e. >= 23 bits
of precision if inexacts are implemented as single-precision floats,
although ideally equivalent to it's dynamic range i.e. 256 bits for
single precision floats, etc. thereby both cover the same dynamic range.