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
? \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,