On Sat, 14 Aug 2010, Raymond Toy wrote:
< On 8/14/10 3:53 AM, Leo Butler wrote:
< >
< > On Fri, 13 Aug 2010, Raymond Toy wrote:
< >
< > < On 8/13/10 4:51 PM, Leo Butler wrote:
< > < > After building 5.22.1 with cmucl 19d, I've
< > < > got the following errors:
< > < Perhaps these are bugs in 19d. Cmucl 2010-08 gives no errors in the
< > < testsuite.
< > < >
< > < >
< > < > Error found in
< > < > /knoppix-home/work/maxima/sandbox/maxima-5.22.1/tests/rtest4.mac,
< > < > problem:
< > < > (86)
< > < According to the logs, this test was added in Dec 2007. This might be
< > < an issue with that version of cmucl. IIRC, maxima sometimes computes
< > < 1^N for very large N. Cmucl would warn about raising a number to a
< > < large N. At some point cmucl added a test so that 1^N doesn't produce
< > < that warning, since, obviously, it's not a problem for any N.
< >
< > The issue here is that the CMUCL from the Ubuntu repositories has a
< > ridiculously low maximum exponent:
< >
< > (%i1) is(errcatch(rat(x^2^128)) = []);
< Yes, you can make it larger. But that just moves the problem out. If
< this must be solved by maxima, then maxima should handle the case of 1^N
< itself, or maxima should include the code from cmucl that fixes it there.
<
< Or better yet, upgrade to a newer version of cmucl. :-) Getting and
< installing the official binaries from common-lisp.net is not hard.
< Just untar somewhere.
Sorry, Ray, but until recently cmucl 19d was the current version in the debian testing
repositories. And 19d is the version in the stable repositories.
The point of using a repository and package management is
to make the infrastructural work as painless as possible. It's a pain
in the ass to update tar files gotten from thither and yon. I'll end
up recreating, in a half-assed way, another package management system...
Of course, if cmcul had a nicer build system...
< >
< > If anything, it is greater than expected:
< I guess those tests need to be more careful and use closeto or
< something. Perhaps it's an issue with cmucl 19d that is using 80-bit
< floats in some operations. (It's supposed to use double floats, but
< there might some cases where it isn't.)
<
< I am rather troubled by these results. You said these didn't occur in
< 5.22.0 but do appear in 5.22.1. But the tests have been there for much
< longer than 5.22.0. And I assume you've been using 19d for all of the
< tests. Something else may have changed?
The test results I reported were from a crunchbang (ubuntu) installation. I
built the release on debian lenny and all the errors disappeared except
for the one reported earlier involving zeta. I am led to believe that
the extra errors are down to some anomaly in the way ubuntu is
re-packaging the debian cmucl package. If you have any ideas, I am happy
to test them and file a bug report against the package.
Leo
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.