#19218: Restrict skew partition input to Schur basis and implement a skew Schur
method
-------------------------------------+-------------------------------------
Reporter: tscrim | Owner: sage-combinat
Type: defect | Status: needs_review
Priority: major | Milestone: sage-6.9
Component: combinatorics | Resolution:
Keywords: schur, symmetric | Merged in:
functions | Reviewers:
Authors: Travis Scrimshaw | Work issues:
Report Upstream: N/A | Commit:
Branch: | fee5688edd81a3e3d185c509f32455607fad31fb
public/combinat/skew_schur-19218 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Changes (by tscrim):
* status: new => needs_review
* commit: => fee5688edd81a3e3d185c509f32455607fad31fb
* branch: => public/combinat/skew_schur-19218
Comment:
While I was at it, there were a couple of other things I tweaked. Most of
these were done because of my initial changes broke something else small.
(I was able to clean up a little bit of Sage's import hell.)
I simplified the `_element_constructor_` for the bases in order to get the
error message I want and those two cases are both handled by `R(x)` and in
cython:
{{{
sage: s = SymmetricFunctions(QQ).s()
sage: %timeit s(5)
The slowest run took 86.46 times longer than the fastest. This could mean
that an intermediate result is being cached
100000 loops, best of 3: 2.95 µs per loop
sage: %timeit s(5/2)
The slowest run took 21.65 times longer than the fastest. This could mean
that an intermediate result is being cached
100000 loops, best of 3: 3.15 µs per loop
}}}
versus previously
{{{
sage: %timeit s(5)
The slowest run took 248.01 times longer than the fastest. This could mean
that an intermediate result is being cached
100000 loops, best of 3: 3.04 µs per loop
sage: %timeit s(5/2)
The slowest run took 20.99 times longer than the fastest. This could mean
that an intermediate result is being cached
100000 loops, best of 3: 3.19 µs per loop
}}}
So a marginal speed gain, but still a gain of ~2% (and much more simple
code structure).
Additionally I made a few changes of `Partition(x)` to `_Partitions(x)`
because it is slightly faster, which matters in these tight loops:
{{{
sage: from sage.combinat.partition import _Partitions
sage: %timeit Partition([7,5,5,3,2,1,1])
The slowest run took 203.43 times longer than the fastest. This could mean
that an intermediate result is being cached
100000 loops, best of 3: 13.9 µs per loop
sage: %timeit _Partitions([7,5,5,3,2,1,1])
The slowest run took 11.24 times longer than the fastest. This could mean
that an intermediate result is being cached
100000 loops, best of 3: 13.3 µs per loop
sage: %timeit _Partitions([7,5,5,3,2,1,1,0,0])
The slowest run took 5.16 times longer than the fastest. This could mean
that an intermediate result is being cached
100000 loops, best of 3: 15.9 µs per loop
sage: %timeit Partition([7,5,5,3,2,1,1,0,0])
The slowest run took 4.42 times longer than the fastest. This could mean
that an intermediate result is being cached
10000 loops, best of 3: 16.7 µs per loop
}}}
We should probably make this change in the rest of the code in other parts
of combinat, especially the SF code as this is usually called frequently.
----
New commits:
||[http://git.sagemath.org/sage.git/commit/?id=fee5688edd81a3e3d185c509f32455607fad31fb
fee5688]||{{{Fixing skew Schur functions and some other misc tweaks.}}}||
--
Ticket URL: <http://trac.sagemath.org/ticket/19218#comment:1>
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/d/optout.
