#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 nthiery):
Replying to [comment:35 tscrim]:
> I don't think so. If we wanted the generators to be part of the
structure (definition), that should be the category of Coxeter syetems as
it is much more rigid than just the groups.
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.
> I agree with this, although my thought is more about how many
> categories will we have are structure categories. As I stated, we
> need more data and I agree that having this default is the safe
> route.
I agree that we need more data. My bet is that most categories will be
either structure categories or categories with axioms.
> Most axioms that come to my mind adds extra structure, but we can see
what happens as we add more axioms.
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,
...).
> With this, we could keep the same names (although I believe the
> method your referring to is `all_structure_super_categories`).
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`.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/16340#comment:37>
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.
