I'm trying to better understand how Sympy is structured with regard to
Function and Symbol.
In most problems I have encountered with ODE's (and PDE's, but I'll
limit my discussion to ODE's) of the form:
dx/dt = f(x, t) x \in R^n, f: R^n x R ---> R^n
there simply is no closed form solution for x(t). So if you somehow
know f(x) and can hard code it, Symbol works fine as the data type for
each x_i (i = 1,....n). This allows you to take partial derivatives
of f, linearize the system, study stability, etc...
The problem I am faced with is in the analytic derivation of f(x, t),
as it arises from Newtonian dynamics. For simple problems, f(x, t)
can be done by determined by 'hand'. For more complicated systems,
this becomes cumbersome and intractable.
Typically, the problem starts out with defining the orientations and
positions of all masses and rigid bodies. Next, velocities with
respect some inertial frame need to be formed, so time derivatives of
very complicated expressions are necessary. In these expressions are
long trig expressions involving the x_i's which generally represent a
position or an angle (generalized coordinates). And this is where my
problem lies: if the x_i's are implemented as Symbol, then diff(x, t)
== 0, and the expressions involving x won't have the correct
derivative. Obviously, I can hand code the chain rule and just take
partial derivatives with respect to each x_i, then multiply by another
Symbol that represents dx_i / dt, but this seems clumsy and cumbersome
to me.
If, instead, each x_i is implemented as Function, implicitly dependent
upon time (again, remember, no closed form solution exists) like:
t = Symbol('t')
x_1 = Function('x_1')(t)
then we get nice things like:
diff(x_1, t)
but then other issues come up, e.g, solve can't solve for anything but
symbol (although there is a patch submitted that fixes this), .match()
can't match Function types, differentiation with respect to Functions
are not currently supported (so no Jacobian of f(x, t) could be done
without substitution), and who knows what else. Substitution schemes
where Functions are replaced by Symbols and then back again are
possible, but it seems fragile and a bit of a hack.
The main point I'm driving at is that it seems that many things seem
to be designed to work exclusively with the Symbol type.
Does anybody here have experience with this sort of situation, and how
it can be dealt with, or how other packages (Maple, Mathematica,
Maxima) might deal with it?
One idea (not necessarily a good one, let me know what you think) is
the following. Suppose you have a problem where you need
differentiation with respect to a parameter (i.e. time), but for
everything else, the behavior of Function is not needed ( i.e., series
() is not needed because no closed form solution exists....). Could a
special type of Symbol be created that carried along with it its
independent variable, something like:
>>>t = Symbol('t')
t
>>>x = Symbol('x', implicitly_dependent_upon=t)
x(t)
and then differentiation with respect to that parameter would return
another Symbol:
>>>x.diff(t)
x'
Or some other notation instead of the x' could be used, maybe xp (p
for prime), and so on:
>>>(x.diff(t)).diff(t)
x''
It seems like this notation could also be useful and applicable to
things with spatial dependence, like stress, strain, temperature,
things that arise in solid and fluid mechanics. i.e.:
v = Symbol('v' implicitly_dependent_upon = [t, x, y, z])
as might be used in the Navier-Stokes equations...
I guess the real need for this is dictated by the case when you need
to derive, symbollically, the differential equations you want to work
with, be they ODE's or PDE's. That happens to be what I'm working on,
and maybe other people might find this functionality useful, or maybe
not.
I guess it might just be as simple as subclassing Symbol and adding
the functionality I just described, but hopefully this would still
allow it to retain the ability to work with all the builtin Sympy
functions that work best with Symbol objects.
Thoughts?
~Luke
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com
To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sympy?hl=en
-~----------~----~----~----~------~----~------~--~---
