#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 | 3d81380c8457e49e2110eb04da8950c19bc0f899
Dependencies: #19368 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by mjo):
Replying to [comment:2 novoselt]:
> `_restrict_to_subspace` sounds more appropriate and in principle can be
of interest on its own, but after reading a bit of your presentation I see
that you think of dual cones as living in the same space.
It's safe to say that everything I know about toric geometry is from your
docstrings. I read enough to make sure that we're actually talking about
the same thing when we say "dual cone." I think the difference is that you
construct the dual cone from the dual vector space whose elements then act
on primal vectors via multiplication (function application). Then a
rational cone is one that can be represented on an integer lattice?
In optimization, I've only ever seen the dual cone defined in the primal
space, but our definition starts in essentially the same way. Rather than
a cone of row vectors in a dual space, we just think of the associated
column vectors in the original space. That is, the cone of `v`s such that
`f_v(w) >= 0` for all `w` in the cone (where the `f_v` live in the dual
vector space).
The out-of-place subspace argument is part of the reason why I made
`_restrict_to_subspace` private. The other is that it's probably less
useful than you think, since it only does what it's supposed to up to
linear isomorphism. Unless you're studying something (like Lyapunov rank)
that's invariant under linear isomorphism, the restriction just doesn't
work.
> I will look closer in a few day (remind me if I don't ;-)), but it is
something worth thinking about: each cone `K` is coming with its
associated space in Sage `K.lattice()` which is not an innter-product
space, and `K.dual()` lives in a different space. It would be best if all
methods and implementations were in agreement on this point.
My use of the fact that `K.lattice().vector_space()` and
`K.dual().lattice().vector_space()` both have column-vector bases is a bit
unsanitary maybe. I guess the latter should be row vectors, and I'd have
to convert them before taking their span in the primal space.
Acknowledging that the primal/dual rays live in dual spaces isn't a
problem as long as I can convert between the two.
Anyway thanks for looking and I'll do what I can to clean it up.
--
Ticket URL: <http://trac.sagemath.org/ticket/19405#comment:4>
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.
