>> An example from the (upcoming) differential geometry module: >> >> p is a point with x=a and y=b >> >> rect is the Cartesian coordinate system >> rect.x (y) are ScalarFields taking a point and returning the x (y) coordinate >> polar is the polar coordinate system with r and theta as basis fields >> >> rect.d_dx is the unit vector along x >> rect.d_dy, polar.d_dr, polar.d_dtheta are the other unit vectors >> >> now the examples >> >> Creating scalar fields without the need for special scalar field >> subclass of Expr: >> >> rect.x(p) = a >> (rect.x+rect.y**2) = a+b**2 >> >> Creating vector fields (i.e. directional derivatives) without the need >> for subclasses of Expr: >> >> (polar.d_dr+polar.d_theta) ( rect.x + 3 ) (p) = cos(theta(p)) + >> r(p)*sin(theta(p)) >> # I was to lazy to calculate r(p) and theta(p) >> >> This can be done with a helper function (e.g. `apply(field, point)`) >> but the current approach seems nicer. > > If you do that, you won't have any simple way of recognising > ScalarFields, or things-like-rect.d_dx (what do you call them?), which > seems rather inconvenient. Worse than that, objects like (rect.x * > rect.d_dx) cannot possibly work satisfactorily.
Why would I want to recognize them? It is all about interface, not what class they are. The other example ( x * d_dx ) is nonsensical mathematically. If a user has a formalism in which it makes sense, he is free to use it, that is all. Off topic: d_dx is the unit vector along x. It needs better name. (in latex it is \frac{\part}{\part x}) >> >> >> Moreover, I still do not think that there are any special cases, as >> there were no test failures when the change was done. > > The absence of test failures only shows that a feature that didn't exist > wasn't used. As for special cases, I already mentioned the Expr vs Basic > thing (why is this implemented only for Expr, when callability is > unrelated to the concept of Expr?), but the special handling of Symbol > is also a problem and the complicated implementation of Expr.__call__ > probably makes assumptions that can be broken. Also, if any Expr > subclass with a Lambda in its args will cause problems. > Yes, I agree. These should be discussed further, however I do not think that these are show-stoppers. I would prefer to finish with the examples from Aaron before proceeding on this. -- 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.