Re: realprecision bug

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

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/