Re: [GP/PARI-2.1.0] arithmetic weirdness

[Igor Schein <igor@txc.com>]

On Mon, Apr 02, 2001 at 01:27:17AM +0200, Philippe Elbaz-Vincent wrote:
> Hi,
[snip]
>    realprecision = 28 significant digits
[snip]
> (01:23) gp > 1390.48+171364.53
> time = 0 ms.
> %1 = 172755.0099999999999999999999
[snip]

Well, I can confirm it with Sun Compiler debugging version, which makes
it pretty much compiler- and optimization-independent.  

? \p27
   realprecision = 28 significant digits (27 digits displayed)
? 1390.48+171364.53
172755.010000000000000000000
? \x
[&=006b8174] REAL(lg=5,CLONE):05000005  (+,expo=17):40800011  a8b4c0a3  d70a3d70  a3d70a3d
? \p28
   realprecision = 28 significant digits
? 1390.48+171364.53
172755.0099999999999999999999
? \x
[&=006b819c] REAL(lg=5,CLONE):05000005  (+,expo=17):40800011  a8b4c0a3  d70a3d70  a3d70a3d
? \p29
   realprecision = 38 significant digits (29 digits displayed)
? 1390.48+171364.53
172755.01000000000000000000000
? \x
[&=006b9624] REAL(lg=6,CLONE):05000006  (+,expo=17):40800011  a8b4c0a3  d70a3d70  a3d70a3d  70a3d709

Looks like this issue occurs only when the number of digits display is
the same as realprecision.  Internal structure is identical in the 1st
and 2nd case, so it gots to be a display issue.  If you cut and paste
172755.0099999999999999999999, you'll get 172755.01000000000000000000000 

This behavior has existed forever ( I can go back as far as 2.0.14 ).

Igor