Always use PPL for facet normals of lattice polytopes

[novoselt]

A follow up to #22310. As promised there, this switch makes even full-dimensional polytopes faster, on the same example we now get

sage: timeit("LatticePolytope(lattice_polytope.cross_polytope(3).vertices()).facet_normals()")
625 loops, best of 3: 976 µs per loop

The reason is that dimension computation used to be quite complicated.

Next in the chain of lattice polytope improvements is #22524

Depends on #22310

Component: geometry

Keywords: sd91, sd90

Author: Andrey Novoseltsev

Branch/Commit: baf0a4a

Reviewer: Travis Scrimshaw

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

[novoselt]

Branch: u/novoselt/PPL_for_normals

[novoselt]

Commit: b4410f1

[novoselt]

Last 10 new commits:

db3b54e	Fix doctests - mostly due to different order of vertices
5281cf4	Use PPL for facet normals of full-dimensional polytopes
d244793	Update a lot of toric doctests for the new facet order
e70f34d	Merge tag '7.6.beta3' into PPL_for_normals
b27e343	Always use PPL for LatticePolytope.facet_normals()
8e77861	Update docstrings for facet normals and constants
ba7656a	Use PPL for LatticePolytope.dim()
38bbdb2	Don't use embedding in LatticePolytope.distances()
f4a696b	Implement point containment test for LatticePolytope
b4410f1	Do not rely on distances for containment check

[novoselt]

Description changed:

--- 
+++ 
@@ -5,3 +5,5 @@
 625 loops, best of 3: 976 µs per loop
 ```
 The reason is that dimension computation used to be quite complicated.
+
+Next in the chain of lattice polytope improvements is #22524

[sagetrac-ursula]

comment:4

I successfully installed this patch and tried some variants on the example. Speed seems to work as advertised:

sage: sim = ReflexivePolytope(3,0)
sage: timeit("sim.facet_normals()")
625 loops, best of 3: 576 ns per loop

[videlec]

comment:5

Have you tried using normaliz? In dimension >= 10 it is likely to be faster. For that reason, it is good to have an optional keyword method= or algorithm= that simplifies speed comparisons.

[novoselt]

comment:6

Replying to @videlec:

Have you tried using normaliz? In dimension >= 10 it is likely to be faster. For that reason, it is good to have an optional keyword method= or algorithm= that simplifies speed comparisons.

The interest here is mostly in polytopes of dimensions 3-4-5, when the bottleneck is often the interface between programs. Also, the old code was quite convoluted for many reasons and adding different algorithms would be tricky. One of the goals of this and related tickets was to clean up the mess to indeed allow using different backends for certain operations.

[roed314]

Changed keywords from none to sd91

[sagetrac-ursula]

Changed keywords from sd91 to sd91, sd90

[sagetrac-ursula]

comment:9

I tried building again, and now this patch fails, with errors involving sage-ursula/src/build/cythonized/sage/. My guess is that the transition from Sage 7.6 to the current development branch is too great. Do you mind updating the patch?