Obsolesence of <> (fwd)

Jonathan Gardner gardner at cardomain.com
Tue Jun 5 16:52:18 EDT 2001


James Logajan wrote:

> Alex Martelli wrote:
>> The "pseudo-mathematical" ideas being those based on < and > which
>> Lulu just proposed?  Well then, if those ideas have any worth, then,
>> GIVEN (as decided by the BDFL) that < and > don't apply, neither
>> must <>.  The only "justification" needed for != is: SOME inequality
>> operator is needed, and it must definitely not be <>, which WRONGLY
>> suggests analogies to < and >.
> 
> Shrug. You haven't made a specific case for "!=". I say that one may segue
> from "<>" as applied to simple numbers, to application to sets of other
> things where "<>"'s semantic historical origins aren't as valid. You seem
> to insist that any hint of properties in the notation used for real
> numbers should not be used for analogous operations on other sets or
> groups. I say that is contrary to how mathematical and programming
> notation evolves to best suit programmers. Consider for a moment
> multiplication. On real numbers the operation is commutative. On matrices
> it is not. (And it is computationally more involved.) Yet the same
> multiplication symbol or notation may be used in both cases. Even in
> Python a symbol like "*" may be applied to a number and a string with a
> non obvious meaning. But "+" may not be applied to a mix of strings and
> numbers. By the way, do you object to "+" used for string concatenation?
> (This WRONGLY suggests an analogy to numeric addition.) If not, why is it
> okay to take "+" or "*" and put them to use for things that are not
> numbers, but it is not okay for "<>"?
> 
>> "There should be one, and ideally only one, obviously correct way
>> to do something".  Having two entirely synonymous operators is
>> unPythonic.  It's an ideal, of course, not a practical reality --
>> pow(x,y) vs x**y, apply(spam,args) vs spam(*args), etc, shows that
>> multiple ways to "do something" can and will survive in Python
>> (particularly for legacy/historical reasons).  It's still a worthy
>> ideal to aim at, in my humble opinion.

Okay, drawing on your example of matrices and such, and taking the 
statement that There Is NOT More Than One Way To Do It:

In mathematics, there are several ways to write multiplication. And, in 
some cases, they have different meanings.

In grade school, we learned 'x' means multiply. In Junior High School and 
High School, we were taught that "ab" means "a x b" and "a . b" means "a x 
b". (The period should be a dot.) Then, in Vector Calculus, I was taught 
that "x" (cross products) and "." (dot products) mean two different things. 
In fact, because of the last property of multiplication, you can't write a 
general multiplication function for vectors. You have to implement two 
seperate methods.

So, taking the argument back to <> and !=: Maybe we should decide that <> 
means "greater than or less than" and != means "not equals to, or not ==". 
Therefore, you can ensure that noone tries to <> two complex numbers, but 
they certainly can != two complex numbers. 

These two things, in math at least, are two different things. You will 
never catch a mathematician writing "Vector A <> Vector B" because it 
doesn't make sense.

But, in the end we are limited by ASCII. Hopefully, when everyone uses 
unicode editors, and when they figure out how to get their keyboard to work 
properly, we can adopt a more mathematical terminology, and include several 
more operators that aren't in ASCII (like the dot for dot product). In the 
end, shouldn't we try to make what is written in the program as legible to 
mathematicians as possible? I mean, the closer the language stays to math, 
the more logical it will be.




More information about the Python-list mailing list