Pro lem(?) with LLLReduction

[Ralf Hemmecke]

Dear Waldek,

I'm not sure whether it's really a problem, but I think we should at
least add two things to the ++ docstrings in lll.spad.

(1) The input vectors are represented as the "rows" (not columns).

(2) The input matrix should have full row rank.

Whereas (1) clearly helps users to see how to prepare the input for LLL,
(2) seems to be a must for the current implementation.

(269) -> LLL(matrix [[2,4,8],[1,3,5],[1,2,4]])$LLLReduction

>> System error:
arithmetic error DIVISION-BY-ZERO signalled
Operation was (/ 0 0).

(269) -> LLL(matrix [[3,6,12],[2,3,5],[1,2,4]])$LLLReduction
C-c C-c
>> System error:
Interactive interrupt at #x5300A846.

In fact, I'd be somewhat happier if LLL could deal with linearly
dependent rows or if there was another function that singled out
dependent rows and then called LLL on the rest.

Opinions?

Ralf

[Waldek Hebisch]

As a general principle in FriCAS I normally try to arrange routines
so that when matrix needs to be treated as collection of vectors
we use row vectors (unless there is good reason to do otherwise).

In case of LLL current docstring says "matrix" and routine is doing
(modulo possible differences due to roundoff) what other LLL routines
are doing.

Concerning linear independence of rows: this is standard assumption
for LLL. There are bunch of extentions of LLL, and some extentions
do not need independence. I treat current implementation as initial
one and tried to keep it simple. Certainly, it would be good to improve
it. My point of view was that there are some fundamental things
to work out before implementing improvements (mainly working
out how much numeric accuracy is needed to have reasonable progress
of LLL computation). But if you want some specific improvement,
I will not stop you doing it...

Certainly it would be good to state more precisely what LLL is
doing.

--
Waldek Hebisch