Re: Weird i386 only error maxima 5.47.0

[Camm Maguire]

Greetings, and thanks so much!

In general, 5.47 introduced a few testsuite errors revolving around
floating point precision issues/error bounds like this.  The GCL code
being exercised not only has to deal with 32/64 bit, but extended
precision hardware, notably the 80bit x68.  Maxima's testsuite when run
across all Debian architectures is therefore very useful in hardening
the underlying GCL routines.

This particular issue is as stated i386 only, and disappears in 5.46
built using the same GCL under the same environment.  So while it need
not indicate an error in maxima code, it must be due to some change in
maxima's code from 5.46 to 5.47.  I thought identifying the same might
point out a GCL bug.

By way of comparison, 5.47 also showed one ulp_test failure which only
showed up on 32bit machines without the 80bit extended precision of x86
underlying.  We traced this down to a weakness in GCL's big_to_double
routine, where we were relying on the floating point hardware to
implement round to even when adding a ulp to the down-rounded result of
mpz_get_d.  We now do this explicitly at the integer level before double
conversion.

These error bound failures really do not matter to anyone who is not
trying to ensure the GCL code is correct.  I'll try for a bit longer to
see if I can flesh out any bugs and then just add an expected failure
where appropriate.

Take care,

Robert Dodier <robert.dodier@gmail.com> writes:

> On Sun, May 26, 2024 at 4:38 PM Camm Maguire <camm@maguirefamily.org> wrote:
>
>> Greetings!  Can anyone point out what might have changed in the maxima
>> code from 5.46 to 5.47 to cause a failure in the following test from
>> rtest8.mac using the same environment and compiler (gcl)?
>
>> ev (e1, bu=4);
>> [63.75, 7.077671781985375E-13, 31, 0];
>> =============================================================================
>>
>> Correct in 5.46, but in 5.47 I get:
>>
>> [63.75, 7.081127676410173E-13, 31, 0]
>>
>> Same floating point lisp code implementation.  Only on 32bit i386.
>
> Well, looks like the relevant code (src/numerical/slatec/dqk31.lisp)
> didn't change between 5.46.0 and 5.47.0, to judge by the empty result
> from git log. Is it possible that different GCL versions were used? If
> 64 bit GCL results are correct and 32 bit is different, is it possible
> that the 32 bit implementation differs in some way?
>
> The second number is an error estimate -- since the integrand is a
> polynomial (u^3), the error estimate is going to be some polynomial
> too. The differing error estimates suggest that rounding was different
> or something. We could probably track down exactly where the
> computations are diverging, but maybe it's not anything to worry about
> -- I don't know.
>
> best,
>
> Robert
>
>
>

-- 
Camm Maguire                                        camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah