#13762: Implement k-bounded quotient space
---------------------------------------------------+------------------------
Reporter: chrisjamesberg | Owner:
chrisjamesberg
Type: enhancement | Status: closed
Priority: major | Milestone: sage-5.6
Component: combinatorics | Resolution: fixed
Keywords: symmetric functions, partitions | Work issues:
Report Upstream: N/A | Reviewers: Anne
Schilling
Authors: Chris Berg, Mike Zabrocki | Merged in:
sage-5.6.beta2
Dependencies: | Stopgaps:
---------------------------------------------------+------------------------
Comment (by jdemeyer):
Please read some comments from #12313, which apply to this code:
(tl;dr: your code is badly written and #12313 will make it much slower)
> Had a quick look. To simplify and speed up the tests a little bit, you
can concentrate on one of the tests that's slow:
> {{{
> sage: cmd='dks4._test_associativity()'
> sage: import cProfile,pstats
> sage: s=pstats.Stats(cProfile.Profile().runctx(cmd,globals(),{}))
> sage: S=s.sort_stats('cumulative')
> sage: S.print_stats()
> ...
> sage: S.print_callers()
> ...
> }}}
> the latter one essentially gives you the call graph, weighted by time
contributed.
>
> In fact it shows you pretty quickly that !ShurFunctions were apparently
VERY heavily relying on parents being cached:
> {{{
> X=dks4[0]+ 2*dks4[1] + 3*dks4[2]
> (X*X)*X #wait quite a long time
> }}}
> This mainly uses `dks4.product` and you can follow the code from there
to see this has not been written with runtime optimization in mind.
Probably if you make some things cached the way there, you'll regain the
original performance.
>
> My first impression is that this code indeed will make a concrete
realization of some structure, perform the operation, and throw away the
concrete realization. Elements on the way basically ARE homs, hence all
the homsets.
> I think the normal behaviour of a CAS should be that a structure S is
considered garbage and can be collected, unless the user has constructed
some object O and keeps a reference to it, and O keeps a chain of
references to S. Sadly, that was not the case for Sage, but this ticket is
part of an attempt to make Sage behave "normally" in that department.
>
> Hence, if the same structure is needed repeatedly during a computation,
then the programmer should keep a reference to it locally, rather than
relying on an external cache. And if different methods of an object O will
use the same structure S, then it makes sense to store S as an attribute
of O, in order to prevent S from being garbage collected as long as O is
alive (but not longer than that).
>
> I think what Nils wanted to say is: If other parts of the Sage library
do not obey the general rules formulated in the preceding paragraph, but
rely on an infinite external cache, then they need to be fixed. But the
need to fix them should not prevent us from changing the infinite external
cache to a finite external cache, because that is of benefit for all parts
in the Sage library that follow the general rules.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13762#comment:30>
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.
