Re: qflllgram

["Karim Belabas" <Karim.Belabas@math.u-bordeaux1.fr>]

* Gonzalo Tornaria [2006-02-27 18:47]:
> Strange behaviour:
> 
> ? qflllgram([1,0;0,-1],0)
>   *** qflllgram: the PARI stack overflows !
>   current stack size: 128000000 (122.070 Mbytes)
>   [hint] you can increase GP stack with allocatemem()
> 
> ? allocatemem()
>   *** allocatemem: Warning: doubling stack size; new stack = 256000000
> (244.141 Mbytes).
> ? qflllgram([1,0;0,-1],0)
>   *** qflllgram: length (lg) overflow

Junk in, junk out: the function is undefined on indefinite matrices.

More precisely:

For flag = 0, the implementation uses floating point computations and
increases the internal precision when incremental Gram-Schmidt fails
(basis vector with non-positive square norm).

When the input is exact, we enter an infinite loop, and eventually
overflow the capacities of the implementation. When the input is
inexact, we give up relatively quickly.

> It /does/ work with flag=1 (lllgramint):
> 
> ? qflllgram([1,0;0,-1],1)
>   *** qflllgram: not a definite matrix in lllgram

For flag = 1, we use the atrociously slow all-integer algorithm. But a
negative vector length in Gram-Schmidt is immediately flagged as an error:
since all computations are exact, it can't be due to roundoff errors.


I don't see why we should clutter the code and slow down the floating
point code to check the input in case the user would be playing tricks
on us. Try it at \g4 and a non trivial computation, like

  \g4
  \p300
  algdep(3^(1/5)+2^(1/6), 30)

Quite a number of precision changes, heh ? [ This could be performed
much more efficiently, but I haven't had time to implement Phong &
Stehle's L^2 algorithm yet ]

Cheers,

    K.B.
-- 
Karim Belabas                  Tel: (+33) (0)5 40 00 26 17
Universite Bordeaux 1          Fax: (+33) (0)5 40 00 69 50
351, cours de la Liberation    http://www.math.u-bordeaux.fr/~belabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux.fr/  [PARI/GP]