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

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.

*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):