This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.
| 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