On Sep 4, 2010, at 11:02 AM, Aaron S. Meurer wrote: > On Sep 3, 2010, at 7:21 PM, Rahul Siddharthan wrote: > >>>> The other issue that came up is, I see from the archives, again a >>>> known problem: if I want to define multiplication for "tuples", a >>>> multiplication of a tuple by a scalar (on the left or the right) is >>>> the tuple of each component multiplied by the scalar. I define the >>>> __mul__ and __rmul__ methods, but __rmul__ fails to get called when >>>> the scalar is a sympy object, because scalar defines a __mul__ that >>>> can handle other sympy objects >> >>> In the current master branch you can use the _op_priority class >>> attribute to make sure your own __mul__() overrides the default. >> >> Thanks. Since I don't want to install the master branch on all the >> student computers, I will hold off on this solution, but will >> implement it in the future. >> >> I see that there is active discussion on the trigsimp/cse problem with >> derivatives, so maybe, in the near future, all these problems would be >> fixed in a "released" version of sympy! That would be very nice. > > Well, the easiest way to have it fixed in the next release is if you send in > a patch to fix it. :)
I just realized that the DummyFunction solution is not necessary to fix this (though having it would still be nice :). Rather, the problem is this: In [9]: diff(f(x), x).subs(f(x), y) Out[9]: 0 This should return Derivative(y, x), which remains unevaluated just fine: In [7]: Derivative(y, x) Out[7]: d ──(y) dx See http://code.google.com/p/sympy/issues/detail?id=2049 I am pretty sure that fixing that issue will fix the cse() and hence the trigsimp() issue. Aaron Meurer > >> >> One more question: what is the recommended procedure for simplifying >> algebraic/trigonometric objects? Is there any function / any setting >> for "simplify" that would automatically get the "simplest" form of an >> expression, by some metric? Or should I advise users to call their >> own simplification routine themselves, according to "taste" and their >> current problem? > > There has been some talk about putting some metric analysis in simplify() > (basically .count_ops()), but it isn't implemented yet, even in the git > master. > > But as it says in the simplify() docstring, you will be *much* better off > learning how the individual simplification functions work, and then applying > the ones that you need for a particular task. Actually, simplification is > one of the things that is much improved in the latest development trunk, > because we recently upgraded to a new Polynomials manipulation module, which > lets us treat arbitrary expressions as polynomial generators (previously only > symbols were allowed). It's also much faster. > > Aaron Meurer > >> >> By sometime next week I will make public an early version of my code, >> which would have basically all of the first two chapters of SICM (the >> "Lagrangian" part), and enough "infrastructure" that implementing the >> rest should be much quicker. >> >> Rahul -- 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.
