#11900: Serious regression caused by #9138
---------------------------+------------------------------------------------
Reporter: SimonKing | Owner: tbd
Type: defect | Status: needs_work
Priority: blocker | Milestone: sage-4.7.2
Component: performance | Keywords: categories regression
Work_issues: | Upstream: N/A
Reviewer: | Author: Simon King
Merged: | Dependencies: #9138
---------------------------+------------------------------------------------
Comment(by nthiery):
Replying to [comment:31 SimonKing]:
> Still, there is too much time spent on the initialisation of polynomial
rings. And the reason seems to be the construction of the parent class of
the categories.
>
> A polynomial ring over a finite prime field F belongs to the category of
Commutative Algebras of F (by #9138). In order to provide the ring with
the correct class (`PolynomialRing_dense_mod_p_with_category` in this
case), one needs to have the parent class of `CommutativeAlgebras(F)`. But
this involves to know the parent classes of F algebras, F vector spaces, F
bimodules, F left modules, F right modules, and rings.
>
> During the elliptic curve computation, F varies. Hence, all the base
classes need to be computed over and over again.
>
> I wonder whether it is possible to make the parent class of a category
''independent'' of the base (here: F) of the category. Then, one could
avoid the creation of about 5000 dynamic classes during the elliptic curve
computation. I guess that's a question to sage-combinat-devel.
>
> How might this work? Perhaps make the parent class of a category a class
attribute: `Algebras(F).parent_class` depends on `F`, but
`Algebras(F).__class__.parent_class` would be independent of F. Or perhaps
one should better introduce a central cache for the parent and element
classes, so that `Algebras(F).parent_class` is just a pointer to
`parent_class_cache[sage.categories.algebras.Algebras]`.
Actually that was the original intent; see the discussion around line 240
of category.py: two categories sharing the same inheritance diagram for
their parent class would actually share that parent class. The
implementation was simple: there was a cache on the dynamic class
creation. There are two issues though:
- How to pickle such a class: the only solution I found was to pickle it
as Algebras(F).parent_class; but this requires to store "Algebras(F)" as
part of the parent class, which prevents sharing. Better solutions
welcome!
- Even if the above is changed, this would still require the creation of
the categories Algebras(F) (and super categories) for all F, which could
take some time.
- I had had similar issues with the coercion system with MuPAD (the
factoring code was creating zillions of fields, which crowded the coercion
graph). So I already thought about modeling simultaneously a bunch of
parents/categories having the exact same properties as a single template
object (say in the coercion graph). But I did not come up with great
solutions yet.
- One needs to be a bit carefull, as the inheritance diagram may depend
on F. For example, Algebras(F).parent_class derives from
VectorSpaces(F).parent_class iff F is a field.
Once again, I am glad you are working on those category optimizations!
Altogether your proposals look very good. I am just unsure about short
circuiting "Category.join", but I would need to look more in
detail. Maybe we would need to add an abstraction layer in
between. Anyway go ahead with whatever works for fixing #11900, and if
we find something better, we can do it in a later patch.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11900#comment:32>
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.
