#11943: The category graph should comply with Python's method resolution order
---------------------------+------------------------------------------------
Reporter: SimonKing | Owner: nthiery
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.8
Component: categories | Keywords: category graph, method resolution
order
Work_issues: | Upstream: N/A
Reviewer: | Author: Simon King
Merged: | Dependencies: #11900
---------------------------+------------------------------------------------
Comment(by SimonKing):
Replying to [comment:21 mderickx]:
> Where can I find the specific elliptic curve code you mention?
I was referring to the things that were discussed on #11900. That ticket
is about a serious speed regression in elliptic curves caused by #9138.
And analysing it, using prun and so on, it turned out that really a lot of
time has been spent on computing the list of all super categories. The
problem is that caching the list of super categories does not really help,
since one has many different categories (of algebras, for example) over
different base fields.
But now that you mention it: It could be that the remark in the code above
{{{
# In elliptic curves, one often has categories over different base
rings.
# Thus, as a short-path, we compare the base rings first, before
we try
# to compute the set of all super-categories.
}}}
is misleading.
The code is supposed to recognise very quickly that a category with base
is not contained in a category with a different base. I am afraid I can
not show you the original example that made me suggest this bit of code.
However, here are some examples showing that it helps.
With the base test (each example being in a new session):
{{{
sage: L = [GF(p)['x','y'] for p in prime_range(5000)]
sage: C = CommutativeRings()
# here the test is not used - this is to show that there is almost no
regression
sage: %time [X in C for X in L]
CPU times: user 0.29 s, sys: 0.00 s, total: 0.29 s
Wall time: 0.29 s
}}}
{{{
sage: L = [GF(p)['x','y'] for p in prime_range(5000)]
sage: D = Modules(ZZ)
sage: %time [X in D for X in L]
CPU times: user 0.06 s, sys: 0.00 s, total: 0.06 s
Wall time: 0.06 s
}}}
With the base test commented out:
{{{
sage: L = [GF(p)['x','y'] for p in prime_range(5000)]
sage: C = CommutativeRings()
sage: %time [X in C for X in L]
CPU times: user 0.26 s, sys: 0.00 s, total: 0.26 s
Wall time: 0.27 s
}}}
{{{
sage: L = [GF(p)['x','y'] for p in prime_range(5000)]
sage: D = Modules(ZZ)
sage: %time [X in D for X in L]
CPU times: user 0.28 s, sys: 0.00 s, total: 0.28 s
Wall time: 0.28 s
}}}
So, if base rings are involved then the test is much faster, and if no
base rings are involved, the test is not much slower.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11943#comment:22>
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.
