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

Re: reading NaNs

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 are here. Eventually, the entire history will be moved there, including any new messages.

bear <bear@xxxxxxxxx> 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))
[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

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
   \__/       qrczak@xxxxxxxxxx
    ^^     http://qrnik.knm.org.pl/~qrczak/