#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:31 vbraun]:
>
{{{
for y, yv in zip(p.faces(dim=2), p.polar().faces(codim=3))
}}}
> This is absolutely terrible and the prime reason why the face lattice
shouldn't make any promises with regards to ordering. Just so that nobody
can use a construct like this. For anybody but the author it is completely
illegible and utterly mysterious that the faces end up being dual. At the
same time, it would be so much easier to write
{{{
for face in p.faces(dim=3):
print face, face.dual()
}}}
I agree that the second form is better (and I think that it is
implemented). But in order to implement it efficiently, one still has to
copy the face lattice of the original polytope.
Now let's consider faces of a polytope P and of the polytope 2*P. It is
also more natural to write
{{{
for face in P.faces(dim=3):
print y, 2*y
}}}
but if you would like 2*y to be a face of 2*P, not just a polytope
obtained from y, how should it be implemented? If they are stored in the
same order, you can easily and very efficiently iterate over faces and
their multiples.
Move on to cones. Let tau be a face of sigma. What is `tau.dual()`? Is it
the cone dual to the cone tau or the face of the cone dual to cone sigma
which is dual to the face tau? So we need to have a different method name
then, `tau.dual_face()` perhaps.
Now let P, P*, C, and C* be Cayley polytopes and cones with their duals.
Faces of P and C are in direct relation, let F be a face of P. How should
I get the face of C corresponding to it? Perhaps `C(F)` is a natural
notation, but how is it going to be implemented? Finding a face generated
by rays coinciding with vertices of F is quite inefficient and no matter
how it is done the result probably should be cached somewhere. Where?
Maybe in P or C and perhaps it is easy to achieve with a special class for
supporting polytopes and supported cones. It is probably a good idea to
implement this in a long run. But there are very many good ideas that have
to be implemented and if faces are ordered in a consistent way, then those
ideas can wait a little, because there is a satisfactory access to related
faces now. And even when they are implemented, I think that the most
efficient implementation will still rely on internal consistency of
orders.
Maybe it is mysterious currently that the face order represents duality.
Then it is my fault for not documenting it correctly and I will try to fix
it. If it was clearly stated in the documentation, with an example how to
use it, there would be nothing mysterious about it.
Note also, that I don't want to SORT faces in any particular way. I just
want to have related faces in the same order as the "initial ones"
happened to be. If nothing else, it leads to efficient implementation, so
it is good to do it even if end-users will use some other interface.
> Also I'm totally opposed to requiring rays in cones to always be
decorated. The cones of a fan are not the only place that uses `Cone`. In
fact, the main reason for this ticket is that the current (PALP-based)
implementation of cones is unsuitable for Kahler cones because it is
constrained to low dimension.
What I was trying to say is that some kind of decoration occurs on its own
just because rays are internally stored as tuples. If you are really
against it and want to store them as sets, that means that anything that
uses rays of that cone should refer to complete rays and instead of other
lists and tuples with order matching the order of rays you need to use
dictionaries with rays as keys. Which certainly can be convenient but you
can do it even if cones have some internal order of rays, so I don't see a
reason for having extra classes.
> We could have an `OrderedCone()` function that constructs the cone while
keeping the ray order intact if possible (at a performance penalty). This
function could then even raise a `ValueError` if there is no unique
minimal representation. But I still think that its a bad idea to
implicitly have some particular order.
I'd rather go with `UnorderedCone()` ;-) I suggested adding a parameter
that will turn off sorting for performance gain. I also don't want to have
IMPLICIT order, I want to completely and clearly document it in the
description of the Cone constructor and its face methods when/if there is
any particular order on anything!
> As far as associating rays with homogeneous variables, I think we really
should subclass the multivariate polynomial ring. Then we can convert rays
to homogeneous variables and properly check homogeneity of polynomials.
Another good idea, but even after this conversion do you really want to
use names like `x_(1,0,0,0,0), x_(0,1,0,0,0), x_(0,0,1,0,0),
x_(0,0,0,1,0), x_(0,0,0,0,1), x_(-1,-1,-1,-1,-1)` for coordinates on
`P^5`?! And for more complicated varieties expressions in such variables
will be completely unreadable! So it is very natural to fix some order of
rays and create variables whose index refers to the index of the
corresponding ray. Even better is to have both "order matching" and
"direct conversion".
> Finally, about `QQ['x, x']``: The variable name is just a string and can
be pretty much anything. The issue was raised during the recent bug days
and the real problem is that conversion to e.g. maxima is broken in such a
case. Sage generally only cares about the order of the variables.
Let's leave `QQ["x, x,"]` and come back to `QQ["x, y"]`. This notation
asks for a polynomial ring over QQ with variables named x and y, correct?
Well, `QQ["y, x"]` asks exactly the same, yet the rings are different. So,
really, `QQ["x, y"]` asks for a polynomial ring over QQ with the first
variable named "x" and the second one "y". In the same way I think that
`Cone[(1,0), (0,1)])` asks for a cone with the first ray (1,0) and the
second ray (0,1).
If we do have
{{{
def Cone(..., keep_ray_order=True)
}}}
then interactive usage will be pretty, yet there will be no performance
penalty for internal computations. Users don't construct Kaehler cone
explicitly, they call `Kaehler_cone` and somewhere inside there is a call
to Cone which is written once and may have as many extra parameters as
necessary.
People refer to the first/second/third equation of the system, generator
of the ideal etc. all the time even without assigning some labels/indexed
names to them. It is natural to assume that you have specified the order
of something when you have written this something in a certain order.
Perhaps, the optimal solution is to let `Cone([(1,0), (1,1), (0,1)])` to
be the cone generated by three (ordered) rays - all of the given ones. And
then have a function like `minimal_ray_generators`. I guess that's kind of
what ideals are doing. I didn't think about this option before. And now I
am a bit hesitant to implement it since I am not sure how many places in
the code rely on the minimality of the set of generators for the strictly
convex case...
I do realize that all your points are valid and my arguments significantly
reflect my personal taste, however I also do use the toric code in
addition to writing it and if I find something to be convenient it is
likely that some other people also will find it convenient. Unfortunately,
it is a bit hard to say how many (or how few) of these other people would
like my way. Although I suspect that not very many will strongly dislike
it since it is harmless (except for some potential slow down, which should
not be a noticeable issue and I suggest to have a way around it when it
is.) I'll ask on sage-combinat for some input.
At the very least I would like to be able to call a function
`sage.geometry.cone.keep_ray_order(True)` that will turn on user-order
preservation for the current session, even if the default is not to keep
the order. But I still strongly believe in trying to preserve the order
whenever possible, i.e. in the strictly convex case. (Overall, this issue
is terribly similar to `ambient_ray_indices` discussed some time ago on
#9972.)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10140#comment:32>
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.
