IntegerLattice class

[malb]

This ticket implements sage.lattices.integer_lattice.IntegerLattice which represents a discrete subgroup of ZZⁿ.

This class is inspired by #15955 but except for the voronoi cell implementation, it is implemented anew from scratch.

This ticket also includes an updated interface to fpLLL which uses Cython's C++ features, uses the fpLLL 4.0 API and interfaces not only with LLL but also with fpLLL's BKZ and shortest vector enumeration.

Component: linear algebra

Author: Martin Albrecht

Branch: 6957074

Reviewer: Daniel Krenn, Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/15976

[tscrim]

Changed work issues from python3 to none

[malb]

comment:74

looks okay, thanks.

[vbraun]

comment:75

Conflicts with #16216

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 8271e3c to 1eb090a

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

f623de2	generated changes from "== None" to "is None"
6a2e806	manual fixup of the generated changes
f87a26f	Merge branch 'develop' into u/wluebbe/ticket/16216b
564c73c	trac #16216: undo a mistake from the last merge
67546ca	merging #16216
1eb090a	fixed doctest failures

[malb]

comment:77

merged

[vbraun]

Changed branch from public/ticket/15976-latex to 1eb090a

[vbraun]

comment:79

PDF docs fail:

! Package inputenc Error: Unicode char \u8:̣ not set up for use with LaTeX.

See the inputenc package documentation for explanation.
Type  H <return>  for immediate help.
 ...                                              

l.24326 A lattice $(b_1, b_2, ..., b_d)$ is $(̣
                                                δ, η)$-LLL-reduced
? 
! Emergency stop.

I think there is a zero-width space or something like that before the delta. But really, why did you remove the original TeX codes?

[vbraun]

Changed commit from 1eb090a to none

[vbraun]

Last 10 new commits:

4f6b44e	fixed doctest failures with latest Sage beta
f07b046	Documentation cleanup and python 3.
2317917	Some more documentation tweaks and added free_module_integer.py to doctree.
8271e3c	Added fplll to doc and changed utf to latex.
f623de2	generated changes from "== None" to "is None"
6a2e806	manual fixup of the generated changes
f87a26f	Merge branch 'develop' into u/wluebbe/ticket/16216b
564c73c	trac #16216: undo a mistake from the last merge
67546ca	merging #16216
1eb090a	fixed doctest failures

[vbraun]

Commit: 1eb090a

[vbraun]

Changed branch from 1eb090a to public/ticket/15976-latex

[vbraun]

comment:81

In fact, there is a http://www.fileformat.info/info/unicode/char/0323/index.htm before the delta (depending on your editor you see a dot below the delta)

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

6957074

fixed make doc-pdf

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 1eb090a to 6957074

[malb]

comment:83

should be fixed now.

[malb]

comment:84

What's the policy on such "doctest failure" like fixes? Does someone have to review them or is it enough to check it again using the automatic tools checking such things?

[vbraun]

comment:85

Use your own judgement... but if you set it back to positive review you better be sure that it works ;-)

[malb]

comment:86

living on the edge … it did work on my machine :)

[vbraun]

Changed branch from public/ticket/15976-latex to 6957074

[dimpase]

comment:88

there is a strange rounding going on in

hv = [QQ(round(elmt, 6)) for elmt in hv]

Can anyone explain it? A careless change there initiated #29866, but still why 6, and not 42 - or better, something input-dependent?

[dimpase]

Changed commit from 6957074 to none

[malb]

comment:89

This is in diamond_cut in diamond_cutting.py, right? Maybe the underlying software uses single precision floats and this is meant to approximate that?

[dimpase]

comment:90

Replying to @malb:

This is in diamond_cut in diamond_cutting.py, right?

yes

Maybe the underlying software uses single precision floats and this is meant to approximate that?

No, since ages (libppl interface was added in 2011 or 2012, I gather - although it could have taken more time for it to become default) Polyhedron() uses ppl as backend, if given rational data, so it's exact. I thought that line does some clever rounding to speed things up, but still I can't imagine a maths statement which could make it rigorous.

Should we just drop the rounding?

[dimpase]

comment:91

It's actually quite strange - you first convert your data to float(), and then build a polyhedron with coodinates obtained by rounding these floats and converting them into QQ.

It's a miracle to me that it (mostly) works.