#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King
Report Upstream: N/A | Work issues: Reduce startup time
Branch: | by 5%. Avoid "recursion depth
Dependencies: #11224, #8327, | exceeded (ignored)".
#10193, #12895, #14516, #14722, | Commit:
#13589 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by SimonKing):
Hi Nicolas,
concerning the notion of "super_categories":
Replying to [comment:69 nthiery]:
> Replying to [comment:66 SimonKing]:
> > You're right. But I think this has been the *only* exception.
>
> And this still is the only exception:
{{{Rings().Commutative().Finite()}}} is a join category.
> {{{
> sage: type(Rings().Finite().Commutative())
> <class 'sage.categories.category.JoinCategory_with_category'>
> }}}
Exactly. And my impression is that your patch drastically increases the
use of join categories. Perhaps this is actually not the case, but if I
recall correctly, creating a join is the default when adding an axiom.
And this means that you implicitly really change the meaning of
`C.super_categories()`. It used to be "the list of all super-categories of
C such that Sage does not implement categories properly between C and the
super-category", except in the case of joins. But if joins are ubiquitous,
then `C.super_categories()` will ''usually'' (i.e., implicitly by default)
be "the list of all super-categories of C, such that all named classes
associated with C can be defined by means of the named classes of these
super-categories together with attributes of `C.__class__`."
My question (or even suggestion!) is to make this implicit policy
official. Rationale:
- The notion of a "category implemented in Sage" is not a mathematical
notion, but refers to implementation. Since we don't talk about
mathematics here, we should give priority to the question: Where is
`super_categories()` used in our implementations?
- If I am not mistaken, we currently use `super_categories()` for two
purposes:
1. Construct named classes
2. Create a list of all_super_categories, which is used to test for sub-
categories in the case of ''non-join'' categories.
Since in future many categories will be join-categories, only the first
point remains really relevant. And this means: We seek a notion of
`super_categories` in terms of named classes. That's where my suggestion
comes from.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:83>
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/groups/opt_out.
