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