#11935: Make parent/element classes independent of base rings
----------------------------------------------------------------+-----------
Reporter: SimonKing |
Owner: nthiery
Type: enhancement |
Status: needs_work
Priority: major |
Milestone: sage-4.7.3
Component: categories |
Keywords: parent class, element class, category
Work_issues: Fix doctest in covariant functorial construction |
Upstream: N/A
Reviewer: |
Author: Simon King
Merged: |
Dependencies: #9138 #11900 #11943
----------------------------------------------------------------+-----------
Comment(by nthiery):
Hi Simon!
Replying to [comment:17 SimonKing]:
> So, I was overdoing it: With my patch, the parent class not only becomes
independent of a base ring, but also it becomes independent of the base
category of a covariant functorial construction - and this is not what we
want.
>
> The point is that CA and CM above have the same super categories, namely
`FooBars(Sets())`. But with my patch, parent classes are the same if both
the super categories and the `ParentMethods` are the same. The
`ParentMethods` are different for `Magmas()` and `AdditiveMagmas()`, but
they are the same for `FooBars(Magmas())` and `FooBars(AdditiveMagmas())`.
>
> I wonder how this should be solved.
>
> One possibility is that
sage.categories.covariant_functorial_constructions overrides the
parent_class and element_class lazy attributes that are defined in
sage.categories.category.
Ah ah, interesting challenge!
So, the question is whether we want to put in the specifications:
Constraint (C1): above any category in the category hierarchy, there
should be a one-to-one correspondence between categories and their
parent class. In particular, C.all_super_categories() and
C.parent_class.mro() should exactly match.
For C(...) a parametrized categories, let me call (O) the
optimization of having C(...).parent_class depend only on
C.ParentMethods and the parent class of the super categories of
C(...).
If we want (C1), then we indeed have to be careful with parametrized
categories. In particular, it seems to me (I haven't written a proof
though :-)) that optimization (O) can only be used for a parametrized
category C(...) if it is further guaranteed that:
Constraint (C2): no parent is simultaneously in two instances C(A)
and C(B) of C.
(C2) seems reasonable for a Category_over_base_ring (a parent should
have a unique distinguished base ring). Maybe it would make sense as
well for a Category_over_base. Your example above shows that we don't
want it in general, and in particular not for covariant constructions.
This calls for Category to not implement (O) by default, and
Category_over_base_ring to override parent_class and element_class to
implement (O).
Another option would be to drop (C1) altogether: it seems like a nice
optimization to reduce the number of classes in the mro whenever
possible (e.g. when categories do not provide ParentMethods). But then
we face an interesting poset/lattice problem, namely whether the C3
algorithm is (can be made) compatible with taking certain subposets.
This is quite related to the kind of optimizations I do in #10963, so
I'd love to have a brainstorm about that; but we'd better have it face
to face when you come over. In any cases, I vote for imposing (C1) in
this ticket, and think about removing this constraint, if at all
possible, in a later ticket. Both for not making this ticket even more
complicated and reducing conflicts with #10963.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11935#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.
