For an example of successive rotations, check out the second code block here: http://docs.sympy.org/0.7.2/modules/physics/mechanics/examples.html
Regarding Vector, should the user being to perform any action they could on another Expr object on a Vector object? If it inherits from Expr, would sin(unit_vector) not raise an error? -Gilbert On Tue, Jun 11, 2013 at 1:10 AM, Stefan Krastanov < krastanov.ste...@gmail.com> wrote: > about immutability and reference frame: I guess I do not understand > the details of what you describe. Anyway, I will not be against > immutability if it does not mess up with `__eq__` and `__hash__` so it > depends on the implementation. > > about Vector: if it is not a subclass of Expr it will not be useful > outside of mechanics. For instance > symplify(sin(asin(phi))*unit_vector) will just raise an error instead > of return phi*unit_vector. > > > > On 11 June 2013 02:39, Gilbert Gede <gilbertg...@gmail.com> wrote: > > 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. > > > > > > -- > 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.
