Andy Wingo <wi...@pobox.com> 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