Re: polcyclo: overflow in precp().

[Bill Allombert <Bill.Allombert@math.u-bordeaux.fr>]

On Fri, Oct 14, 2022 at 07:21:51PM +0200, Karim Belabas wrote:
> Hi Max,
> 
> * Max Alekseyev [2022-10-14 16:34]:
> > Can anything be done about this error?
> > 
> > ? allocatemem(2^31)
> >   ***   Warning: new stack size = 2147483648 (2048.000 Mbytes).
> > ? polcyclo(524308,10+O(2^2))
> >   ***   at top-level: polcyclo(524308,10+O(2^2))
> >   ***                 ^--------------------------
> >   *** polcyclo: overflow in precp().
> 
> 1) Yes, t_PADICs are very inefficient and provided for convenience if
> denominators are involved, when the much more efficient t_INTMOD are not
> an option. Use a t_INTMOD !
> 
> Here, polcyclo(524308, Mod(10,4)) works and is instantaneous.
> 
> 2) The real problem here is
> 
> ? 2^262154*(1 + O(2)) - 1
>   *** _+_: overflow in precp().
> 
> because we're trying to construct a t_PADIC with so many significant
> digits it can't even be represented given the current design of the
> t_PADIC type.
> 
> The fact that we don't encode the p-adic precision or valuation in 64
> bits is a known design bug in the t_PADIC type: we packed both together
> in 64 bits to save on memory (and copying costs) instead of allowing one
> codeword for each... It's silly nowadays but I won't change this: it's a
> lot of work to remove those limits, and there is no application (our
> handling of most of these "huge" t_PADICs being so bad anyway).
> There are other analogous hardcoded limitations of other types, see
> http://pari.math.u-bordeaux.fr/faq.html#limits

This is true for t_SER, but for t_PADIC, we have enough bits available.
So if we were to rewrite t_SER no to use valp/setvalp, we could increase
the limit.

Cheers,
Bill