Le mercredi 23 mai 2012 à 22:24 +0200, [email protected] a écrit : > > I'd really like to see what the point of this is, because, for now, I'm > > only seeing the complications caused by all the special cases and the > > possibilities for unexpected interactions. > > > > 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. > > > 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. > Finally, Aaron also mentioned that he has some examples in mind. I'd like to see them as well, particularly if they're more closely related to existing features. Having to discuss the design of a new module adds confusion to an already complex issue. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
