Also, it looks like the SymPy version of Tuples (if I am correct in
what Sage's Tuples does) is buried in sympy.utilities.iterables:

In [1]: from sympy.utilities.iterables import variations

In [2]: time len(variations((E, pi, sqrt(2)), 3, repetition=True))
CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s
Wall time: 0.00 s
Out[3]: 27

In [4]: %timeit len(variations((E, pi, sqrt(2)), 3, repetition=True))
10000 loops, best of 3: 68.7 us per loop

In [5]: %timeit len(variations((1, 2, 3), 3, repetition=True))
10000 loops, best of 3: 57.8 us per loop

In [6]: %timeit len(variations((S(1), S(2), S(3)), 3,
repetition=True))
10000 loops, best of 3: 71.4 us per loop

I'm not sure if it is counted as implemented, as it is not imported
into the global namespace with "from sympy import *", but the code is
definitely there.  It looks like we don't suffer from the slow down of
Sage with non-integer objects.

Aaron Meurer

On Aug 17, 9:09 pm, "Aaron S. Meurer" <asmeu...@gmail.com> wrote:
> Hi.  You might look at SymPy's built in benchmarks (run ./bin/py.bench).
>
> As for factor, you might look at Mateusz's branch where he has the new  
> Polys module (http://github.com/mattpap/sympy-polys/commits/polys).
> I ran the test in his branch and got:
>
> In [1]: time factor(x**20 - pi**5*y**20)
> CPU times: user 0.23 s, sys: 0.00 s, total: 0.24 s
> Wall time: 0.27 s
> Out[2]:
>   ⎛   4      4⎞ ⎛   12  4    2  8  8    3  4  12    16    4  16⎞
> -⎝- x  + π⋅y ⎠⋅⎝π⋅x  ⋅y  + π ⋅x ⋅y  + π ⋅x  
> ⋅y   + x   + π ⋅y  ⎠
>
> So it is faster (considerably) than Sage, at least according that the  
> wiki you linked to.  This isn't in SymPy yet, but it hopefully will  
> make it to the git trunk soon.
>
> Also, you might look into using a tool like py.bench instead of naive  
> clock deltas.
>
> As for the best thing to use for a benchmark, I think it should be  
> something that takes long enough to run that it has a low margin of  
> error, but is able to finish in all systems that you try it in.  Also,  
> some tests will show you more of the speed differences of the  
> algorithm implemented (like probably the factor example), while others  
> will likely show you more the difference in what the engine is running  
> on (like Python vs. a C implementation).
>
> Aaron Meurer
> On Aug 17, 2009, at 4:15 PM, fijal wrote:
>
>
>
>
>
> > Hi.
>
> > I've been looking for some sympy benchmarks as a potential target for
> > pypy's jit. I've found this:http://wiki.sympy.org/wiki/Symbench
>
> > What's the reasonable small, yet telling something benchmark that
> > makes
> > sense? We're basically trying to collect some that are both simple and
> > yet
> > real-world enough. Any quick thoughts?
>
> > Cheers,
> > fijal
>
> > PS. I really like the fact that sympy is pure python, that makes it a
> > good
> > target.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com
To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sympy?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to