#10667: Morphisms and Objects of Categories
---------------------------+------------------------------------------------
Reporter: SimonKing | Owner: nthiery
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-5.0
Component: categories | Keywords: objects morphisms containment
Work_issues: doctests | Upstream: N/A
Reviewer: | Author: Simon King
Merged: | Dependencies: #9138, #11115
---------------------------+------------------------------------------------
Comment(by SimonKing):
Replying to [comment:17 nthiery]:
> The only way to avoid such errors
> sanely is to specify general rules about the order of the base classes
> of a class.
I thought of that. But it could slow things down.
> Here, I would say that the rule is that category code (in particular
> what comes from a_category.parent_class) should always come after
> concrete classes.
It is not very much concrete. The real error reduces to what I have shown.
But in fact, the class Homset comes from
`sage.categories.objects.HomCategory.ParentMethods`. To be precise:
{{{
sage: from sage.structure.dynamic_class import dynamic_class
sage: C = Objects().hom_category()
sage: dynamic_class('bla', (C.parent_class,), C.ParentMethods)
}}}
And going further down, the above is caused by some lines in the
parent_class lazy attribute:
{{{
return dynamic_class("%s.parent_class"%self.__class__.__name__,
tuple(cat.parent_class for cat in
self.super_categories()),
self.ParentMethods,
reduction = (getattr, (self,
"parent_class")))
}}}
In my case, `cat.parent_class` is a sub-class of `self.ParentMethods`
(self being C above). Here is the relation with my patch:
{{{
sage: C = ChainComplexes(ZZ)
sage: HC = C.hom_category()
sage: HC.super_categories()
[Category of hom sets in Category of objects]
# it was [Category of sets] without my patch!
}}}
And finally, that comes from
{{{
sage: HC.base_category
Category of chain complexes over Integer Ring
# it used to be Category of objects without my patch
}}}
Since `[category.hom_category() for category in
self.base_category.super_categories()]` is part of the super categories,
the change of the base category was the ultimate cause of the error.
However, I wouldn't like to change the base_category. After all, the
base_category is the category to which the homsets belong. Here, the
homsets belong to the category of chain complexes over Integer Ring. Thus,
"category of objects" is plainly wrong.
So, for now, I see two ways to fix it:
1. Change `HomCategory.super_categories`. It should only return
`self.extra_super_categories() + Sets()` (after all, homsets are sets),
but not `[category.hom_category() for category in
self.base_category.super_categories()]`.
2. Change `parent_class`, so that not all of `tuple(cat.parent_class for
cat in self.super_categories())` is included, but only the bits that are
no sub-classes of `self.ParentMethods`.
Is it really mathematically correct that the hom-category of a category C
is a subcategory of the hom-category of any super-category of C?
For example, if C is the category of unital K-algebras (K some field) then
C is a subcategory of the category of K-vectorspaces. The homsets of
K-vectorspaces are K-vectorspaces. But the homsets of unital K-algebras do
not form K-vectorspaces, isn't it?
At least, computationally, option 1 is faster than option 2. And when you
confirm that option 2 (which is the status quo!) is actually
mathematically wrong then it is clear what I will do.
> By the way: congrats on all your category optimization work. I love it!
Thank you!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10667#comment:18>
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.
