I chose the & to represent dot product specifically because of its meaning of and/interection in Python; that is how I view the dot product of two vectors, as the common component between two vectors. I decided to only use * for scalar multiplication, to further reinforce that operations between vectors are different, and use their own symbols.
I do admit that there is less justification for the choice of ^ for the cross product and | for the outer product. Also, I've set things up to throw errors if non-permitted operations happen; this is also part of the reason I chose not to extend SymPy's Expr or Basic. Do you have any suggestions for alternate operators to represent dot, cross, and outer products besides &, ^, and |? -Gilbert On Aug 11, 2:48 pm, Matthew Rocklin <mrock...@gmail.com> wrote: > I agree with Jason that coercing operators to perform unfamiliar tasks is > probably a poor choice. I disagree however that operators have only a single > meaning or that they should be avoided when their meaning might be > ambiguous. > > Example of the first (operators have only a single meaning) > & also means set intersection in Python > > Example of the second (using operators even when meaning is ambiguous) > In numpy * could mean elementwise multiplication or matrix multiplication. I > don't think anyone is suggesting that we remove the * operator and just use > elementwise_mult(A, B) for arrays. If this happened I would personally > switch back to Matlab... *shudder*. > > My personal opinion (and I hold zero sway here) is that the operators that > Luke has proposed probably shouldn't be used as they are but that we should > remain open to this idea. I'm hopeful that at least some of the operations > he wants have nicely intuitive operator representations. > > > > > > > > On Thu, Aug 11, 2011 at 4:22 PM, Jason Moore <moorepa...@gmail.com> wrote: > > Couple more thoughts on operator overloading. > > > Let's assume the '+' symbol means 'to add' in the language of choice. It is > > very clear that what adding two numbers should do, but what about other > > objects: > > > object = matrix > > '+' should add the matrix. we could write a function called 'add_matrix', > > but it is pretty clear that overloading the '+' is absolutely equivalent. > > There aren't other ways to add matrices (although you could invent them, > > like add rows to columns and columns to rows, or something) > > > same for vectors > > '+' should add vectors, same as matrices, it adds each entry and there is > > probably no reason to write a function 'add_vector', just overload __add__ > > > what about: > > object = cat > > does 'adding one cat to another' mean to squish them together or tie them > > by the legs, or stack them on top of each other, or combine their names? You > > can pick one these as the default add operation for __add__ but it is > > probably more meaningful to have functions and/or methods that tell the use > > what they are doing: cat.combine_names(othercat). > > > In the R ggplot example, the '+' means 'to draw another element in the > > graph' or 'add another element in the graph'. So you can "add" lots of plot > > objects to your figure by using the '+'. I find that it just offers > > confusion rather that being helpful, but once you get it your code is > > shorted and easier to read for you. It just doesn't match the rest of the > > code in your script. I'm of the position that overloading the mathematical > > operators should be for things that have a mathematical semblance to the > > operator. > > > So as an analogy, the symbol '&' means 'bitwise and comparison' in python. > > > So what does it mean to 'bitwise and compare' a vector? > > > It surely doesn't mean to take the dot product (inner product) of a vector. > > The '.' or '*' seem like more appropriate symbols for a dot product of a > > vector. In documents we typically use a dot to represent the dot product (or > > angle braces for inner products) and it isn't confused with a dot > > for multiplication if we know we are working with vectors. The outer product > > doesn't really have a symbol on the keyboard. It often uses an x with a > > circle around it. Same with cross...the 'x' would be the best choice, but > > our language choice probably doesn't allow that. > > > So, as Luke pointed out the & symbol would work with different classes in > > different ways. For vectors it would mean dot product, but for other things > > that can be bitwise compared, they'd overload to that. I guess that is fine, > > even thought initially confusing. > > > --------------------- > > All in all, I think all three methods should be supported if there are > > people who want to use them. This way no one is forced to type things a > > certain way. This reflects the numpy and scipy setup. You can use functions, > > methods and they even overload mathematical operators when appropriate. I'm > > sure they do this to make it comfortable for users of other programming > > languages to adopt the software without having to learn a new paradigm. > > > The only reason not to support all methods, would be if there is a reason > > for maintainability sake. Otherwise, more options are better, because more > > folks will be comfortable with using the program. > > ------------------------------ > > > -- > > You received this message because you are subscribed to the Google Groups > > "sympy" group. > > To view this discussion on the web visit > >https://groups.google.com/d/msg/sympy/-/bH5GNLGSM7oJ. > > > 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. -- 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.
