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. :) > > 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.
