On 20.04.2012 20:31, Aaron Meurer wrote:
On Fri, Apr 20, 2012 at 1:22 PM, Tom Bachmann<e_mc...@web.de> wrote:
Sure. But I think (possibly contrary to what I said earlier), staircase
really isn't the problem. If the result is huge then the next parts
(calling
reduced(), solving the linear system) are going to take ages as well.
Maybe we should run kernprof on it to see what function calls are
really taking up the most time.
I'm using mprofile. But it's not all that easy to decipher where the problem
is (even from a nice graph *g*), or if there even is a real problem (an
algorithm that suffers combinatorial explosion simply is not going to work
with large expressions...).
What is mprofile? I didn't find it by Googling.
I'm sorry ^^. It's cProfile. (I run it via python -m cProfile ... got
the letters mixed up in my head).
I think it's useful. This will tell us which algorithms we need to
focus on optimizing. Even if the algorithm itself can't really be
improved, there are likely a lot of little things we can do to make
things faster. For example, something as simple as rewriting a
recursive function non-recursively can make a huge difference
(especially if it's one in the core of the polys). I've also found
quite often that the problem lies in some trivial inefficiency because
someone coded up a simple algorithm in a naive way.
Absolutely. I'll see what I can find out.
Aaron Meurer
--
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.
--
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.
