Regarding "dependencies" of hints, I don't think it's possible. Consider for example
cos(x*(y + 1))*(z + 1) expanded with the trig and mul hints. On the one hand, you need to apply the mul hint first to expand the x*(y + 1) to x*y + x. Otherwise, the trig hint will not expand the cosine of a sum. On the other hand, if you apply mul before trig, then when you expand, you'll get (-sin(x)*sin(x*y) + cos(x)*cos(x*y))*z + -sin(x)*sin(x*y) + cos(x)*cos(x*y). This can be carried out to arbitrary depth, and using almost any of the hints. In master, expand(cos(x*(y + 1))*(z + 1), trig=True) gives the fully expanded form -z*sin(x)*sin(x*y) + z*cos(x)*cos(x*y) - sin(x)*sin(x*y) + cos(x)*cos(x*y) In my branch, it will give z*(-sin(x)*sin(x*y) + cos(x)*cos(x*y)) - sin(x)*sin(x*y) + cos(x)*cos(x*y) (this depends on the order of the hints, of course, which currently depends on hash randomization, but that's the idea). So that's the price to pay. In my branch, hints are applied exactly once, in whatever order they are applied in (I'm not planning on messing with that for now). In master, they are recursively applied several times. The result is that in my branch, things should be faster, but you may have to call expand() multiple times to get a fully expanded expression if it happens to require multiple passes to do so. On my computer, in my branch, test_expand takes 0.12 seconds, in master, it takes 0.79 seconds, mostly due to the infamous slow test_3022 (I tested on Python 2.5 to keep hash randomization out of the picture). Aaron Meurer On Mon, Jul 16, 2012 at 9:26 PM, Aaron Meurer <[email protected]> wrote: > I've gone ahead and removed it in my forthcoming branch for now. With > the changes I've made so far, the issue from 3022, > S("-I*exp(-3*I*pi/4)/(4*pi**(3/2)*sqrt(t))").expand(complex=True), > doesn't give a recursion error. > > Aaron Meurer > > On Mon, Jul 16, 2012 at 8:15 PM, Chris Smith <[email protected]> wrote: >> On Mon, Jul 16, 2012 at 9:03 PM, Aaron Meurer <[email protected]> wrote: >>> Chris, can you explain what's going on in Add._eval_expand_mul? This >>> is breaking the pattern of all the other do-nothing _eval_expand >>> functions, and I don't understand what it's supposed to be doing. Is >>> this a hack, or do you think all such noop functions should be written >>> this way? >>> >>> The relevant commit is 6b892e98. >>> >> Perhaps I can check on this in the next day or two. >> >> /c >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" 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/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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
