#8986: Add support for convex rational polyhedral cones
----------------------------------+-----------------------------------------
Reporter: novoselt | Owner: mhampton
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-4.4.4
Component: geometry | Keywords:
Author: Andrey Novoseltsev | Upstream: N/A
Reviewer: Volker Braun | Merged:
Work_issues: |
----------------------------------+-----------------------------------------
Comment(by novoselt):
Replying to [comment:15 vbraun]:
> The `Polyhedron` class already has a `contains()` method that tests for
inclusion (I wrote it with toric varieties in mind :-).
`ConvexRationalPolyhedralCone._contains()` could have called that, saving
a few lines of duplicate code. Not that big a deal, though. I'm happy to
give it a positive review either way. Let me know what you think.
So does `LatticePolytope` class, which was written with the same goal in
mind ;-) As I have already complained somewhere, any calls to underlying
`LatticePolytope` or `Polyhedron` objects can trigger system calls to
other programs, which in many cases gives a huge overhead (compared to the
rest of involved computations). So in this case I preferred to use a
"native" way for cones to check if a point is inside. Of course, computing
facet normals the first time will eventually call PALP to get facet
normals of the corresponding polytope, but:[[BR]]
1) there is a way to compute facet normals for a lot of polytopes (e.g.
corresponding to all cones of a fan) with a single call to PALP, in which
case the overhead is negligible;[[BR]]
2) if a cone was pickled and unpickled, it definitely does not have
polytope objects anymore, but it may still have facet normals, if they
were computed before pickling;[[BR]]
3) we may eventually write our own initial computation of facet normals at
least in some cases, for example, for complete fans.
Regarding 1) - the first call to `ReflexivePolytopes(3)` takes currently
5-10s. It reads a text file with vertices and then precomputes a bunch of
stuff to save time later. Computing all this stuff without using group
calls to PALP was taking about 15 minutes. I don't see any reasons why
such calls cannot be done for Polyhedra, but I don't know how easy that
would be. Do you think there is any point trying to implement it?
To summarize: please give a positive review to the present version ;-)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/8986#comment:16>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
