Karim BELABAS on Thu, 21 Nov 2002 19:46:23 +0100 (MET) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: bug on Itanium |
On Thu, 21 Nov 2002, Bill Allombert wrote: > On Thu, Nov 21, 2002 at 12:32:43PM +0100, Bill Allombert wrote: > > On the other hand, on ia64 with gcc 3.2 and 2.96, I get > > qflll(1/mathilbert(7)) --> oo loop > > It also happen on alpha, so I suppose it is 64 bits specific. I very recently modified the floating point LLL code for exact inputs, and did not pay attention to [ pre-existing ] dependance on sizeof(long) [ my main machines all have 32-bit architectures ]. I have fixed the problem. When the entries are exact, the new code is expected to be fault-tolerant (it should never abort with a "precision problem"), and much faster. Floating point LLL should be faster than lllint except 1) for small entries, 2) in large dimensions (say 100 and more). Example: compare qflll(1/mathilbert(50)) with the stable version, or 2.2.4 at various precision. You can also try qflll(, 1) My primary goal was nffactor() in high degrees (had to finish a paper...). It works nicely here (~ factor 100 speedup in my applications). I have also switched the whole polred[abs] machinery to always use floating point LLL code, even for totally real fields, where the Gram matrix is exact. I expect the polred functions to be _much_ faster for large totally real polynomial [ such as produced by quadhilbert, quadray, bnrstark... ]. So if something's wrong with this code, it should show up quickly, on many fronts. Happy hunting, 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 Email: Karim.Belabas@math.u-psud.fr F-91405 Orsay (France) http://www.math.u-psud.fr/~belabas/ -- PARI/GP Home Page: http://www.parigp-home.de/