#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.

Reply via email to