#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 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.
That is not a vague though that popped up when I created this ticket,
but a concrete feature that we have been longing for years and we
could not implement in MuPAD (MuPAD categories did not handle
morphisms) despite our many use cases.
> I really think the `Cat.hom_structure` formalism that I suggested
> would be easier.
And I think mine is no more complicated, while being more consistent
with the rest of the framework :-)
It seems like most of the discussion comes from confusion and
vagueness (and I take my share of the blame for that). 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.
> In particular, there is no need to provide `Cat.HomMethods` or
> `Cat.MorphismMethods`. In fact, they are redundant: If you simply
> state that `Cat.hom_structure` is `VectorSpaces(QQ)`, then the
> morphisms already have the element methods of vector spaces, whereas
> in your approach you needed to restate (copy-and-paste) them as
> `Cat.MorphismMethods`.
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.
Cheers,
Nicolas
PS: by the way, I am wondering if we should be using Cat.objects() or
Cat.Objects() (given that we already have Cat.Quotients(),
Cat.Subobjects(), Cat.CartesianProducts(), ...). Here, I am thinking
about using the occasion to replace Cat.hom_category() by Cat.Homsets().
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10668#comment:7>
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.
