bear <xxxxxx@sonic.net> writes:

> I strongly disagree with the idea of mixed exactness in the real and
> imaginary parts of a complex number.  5.0+3i and 5+3.0i are the same
> inexact number and should not be treated differently.

I disagree. For me this holds:

(real-part (/    +1.2i 0.0))      = 0
(real-part (/ 0.0+1.2i 0.0))      = +nan.0
(real-part (/    +1.2i 0.0+0.0i)) = +nan.0
[Actually I'm getting -nan.0; I'm not sure whether it should be
distinguished, and if yes then whether this sign is correct.]

(cos    +1.2i)         = 1.8106555673243747
(cos 0.0+1.2i)         = 1.8106555673243747-0.0i
(real? (cos    +1.2i)) = #t
(real? (cos 0.0+1.2i)) = #f

Note how CLISP behaves:

[1]> (cos #C(0 1.2))
1.8106556
[2]> (cos #C(0.0 1.2))
#C(1.8106556 0.0)

> I would suggest requiring an error to be signalled if inexact->exact
> gets an argument greater or less than any exact number representable
> by the implementation.

In a good implementation the only such cases will be infinities and
NaN. Of course if it doesn't support bignums then it should signal an
error.

Actually my implementation returns exact infinities in this case
(because the host language supports them and I see no reason to hide
that). An error is signalled for NaN.

> Likewise if exact->inexact recieves an argument outside the range
> representable as inexact numbers in the implementation.

This should generate +inf.0, not an error, unless the OVERFLOW
exception is enabled.

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