clisp-devel

code cool-down!

[Bruno H. <br...@cl...>]

Hi Sam,

Normally I like _all_ kinds of bug fixes. But not this one.
Can please undo this patch until the release:

2005-06-06  Sam Steingold  <sd...@gn...>

	* compelem.d (N_imagpart): use the normal Rational/Float contagion
	rules for reals
	* clispload.lsp (*expected-failures*): removed MISC.598

This patch does not fit in a code cool-down phase because
  1. it changes user-visible and documented behaviour,
  2. it is not a unanimous bug fix. IMO
     - it should be protected by a global variable *COMPLEX-NUMBERS-ANSI*
       that is part of the big *ANSI* switch.
     - it is the beginning of a new area of work. The whole scope of this
       *COMPLEX-NUMBERS-ANSI* is about 2 weeks of work.

Thanks.

Bruno

Re: code cool-down!

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

Hi Bruno,

> * Bruno Haible <oe...@py...> [2005-06-06 20:02:28 +0200]:
>
> 2005-06-06  Sam Steingold  <sd...@gn...>
>
> 	* compelem.d (N_imagpart): use the normal Rational/Float contagion
> 	rules for reals
> 	* clispload.lsp (*expected-failures*): removed MISC.598
>
> This patch does not fit in a code cool-down phase because
>   1. it changes user-visible and documented behaviour,
>   2. it is not a unanimous bug fix. IMO
>      - it should be protected by a global variable *COMPLEX-NUMBERS-ANSI*
>        that is part of the big *ANSI* switch.
>      - it is the beginning of a new area of work. The whole scope of this
>        *COMPLEX-NUMBERS-ANSI* is about 2 weeks of work.

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).

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.iris.org.il> <http://www.openvotingconsortium.org/>
<http://www.palestinefacts.org/> <http://www.mideasttruth.com/>
Abandon all hope, all ye who press Enter.

Re: code cool-down!

[Bruno H. <br...@cl...>]

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

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.

Bruno

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.