One comment below. On Thu, Aug 11, 2011 at 1:15 PM, Jason Moore <moorepa...@gmail.com> wrote: > 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?
He is only overloading these operators for his classes, so it would have no effect on the same operators used with other classes. So, if you wanted to do bitwise manipulations on ints (or any other classes which support &/^/|) and vector products using the &/^/| operators in the same script, you could, and the code would work properly, although a reader would have to be more aware of the context in which the & is being used. Doing a &/^/| between incompatible types (i.e., int and Vector) would raise a TypeError exception. However, one could argue that it is safer to use operators because they are tied to the classes, whereas with the functions, if you import them into the global namespace you could unintentionally overwrite any other dot/cross/outer functions that may have existed. Obviously this is avoidable with the import syntax Python offers, but if you were careless, it could happen. The binary operators he is overloading are really no different from any other class method, except for the rules of precedence defined by the Python language. Obviously there are pros/cons of both ways, I think the real question is whether to support both interfaces, or to be more restrictive and only support one. This question of whether it is better to only support one way of doing things versus a couple ways of doing things has also come up in regards to how basis vectors of a Reference Frame are accessed, and it seems like having two ways to do things might not be too much of a hassle to support, with the added benefit that with the extra functionality, the Python code can look very similar to how it is printed/prettyprinted/latex'd, which I think is a very desirable quality. > 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 <hazelnu...@gmail.com> 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 <gilbertg...@gmail.com> >> 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 sympy@googlegroups.com. >> > To unsubscribe from this group, send email to >> > sympy+unsubscr...@googlegroups.com. >> > 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 >> sports-bio-mechan...@googlegroups.com. >> To unsubscribe from this group, send email to >> sports-bio-mechanics+unsubscr...@googlegroups.com. >> 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, UC Davis > Davis Bike Collective 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 > "Sports Bio Mechanics" group. > To post to this group, send email to sports-bio-mechan...@googlegroups.com. > To unsubscribe from this group, send email to > sports-bio-mechanics+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sports-bio-mechanics?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 "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
