Fabian,
I think the example you gave is good, but I think it would be better
if you could imply that x == x(t) upon instantiation, rather than
anytime you need to take the derivative, so that you would have
something like:
In [1]: t = Symbol('t')
In [2]: x = Symbol('x', args=[t])
In [3]: x.diff(t)
Out[3]:
d
--(x(t))
dt
I think making the user type 'x(t).diff(t)' instead of 'x.diff(t)'
would be more error prone (you could easily forget to do it once and
screw everything all up). To me it seems better to just declare that
it is dependent upon some parameter when you create it, and
forevermore you don't have to be explicit about it.
The next question is with regards to the return value of x.diff(t) in
the above case. Currently, it returns Derivative. For the stuff I am
doing, I need 'x.diff(t)' to have the functionality of Symbol, i.e., I
need to be able to take the derivative of an expression with respect
to x.diff(t), and I don't want to have to perform cumbersome
substitutions back and forth, also, being able to match terms, find
coefficients, solve, etc., all work with Symbol but not necessarily
with other things like Function or Derivative.
What do you think about the idea of an assumption for Symbol saying
that it is implicitly dependent upon some other Symbols? If this
assumption were set to be True, and the list of other Symbols
specified, there could be some small amount of code in the diff()
method of Symbol that would notice this and return a Symbol instead of
a Derivative. This would still allow for the chain rule to be applied
correctly, so that you could get this kind of behavior:
In [4]: diff(sin(x), t)
Out[4]:
D(x(t), t)*cos(x(t))
but still have the first term, the D(x(t), t), be a Symbol, so that
you could do:
In [4]: dexpr = diff(sin(x), t)
In [5]: solve(dexpr - 1, x.diff(t))
Out[5]: {D(x(t), t): 1/cos(x(t))}
The reason it might be nice to subclass it is so that printing could
be more tightly controlled.... things get long and unreadable if you
are always using x(t) instead of x, D(x(t), t) instead of x' (or
something similar). But maybe it could still be done without
subclassing?
The other approach would be to make everything in Sympy work equally
well with Function, Derivative, and Symbol. I don't know if this is a
good idea or not, but it also seems like it would be a ton of work.
What do you think?
~Luke
W
On May 27, 1:44 am, Fabian Pedregosa <fab...@fseoane.net> wrote:
> 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/5c0d66d518a...
>
> 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
-~----------~----~----~----~------~----~------~--~---
