Karim BELABAS on Thu, 13 Mar 2003 22:11:32 +0100 (MET) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: rnflllgram() regression |
On Thu, 13 Mar 2003, Igor Schein wrote: >> It's still a precision problem but at a higher level: the base nf is not >> computed to a sufficient accuracy. The natural solution (which I've >> implemented in CVS) is to increase that accuracy and go on. >> >> Since the relative LLL algorithm (even implemented with exact computations) >> doesn't really work, this produces worse results than immediately using the >> right accuracy [ in regular LLL, going astray due to accuracy problems >> is quickly corrected in the following iterations. Here, not at all ]. > > I guess by worse results you mean the following: > > ? rnfpolred(nfinit(quadpoly(1297,y)),quadray(1297,1)); > *** the PARI stack overflows ! > current stack size: 512000000 (488.281 Mbytes) > [hint] you can increase GP stack with allocatemem() Errr, no. This is another precision problem which I didn't think of: I checked the eigenvalues of a supposedly positive definite matrix were non-zero 0 (meaning complete loss of accuracy, e.g 0.E50). In fact, they ended up being negative... Fixed. > If I set \p163 though, it works fine at default stack. It does in default precision also now. > BTW, at \p163 current CVS is 30% faster than 2.2.5 when running this > command, so it's a significant performance improvement. I have completely rewritten the routine [ again, the underlying algorithm doesn't work. Sad... ] Karim. -- Karim Belabas Tel: (+33) (0)1 69 15 57 48 Dép. de Mathématiques, Bât. 425 Fax: (+33) (0)1 69 15 60 19 Université Paris-Sud http://www.math.u-psud.fr/~belabas/ F-91405 Orsay (France) http://www.parigp-home.de/ [PARI/GP]