#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 SimonKing):
Hi Nicolas,
Replying to [comment:18 nthiery]:
> 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.
That would indeed be a possibility. My first reaction was "The problem
arose in covariant functorial construction, thus, use (O) by default, but
let covariant functorial constructions override it with the non-optimised
approach".
But after all, the subject of this ticket is "Make parent/element classes
independent of base rings". So, your suggestion fits 100% into the scope
of this ticket.
However, it is not all that easy. For example, by #9138, the category of a
univariate polynomial ring is a ''JOIN'' of a category with base (namely
commutative algebras) and a base free category (Euclidean domains or so).
The join category has a `base()` method, due to one of the patches at
#11900, but it does not inherit from
`sage.categories.category_types.Category_over_base`.
In other words:
If we use optimisation (O) ''only'' on
`sage.categories.category_types.Category_over_base` then we would not see
any speedup in elliptic curve computations.
Here are a few scenarios:
1. Use (O) by default, but do not use it on covariant functorial
constructions. The question is whether this is consistent.
1. Do not use (O) by default, but use it on `Category_over_base`.
Problem: We would not see a speed-up.
1. Do not use (O) by default, but use it on every category that has a
`base` method. That includes `Category_over_base`, but also (by #11900)
''any'' category that is sub-category of a category with base.
The problem with the third approach is: Testing whether the category is
sub-category of a category with base is expensive. Thus, it is possible
that the regression (due to this test) is bigger than the speed-up
obtained from optimisation (O).
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11935#comment:19>
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.
