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