On May 29, 2012, at 12:10 PM, Ronan Lamy <ronan.l...@gmail.com> wrote:
> 2012/5/25 krastanov.ste...@gmail.com <krastanov.ste...@gmail.com>:
>>>> 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.
>
> You always end up needing to recognise what kind of object you're
> handling, for some reason or other. Making it impossible in principle
> is a bad idea that will come back to bite you.
>>
>> 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.
>
> IIUC, this is the "dequantised" version of X P, which is a perfectly
> well-defined quantum operator. "Obviously", (x * d_dx)(f) should
> return x * f'(x), but I see no way to make it work in your design.
I noticed this too. It wouldn't really be possible to make an
"operator of operators", like a differential equation, because
something like (Derivative + f)(f)(x) would return Derivative(f(x), x)
+ f(f(x)). I don't really see how one could do this with Lambdas
either, btw.
>
>> Off topic: d_dx is the unit vector along x. It needs better name. (in
>> latex it is \frac{\part}{\part x})
>
> I'm rather confused by your explanations. You seem to alternate between
> describing it as a simple vector (but in which space?) and a differential
> operator. These seem to be completely different things to me.
Welcome to the very confusing world of differential geometry. The
field is mired with tons of very confusing abuses of notation. I think
the main thing to remember is that the isomorphism from a vector space
and its second dual is taken as exact equality, so that a vector (or
covector) is always considered also as a functional on its
corresponding convector (or vector).
Aaron Meurer
--
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.
