#9504: Add support for toric sublattices
----------------------------------+-----------------------------------------
Reporter: novoselt | Owner: mhampton
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.5.2
Component: geometry | Keywords:
Author: Andrey Novoseltsev | Upstream: N/A
Reviewer: | Merged:
Work_issues: quotient lattices |
----------------------------------+-----------------------------------------
Comment(by novoselt):
My main progress on quotients so far was looking over these FGP modules
and thinking what should we do. I think I am in favor of leaving
`quotient` and `/` to be the same as they are with possibility to produce
torsion modules, but implementing `quotient_lattice` to return some
`ToricLattice_quotient` object which is **NOT** derived from
`FGP_module_class` and works only when there is no torsion. Reasons:
* "Toric lattice" is a thing isomorphic to `ZZ^n`, so if we want a
quotient which is also a toric lattice, it should not contain torsion.
* This case is likely to be simpler than general quotients and,
therefore, can be implemented more efficiently than general quotients.
* In this case I do want elements of these quotients behave differently
from the "usual ones," details below.
* On the other hand, it is probably still nice to have a possibility to
construct torsion quotients, so it would be better not to hide this
functionality completely.
There more I think about it, the more I get convinced that quotient
lattices and their elements should behave as follows:
* Quotients don't have their own names, they are attached to the original
ambient lattices.
* Elements do have both representations: in terms of some basis for the
quotient and a fixed representative of the class. The latter is the one
which is used "externally".
* If `Q` is a 2-d sublattice of a 3-d lattice `N`, I think that its
elements should print like
{{{
N[1,2,3]
}}}
i.e. still shown as elements of N, but with some hint that this is a
quotient object, after all, that's exactly how quotient objects are
represented in mathematics: by an element of the original space with a bar
on top or something like this.
* Creation of elements of `Q` should work both as `Q(1,2,3)` and `Q(1,2)`
- in the first case an element of `N` is used and in the second one - the
internal basis (there should be no confusion between two - if `Q` and `N`
are of the same dimension, then `Q` is `N`). This will allow users to
write
{{{
Q(1,2,3) * M(1,2,3)
}}}
and it will either work if `M(1,2,3)` is an element of the lattice dual
to `Q`, i.e. it is within proper submodule where the choice of a
representative for elements of `Q` does not matter, or an exception will
be raised. Those who know what they are doing can also use
{{{
Q(1,2,3).lift() * M(1,2,3)
}}}
and in this case there can be no error but the result may depend on the
choice of the lift (which is fixed during any given session, at least).
I think such behaviour is cleaner and more consistent than using
coordinates in internal basis, it will also clearly distinguish all
elements that are related to the same ambient lattice, no matter how many
submodules and quotients are involved. Plus, it is more or less clear what
is `Q(1,2,3)`, but what is `Q(1,2)`, how is it related to its lift, and
how will it pair with a given element of the dual lattice?
Coming back to the proposal not to derive from FGP. One more good point is
that we may represent nested sublattices/quotients more efficiently (I
think all obejcts of the form "quotient of quotient of sublattice of
quotient" can be represented by a single quotient of a sublattice of an
ambient lattice). Bad point is that we may work a little bit harder and we
may loose consistency with "standard quotients".
So we need to decide on: 1) Should `ToricLattice_quotient` derive from
`FGP_Module_class` or not? 2) Should we represent quotient elements mostly
by representatives as described above?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9504#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 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.