#17096: Implement categories for filtered algebras
-------------------------------------+-------------------------------------
       Reporter:  tscrim             |        Owner:  tscrim
           Type:  enhancement        |       Status:  needs_review
       Priority:  major              |    Milestone:  sage-6.4
      Component:  categories         |   Resolution:
       Keywords:  filtered algebras  |    Merged in:
        Authors:  Travis Scrimshaw   |    Reviewers:
Report Upstream:  N/A                |  Work issues:
         Branch:                     |       Commit:
  public/categories/filtered_algebras-17096|  
b29f67e46e18721313330d3a6e116cf3df2eaf8e
   Dependencies:                     |     Stopgaps:
-------------------------------------+-------------------------------------

Comment (by darij):

 Replying to [comment:32 darij]:
 > For the graded algebras returning themselves, this can -- and should --
 be fixed. I think the contract is important -- the ass. gr. algebra
 without it is like a free algebra without a way to access its generators.
 Is it necessary to define the ass. gr. algebra of a filtered Clifford
 algebra to be the exterior algebra?
 >
 > EDIT: On a second thought, maybe it is better to implement the
 projection and the back-and-forth isos not as methods on the ass. gr.
 algebra but as methods on the filtered algebra. This allows one and the
 same graded algebra to serve as the ass. gr. alegbra for several different
 filtered algebras. Would this make sense?

 Actually, these were bad ideas. Sorry, I don't think overwriting the
 `graded_algebra` method does any good, unless the return value is a
 refinement of what it would normally be (i.e., the
 `AssociatedGradedAlgebra` of self).

 For an example why preserving a contract (and having a contract in the
 first place) is important, let's recall that `gr` is a functor. In fact,
 every filtration-preserving map `f : A -> B` of filtered modules induces a
 graded map `gr f : gr A -> gr B` of the associated gradeds. This map `gr
 f` sends the residue class of any `a \in F_n(A)` (this means the `n`-th
 filtered part of `A`) to the residue class of `f(a) \in F_n(B)`. (This is
 *not* the map that would be obtained by composing the canonical iso `gr A
 -> A` with `f : A -> B` and then with the canonical iso `B -> gr B` when
 `A` and `B` are graded with basis. It is defined even without bases.) How
 would we implement this (on filtered modules or algebras with basis)? I
 would proceed like this:

 {{{
 def induced_graded_map(self, other, f):
     r"""
     Return the graded linear map ``self`` `\to` ``other`` canonically
     induced by a linear map `f` from the filtered module whose
     associated graded module is ``self`` to the filtered module whose
     associated graded module is ``other``.

     [...]

     """
     # not tested
     A = self._A # This requires ``self`` to have a ``_A`` attribute,
                 # which must be part of the contract.
     def on_basis(m):
         i = m.size() # This needs a ``size`` function on the indexing
                      # set of the basis of ``self``, which gives the
                      # degree. This is NOT a good idea, because the
                      # same indexing set should be usable for bases
                      # of different filtered algebras, with different
                      # degree functions.
         return other.projection(i)(f(A.monomial(m)))
         # This assumes that the basis element of ``A`` indexed
         # by ``m`` is a lift of the basis element of ``self``
         # indexed by ``m``. This is a fairly harmless assumption.
     return self.module_morphism(on_basis=on_basis,
                                 codomain=other, category=self.category())
     """
 }}}

 This is a piece of code so basic and general that it should be in
 ``associated_graded.py``. But if we start redefining ``graded_algebra`` in
 ways that remove its ``_A`` attribute, its ``projection`` method and
 whatever else, then this code breaks.

--
Ticket URL: <http://trac.sagemath.org/ticket/17096#comment:33>
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.

Reply via email to