#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: |
--------------------------+-------------------------------------------------
Old description:
> Hom is currently implemented as a covariant functorial
> construction:
>
> {{{
> sage: Rings().hom_category()
> Category of hom sets in Category of rings
> sage: Rings().hom_category().super_categories()
> [Category of hom sets in Category of sets]
> }}}
>
> The intention was to model the fact that a morphism in a category is
> also a morphism in any super category, via the forgetful functor. With
> the example above, if A and B are rings, then a ring morphism phi:
> A->B is also a set morphism. However, at the level of parents, and as
> noted in the documentation of sage.category.HomCategory, this is
> mathematically plain wrong: if A and B are rings, then Hom(A,B) in the
> category of rings does not coincide with Hom(A,B) in the category of
> sets.
>
> I, Nicolas, take full blame for this misfeature; it was just the
> shortest route to implement some urgently needed features about
> morphisms, and still get that huge chunk of category code done.
>
> Here are some thoughts for a proper implementation:
>
> - Add support for a HomMethods subclass, similar to ElementMethods
> and ParentMethods. If Cat is a category, then Cat.ElementMethods
> will provide generic methods for morphisms in Cat and any
> subcategory. This will require to implement the building of a
> hierarchy of abstract classes Cat.method_class. And to either tweak
> sage.categories.morphism.Morphism to add inheritance from this
> class, as is done in Element and Parent, or to tweak the
> implementation of Homset.element_class so that, for H a homset in
> Cat, H.element_class would inherit from Cat.method_class besides
> the usual stuff (I guess I prefer the later option).
>
> - Reimplement HomCategory. For Cat a category, the purpose of
> Cat.hom_category() shall be to provide mathematical information
> about its homsets (e.g. that a homset in the category of vector
> spaces is also a vector space). It should ignore the super
> categories of C in general, except if is a full subcategory (a
> homset in the category of finite groups is also a homset in the
> category of groups).
>
> - If CatA is a subcategory of catB, add automatic coercion (or just
> conversion?) from Hom(A,B, CatA) to Hom(A, B, CatB), modeling the
> appropriate forgetful functor. There are too many such coercions
> for them to be registered explicitly. So this probably need to be
> implemented through a specific CatB._has_coerce_map_from(A) for
> homsets.
>
> Some extra work will probably be needed if one wants to handle
> mixed morphism arithmetic (e.g. having the sum of an algebra
> morphism and a coalgebra morphism return a vector space morphism).
New description:
Hom is currently implemented as a covariant functorial
construction:
{{{
sage: Rings().hom_category()
Category of hom sets in Category of rings
sage: Rings().hom_category().super_categories()
[Category of hom sets in Category of sets]
}}}
The intention was to model the fact that a morphism in a category is
also a morphism in any super category, via the forgetful functor. With
the example above, if A and B are rings, then a ring morphism phi:
A->B is also a set morphism. However, at the level of parents, and as
noted in the documentation of sage.category.HomCategory, this is
mathematically plain wrong: if A and B are rings, then Hom(A,B) in the
category of rings does not coincide with Hom(A,B) in the category of
sets.
I, Nicolas, take full blame for this misfeature; it was just the
shortest route to implement some urgently needed features about
morphisms, and still get that huge chunk of category code done.
Here are some thoughts for a proper implementation:
- Add support for a HomMethods subclass, similar to ElementMethods
and ParentMethods. If Cat is a category, then Cat.HomMethods
will provide generic methods for morphisms in Cat and any
subcategory. This will require to implement the building of a
hierarchy of abstract classes Cat.method_class. And to either tweak
sage.categories.morphism.Morphism to add inheritance from this
class, as is done in Element and Parent, or to tweak the
implementation of Homset.element_class so that, for H a homset in
Cat, H.element_class would inherit from Cat.method_class besides
the usual stuff (I guess I prefer the later option).
- Reimplement HomCategory. For Cat a category, the purpose of
Cat.hom_category() shall be to provide mathematical information
about its homsets (e.g. that a homset in the category of vector
spaces is also a vector space). It should ignore the super
categories of C in general, except if is a full subcategory (a
homset in the category of finite groups is also a homset in the
category of groups).
- If CatA is a subcategory of catB, add automatic coercion (or just
conversion?) from Hom(A,B, CatA) to Hom(A, B, CatB), modeling the
appropriate forgetful functor. There are too many such coercions
for them to be registered explicitly. So this probably need to be
implemented through a specific CatB._has_coerce_map_from(A) for
homsets.
Some extra work will probably be needed if one wants to handle
mixed morphism arithmetic (e.g. having the sum of an algebra
morphism and a coalgebra morphism return a vector space morphism).
--
Comment(by nthiery):
Replying to [comment:1 SimonKing]:
> Replying to [ticket:10668 nthiery]:
> > The intention was to model the fact that a morphism in a category is
> > also a morphism in any super category, via the forgetful functor. With
> > the example above, if A and B are rings, then a ring morphism phi:
> > A->B is also a set morphism. However, at the level of parents, and as
> > noted in the documentation of sage.category.HomCategory, this is
> > mathematically plain wrong: if A and B are rings, then Hom(A,B) in the
> > category of rings does not coincide with Hom(A,B) in the category of
> > sets.
>
> I don't see why this should be wrong: Any ring homomorphism is a set
homomorphism. Hence, `Hom_Rings()(A,B)` is a subset of `Hom_Sets()(A,B)`
-- nobody claims that they coincide.
Very short answer for now: here the question is whether Hom_Rings()(A,B)
is an object of Hom_Sets(). It's not. The point of
VectorSpaces().HomCategory() is to encode mathematical information about
the homsets, like the fact that Hom(A,B) is itself a vector space. We
don't want this information to be applied to a homset of a subcategory (a
homset in Algebras() being certainly not a vector space).
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10668#comment:2>
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.
