#10148: Automorphism group of a Polyhedron
----------------------------------+-----------------------------------------
Reporter: vbraun | Owner: mhampton
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-feature
Component: geometry | Keywords:
Author: Volker Braun | Upstream: N/A
Reviewer: Andrey Novoseltsev | Merged:
Work_issues: |
----------------------------------+-----------------------------------------
Changes (by novoselt):
* status: needs_review => needs_work
Comment:
First of all, let me correct myself - when I was talking about GL-
symmetries, of course I meant affine-linear ones - they just happen to be
the same for reflexive polytopes and I forgot about general situation.
I am more interested in the linear automorphism group and even more in the
lattice preserving one, rather than in the combinatorial one. I think the
abundance of automorphism groups indicates that maybe we should never have
a method called just `automorphism_group`, but always indicate its kind,
as it is done in the new patch.
The current implementation does not preserve the lattice - the example
that I have given above is the polytope of WP(1,1,2) and one of the edges
has length 2 while others only 1. So there is only one lattice-preserving
symmetry. (But that's OK for this ticket.)
Previously raised issues were addressed, but I have some new comments :-)
1. "Note that there are no translations possible since `Q` contains only
a single vertex." is a bit misleading. "Separate" translations are
possible iff there is a non-trivial linear subspace. In this case you
probably meant that there are no "translation components" attached to
matrices, since there is only a single vertex. I think this either should
be explained in more detail, or not mentioned at all.
2. I don't understand how the floating point part works. I am not at all
an expert on such cases, but I don't understand how calling a function
returning `x == 0` is any different from direct comparison with 0, which
should not be done for floating point numbers anyway. How can it ever
return `True` for anything but exactly zero? It seems to me that you
should be comparing `x-c` with the absolute value of `x` and `c` and if
the ratio is too small, declare it to be zero. Probably some care should
be taken in the case when `x` or `c` is actually zero. Fixing some
absolute threshold in advance for `x-c` will lead to incorrect work with
"small" polyhedra, but maybe some rough estimate for the diameter can be
used. E.g. it is relatively cheap to compute the bounding box of the
polyhedra generators and then declare its size divided by 10^6^ or so to
be zero. Or one can try to be more clever and choose this tolerance based
on the actual "edge colors" before rounding. The current version seems to
be too fragile to me.
3. I think you should treat vertices and rays/lines differently when
constructing `v_list`, adding 1 to vertices (which fixed translation
issues above) and 0 to others. Otherwise
{{{
sage: p = Polyhedron(vertices=[(1,0), (1,1)], rays=[(1,0)])
sage: p.restricted_automorphism_group().order()
1
}}}
while it should be 2, I think.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10148#comment:9>
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.
