Added givens
What's new
- Added
gso_givens.handgso_givens.cpp. - Added
test_lll_givens.cppin the tests folder.
The givens GSO class should be compatible with LLL, but not (yet) with Wrapper. I didn't check whether BKZ can run on this givens GSO class.
Issues:
- Operations on the Givens-matrix
l_givensare mainly Givens-rotations, which are column operations. @lducas suggested to store the transpose ofl_givensinstead ofl_givensitself. However, then the 'lazy' size-reductions occur as column operations. So, the main question is: Should we storel_givensor the transpose of it? What is the fastest way? - Discovering rows could be amortized by discovering multiple rows at a time, and not telling it to the interface.
- How do the different lazyness approaches influence the numerical stability?
Speed
- The Givens-GSO is [compared with the same precision] 2 - 3 times slower than the normal GSO. At dimension 180 however, the normal GSO aborts due to instability, while Givens proceeds.
- There's a test-file
test_benchmark.cppwhich tests various big cases. I will remove this one -- if you want to check for the timings yourself, run it separately.
Codecov Report
Merging #351 into master will decrease coverage by
0.53%. The diff coverage is51.73%.
@@ Coverage Diff @@
## master #351 +/- ##
==========================================
- Coverage 74.36% 73.82% -0.54%
==========================================
Files 55 57 +2
Lines 4891 5211 +320
==========================================
+ Hits 3637 3847 +210
- Misses 1254 1364 +110
| Impacted Files | Coverage Δ | |
|---|---|---|
| fplll/gso_interface.h | 41.44% <ø> (-0.91%) |
:arrow_down: |
| fplll/gso_givens.h | 33.33% <33.33%> (ø) |
|
| fplll/gso_givens.cpp | 56.29% <56.29%> (ø) |
|
| fplll/lll.cpp | 93.96% <0%> (+2.51%) |
:arrow_up: |
| fplll/nr/matrix.h | 69.09% <0%> (+3.05%) |
:arrow_up: |
| fplll/nr/nr_Z_mpz.inl | 92.59% <0%> (+8.64%) |
:arrow_up: |
| fplll/nr/numvect.h | 90.47% <0%> (+10.86%) |
:arrow_up: |
| ... and 2 more |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing dataPowered by Codecov. Last update 661daa8...73a552c. Read the comment docs.
Ping ?
I can try to look at this. @lgremy would you mind helping with this as well?
Hi,
Sorry for the very late reply. I do not have time to look carefully at the code, but I have two remarks, especially about the running time and the lazyness approach.
- Running time
I do not think that we can compare timing at the point of the implementation. Indeed, the variable
n_known_colsis not use in this implementation. The goal ofn_known_colsin the classical GSO implementation is to try to capture the shape of the basis and avoid to do computation of the typea += 0 * 0. It can be a part of the explanation of
The Givens-GSO is [compared with the same precision] 2 - 3 times slower than the normal GSO.
- Lazyness approach I do not have a reference about the use of Givens inside LLL. But if I compare with Householder inside LLL, which must provide more or less the same numerical stability, the R coefficients are refreshed at each incomplete size reduction (Step 2 of Algorithm 3). So I suppose that for Givens, it must be quite the same.
Householder inside LLL is supposed to be faster than LLL using GSO for dimensions larger than 160-170 (see Gilles Villard's tests), so I will be not surprised if it would be the same for Givens, and this is what we can expect from your observation
At dimension 180 however, the normal GSO aborts due to instability, while Givens proceeds.
I will continue to look at the code, but is there any reference describing how to use Givens inside LLL?
Thanks.
Dear @lgremy, (and others)
I am sorry for leaving out the most important part [comments/references] of the Givens implementation. Next week I try to find time to look at my code again and putting appropriate examples, references and comments.
Koen