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.

Reply via email to