Hi.
On Sep 2, 2010, at 7:48 AM, Rahul Siddharthan wrote:
> Hello,
> I am trying to re-implement most of the code from "Structure and
> Interpretation of Classical Mechanics" (Sussman and Wisdom,
> http://mitpress.mit.edu/sicm) in sympy. The original language is
> their particular dialect of Scheme. I have had success with most of
> the first chapter, but with quite a few "kludges": I will mail the
> mailing list with details when the code is a bit cleaner.
This is great. SymPy code is *MUCH* easier to read than some lisp, in my
opinion.
> Currently, I find the following issue:
>
> theta = Function("theta")
> phi = Function("phi")
> psi = Function("psi")
> t = symbols("t")
> trigsimp(expand(diff(theta(t),
> t)*sin(phi(t))*sin(psi(t))*sin(theta(t)),True,True),True,True)
> (output)==> 0
> trigsimp(expand(diff(theta(t),
> t)*sin(phi(t))*sin(psi(t))*sin(theta(t)),True,True),True,False)
> (output)==> D(theta(t), t)*sin(phi(t))*sin(psi(t))*sin(theta(t))
>
> The second answer is correct, the first is wrong. Is there a problem
> with recursive evaluation when derivatives are present? I ran into
> this problem when trying to simplify the derivative of a matrix.
> Without "recursive", non-derivative expressions are rather
> inadequately simplified; with "recursive", expressions containing
> derivatives apparently return zero.
This is a bug that exists even in the git master. See issues 1938 and 1986 in
our Google Code issue tracker.
This same problem pops up from time to time with derivatives. Basically, if
you do diff(f(x), x).subs(f(x), t0) (say to make t0 a dummy symbol), then it
will become diff(t0, x), which evaluates to 0 (because as far as it knows, t0,
is constant with respect to x).
The actual problem here is in the cse() (common subexpression elimination)
function:
In [38]: cse(diff(theta(t), t)*sin(phi(t))*sin(psi(t))*sin(theta(t)))
Out[39]: ([(x₀, θ(t))], [0])
By the way, if you want to submit a patch to fix this, that would be great.
>
> A previous issue, while I am on the subject: "from sympy import *"
> clobbers the Python builtin "sum" function, so eg
> sum([1,2,3])
> doesn't work. Is that intended?
Yes, it is unfortunate that we override the builtin sum for our own symbolic
Sum. See http://code.google.com/p/sympy/issues/detail?id=1376. The easiest
workaround at the moment is to do
In [36]: from __builtin__ import sum as pysum
In [37]: pysum([1, 2, 3])
Out[37]: 6
>
> All this is on Sympy 0.6.6. (Ubuntu 10.04 package). Should I upgrade?
>
For the things you said here, they are the same, but maybe at some point.
There are a lot of other nice features, not so much in 0.6.7, but in our git
development branch that could be useful to you at some point. If you ever run
into another problem, it could be worth your time to pull in the latest git
master and see how it runs there. These will eventually be part of SymPy
0.7.0. See http://code.google.com/p/sympy/wiki/GettingTheBleedingEdge if you
don't know how to use git.
Aaron Meurer
> Thanks,
>
> 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.
