Re: bug on Itanium

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

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/