Re: code cool-down!

[Sam S. <sd...@gn...>]

> * Bruno Haible <oe...@py...> [2005-06-06 22:42:03 +0200]:
>
> Sam wrote:
>> I disagree.
>> <http://www.lisp.org/HyperSpec/Body/fun_realpartcm_imagpart.html>
>>         If number is real, then realpart returns number and imagpart
>>         returns (* 0 number), which has the effect that the imaginary
>>         part of a rational is 0 and that of a float is a floating-point
>>         zero of the same format.
>>
>> thus this is a bug fix for *FLOATING-POINT-RATIONAL-CONTAGION-ANSI*.
>> (thanks to Paul Dietz for pointing this out).
>
> Your change is an isolated change that makes no sense on its own:
>
>   > (imagpart #c(3.4 -1))
>   -1
>   > (imagpart #c(3.4 0))
>   0.0

that's because #c(3.4 0) is the same as 3.4

> To make sense, this needs to be accompanied by changes in the functions
> COMPLEX, many functions in comptran.d, TYPEP and SUBTYPEP. All based on
> *COMPLEX-NUMBERS-ANSI*. *FLOATING-POINT-RATIONAL-CONTAGION-ANSI* is the
> wrong discriminator for this operation.

you appear to assume that
    (imagpart real) == (imagpart (coerce real 'complex))
or something similar.

see the above quote from the CLHS:
    (imagpart real) == (* 0 real)

this has _NOTHING_ to do with the real and imaginary parts of a complex
number, or, indeed, with typep and subtypep.

even after you add *COMPLEX-NUMBERS-ANSI*, you will _STILL_ have to make
IMAGPART depend on *FLOATING-POINT-RATIONAL-CONTAGION-ANSI* and _NOT_ on
*COMPLEX-NUMBERS-ANSI* -- because, as pointed out above,
    (imagpart real) == (* 0 real)

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.dhimmi.com/> <http://www.jihadwatch.org/> <http://www.memri.org/>
<http://pmw.org.il/> <http://www.palestinefacts.org/>
Microsoft: announce yesterday, code today, think tomorrow.