Lutz Euler is the man -- even though he's not subscribed, he used his
powers to telepathically read the mail and figured out what's going
---------- Forwarded message ----------
From: Lutz Euler <lutz.euler@...>
Date: 24 March 2011 01:49
Subject: Re: sbcl-1.0.45 and maxima-5.23.1 testsuite
To: Nikodemus Siivola <nikodemus@...>, "Andrey G. Grozin"
> On 17 January 2011 18:15, Andrey G. Grozin <A.G.Grozin@...> wrote:
>> Now there is a new testsuite failure with sbcl. It's rtest16, problem 385.
>> It's about floating-point calculation of zeta(%i+3) (%i is the imaginary
>> unit). sbcl produced a resulr with error of order 3*10^(-9) instead of
>> expected 10^(-15). Earlier versions of sbcl did not have this failure.
>> Looks like a regression. All the other lisps listed above also don't have
>> this particular failure (ecl has 2 failures in rtest8, this is another
>> story). Looks like something is calculated in single precision when it
>> should be done in double.
> Do you recall what's the latest version in which that test passed? (It
> fails with 1.0.44 as well.)
> Alternatively, if a Maxima wizard can reduce a test-case that doesn't
> involve Maxima -- just shows an SBCL operation that returns the wrong
> value -- what would help too.
I am not a maxima wizard but I believe I have found the cause of the
problem: SBCL's "expt" with integer or rational base and complex
double-float exponent uses an intermediate single-float value for its
calculations thus, while yielding a complex double-float result as
required, this result is exact only to single-float precision.
This behaviour is the same already in SBCL 0.8.12, which is the oldest
version I happen to have available readily compiled.
Maxima's calculation of the zeta function with the argument of the
test case is done using the lisp function "float-zeta", defined in
maxima-5.23.1/src/combin.lisp. The formula contains a sum of several
terms each containing a quotient of something by "expt" of a small
integer and the argument to the zeta function, the latter converted
to complex double-float. These "expt"s are calculated directly using
SBCL's "expt". Here is a trace:
Maxima 5.23.1 http://maxima.sourceforge.net
using Lisp SBCL 188.8.131.52
Type (to-maxima) to restart, ($quit) to quit Maxima.
MAXIMA> (trace expt)
MAXIMA> (float-zeta #$(3+%i)$)
0: (EXPT 4 3.0)
0: EXPT returned 64.0
0: (EXPT 2 #C(-2.0 -1.0))
0: EXPT returned #C(0.19230972430417587 -0.15974031883619208)
0: (EXPT #C(7.2421875 1.0) #C(1.25 0.5))
0: EXPT returned #C(4.418528303829868 10.318276280305101)
0: (EXPT 1 #C(3.0 1.0))
0: EXPT returned #C(1.0 0.0)
0: (EXPT -1 0)
0: EXPT returned 1
0: (EXPT -1 0)
0: EXPT returned 1
0: (EXPT 21 #C(3.0 1.0))
0: EXPT returned #C(-9217.405235813078 897.5555997887233)
0: (EXPT 2 #C(3.0 1.0))
0: EXPT returned #C(6.1539112363389945 5.11169025143816)
... [many more calls to (expt <small int> #C(3.0 1.0))]
The test case expects the following result:
#C(1.10721440843141 - 0.1482908671781754)
As a simple reduced test case without maxima we have:
(expt 2 #C(3.0d0 1.0d0))
Clisp (2.48) gives:
and Clisp with more precision (setf (system::long-float-digits) 500):
(expt 2 #C(3.0l0 1.0l0))
The definition of "expt" is in sbcl/src/code/irrat.lisp.
(defun expt (base power)
(number-dispatch ((base number) (power number))
(((foreach fixnum (or bignum ratio) single-float double-float)
(if (and (zerop base) (plusp (realpart power)))
(* base power)
(exp (* power (log base)))))
The calculation of (log base), base being an integer, yields a
single-float as required by the standard. For the purpose of "expt"
it may be a bug to use (log base) as the standard says in section
184.108.40.206 "Rule of Float and Rational Contagion":
"When rationals and floats are combined by a numerical function,
the rational is first converted to a float of the same format."
For a quick test I replaced the calculation in the SBCL source as follows,
(exp (* power (log (coerce base 'double-float))))
then compiled SBCL and maxima. This SBCL calculates:
* (expt 2 #C(3.0d0 1.0d0))
This seems to differ from Clisp's result only in the last bit of the
real and imaginary part each.
The zeta value calculated by maxima is then:
(%i1) zeta (3 + %i), numer=true;
(%o1) 1.107214408431409 - .1482908671781753 %i
The resulting maxima passes its test suite with no unexpected errors.
In case it matters, the above is under x86-64, except when using
SBCL 0.8.12, which is x86.
If "expt" indeed needs to be modified a correct fix seems a bit more
complicated as currently there are two clauses dealing with complex
exponents, both not distinguishing between single and double floats.
The standard seems to require to look at all argument types and to use
single-float calculations if all arguments are integer or rational or
single-float, be it real or complex, and to use double-float calculations
if at least one argument is double-float real or complex?
Also, the current implementation of "expt" allows (with a complex
exponent) bignums or ratios as the base that are too big or too small
to be represented as a single-float, provided their logarithm can
(and the exponent is such that the result fits in its type).
If one doesn't want to lose this property, a function for log of
ratios and integers returning a double-float would need to be defined.
This may be easy as "log" already contains the needed logic, only
unfortunately always coercing the result to single-float.
On the other hand I believe the standard does not require this, so
hopefully nobody depends on this accidental property. And, when the
exponent is real, bignum/ratio bases too large and too small don't work
On the third hand, as "log" (intentionally, seemingly) deals with bignums
and ratios that don't fit in a float, maybe "expt" should, too, even in
the case of a real exponent?
Moreover, "log" is implemented the way it is to be more exact in the case
that its argument is a ratio very near to one. This carries over to "expt":
The original SBCL calculates:
* (expt (/ (expt 2 64) (1+ (expt 2 64))) #c(10 10))
whereas with the above hack we have the less exact
(Sorry, can't resist: Did you notice that "log" returns zero for rational
arguments very near to one if the integer length of numerator and
denominator differs by one?
(log (/ (expt 2 64) (1- (expt 2 64)))) -> 0.0
(log (/ (1+ (expt 2 64)) (expt 2 64))) -> 5.421011e-20
which result would be correct for the former ratio, too.)