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

*To*: jcowan@xxxxxxxxxxxxxxxxx*Subject*: Re: arithmetic issues*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Fri, 21 Oct 2005 22:39:36 -0400 (EDT)*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <20051021155906.GC16464@NYCMJCOWA2> (jcowan@xxxxxxxxxxxxxxxxx)*References*: <20051021145326.816C11B77BB@xxxxxxxxxxxxxxxxxxxxx> <20051021155906.GC16464@NYCMJCOWA2>

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

**Follow-Ups**:**Re: arithmetic issues***From:*bear

**References**:**arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*John.Cowan

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