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.
