Aubrey Jaffer <xxxxxx@alum.mit.edu> writes:

> Being error objects, syntax for NaNs should be unspecified.

I disagree.

Note that supporting special values (+inf.0, -inf.0, +nan.0, -0.0)
needs at least functions to recognize them, in particular finite?
(to go a fast path for non-pathological cases) and either negative-zero?
or sign-bit? (the latter answering "positive" for 0.0 and "negative" for
-0.0). Recognizing NaN is more clear with a distinguished predicate than
with (= x x).

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

For example (- 0.0), (/ -inf.0) and -1e-2000 yield -0.0,
(* 0.0-i 0.0-i) yields (-1.0-0.0i).

> In an implementation with -0.0, what is the result of (* -5.0 0.0)?

-0.0

> -0.0 is insufficiently specified by SRFI-77; it will be a portability
> killer.

The relevant IEEE standard that everybody uses specifies it.
Most processors support it natively.

> Mathematically, mixed exactness complex numbers makes no sense.

Not true. For example 1.23 is a real number for sure, but its value
could have been rounded. 1.23+0.0i and 1.23-0.0i signify that the true
value might not be real.

1.23+0i can be unified with 1.23 just like 123/1 is unified with 123.

> The procedures REAL-PART, IMAG-PART, and MAKE-RECTANGULAR already
> guarantee that the orthogonal representation is available.  The
> language should not constrain an internal representation which is
> transparent to the user.

It's not transparent anyway if real-part and imag-part are reqired to
return former arguments of make-rectangular (as long as they are real
numbers) in the sense of eqv? or at least =. No implementation uses a
different representation anyway, so constraining is theoretical.

C++ made the mistake of not specifying the layout of complex numbers
and having re() and im() as methods instead of fields. Every
implementation does the same anyway, and not specifying this makes
harder to interface to other languages.

>  | * Should `(floor +inf.0)' return +inf.0 or signal an error
>  |   instead?  (Similarly for ceiling, flfloor, infloor, etc.)
>
> Floor is specified to return an integer.  +inf.0 is not an integer.
> Thus it is an error.

IMHO it's more useful to return +inf.0, because then the program
doesn't have to treat the possibility of overflow at this point yet.
IEEE, processors, and other languages which return an inexact number
here, all return +inf.0 I think.

--
   __("<         Marcin Kowalczyk
   \__/       xxxxxx@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/