Re: [PATCH] First batch of numerics changes

[Mark H Weaver]

Andy Wingo <address@hidden> writes:
> I don't understand this change:
>
>> From c42d03050ea0f96556e73e405e530b78bb85aba7 Mon Sep 17 00:00:00 2001
>> From: Mark H Weaver <address@hidden>
>> Date: Wed, 26 Jan 2011 02:56:20 -0500
>> Subject: [PATCH] Add case for fractions with differing SCM_CELL_TYPE to 
>> scm_equal_p
>>
>> * libguile/eq.c (scm_equal_p): Add a special case for fractions with
>>   differing SCM_CELL_TYPE, which might nonetheless be considered equal
>>   (due to the use of 0x10000 as a flag), to scm_equal_p.  This code
>>   was already present in scm_eqv_p.

To be honest, I didn't investigate until now.  I just wanted to make
`equal?' act the same as `eqv?' for numbers, and it seemed prudent to
copy that code over.  I didn't consider the possibility that the code
was useless, but now I see that it should be removed from both places.

> In what case would two fractions ever not have the same SCM_CELL_TYPE ?
> I don't understand this discussion of flags.  AFAICS fractions have their
> own tc16, and no flags are ever set.

Judging from the following test case at the end of numbers.test, I guess
there was a tentative plan to implement a "lazy reduction bit" for
fractions, presumably meaning that they would not be reduced to lowest
terms until the first time their numerator or denominator was accessed.

> (with-test-prefix "equal?"
>   (pass-if
>   
>    ;; lazy reduction bit for rationals should not affect equal?
>    (equal? 1/2 ((lambda (x) (denominator x) x) 1/2))))

However, from looking at the code for handling fractions, it is clear
that this plan was never implemented.  I will submit a patch to get rid
of that cruft.

> Furthermore I would think that the `if (SCM_NUMP (x))' block in
> scm_eqv_p could use a switch statement instead of a bunch of ifs.

Agreed, I will do it.

     Mark