Ilya Zakharevich on Fri, 4 Oct 2002 11:45:30 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: bug in pari-gp precision? (fwd) |
On Fri, Oct 04, 2002 at 03:33:15PM +0200, Karim BELABAS wrote: > ? 1. + 10^-50 - 1. > %2 = -2.52435489 E-29 > > What is happening here? Personally, I see no problem here (although I cannot guess what the particular implementation is doing). You are running this with the precision 28digits, right? PARI translates its "programs" from strings to data "on the fly". It sees "1.", and creates a value with 28 digits of precision. This means the absolute error is of order of magnitude of 1e-28 (or 1-e29, depending on how you count ;-). Combining two of these "1.", one expects the error of 2e-28 or 2e-29. What is your percieved problem? ? \p 100 realprecision = 105 significant digits (100 digits displayed) ? x = 1. %8 = 1.00000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000 ? \p 28 realprecision = 28 significant digits ? x + 10^-50 - x %9 = 10.00000000000000000000000000 E-51 > question. Each ideal simplex is given by a complex parameter which is an > algebraic number. We thus describe the parameter by giving an an > approximate numerical value (at least 50 digits pari precision by default) > plus an exact description as an element of an appropriate number field. I advocate it for a long time that adding such a *type* to PARI should be "a simple matter of programming". One should be able to declare a user-defined type with a minimal effort. I already discussed how one can do it. [Of course, PARI will win large if such a type is a builtin, but given that it is not, maybe it is more beneficial to support such a type as "loaded from a module".] And AFAIU the first step to do this is to macroize avma = avma2 to RESTORE_AVMA(avma2). I sent a recipe how to do it quickly some time ago. Hope this helps, Ilya