Luke wrote:
> 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.
>>>
>>
> >
>
>
Consider:
from sympy import *
t = Symbol('t')
x = Function('x')(t)
print x
y = cos(x)
dydx = diff(y,t)
print dydx
With output:
x(t)
-D(x(t), t)*sin(x(t))
I think what would be needed is a flag that would terminate application
of the chain rule at the appropriate point since for the chain rule to
work diff() must take the derivative of cos(x) with respect to x which
is the derivative with respect to a function. If the second argument of
diff() shows where to stop the process all would work out fine.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
