zxh
zxh
After running "py.test --cov=g6k" in the terminal, the error occurred in the picture described below. 
> It seems the dbsize has passed the 2^32 boundary, it could be that an internal integer type is too small. So if I change the float type from "dd"...
> No, I was talking about an integer type, not floating point. It is well known that an integer type wraps around to its lowest possible value after reaching its...
> That would be the general idea. I did notice shrink_db uses `unsigned long`, but on the other hand: grow_db does as well... Can you maybe give the compiler and...
> 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...
> 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...
> > 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...
> 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...
> The `db_size_limit` parameter is not something that is implemented in the main G6K implementation. We did implement it in the GPU version. Overall it is simply adding the parameter...