#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.2
Component: categories | Resolution:
Keywords: days54 | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King, Frédéric
Report Upstream: N/A | Chapoton
Branch: | Work issues:
public/ticket/10963-doc- | Commit:
distributive | c718f218fbc726bf3cf7f4c3f20638c9b0c7eea7
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by SimonKing):
Bad news: I just observed a regression in the creation of polynomial
rings.
With the current master, one has
{{{
sage: def test():
....: for p in prime_range(10000):
....: P = GF(p)['t','x','z']
....:
sage: %time test()
CPU times: user 4.95 s, sys: 0.09 s, total: 5.05 s
Wall time: 5.05 s
}}}
which is bad enough (it used to take half of the time two years ago).
With this ticket, one has
{{{
sage: def test():
....: for p in prime_range(10000):
....: P = GF(p)['t','x','z']
....:
sage: %time test()
CPU times: user 8.89 s, sys: 0.12 s, total: 9.01 s
Wall time: 9.02 s
}}}
`%prun` says:
{{{
13516 2.688 0.000 2.711 0.000
dynamic_class.py:324(dynamic_class_internal)
25801/11055 1.034 0.000 10.426 0.001 category.py:1920(join)
1229 0.725 0.001 17.076 0.014
polynomial_ring_constructor.py:569(_multi_variate)
4913/3685 0.673 0.000 5.067 0.001
category_with_axiom.py:2070(super_categories)
28256 0.597 0.000 2.898 0.000 category.py:1864(_sort_uniq)
140033 0.591 0.000 2.401 0.000 {any}
149908/137618 0.564 0.000 2.071 0.000
category.py:1371(is_subcategory)
14748 0.504 0.000 0.807 0.000
category.py:2756(_subcategory_hook_)
160943 0.439 0.000 1.353 0.000 category.py:1886(<genexpr>)
41768 0.421 0.000 0.515 0.000 {sorted}
175672 0.420 0.000 0.420 0.000 {isinstance}
30710 0.364 0.000 0.921 0.000
category.py:1806(_flatten_categories)
106875 0.355 0.000 0.557 0.000 category.py:1822(<genexpr>)
13511 0.354 0.000 4.731 0.000
category.py:436(__classcall__)
14741/6141 0.330 0.000 10.581 0.002
category.py:1601(_with_axiom_as_tuple)
83830 0.329 0.000 0.527 0.000
category.py:675(_subcategory_hook_)
50121 0.291 0.000 0.600 0.000
category_types.py:282(_subcategory_hook_)
140093 0.289 0.000 0.289 0.000 {issubclass}
27021/25791 0.224 0.000 0.608 0.000
category.py:2480(_make_named_class)
13510 0.205 0.000 3.420 0.000 category.py:467(__init__)
13510/6142 0.198 0.000 9.498 0.002
category.py:996(_super_categories)
11053 0.191 0.000 2.960 0.000
category_types.py:342(__init__)
11056/1229 0.185 0.000 10.547 0.009
category_with_axiom.py:1900(__classcall__)
}}}
The time for taking the join is clearly not acceptable.
I wonder if some trickery for a speed-up would be in order. After all,
when we want to create the join of category of algebras over B with
category of euclidean domains, and we already have the join of category of
algebras over A with category of euclidean domains, then we could cheaply
create a copy of the existing category and just replace the base.
Well, not quite, further attributes depend on the base. But perhaps some
recycling is possible.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:504>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
