Karim BELABAS on Tue, 4 Feb 2003 11:06:53 +0100 (MET) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: realprecision bug |
On Wed, 22 Jan 2003, Walter Neumann wrote: > On Wed, 22 Jan 2003, Bill Allombert wrote: >> On Mon, Jan 20, 2003 at 05:35:02PM -0000, Jon Perry wrote: >>> ? default(realprecision,4) >>> ? 1.463874 >>> %6 = 1.463 >>> ? 0.327947 >>> %7 = 0.327952003 >> >> It looks like it is fixed in the 2.2 serie. >> Cheers, >> Bill. >> > > No it isn't fixed, you expect 1.464 in both of the following: > > GP/PARI CALCULATOR Version 2.2.5 (development CHANGES-1.644) > i686 running linux (ix86/GMP kernel) 32-bit version > (readline v4.2a enabled, extended help available) > > ? default(realprecision,4) > realprecision = 9 significant digits (4 digits displayed) > ? 1.463955324 > %1 = 1.463 > ? 1.4639553240 > %2 = 1.464 Hi, I have rewritten the input/output handling for floating point numbers from scratch [ still doesn't use divide-conquer, so still quadratic time input/output ]. I have stomped a number of bugs as the above, or (10:57) gp > \p0 realprecision = 9 significant digits (0 digits displayed) (10:57) gp > 11234. %1 = 11234. (10:57) gp > \p1 realprecision = 9 significant digits (1 digits displayed) (10:57) gp > 11234. %2 = 11585. \\ !!! (10:57) gp > \p28 realprecision = 28 significant digits (10:57) gp > 1e1000000 %3 = 9.999999999999999999999996198 E999999 \\ precision loss (10:58) gp > \p19 realprecision = 19 significant digits (10:58) gp > 1.2 %4 = 1.199999999999999999 \\ internal precision is sufficient to enable \\ rounding to 1.2 It also turned out that rounding for output was essentially random, and not really related to the available trailing digits, so the benches had to be massively updated [ the 64bit benches are not correct yet ] I may have introduced new bugs. Please report any surprising behaviour... Karim. P.S: confrac() has disappeared, convi() interface has changed, and will change again soon. Currently, given a t_INT convi() returns the list of base 10^9 digits, which is fast but inconvenient. I contemplate returning a character string, which would make rounding 9 times slower, but would be much easier to interface, for instance with the GMP kernel. -- Karim Belabas Tel: (+33) (0)1 69 15 57 48 Dép. de Mathématiques, Bât. 425 Fax: (+33) (0)1 69 15 60 19 Université Paris-Sud Email: Karim.Belabas@math.u-psud.fr F-91405 Orsay (France) http://www.math.u-psud.fr/~belabas/ -- PARI/GP Home Page: http://www.parigp-home.de/