Subject: Tests fail for Maxima (HEAD) with ECL 8.12.0
From: Robert Dodier
Date: Mon, 6 Apr 2009 11:03:57 -0600
On Mon, Apr 6, 2009 at 6:53 AM, Raymond Toy <raymond.toy at stericsson.com> wrote:
>> Result:
>> 1 20 sqrt(10)
>> .3333333333333333 sqrt(10) (bessel_j(-, -----------)
>> 3 3
>> 1 20 sqrt(10)
>> + bessel_j(- -, -----------)) - airy_ai(- 10)
>> 3 3
>>
>>
> This bug (or was it the next one?) has been there for a while. I only
> see this with ecl; the other Lisps I've used (clisp, cmucl, gcl) work. I
> been too lazy to look at it. :-(
I'd like to get to the bottom of this but I'm not going to try to
get it fixed in this release.
>> Input:
>> 60
>> 2 - 1
>> float(-------) - 1
>> 60
>> 2
>>
>>
>> Result:
>> - 1.110223024625157e-16
> This and similar failures are recent. I think it's a deficiency in how
> ecl converts big ratios to floats using cl:float. I don't really want to
> work around this bug just for ecl.
I'm inclined to view this as a bug in ECL, although the CL spec
for FLOAT is silent on what to do: it says "a float is returned that
is mathematically equal to number". What if there is no such
float? Doesn't say.
(COERCE is a little better but still ambiguous: "equal in sign and
magnitude to the object to whatever degree of representational
precision is permitted by that float representation". Does that
mean truncation or rounding?)
It's a good thing the CL spec was written by superior beings
and need never be revised or even questioned. Otherwise
I would start ranting about what a disaster it is.
> We could just borrow the code from cmucl (or others) that convert
> ratios to floats.
I'm inclined to lean on the ECL team to change their implementation
of FLOAT. Let's get the ECL team to do copy the code from CMUCL.
Robert Dodier