#9296: Add lattice computations for convex polyhedral cones
----------------------------------+-----------------------------------------
Reporter: vbraun | Owner: mhampton
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-4.5
Component: geometry | Keywords:
Author: Volker Braun | Upstream: N/A
Reviewer: Andrey Novoseltsev | Merged:
Work_issues: |
----------------------------------+-----------------------------------------
Changes (by novoselt):
* status: needs_review => needs_info
Comment:
After more careful reading of the code and the documentation, I am having
second thoughts about the importance of 5) in the first comments -
returning `ToricLattice` objects as `sublattice` etc.
Basically, we have two dual lattices and want to decompose each of them
into two. After that it seems that there is need to access "embedded"
basis of each sublattice, matrix of this basis, and work with projections
that will be given as elements in a lower dimensional lattice. If each of
the four sublattices is an instance of some `ToricSublattice` (analog of
`(ZZ^3).submodule(...)`), then there should be only four methods in cones
to access them and every single one will have exactly the same methods for
basis, basis matrix, and projection. This will be more clear and
consistent and will help to avoid code duplication and extremely long
names.
Right now I find it confusing for a programmer (at least for me) that
`sublattice_basis` and `_sublattice_basis` are, in principle, the same
things, but represented quite differently. I also find it confusing for a
user that `sublattice_basis` works with sublattice in the embedded
representation and `sublattice_projection` in quotient. I also don't quite
like the lattice argument to projection functions - it seems to me that
all lattices in question should be fixed once they are constructed the
first time, since they are closely related to each other and are
completely determined by the cone itself and the chosen way of splitting.
(It does make sense, however, to have these lattices "incompatible" for
different cones, but given the way how they work now it is not that easy
to create them.)
Sorry for dragging so long a relatively simple ticket, but I seems to me
that there are two ways to total happiness:
* Implement `ToricSublattice` class and use it.
* Make these methods private untill there is `ToricSublattice` class.
Let me know what you think...
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9296#comment:14>
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.
