Re: bug in pari-gp precision? (fwd)

[Ilya Zakharevich <ilya@Math.Berkeley.EDU>]

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