Stefan, I think I disagree about Reference Frames being immutable. If you are going to create a series of Reference Frames when performing successive rotations, you are going to need to need to be able to modify the original frame to point to the new frames. There is a similar issue for setting the angular velocity of a Reference Frame after it is created.
Also, do you think that Vector should be a subclass of Expr? -Gilbert On Mon, Jun 10, 2013 at 5:45 AM, Stefan Krastanov < krastanov.ste...@gmail.com> wrote: > > @Stefan. I agree about the tree traversals part. However, I still feel > there must be a way for the user to check if two scalar fields expressed in > different ways are mathematically equivalent. Could you suggest a way? > Maybe just another function? > > This is described in one of the first pages of the sympy > documentation: Checking for equality in general is mathematically > impossible. In practice most of the time one does `simplify(expr_a - > expr_b)` and sees whether he gets 0. In numerics one just plots the > difference. > > > Also, have a look at the __eq__ function of the current Vector class. > > The current Vector class is not really a part of SymPy. One of the > reasons that these two projects are useful is that they will make > mechanics and sympy more inter-operable so stuff like `simplify` can > be used seamlessly in mechanics. > > > I would really like atleast _some_ way of checking mathematical equality. > > As I mentioned above, there is already a way for that and the issues > surrounding it are described in the docs (well, the documentation can > be better, that is clear :) > > > Anyway, given all these issues I can not imagine an api similar to the > currently suggested one working well with sympy. Both ScalarField and > Vector will break most of sympy if they eagerly eat all expressions > that are added to them. Unrelated to that, ScalarField is ill defined > because all the confusion around reference frames and coordinate > systems and reuse of Symbols. Reference Frames and/or Coordinate > Systems are represented as mutable objects which is nonsensical > mathematically (one does not change how to references relate (one > might want to parametrize something wrt time, but this is not the > same))... > > @Sachin and Prasoon, can you work together on the next iteration of > the design that is meant to fix these issues? When would you be able > to show it? > > Multiple times I have suggested partial/fragmented designs similar to > `diffgeom`. While some parts of `diffgeom` have no place here, some of > the ideas (the representation of general fields based on sympy > expressions containing base fields) could be helpful in preserving all > the invariants important for sympy. Do you want me to provide a more > complete suggestion on which you can base yours, or do you prefer to > continue on your own for the moment? > > -- > 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. > > > -- 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.
