#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):
That was indeed useful to think about it! But I didn't change my mind ;-)
Regarding non-strictly convex cones, I think that there is no point in
trying to preserve user's order, but it would be nice to state it in the
documentation: if users care about the order in these cases, they must use
`check=False` option. Otherwise I think the output should be as it is now:
{{{
strict_ray_0, ..., strict_ray_k, line_1, -line_1, ..., line_m, -line_m
}}}
For strictly convex cones I indeed want to work with decorated cones, but
I'd rather not call them that way explicitly everywhere. The reason is
that these cones are designed for toric geometry and so their rays (or ray
generators) correspond to homogeneous coordinates. If I want to have rays
`r1, r2, r3` and I want to associate to them variables `x, y, z`, then I
would probably create a cone with rays `r1, r2, r3`, and then create a
toric variety based on this cone with variable names `x, y, z`. If the
order of rays may change during construction, it means that I need to
construct the cone, look at the order of rays, and then rearrange my
variable names accordingly, if necessary. This is inconvenient, so while
mathematically the cone is determined by the set `{r1, r2, r3}` and
associated variables are not `x, y, z` or even `x1, x2, x3`, but `x_r1,
x_r2, x_r3` and one should refer to them specifying the ray, in practice
it is convenient to have some fixed order. Since there is no natural order
on ray, the best one seems to be the one given by the user. I think that
in most case users will actually provide the generating set, so computing
it is almost redundant, but sometimes users (if they are like me ;-))
THINK that they provide the generating set, but it is not - that's why it
is important to have `check=True` by default. Regarding this option, it
also seems natural that if it is acceptable to give `check=False` for
certain input, with `check=True` the output will be the same, but slower.
I am not sure if there is any sense in having separate classes for cones
and decorated cones. It is also not obvious which one should be the base
class. On the one hand, decoration is extra structure. On the other hand,
storing stuff as tuples gives this structure "for free". Personally, I
never wished to have cones without any order. That does not mean that
others don't need them, but right now one can use current cones with
`is_equivalent` instead of `==` and `ray_set` instead of `rays` to
disregard the order.
Some more personal experience:
1. The first time I had problems due to order change was with getting
nef-partitions from nef.x. Because in general PALP preserved the vertices
if they are vertices, but nef.x was reordering them when computing nef-
partitions (I think this is no longer true in the last version of PALP,
but I started using it a little earlier). The solution was to add sorting
to some function in the guts of lattice polytope, so that this reordering
is not exposed to the user.
1. The second annoying issue with PALP was that the i-th face of
dimension 0 could be generated by j-th vertex for i != j. While in
principle vertices as points of the ambient space and vertices as elements
of the face lattice are different, this discrepancy can be quite
inconvenient: you need to remember that it exists and you need to insert
extra code to do translation from one to another. So eventually I added
sorting for 0-dimensional faces.
1. Faces of reflexive polytopes and their polars are in bijection. I find
it very convenient to write things like
{{{
for y, yv in zip(p.faces(dim=2), p.polar().faces(codim=3))
}}}
This eliminates the need for each face to be able to compute its dual.
While it is not terribly difficult, it is certainly longer than having no
need to do any computations at all. In order to accomplish it, there is
some twisted logic in lattice polytopes that ensures that only one
polytope in the polar pair computes its faces and the other one then
"copies it with adjustments". I hope to redo it in a better way, but at
least it is isolated from users, for whom the dual of the i-th face of
dimension d is the i-the face of codimension d.
Somewhat related behaviour of other parts of Sage:
1. Submodules compute their own internal basis by default, but there is
an option to give user's basis. In the latter case the internal basis is
still computed and one has access to either basis. One can also get
coordinates of elements in terms of the user basis or in terms of the
standard basis using `coordinates` for one and `coordinate_vector` for
another and I never remember which one is which. Personally, I think that
this design can be improved. But in any case they do have some order on
the generators as well as other `Parent`s without strict distinction
between decorated and "plain" objects.
1. `QQ["x, y"] == QQ["y, x"]` evaluates to False, so while these rings
are generated by the same variables the order matters. (To my surprise,
one can also define `QQ["x, x"]` and it will be a ring in two variables
with the same name...)
By the way - currently cones DON'T try to preserve the given order of
rays, they just happen to do it often and I didn't really notice it in the
beginning (or maybe I assumed that cddlib preserves the order and there is
no need to do anything). But I consider it a bug.
As I understand, some people need to work with polyhedra that have a lot
of vertices, maybe thousands. In this case sorting according to the
"original order" may be a significant performance penalty, so it makes
sense that PPL does not preserve it. It may also be difficult for general
polyhedra with generators of different type and non-uniqueness of minimal
generating set (as it is the case for non-strictly convex cones). But
cones for toric geometry in practice tend to be relatively simple and
strictly convex (maybe with non-strictly convex dual, but users are less
likely to construct those directly), so I think that this is not an issue.
We can add an option to turn sorting on or off, but, of course, I'd like
to have it on by default.
As I said, I will be very happy to do writing of sorting and doctest
fixing myself!-)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10140#comment:28>
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.
