#9296: Add lattice computations for convex polyhedral cones
----------------------------------+-----------------------------------------
Reporter: vbraun | Owner: mhampton
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.5
Component: geometry | Keywords:
Author: Volker Braun | Upstream: N/A
Reviewer: Andrey Novoseltsev | Merged:
Work_issues: |
----------------------------------+-----------------------------------------
Comment(by novoselt):
2) `is_trivial` it is then!
All methods that go into `IntegralRayCollection` should make sense AND
have the same implementation for cones and fans. Mostly things like
ray/rays/ray_matrix/lattice.
`is_simplicial` makes sense for cones and fans but has different code and
definition, so such functions must be placed separately into cone and fan
classes. I am pretty sure that I already put everything possible into ray
collection class - I didn't plan it at all initially, but then got annoyed
repeating ray accessing methods. Please return back the moved methods ;-)
Things like containment checks are definitely different for cones and
fans. Things like `lines` don't seem to make any sense for fans, so should
not appear as valid methods.
3) I would interpret `sigma.N()` more like `N(sigma)` rather than
`N_sigma`. As I understand both notations are in use to denote
complementary things and it does not add clarity.
Perhaps a solution is to use names like `spanned_lattice`,
`complementary_lattice` etc. (I just made up these names, so they probably
deserve some further thinking/choosing), and make an option to add
synonyms. E.g. there is some way in Sage to turn on creation of names
automatically and to allow function-like syntax instead of methods. We can
have a function like `beginner_mode` in toric modules (probably `fan` is
the best place to put it, to allow simultaneous changes to cones and fans
in the same place), which will do things like
{{{
...
ConvexRationalPolyhedralCone.N =
ConvexRationalPolyhedralCone.spanned_lattice
...
}}}
What do you think about it? If the name sounds too patronizing, we can
choose something like `use_M_and_N_toric_lattices`. I do not want to have
it by default, but as an option it gives the system more flexibility and
makes it better.
> 4,5) If I remember correctly then the "sequence of generating lattice
vectors" ends up being used more often than the projection to the quotient
lattice. So you might want to wait a bit before overengineering this part.
Absolutely, the only change in this direction that I would like to get in
this patch are names more accurately representing what do they actually
return. If they return a basis of something, then `something_basis` is
more clear than just `something`. A *side effect* of this is that if we
need to add `something` method later, it will be easy, but there is no
necessity for this addition. I regret that `points` method of lattice
polytopes returns a matrix, a list of points would be more convenient. If
I had named this method `point_matrix` to start with, not only it would be
more clear, but it would be trivial to add `points` method returning a
list now.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9296#comment:5>
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.
