Luke wrote:
> 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)
Hi Luke!
I proposed something like this not long ago
http://groups.google.com/group/sympy/browse_thread/thread/5c0d66d518ab8c14/dad0819980dce358?lnk=gst&q=fabian#dad0819980dce358
so I'm very glad we both arrived to the same conclusion.
Definitely Function should not be used as an unknown, and symbol should
be used instead as you pointed out (maybe with some assumptions, maybe
that would not be necessary for most cases)
> 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''
the following work well now:
In [1]: x = Symbol('x')
In [2]: t = Symbol('t')
In [3]: x(t).diff(t)
Out[3]:
d
--(x(t))
dt
And I think this is both elegant and simple.
>
> 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.
>
I don't think we just use symbol. Symbol represents an unknown and in
the same way that we don't subclass when representing an unknown that
lives in Z or that is not commutative, we should not subclass an unknown
that lives in the space of functions.
> 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
-~----------~----~----~----~------~----~------~--~---
