> For the mutability issue : Just as Aaron suggested, we do really need the > objects to be mutable. Doing something as
If I understand correctly, Aaron's main point was that mutability is useful only in certain cases and I do not think that the current module requires it. Most of the arguments in favor of mutability were about how to relate two reference frames (both static translation and orientation as well as relative velocity and angular velocity). I think that the example I provided addresses these issue and mutability is not necessary. > Then there is the problem of ScalarField + ScalarField == ScalarField. I > think as long as we use different variables in different frames, we can just > drop the whole concept of a ScalarField class. As I have said, I am in favor of that. Moreover, using the same variables in different frames seems like a bad idea anyway. > Then, we need to address the problem with Vector. What does the Vector > inherit from? Taking a hint from the tensor module, I think we can have a > VectorExpr class that inherits from Basic so that > > x == x.func(*x.args) > > holds. Vector shall then inherit from VectorExpr. Why not just follow the methodology used for scalar fields? I.e. just creating symbols to be used as base vectors. If the issue is only about printing then subclass Symbol. Concerning the garbage input, you can do verification when you call a function on your garbage expression. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
