#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:36 pbruin]:
> This actually strengthens my conviction that "structure category" is
> not a well-defined notion.
It's perfectly defined: C is a structure category if whenever A and B
are in C and phi is a morphism between A and B for any strict super
category of `C`, then phi is a `C` morphism. And it coincides with the
intuition we have of it: does `C` define some additional structure
(typically an operation) that has to be preserved by `C`-morphisms.
> Instead, I have the impression that the structure should be regarded
> as being attached to what is currently called the "axiom" rather
> than to the category.
> In this example, it depends on how you define `Rings()`: either as
> `Rngs() & Semigroups().Unital()`, in which case it is just a join of
> categories without new structure, _or_ as `Rngs().Unital()`, in which
> it does have extra structure (at least at first sight; you have to
> know that the category code magically rearranges the construction to
> turn `Rngs().Unital()` into a join of larger categories). In fact,
> `Semigroups().Unital()` (= `Monoids()`) is not a structure category
> either; it is the join of `Magmas().Unital()` and `Semigroups()`.
I don't see why `Rngs().Unital()` should suggest it's a structure
category. `A.Unital()` is never a structure category unless `A` is the
category defining `Unital`. That is `A=Magmas()`.
> I don't see why this should necessarily be the case; we would just
> encode for each direct supercategory (of which there are usually
> just one or two) whether it is a full supercategory.
Well, I tried, and the code stunk with duplication, urging me to do it
differently :-) Feel free to try for yourself. In particular, it
becomes painful for categories with axioms or functorial construction
categories where the super categories are computed automatically for
you.
> This makes computing all full supercategories not any slower (and
> probably faster) than computing all supercategories,
Yup.
> or presumably all "structure supercategories" for that matter.
Possibly so. There are few structure supercategories so that's rather
cheap too.
I'll answer the rest tomorrow.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/16340#comment:38>
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.
