Karim Belabas on Sat, 22 Mar 2014 18:45:51 +0100


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: third release candidate for 2.7.0


* Bill Allombert [2014-03-22 18:20]:
> On Sat, Mar 22, 2014 at 06:04:37PM +0100, Karim Belabas wrote:
> > 3) After 'Configure --tune', the gp binary produces slightly different
> > results from the expected ones. This is a known bug, not release-critical,
> > and hard to fix. We will address it during the 2.8.* cycle :-)
> 
> I would like to clarify this: After 'Configure --tune', the gp binary *can*
> produces slightly different results from the expected ones.  However this is
> not the expected outcome: we are running ./Configure --tune every day to check
> for such issues.
>
>  So if this happens to you with an old tune.h file, try to redo
> ./Configure --tune to see whether this makes the issue disappear.

A quick word about the underlying problem. Depending on the tuning
parameters, different algorithms will be used to compute transcendental
functions, with slightly different accuracy / stability properties.
To make up for that we perform computations at a (controlled) higher
accuracy, then round the results to the originally expected accuracy.
A generic function affrr_fixlg() exists just for that purpose.

Unfortunately, this doesn't work with real zeroes which are unaffected
by rounding: 0.E-57 is copied verbatim, instead of being "rounded" to
0.E-38. This in turn implies that later computation may be performed at
a higher accuracy than intended, yielding different results (within 1ulp
in simple cases). This is the "known bug" I was referring to above.


I see no generic solution to this problem -- which does not affect basic
multiprecision, only functions like exp/log, arg/atan, etc. -- within the
scope of our current floating point model. Functions must be handled one
at a time: there are 27 occurences of affrr_fixlg() + 9 occurrences of
affc_fixlg() and we must investigate what should happen to floating
point zeroes in all neighbouring code...

I emphasize that all results are "correct": the problem is that they
disagree with our specifications, hence make testing harder.

Cheers,

    K.B.
--
Karim Belabas, IMB (UMR 5251)  Tel: (+33) (0)5 40 00 26 17
Universite Bordeaux 1          Fax: (+33) (0)5 40 00 69 50
351, cours de la Liberation    http://www.math.u-bordeaux1.fr/~kbelabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux1.fr/  [PARI/GP]
`