#9296: Add lattice computations for convex polyhedral cones
---------------------------+------------------------------------------------
Reporter: vbraun | Owner: mhampton
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.4.4
Component: geometry | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
---------------------------+------------------------------------------------
Changes (by novoselt):
* status: needs_review => needs_work
Comment:
Hi Volker,
I have a bit limited computer time this week, so I can be slow in
responses and will probably wait till next week for final positive
verdicts.
Comments on the current version:
1) `ray_basis` assumes that rays start from a linear independent set. I
would rather not make such an assumption since otherwise every cone should
sort its rays during construction (and it is not really even "sorting",
it is just selecting a certain subset and putting it in front) and cones
of fans will not be able to have the order of rays induced from the fan.
On the other hand, it is easy to get basis as something like
{{{
self.rays(self.ray_matrix().pivots())
}}}
(I didn't check the exact command, but it is possible to get indices of
pivot columns).
2) (very minor) Maybe `is_origin` is more intuitive than `is_trivial`? I
am fine with both names, just a thought. And probably this function should
be added to `IntegralRayCollection`, so that it is available for fans as
well. Such little functions were exactly the reason for creating that
class.
3) I am against functions and attributes with direct names of lattices. I
want to be able to have cones in any lattice and call any functions on
them. If lattice names are hard-coded into functions it makes it confusing
to call them for cones from the dual lattice. I agree that `N` and `M` are
standard, but in mirror symmetry it is also common to perform operations
on both sides and it would be better if it was possible to do it without
making a representative of each fan in the `N`-lattice.
4) It seems that some suffix like `_basis` would be nice for functions
that return not the actual lattice in the sense of a `ToricLattice`
object, but rather a sequence of elements that generate it.
5) Related to 4), but perhaps a note for the future todo list rather than
something to be implemented in this patch. Ideally, I think all these
methods should return `ToricLattice` objects with canonical coercion maps
between appropriate lattices. I don't know how easy it will be to
implement it, but it seems it should be more natural and convenient if it
works. As I understand, tests like belonging to a lattice will then work
not only for the actual lattice elements, but also for elements from those
related lattices directly. I can try to play with it in a week, once I am
home. By the way, if 4) is done now, then 5) can be done later without any
name conflicts by adding functions without prefix.
Let me know what you think!
Andrey
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9296#comment:2>
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.
