#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 pbruin):
Hi Travis,
> Replying to [comment:30 pbruin]:
> > Is it clear that the "structure category" terminology is the way to
go? Personally I still don't like it very much (again, it pretends to be
about categories but instead is about relations to their supercategories).
>
> It's more of there has been no better alternative proposed. If we move
away from the terminology "structure category", then I feel like we loose
the ability to name methods like `all_structure_super_categories`. However
I do understand your objection.
After looking at the code, I actually have the feeling that this
`all_structure_super_categories()` method is a somewhat unnatural solution
to the question of determining whether one category is a full subcategory
of another. At first sight it looks like a category should be able to
simply declare if is it a full subcategory of its supercategories (for
each supercategory individually, if necessary). Then
`is_full_subcategory()`, given two categories, could check if there is a
sequence of full subcategory inclusions between the two categories.
> > I would prefer the proposals made by Nicolas in comment:9 and Simon in
comment:10 to have an `additional_structure()` method that returns
something meaningful about the additional structure, not just True or
False.
>
> Currently the default is that new subcategories are structure categories
(so they are not full subcategories). If we were to go with returning
pairs `(op, method)`, then the question becomes do we want the default to
be `False` or do we allow `True` to remain the default and have it be when
we can't adequately define the structure?
Hmm, it doesn't sound very desirable to define a category where you can't
define what its extra structure is...
> Actually, that made me have a thought. How about instead of
`is_structure_category` we have `has_additional_structure`, and then we
could extend this to `additional_structure` (on a followup ticket).
This sounds good. We could go even further and formalise the notion of
category with extra structure, so we would have
1. `CategoryWithAxiom`: like the existing class, but more restrictive.
Specifies an additional axiom to be satisfied by the objects, and defines
the full subcategory objects satisfying this axiom. For example,
commutativity for groups.
2. `CategoryWithStructure`: proposed new class. Specifies an additional
structure on objects that must be preserved by morphisms, and defines a
usually non-full subcategory.
In certain cases something that is now called an axiom would become an
extra structure. For example (thinking about the discussion on #16843)
the `Unital` property for rings (as a subcategory of `Rngs`) would become
a structure instead of an axiom, because morphisms are restricted by the
requirement that they preserve the unit element.
--
Ticket URL: <http://trac.sagemath.org/ticket/16340#comment:32>
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.