#10140: Base sage.geometry.cone on the Parma Polyhedra Library (PPL)
----------------------------------+-----------------------------------------
Reporter: vbraun | Owner: mhampton
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-4.7
Component: geometry | Keywords: ppl
Author: Volker Braun | Upstream: N/A
Reviewer: Andrey Novoseltsev | Merged:
Work_issues: |
----------------------------------+-----------------------------------------
Comment(by novoselt):
Replying to [comment:34 vbraun]:
> Since the faces of `P` and `(2*P).polar()` have no particular
relationship I see it as a feature that we don't pretend otherwise. In the
worst case you have to separately construct the face lattice of `2*P`. Is
it really that time-critical? Why can't you just work with `P` alone in
that case?
I was talking about P and 2*P, whose faces are in as direct relationship
as it goes. But it also implies that faces of P and (2*P).polar() are in a
canonical inclusion-reversing bijection. If the order of their faces
"match", one can iterate over related pairs without any extra effort/code
and I found it to be extremely convenient and natural (having said that, I
admit that I am biased and there can be a cleaner interface). Necessity to
do such iterations arises in working with Hodge numbers and generating
functions corresponding to nef-partitions. Regarding time: my first
straightforward implementation using 2*y as just a polytope obtained from
y was taking about an hour on a certain (simple) example. After some
optimization and in particular enforcing face order on P and 2*P and using
2*y as a face of 2*P brought it down to less than a minute. Of course,
part of the problem is that PALP is used via system calls so combining
many of them into a single one helps a lot, but in any case nothing can
beat `zip(P.faces(2), twoP.faces(2))` ;-) Anyway, I plan to redo lattice
polytopes ones I'm done with my thesis and I'll try to both explain this
efficient method in the documentation and provide a more natural interface
whenever possible.
> Its funny that you mention the ideals, because they make no promise
about the generators.
I meant that by default they don't even compute a minimal set of
generators. But I don't recall any use for non-minimal representation of
cones, so I think that there isn't any point to do the same for cones.
We got a reply from Nicolas on sage-combinat, which I copy below:
----
Just two cents from an outsider (I'll certainly will have a need for
Cone's at some point, but don't have practical experience).
When there is no clear cut answer for a design decision, I tend,
whenever possible, to just postpone it; more often than not, the
answer will become clear by itself after accumulating practical
experience. In that case, there could be an option like:
Cone(rays=[(1,0),(0,1)], keep_order = True)
and the documentation could explicitly specify that the default value
is currently *undefined*, and will be chosen later on. I guess for the
moment I would unofficially set it to False, since that's the cheapest
while True is somehow "adding a feature"; so that's less likely to
break code in case of change later on.
----
So, I guess, I am currently loosing 1:2, unless you have changed your mind
;-)
If not, I propose the following:
1. State in the documentation of `Cone` that by default the order of rays
is going to be "fixed but random" and in particular may change in future
versions of Sage. (Which may very well happen due to upgrade in PPL.
Personally, I don't like when these "random orders" change and it is yet
another reason to stick with the user ordering ;-))
1. Add `keep_order=False` to the list of parameters. If
`keep_order=True`, well, keep the order as much as possible in the
strictly convex case, i.e. through away extra generators from the original
ordered list. If `keep_order=True` and the cone is not strictly convex,
perhaps give a `UserWarning` like "keep_order=True does not affect not
strictly convex cones, see check=False instead!"
1. Add a function `sage.geometry.cone.keep_order(True/False)`, without
importing it into the global name space, that will switch the default
behaviour for the current session, so that if users always want
`keep_order=True`, they don't have to repeat it all the time. Mention this
function in the description of `keep_order` parameter in `Cone`.
1. Perhaps in the documentation of that function we may mention that if
users feel strongly that it should be the default always, they can explain
it on the above sage-combinat discussion. (I suppose it is OK to include
such links in docstrings.)
1. In the documentation examples where the ray order is important, use
`keep_order=True` instead of `check=False` (there are some examples in the
patch where you have added this option).
1. Maybe `keep_ray_order` is better than just `keep_order`.
Does it sound like a good compromise? (I.e. the one that leaves everyone
mad (c) Calvin ;-))
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10140#comment:35>
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.
