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 -~----------~----~----~----~------~----~------~--~---