Re: arithmetic issues Aubrey Jaffer 22 Oct 2005 02:39 UTC

 | Date: Fri, 21 Oct 2005 11:59:06 -0400
 | From: "John.Cowan" <xxxxxx@reutershealth.com>
 |
 | Aubrey Jaffer scripsit:
 |
 | > For an interpreter this would mean that 1/2 read before the
 | > full-tower module was loaded could be an inexact 0.5; but after
 | > loading 1/2 would read as an exact 1/2.  Unpredictability is bad.
 |
 | It would merely mean that 1/2 would be an error (and preferably
 | would signal an error as well).  Of course, #e1/2 would still be an
 | inexact 0.5.

I think you meant #i1/2

 | > None of the examples in SRFI-77 return -0.0 unless they are
 | > passed -0.0 as an argument.  Does -0.0 result only from a literal
 | > -0.0 constant?
 | >
 | > In an implementation with -0.0, what is the result of (* -5.0 0.0)?
 | >
 | > -0.0 is insufficiently specified by SRFI-77; it will be a portability
 | > killer.
 |
 | The IEEE standard is our friend here.

0.0 being the most common inexact number, SCM has only one boxed 0.0.
Thus in SCM:

  (/ (* 0.0 -5.0))  ==> +inf.0

While in an implementation with two zeros:

  (/ (* 0.0 -5.0))  ==> -inf.0

Thus dual zero systems behave differently from single zero systems,
which can cause portability problems.