I'm for the functional names as it is how all the programming languages that I know of implement dot products and cross products. It is clear what they mean and the symbols we use in math for the dot product and cross product (a dot and a cross) do not exist explicitly on the key board. Secondly, those symbols you use are already resevered for python operations, what happens when I have a script that requires both the dot product of a vector and the bitwise and comparison?
I think operator assignment belongs in language design. You all have chosen python as your language of choice for the software, so your are stuck with syntax and style from the python language. Everyone that uses your software has to learn python to some degree before they can use it anyways. Autolev for example is it's own mini langague so they have the power to assign whatever keyboard keys to various opeartions, like the '>' for vectors and other operations. Python has standards and overloading symbols is funky. Another example I know of is the ggplot library in R. They overload the '+' symbol is a very non-R way. When you read R code with ggplot stuff embedded in it you have to think in a totally different way than the rest of the code to understand what is going on. Keep in mind that people's scripts can have many modules imported from tons of python librarys, including your library (sympy.physics.mechanics). If you rewrite the language definition, then it doesn't necessarily fit with the rest of the code. Jason On Thu, Aug 11, 2011 at 12:42 PM, Luke <[email protected]> wrote: > I ran this same question by my girlfriend who teaches undergraduate > physics classes. She isn't an experienced programmer, so concepts of > operator overloading and object oriented vs functional programming > styles are not on here mind, but she has taught a lot of the core > required physics classes to both majors and non-majors at UC Davis, so > she has a lot of experience interacting with undergraduates on this > kind of thing. Surprisingly, she thought the operator interface > seemed the clearest because once you learn the meanings of the &, ^, > |, it is about as close to what you would write on a black board or on > paper as you could hope for. > > That said, there are issues with &, ^, and |, namely it is unlikely to > know what they mean unless you read the docstrings of Vector or read > the Sphinx documentation that Gilbert has written. Additionally, as > Matthew brings up using '^' for the cross product may visually > conflict with the wedge operator. Then again, it doesn't seem to hurt > to have overlapping syntax's, as long as they are both well > documented. > > I vote for keeping the operators and the functions, and if any are > removed, to remove the methods. > > If people have thoughts on any negative implications of implementing > multiple ways to perform the same thing, especially related to long > term maintenance of the code, it would be great to hear them. > > ~Luke > > On Thu, Aug 11, 2011 at 12:14 PM, Gilbert Gede <[email protected]> > wrote: > > My Summer of Code project is writing a submodule of SymPy for creation of > > symbolic equations of motion for multibody systems. As part of this, I've > > implemented classes to represent vectors and dyadics. I have currently > > implemented three ways to do mathematical operations on vectors: an > > operator, a function, and a method interface. > > I think three interfaces for these operations is too many, and am looking > > for some input on which ones people prefer. The implemented interfaces > look > > like: > > Cross product: > >>>> (vec1 ^ vec2) > >>>> cross(vec1, vec2) > >>>> vec1.cross(vec2) > > Dot product: > >>>> (vec1 & vec2) > >>>> dot(vec1, vec2) > >>>> vec1.dot(vec2) > > Outer product: > >>>> (vec1 | vec2) > >>>> outer(vec1, vec2) > >>>> vec1.outer(vec2) > > Here is one example where vector and dyadic quantities are used in the > code. > > I is a dyadic, and omega and alpha are vectors. > >>>> -(I & alpha) - (omega ^ (I & omega)) > >>>> -dot(I, alpha) - cross(omega, dot(I, omega)) > >>>> -I.dot(alpha) - omega.cross(I.dot(omega)) > > > > I'd appreciate people's opinions on: > > 1) Which is clearest? > > 2) Which would be easiest to teach? > > 3) Which is least error prone? > > I personally prefer the operator interface (&, ^, |), as I think once you > > learn what the three operators represent, it is clearer to read and > write. > > I would especially value the input of anyone who would be interested in > > using this as part of teaching students. > > I've also made a poll here: http://www.surveymonkey.com/s/CK8HDMD > > Thanks, > > Gilbert > > > > -- > > 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. > > > > > > -- > "Those who would give up essential liberty to purchase a little > temporary safety deserve neither liberty nor safety." > > -- Benjamin Franklin, Historical Review of Pennsylvania, 1759 > > -- > You received this message because you are subscribed to the Google Groups > "Sports Bio Mechanics" 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/sports-bio-mechanics?hl=en. > > -- http://mae.ucdavis.edu/~biosport/jkm/ Sports Biomechanics Lab <http://biosport.ucdavis.edu>, UC Davis Davis Bike Collective <http://www.davisbikecollective.org> Minister, Davis, CA BikeDavis.info Office: +01 530-752-2163 Lab: +01 530-752-2235 Home: +01 530-753-0794 -- 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.
