Re: (BUG?) Erroneous I+R overflow in GP/PARI Version 2.0.18 (beta)

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

>>  ?  exp(2*Pi*I*((9/2)/(3/35 + 3/35*I)))-1
>>    ***   overflow in I+R
>>  ?  exp(2*Pi*I*((9/2)/(3/35 + 3/35*I)))
>>  %1 = 0.0000000000000000000000000000 + 4.263424501275723583926909456 E71*I

[Bill Allombert:]
> This is not a bug at all, the real part of %1 is 0E74, but the
> precision is only 28 digits, so 0E74 can be any number between -1E46
> and 1E46, so adding 1 is not meaningful.
> 
> So two thing can be done(or not !)
> 
> %1 should be printed 0E74 + 4.263424501275723583926909456 E71*I to
> insist on the accuracy. It is already the case for negative exponents
> 
> ? 1.-1
> %14 = 0.E-28
> ? 100000.-100000
> %16 = 0.E-24
> 
> Secondly, 0E74+1 should return 0E74, which is correct, but will
> probably not lower the number of bug reports on this topic.

I agree with Bill's analysis. I have implemented his two suggestions and
modified the manual accordingly (sections 'What is 0?' and description of
default 'format') [ The manual was actually imprecise enough so as to allow
both modifications to be made without 'falsifying' any of the statements
there. ]

There is another related problem which I didn't handle: with repect to the
natural ordering of the reals, any two real zeroes are considered equal
(which makes some sense), and any real zero is strictly smaller than any
positive number (which, although 'natural', looks very dubious).

(09:36) gp > 0e-100 == 0e100
%1 = 1
(09:36) gp > 0e200 < 1.
%2 = 1

  Karim.
__
Karim Belabas                    email: Karim.Belabas@math.u-psud.fr
Dep. de Mathematiques, Bat. 425
Universite Paris-Sud             Tel: (00 33) 1 69 15 57 48
F-91405 Orsay (France)           Fax: (00 33) 1 69 15 60 19
--
PARI/GP Home Page: http://www.parigp-home.de/