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 <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 >> >> > > > -- > 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. > -- 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.
