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

*To*: <srfi-77@xxxxxxxxxxxxxxxxx>*Subject*: Re: arithmetic issues*From*: Paul Schlie <schlie@xxxxxxxxxxx>*Date*: Sun, 23 Oct 2005 22:06:49 -0400*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*Thread-index*: AcXYP5e51nyR6kQyEdqOfgADk1ictA==*Thread-topic*: arithmetic issues*User-agent*: Microsoft-Entourage/11.2.1.051004

> 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.

- Prev by Date:
**Re: arithmetic issues** - Next by Date:
**Re: arithmetic issues** - Previous by thread:
**Re: arithmetic issues** - Next by thread:
**Re: arithmetic issues** - Index(es):