Re: R5RS numbers

Ray Dillinger <bear@sonic.net> writes:
 
>
> Whoa, hold the phone.  This is a reasonably close approximation
> but I got two questions -- where's the second argument to
> inexact->exact,  and why is this an approximation?

inexact->exact has one argument in R5RS. Did you mean rationalize?

> Shouldn't it just be 13/10? You're supposed to get the simplest
> rational that's within range of the number,

R5RS says "exact number that is numerically closest to the argument".
It is the closest, in fact it's the only exact number *equal* to the
argument, so I have no choice.
 
> 
>
> This is a slightly odd result.  It's clearly an inexact number,
> but why isn't it written back by the interpreter as 1.0+0.0i ?

Because a complex number has its real and imaginary part exact or
inexact independently of each other. And this is because this is so in
the underlying implementation (even though it's the implementation I
control of the language I control), so I would not like to change that
unless necessary. I consider a complex number inexact-in-Scheme if at
least one of its parts is inexact, and haven't found a contradiction
with R5RS yet.

Note that C99 has an imaginary type (in addition to complex) in order
to preserve the sign of 0.0 where it would be lost if 3.0*I had 0.0
as its real part. I believe this is what William Kahan has in mind
on pages 11-15 of <http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf>.
So forcing them to be 0.0 instead of 0 if the other part is inexact
would in fact give worse results on some computations. I hope R5RS
is compatible with the notion of -0.0 as distinct from 0.0 (although
equal to it).
 
> 
>
> This however, is a clear error.  You can't take the real part
> of an inexact complex number and get an exact real number.

Why? R5RS says:

"With the exception of inexact->exact, the operations described in
this section must generally return inexact results when given any
inexact arguments. An operation may, however, return an exact result
if it can prove that the value of the result is unaffected by the
inexactness of its arguments."

And in the case of 2+3.0i, perhaps obtained from a computation like
(+ 2 (* 3.0 +i)), inexactness of the imaginary part indeed can't
influence the value of the real part. If, during further computation,
another number is produced whose real part depends on both real and
imaginary parts of 2+3.0i, then of course both parts of it will be
inexact.

The only concern might be the syntax of literals on input. I'm
assuming that +3.0i has exact 0 as its real part, and that 3.0 has
exact 0 as its imaginary part. Given that, the exactness behavior of
my complex numbers is definitely correct (modulo undetected bugs).

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