#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 [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.
> 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.
You mean "Cat.HomMethods will provide...", I guess.
> - 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).
The approach with `HomMethods` would provide methods defined for homsets,
whereas the fact that a homset of vector spaces is a vector space has
implications for the methods of ''elements'' of the homsets (i.e., for
methods of morphisms).
I don't know whether we need special methods for homset, but of course it
would be nice to have homsets that are vector spaces.
What about the following approach:
* There is the base class `sage.categories.category.HomCategory`. I
suggest to provide it with an optional argument `hom_structure`. Define,
for example, `H =
HomCategory(Algebras(QQ),hom_structure=VectorSpaces(QQ))`. Then, `H` is
the category of homsets in the category of algebras over `QQ`, and each
homset would automatically be a vector space over `QQ`. Moreover, `H`
would be a sub-category of `VectorSpaces(QQ)`.
* I suggest to introduce a lazy attribute `C.hom_structure`, that
defaults to `C.HomStructure` if that exists, and otherwise returns the
join of `S.hom_structure` for all `S in C.super_categories()`. Then,
`C.hom_category()` defaults to `HomCategory(C,
hom_structure=C.hom_structure)`.
* Of course, any category can define a custom `HomStructure` (e.g., in
the `__init__` method of `VectorSpaces(R)`, we would define
`self.HomStructure=self`, ensuring that `self.hom_structure` is the right
thing). In order to avoid an infinite recursion of the lazy attribute, we
also need to define `Objects().HomStructure=Objects()`.
> - 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.
That would be a good candidate for your `HomMethods`, don't you think?
> 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).
I guess that would be an extension of the `sage.categories.pushout`
formalism.
Anyway, my suggestion is to start with the `hom_structure` approach, as it
seems to be relatively straight forward to implement.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10668#comment:1>
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.
