guile-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] First batch of numerics changes


From: Mark H Weaver
Subject: Re: [PATCH] First batch of numerics changes
Date: Sat, 29 Jan 2011 15:20:37 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Andy Wingo <address@hidden> writes:
>>    if (SCM_CELL_TYPE (x) != SCM_CELL_TYPE (y))
>> +    return SCM_BOOL_F;
>
> Doesn't this prevent 1.0+0.0i from being eqv or equal to 1.0 ?

No, because 1.0+0.0i never exists in the current code.

At the top of numbers.c it says:
> /* General assumptions:
>  * All objects satisfying SCM_COMPLEXP() have a non-zero complex component.

and I have found this to be true.  scm_c_make_rectangular is the
primitive function that creates complex numbers, and it returns a real
number if the imaginary part is zero.  All other functions call it
directly or indirectly.

I know this well because I made a patch to allow the creation of complex
numbers with inexact 0.0 imaginary part.  In fact, I purposefully
arranged for (eqv? 1.0+0.0i) to evaluate to #f, for the same reason that
(eqv? 0.0 0) evaluates to #f.

According to R6RS, a number is real only if its imaginary part is both
zero and exact.  Therefore, the imaginary part of any real number is an
exact 0, otherwise it wouldn't be real.  But the imaginary part of
1.0+0.0i is clearly an _inexact_ zero.

R6RS explicitly states that eqv? returns #f if one number is exact and
the other is inexact.  So (eqv? 0.0 0) must be #f, and has been.  The
only remaining assumption here is that (eqv? z1 z2) works by comparing
the real and imaginary parts component-wise using eqv?.  If you agree
with this, then it follows that any complex number, even one with an
inexact zero imaginary part, must be unequal to _any_ real number.

However, regardless of whether or not you agree with all this, the fact
remains that currently, Guile never creates non-real complex numbers
with zero imaginary part.  So the patch is safe.

    Best,
     Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]