#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:39 tscrim]:
> 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
+1, definitely (in a separate ticket of course)
> (and I'd almost say we should rename the category to reflect this).
Possibly so; but then one has to do the same for Weyl groups, and
WeylSystems does not look so compelling. In any cases, things will
become easier when this will have been axiomatized, so that in theory
there would be a single entry point (CoxeterGroups), with axioms
Crystalographic, ...
> So perhaps axiom categories could not be structure categories by
default...more data is probably needed.
That felt like a reasonable default which is why I implemented this
way; especially since anyway the only case where there can be
additional structure for the axiom category is within the category
defining the axiom.
> Actually that brings up another question, should (regressive) functorial
constructions be structure categories by default? Or again do you think
more data needed?
At this point I'd be uncomfortable with it, since e.g. Graded is one
such construction. So I guess it's best done construction by
construction until we have more data. But it may well be that things
should be as for axiom categories: except within the category defining
the construction, there is no additional structure.
In fact, maybe the correct default would be to have,
`A.B().has_additional_structure()` return True if and only if `A` is
the category defining the axiom/regressive construction `B`.
> > 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)?
Well, first it's more concise (just return None or `self`) and
involves less duplication.
Also, it gives more information to the system: there are cases where a
category defines no additional structure even though it's not a full
subcategory of any of its direct super categories. Think of some full
subcategory of `Magmas() & AdditiveMagmas()`. Granted, you could have
`full_super_categories` return a join, but this would deviate from
everywhere else (a category never has a join as super category), and
thus probably be a source of problems.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/16340#comment:43>
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.
