#10963: Axioms and more functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.2
Component: categories | Resolution:
Keywords: days54 | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King, Frédéric
Report Upstream: N/A | Chapoton
Branch: | Work issues: merge with #15801
public/ticket/10963-doc- | once things stabilize
distributive | Commit:
Dependencies: #11224, #8327, | ce2193e9d6f179d2d51812c6af002697ccfbaa8c
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506, |
#15757, #15759, #15919 |
-------------------------------------+-------------------------------------
Comment (by pbruin):
Hello Nicolas,
> From the primer:
(More precisely, from a section of the primer introduced in ''this
ticket''...)
> {{{
> We have seen above that, for example, the category of groups is
> considered by Sage as a subcategory of the category of sets. For
> category purists, this is not quite correct: namely, a group is not a
> set; instead, one can recover the underlying set by forgetting the
> multiplicative structure. However, it would be impractical to have to
> explicitly forget the multiplicative structure whenever one wanted to
> apply on a group an operation defined on sets. In object oriented
> parlance, we really want the relation "a group *is a* set", so that
> groups can inherit code implemented on sets.
>
> Therefore, in Sage, as well as in most systems with a similar category
> framework, we use this slightly abusive definition of subcategory:
>
> A category ``Ds()`` is a *subcategory* of the category ``Cs()`` if, up
> to implicitly applying the appropriate forgetful functor, every object
> of ``Ds()`` is an object of ``Cs()``. Reciprocally, ``Cs()`` is in
> this case a *super category* of ``Ds()``.
> }}}
>
> This is the correct hierarchy relation that we want for organizing the
> code.
I do agree with the above motivation for having this hierarchy. Since
Darij raised this point in comment:617, I just wanted to state my
agreement with his opinion that it should not be called "subcategory". In
other words, this section of the primer would be a good justification for
the ''existence'' of this hierarchy, but it currently reads like an
attempt at justifying a design decision to ''name'' this the subcategory
relation, overriding existing mathematical terminology.
> This hierarchy relation has been called "subcategory" in Sage since
> 2007, following the other systems with a category mechanism (Axiom,
> MuPAD, ... and actually GAP as well).
Not out of disrespect for the terminology used by Sage and other computer
algebra systems, but the subcategory relation in the mathematical sense
has been called "subcategory" since the 1940s. I admit never having used
Axiom, MuPAD or GAP, but from browsing the documentation of those systems,
I get the impression that Sage is moving (or has already moved) far beyond
them. Hence, given the goal of creating a more flexible framework than
the type of relatively fixed hierarchy of those systems, of transparently
combining functorial constructions, building new categories dynamically
etc., I think it is exceedingly important to be extremely careful about
both the design and the terminology. Whenever some construction in Sage
conflicts (in name or content) with existing mathematical usage, one at
least has to take seriously the possibility that this will create subtle
and less subtle problems (if only confused users) in the long run.
> If you believe that the implicit
> application of the forgetful functor makes it abusive to call this
> "subcategory", or if you think we *also* want to model the "pure
> subcategories relation", we can debate the pros and cons. But this
> belongs to a separate new ticket.
Certainly, I do not want to say that something should be done about it
here and now.
For the moment, in the primer, would it perhaps be an option to just
''document'' that this relation is currently called "subcategory" in Sage
and not attempt to ''justify'' this terminology? (And maybe to consider
rewording the mention of "category purists"; not that I consider myself
one... 8-) )
Finally, let me stress that I greatly value the work done by you and other
people on this part of the infrastructure of Sage. Please view my
comments as evidence that this infrastructure is important enough to me to
spend some time and energy to discuss the issues involved in "getting it
right".
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:627>
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.
