Karim BELABAS on Thu, 14 Sep 2000 09:43:24 +0200 (MET DST) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: (BUG?) Erroneous I+R overflow in GP/PARI Version 2.0.18 (beta) |
>> ? 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/