#10668: Refactor category support for morphisms (Hom is not a functorial
construction!)
--------------------------+-------------------------------------------------
Reporter: nthiery | Owner: nthiery
Type: defect | Status: new
Priority: major | Milestone:
Component: categories | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
--------------------------+-------------------------------------------------
Comment(by SimonKing):
Replying to [comment:7 nthiery]:
> Replying to [comment:6 SimonKing]:
> > Not in a sub-category! Namely, if `Cat` is the category of
> > F-vectorspaces, then `Cat.MorphismMethods` would include addition
> > and skalar multiplication. But for a sub-category of `Cat`, such as
> > F-algebras, we don't want that, as you had pointed out.
>
> Of course addition should not be put in MorphismMethods. On the other
> hand, there are a lot of generic operations on morphisms that pass
> down to subcategories, like inverting a morphism (say in the category
> of finite sets) or computing the matrix/the rank/the det/you_name_it
> of a morphism of finite dimensional vector space. It is essential to
> pass those generic methods down to subcategories.
I see. Yes, for those kind of methods, your approach makes very much
sense.
But what would actually prevent us from doing ''both''? Our two approaches
are good for different things, and they are orthogonal to each other. If I
understand correctly, you suggest that there should be
`Cat.morphism_class` from which morphisms inherit, analogous to
`Cat.element_class`, thereby getting "hereditary" (to sub-categories)
methods. I suggest that `Cat` should have an attribute that allows
`Cat.hom_category()` to assign the correct category to the homset category
(hence, `Cat.hom_category().is_subcategory(Cat.hom_structure)`), so that
homomorphism would inherit from `Cat.hom_structure.element_class` (by the
existing framework - hence, my suggestion is indeed very consistent with
with the existing framework :-).
Is there any reason to not have a double inheritance from
`Cat.morphism_class` and `Cat.hom_structure.element_class`
(`Cat.hom_structure` being a category)?
> So let's both
> write a little prototype to have a concrete ground to discuss on. We
> don't have to include the coercion / push_out part in this prototype
> since we agree on it. I can try to implement mine sometime next week.
OK.
> Cat.HomCategory() will still use the standard super_categories()
> approach to state that it is a subcategory of VectorSpaces(), and its
> elements will inherit from VectorSpaces().element_class.
OK, this is what I suggested above: One needs to introduce a standard
mechanism to declare the category which `Cat.hom_category()` is sub-
category of.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10668#comment:8>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
