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



 | Date: Fri, 21 Oct 2005 11:59:06 -0400
 | From: "John.Cowan" <jcowan@xxxxxxxxxxxxxxxxx>
 | 
 | 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.