Bill Allombert on Fri, 14 Oct 2022 22:06:12 +0200 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: polcyclo: overflow in precp(). |
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