WvanWoerden

Enumeration in FPLLL is implemented over doubles, so there is no way large entries are going to work without rewriting the whole enumeration part with higher precision types (which is...

The change looks good to me (maybe after some more benchmarks). To give some context: the descending sort was introduced on purpose (but is certainly suboptimal). The thought was to...

Should be resolved now. The old doctest failed the (already existing) input assumption that Q is given in local diagonal form. The new code uses this assumption and therefore gave...

The previous build resulted in an error because some .coverage file was missing (see https://github.com/sagemath/sage/actions/runs/10962048022/job/30442695828 ). Is there something I can do to fix this? The coverage report is fine...

That seems to have fixed it, should be good to merge now.

Thank you both for noticing this and for the suggestions. I've updated the docs accordingly.

An easy workaround might be to call g6k.extend_left(g6k.l) before iterating over the vectors. This moves the sieve to the full context [0, r) and Babai lifts the database of short...

At the very least the following typedef of `IT` should be changed to uint64_t (and then recompiled): https://github.com/fplll/g6k/blob/88fdac1775585ef2a0269ef29cebf158cd5719d0/kernel/siever.h#L120C8-L120C132 I don't know how well all the internal procedures really use this...

> I have another question: since the db_size is limited to 2^32 -1, which corresponds to the 146-dimensional pump sieve , how do you solve the 180-dimensional SVP challenge by...

For those runs we indeed implemented a hard limit on the database size so we would never go over the 1.5TB. You should be able to do something similar with...