Thanks for bringing up my argument. I would recommend against using &, ^, and | because they have operator precedence much different than what you would expect. Luke, did you tell your girlfriend that you have to type x + (y & z) or else it will be interpreted as (x + y) & z? I think she may change her mind on how clear this is with this fact in mind, especially to unsuspecting new users.
The idea of using ** and // is perhaps a good one. Here's the Python operator precedence table for reference http://docs.python.org/reference/expressions.html#summary. There's also % in there at the same level as *. Indeed, do you even use / (single slash)? Another idea that I briefly mentioned on the pull request is to use __call__, __index__, and/or __getattr__. The following are all valid syntactic sugars: v1.v2 v1[v2] v1(v2) Unlike &, ^, and |, these have operator precedence that you would expect. The first one will not work in a nested manner, unfortunately. It also requires you to have a very consistant variable naming scheme, or else some kind of namespace hacks. It does look just like v1 dot v2, though. Finally, I suggested using shorter method names, for less typing. So instead of v1.dot(v2) or v1.cross(v2), you could have just v1.d(v2) or v1.c(v2). This would probably be a bad idea to have functions like this, as they would easily be clobbered, but for methods, it would work fine. And by the way, I don't see any reason why you can't have more than one interface. We allow, e.g., both f(x).diff(x) and diff(f(x), x) syntaxes in SymPy, and I don't think it leads to any confusion. Aaron Meurer On Thu, Aug 11, 2011 at 2:45 PM, Matthew Rocklin <[email protected]> wrote: > Thanks for the link Jason, there is some good discussion there which it > would be optimal to not have to repeat. > My opinion after reading through that is as follows. > I like operators. If the language supports it and you can find a good set > they really do make writing code feel more like writing math. For a package > like SymPy that tries to attract scientific and mathematical users I think > that this is very important. If a scientific user finds that their code just > looks like math they get hooked pretty quickly. This is good and I think we > should promote this. > I also think it's important that these operators act exactly as they should > without reading documentation. We must assume that these users will not read > documentation. Given this, are we setting up stumbling blocks for them to > trip on? I brought up the ^ issue, Aaron brought up the operator precedence > issue in the other discussion (the implicit parentheses in "a + b & c" don't > lie where you think they do). Given these issues I probably would fall back > on using just functions rather than the operators suggested. However, maybe > there are some other operators that do work well for some (if not all) of > the operations. > Luke, are you already using *? **? These probably have precedence closer to > what you'd like. Is // useful for anything? > If it was me I would write all internal code using functions, not operators. > Then you could add in operators separately and pull them out easily if they > caused trouble. Again, I like operators, I think they're important. I hope > that there is a good way to make them work here. > > On Thu, Aug 11, 2011 at 3:19 PM, Jason Moore <[email protected]> wrote: >> >> FYI: there is a lot of stuff on the subject we've already typed >> here: https://github.com/sympy/sympy/pull/450#issuecomment-1782199 >> For the sake of retyping. >> >> On Thu, Aug 11, 2011 at 1:15 PM, Jason Moore <[email protected]> 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? >>> 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, 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 >> >> >> >> -- >> 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 >> "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. > > -- > 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. > -- 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.
