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

*To*: alexshinn@xxxxxxxxx*Subject*: Re: is NaN a number?*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Fri, 20 May 2005 00:06:07 -0400 (EDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <5fb7e087050518191857b051d9@xxxxxxxxxxxxxx> (message from Alex Shinn on Thu, 19 May 2005 11:18:44 +0900)*References*: <5fb7e087050518191857b051d9@xxxxxxxxxxxxxx>

| Date: Thu, 19 May 2005 11:18:44 +0900 | From: Alex Shinn <alexshinn@xxxxxxxxx> | | Is the following a typo? | | (complex? 0/0) ==> #t | (real? 0/0) ==> #f | | One would assume that | | (complex? x) -> (real? (real-part x)) | | Moreover, since 0/0 is by definition "Not a Number" it seems natural that | | (number? 0/0) ==> #f Thus far in SRFI-70, 0/0 is not a real number, but it is a number. 0/0 is contagious through all numerical operations (which don't signal errors). Having it be a number allows it to be an argument to those operations. Alternatively, an implementation could make 0/0 non-numeric and extend numeric operations to accept it or not. But extending STRING->NUMBER and NUMBER->STRING to deal with a type other than numbers is awkward. 0/0's contagion should make: (real-part 0/0) ==> 0/0 (imag-part 0/0) ==> 0/0 (magnitude 0/0) ==> 0/0 (angle 0/0) ==> 0/0 which requires modification of the z = x1 + i x2 = x3^(i x4) rule if 0/0 is complex. Because 0/0 is an optional feature, leaving to the implementation the choice of values for (complex? 0/0) and (number? 0/0) complicates portable code dealing with it. So I will change SRFI-70 so that: (number? 0/0) ==> #t (complex? 0/0) ==> #f

**References**:**is NaN a number?***From:*Alex Shinn

- Prev by Date:
**My ideas about infinity in Scheme (revised)** - Next by Date:
**Re: My suggestions to the R6RS committee about numerics** - Previous by thread:
**is NaN a number?** - Next by thread:
**FP Hardware** - Index(es):