#19405: Add lyapunov_rank() method for polyhedral cones
-------------------------------------+-------------------------------------
Reporter: mjo | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.10
Component: geometry | Resolution:
Keywords: | Merged in:
Authors: Michael Orlitzky | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/mjo/ticket/19405 | 374f5e8a9940e7b22586fe2e702046a8c7907994
Dependencies: #19368 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by novoselt):
Well, to start with, we should realize that it is NOT a quotient! And
that's one of those cases when all the fuss about distinct lattices M and
N is handy. If our cone lives in N, then `orthogonal_sublattice` is in M
and there is no way to quotient N by it. What you want instead is to take
the sublattice of N spanned by the cone and think of the cone as living in
this sublattice where it will become solid. Since you have discovered that
constructing cone in sublattices breaks some methods, you actually want to
pick some basis for this sublattice (non-canonical choice) and then send
your cone to a "standalone lattice". If you want to expose this
functionality to users, perhaps `solid_restriction` or `solid_inclusion`
would make sense. Another option is to have it as an internal function
with whatever name you like ;-)
For exposure to the user, it may be preferable to have two methods: one to
restrict to sublattice as indeed a sublattice (this is canonical), and
another taking a cone living in sublattice/quotient lattice/whatever and
representing it in the basis of this whatever. The latter is not canonical
and has not much mathematical sense, but it makes life easier in the code
since nothing should break on regular lattices. (Fixing everything so that
nothing breaks on sublattices is an even better noble goal, but will take
longer to reach.)
As for caching, I guess I just had overall approach to cache everything
that it relatively expensive to compute or is complicated. "Factor cones"
are complicated because they are cones - if you start working with their
face lattices etc. it is nice to cache things. So far I didn't encounter a
situation where it was hurtful. On the other hand, this is not how caching
should be implemented in most cases: just return whatever is necessary and
add `@cached_method` decorator.
--
Ticket URL: <http://trac.sagemath.org/ticket/19405#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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
