Alan,
I brought this issue up a while back and submitted a patch that
fixed the same issue in solve. I haven't gotten around to writing the
same piece of code for diff, but this is on my to do list for the same
reasons as yours. I think the fundamental issue is that Symbols are
treated as constants when it comes to differentiation, so we have to
use Function if we want things like the chain rule to work. The
issue, however, is that this use of Function is distinct from the more
typical use of function: creating user defined symbolic functions
(e.g., the sin and cos functions), by subclassing Function, where all
the behavior is known with certainty. This is very distinct from the
case of generalized coordinates, which are functions of time (or some
other scalar parameter), but typically don't have an analytic
representation, since they often arise from ODE's without analytic
solutions.
I have been playing around with how to subclass Function or Symbol in
a way that would give the behavior that would be desired for a
generalized coordinate. The argument for subclassing from Symbol
would be to ensure all the things you can do with Symbols could be
done with generalized coordinates, which I could see being a lot of
things. There are many things that one would like to to be able to do
with generalized coordinates that can't (currently) be done on sympy
Function objects (diff is one example) A few things on my list would
be:
1) Customized printing so that the '(t)' isn't displayed after each
one.
2) Differentiation w.r.t the independent variable (often Symbol('t'))
would return another type: perhaps a Generalized Speed, rather than a
Derivative object. This generalized speed would also be subclassed
from Symbol, so that all the same manipulations could be performed on
it.
Here is one issue that I don't really know how to handle:
In [24]: t = Symbol('t')
In [25]: x = Function('x')(t)
In [26]: x
Out[26]: x(t)
In [27]: type(x)
Out[27]: x
In [28]: y = Function('y')(t)
In [29]: y
Out[29]: y(t)
In [30]: type(y)
Out[30]: y
Note that they type of x and y are both different. What I'm
envisioning is something with the following behavior:
In [1]: x = GeneralizedCoordinate('x')
In [2]: type(x)
Out[2]: GeneralizedCoordinate
In [3]: xp = x.dt()
In [4]: print xp
Out[4]: x'
In [5]: type(xp)
Out[5]: GeneralizedSpeed
We could also take this one step further and create a
GeneralizedAcceleration. The main goal is to avoid having to do the
annoying substitutions back and forth as you mentioned.
What other behavior do you think this class should have, and do you
think we can do it by subclassing from Symbol, rather than Function?
That to me seems the most logical, we just need to ensure we can make
the chain rule work, so this behavior is preserved:
In[1]: sin(x).diff(t)
Out[2]: x'*cos(x)
~Luke
On Jun 28, 8:53 am, "Aaron S. Meurer" <[email protected]> wrote:
> The routines in solve() for solving for a function or a derivative
> could probably be adapted to diff (and others?) pretty easily. See
> commit 5e5a333da78a3af743e5dc5f0130448aaea7c85a.
>
> Aaron Meurer
> On Jun 28, 2009, at 7:11 AM, Alan Bromborsky wrote:
>
>
>
> > I tried this:
>
> > from sympy import *
>
> > x = Symbol('x')
> > print x
> > f = Function('f')(x)
> > print f
> > y = cos(x)
> > dydx = diff(y,x)
> > print dydx
> > y = cos(f)
> > dfdx = diff(y,f)
> > print dfdx
>
> > and got:
>
> > x
> > f(x)
> > -sin(x)
> > Traceback (most recent call last):
> > File "/home/brombo/diff.py", line 11, in <module>
> > dfdx = diff(y,f)
> > File
> > "/usr/local/lib/python2.6/dist-packages/sympy-0.6.5_beta2_git-
> > py2.6.egg/sympy/core/multidimensional.py",
> > line 127, in wrapper
> > return f(*args, **kwargs)
> > File
> > "/usr/local/lib/python2.6/dist-packages/sympy-0.6.5_beta2_git-
> > py2.6.egg/sympy/core/function.py",
> > line 708, in diff
> > return Derivative(f,x,times, **{'evaluate':evaluate})
> > File
> > "/usr/local/lib/python2.6/dist-packages/sympy-0.6.5_beta2_git-
> > py2.6.egg/sympy/core/function.py",
> > line 486, in __new__
> > raise ValueError('Invalid literal: %s is not a valid variable' % s)
> > ValueError: Invalid literal: f(x) is not a valid variable
>
> > There was a discussion about this topic a while back. Is anything
> > being
> > done about it? Is the only current workaround to substitue a dummy
> > variable for 'f', differentiate, and substitute 'f' for the dummy
> > variable? I too wish to work with Lagragians and generalized
> > coordinates.
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
