You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With #28880 at hand, it makes sense to set up polyhedra from both Vrepresentation and Hrepresentation, if the backend supports it.
This is faster an any case, if the backend supports precomputed data (currently only field, but polymake and normaliz potentially can do that as well). Otherwise it might be faster, as it chooses the shorter representation by default. E.g.
setting up a hypercube is then done by inequalities instead of vertices,
translating a hypercube should be done by inequalities not by vertices.
This ticket collects all those instances, where we will set up the polyhedron from both Vrep and Hrep:
With #28880 at hand, it makes sense to set up polyhedra from both Vrepresentation and Hrepresentation, if the backend supports it.
This is faster an any case, if the backend supports precomputed data (currently only
field
, butpolymake
andnormaliz
potentially can do that as well). Otherwise it might be faster, as it chooses the shorter representation by default. E.g.This ticket collects all those instances, where we will set up the polyhedron from both Vrep and Hrep:
PolyhedronFace.as_polyhedron
CC: @jplab @LaisRast
Component: geometry
Issue created by migration from https://trac.sagemath.org/ticket/29199
The text was updated successfully, but these errors were encountered: