On May 4, 2010, at 4:45 PM, Bastian Weber wrote: > Aaron S. Meurer wrote: >> You might want to look at the compare_ode_sol() (and the key >> equivalent rewrite I have at >> http://github.com/asmeurer/sympy/commit/2c5167990473ca4079f334214ffe0c898b18cbda). >> It is specifically for solutions given from dsolve(), but the >> heuristic involves seeing if the expression contains unevaluated >> Integral's, is or isn't solved for f(x), and finally, the length of >> str(expr). >> >> len(str(expr)) is probably the simplest way to check this. I never >> considered looking at the depth of the expression, though. >> > > Currently I have just basic arithmetics, so I guess the heuristic would > reduce to len(str(expr)). That came to my mind earlier but I tried to > avoid that because computing str(expr) seems to be rather costly. My > experience is: printing the str representation of large expressions > (such as determinants) takes much more time than calculating them. > > Just a (non representative) example: Computing that an expression has > "depth" 23 take less than a second. But computing str(expr) took too > long for my patience. (i.e. more than about 30 seconds) > > > For curiosity I did the following: > > I used the function: > > > def count_branches(ex): > if ex.is_Atom: > return 1 > > else: > return sum(map(count_branches, ex.args)) > > > to compute how many lowest level branches the tree has. > Result for my expression is 157130. (!) > > The expression has many Rational-instances as atoms, so the average > stringlength of an atom in my case is 20. This means more than 2 MB of > str representation. When I relate this to the computation time of str(.) > of moderate expressions I get the feeling that this will take very long.
So the problem is large rational coefficients. You might want to try setting the environment variable SYMPY_GROUND_TYPES=gmpy (you will need to install gmpy). Assuming you are working in master with the new polys, this should make things faster, especially if you are using Poly()'s. ZZ.dtype will tell you the ground type. Integer is SymPy (slowest), int is Python (next slowest), and mpz is gmpy (the fastest). > > > > >> By the way, you can probably make that operation faster first, by >> using the Poly class, and second, by somehow making det() do >> intermediate simplifications (things should actually already be >> better in this respect with the new polys). > > Using the Poly class is a very good hint! In my first test speedup is > very notable. > > But I really think intermediate simplifications are the key. > Unfortunately I have no idea how to do that. You also might try the non-default determinant method, i.e. det(method="berkowitz"). Actually, for me that method returns less simple results (more factored) than the default one, but you might do it anyway just to see what you get. Aaron Meurer > > But it is not that important at the moment. > > I will concentrate on how I can avoid the complexity from the beginning. > > > Regards, > Bastian > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sy...@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 sy...@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.
