#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:9 nthiery]:
> > 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.
>
> And that's a second misunderstanding: this mechanism already exists,
> and I am not planning to remove it (though the syntax might change a
> tiny bit; we probably don't need the extra_super_categories thingy,
> and just use super_categories.
What mechanism do you mean? I am of course aware of the
`extra_super_category` method - but
`sage.categories.category.HomCategory.extra_super_category()` returns
`[]`, and `sage.categories.category.HomCategory.super_categories()`
returns stuff that we don't want (namely `C.hom_category()` for all `C` in
`self.base_category.super_categories()`).
Of course, it would suffice to make
`VectorSpaces(QQ).hom_category().extra_super_categories()` return
`[VectorSpaces(QQ)]`. But this would currently require to introduce a
custom `HomCategory` class for `VectorSpaces` that overrides the method of
the `HomCategory` base class. This is not nice and should be simplified.
What I plan is: Remove inheritance of the hom-categories of the super-
categories of the base-category from
`sage.categories.category.HomCategory.super_categories()`; it should
basically return `self.extra_super_categories()+[Sets()]`. Moreover,
define `sage.categories.category.HomCategory.extra_super_categories()`
like this:
{{{
def extra_super_categories(self):
try:
return [self.base_category.hom_structure]
except AttributeError:
return []
}}}
Then, in the init-method of the category of vector spaces, one would
simply add the line
{{{
self.hom_structure = self
}}}
Similarly (I hope that I am not confusing things now), one would add the
line
{{{
self.hom_structure = LeftModules(self.base_ring())
}}}
to the init method of ''right'' modules; and `self.hom_structure =
RightModules(self.base_ring())` for left modules, and so on. That seems
easier than defining a whole class `HomCategory` for `LeftModules`.
> What do you think of using the occasion to rename Cat.hom_category()
> into Cat.Homsets(), for consistency with Cat.Quotients() and the like?
Personally, I don't like uppercase method names, and I remember that it is
officially recommended to avoid capital letters in Python method or
function or module names, whereas upper case is recommended to use for
classes (but I do not remember where I was reading that recommendation).
Best regards,
Simon
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10668#comment:10>
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.
