#16340: Infrastructure for modelling full subcategories
-------------------------------------+-------------------------------------
       Reporter:  nthiery            |        Owner:
           Type:  enhancement        |       Status:  needs_review
       Priority:  major              |    Milestone:  sage-6.4
      Component:  categories         |   Resolution:
       Keywords:  full               |    Merged in:
  subcategories, homset              |    Reviewers:  Darij Grinberg,
        Authors:  Nicolas M. ThiƩry  |  Travis Scrimshaw
Report Upstream:  N/A                |  Work issues:
         Branch:                     |       Commit:
  public/categories/full_subcategories-16340|  
d4c7a88563a397291b6cd5ddadb8f574cc1eedb5
   Dependencies:                     |     Stopgaps:
-------------------------------------+-------------------------------------

Comment (by tscrim):

 Replying to [comment:37 nthiery]:
 > Both concepts are useful, but it's far from clear for me that we want
 > to maintain both categories Coxeter groups / coxeter systems. Given
 > that:
 >
 > - Our Coxeter groups all come endowed with a distinguished set of
 >   generators.
 >
 > - It's easier to change a structure category to a non structure
 >   category than the converse (since it's adding features).
 >
 > - With the current setting, we already have both concepts: e.g. when
 >   constructing a morphism between two coxeter groups, you can choose
 >   to construct it as a group morphism or as a Coxeter group morphism.

 After looking over the category, I agree with you that it is modeling a
 Coxeter system. However I think we should expand the documentation at the
 beginning of the category to emphasize this (and I'd almost say we should
 rename the category to reflect this).

 > Do they? So far, only one of the existing axioms (Unital and its
 > additive variant) add extra structure. And the one I am thinking for
 > the future don't add extra structure (about monoids: L,R,J-Trivial,
 > ...).

 I was thinking associative and inverse add structure (to the morphism),
 but they don't, they just guarantee properties about the elements (and the
 axioms are preserved under the morphisms). I was also thinking of things
 like "grading", "topogolical", and "metric" but they aren't axioms (they
 are/would be functorial constructions). So perhaps axiom categories could
 not be structure categories by default...more data is probably needed.

 Actually that brings up another question, should (regressive) functorial
 constructions be structure categories by default? Or again do you think
 more data needed?

 > If we switch to has_additional_structure, it feels like we are not
 > using `structure` as an adjective for qualifying a category anymore,
 > but rather as a noun. So ``all_structure_super_categories`` does not
 > really make sense. On the other hand, we could possibly name this
 > method "structure":
 >
 >       sage: Rings().structure()
 >       [Category of unital magmas, Category of additive unital additive
 magmas]
 >
 > We could actually get rid of "has_additional_structure" altogether,
 > and instead have `C.additional_structure()` return `C` by default,
 > with the possibility to override it to return `None`, or, in the
 > future, something more meaningful than `C`.

 However with doing things this way, how is it different than explicitly
 specifying the full subcategories (well, in reverse)?

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