| 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]
`