Discussion: Introducing new operators for matrix computation

[Paul Prescod]

Huaiyu Zhu wrote:
> 
> ...
> 
> Python already provides both function names and binary operators, so the
> first level issue is not there.  However, while it gives almost unlimited
> supply of function names that can be overridden, there is only a handful of
> binary operators which have deep rooted meanings and not enough for
> overloading. This limit is largely arbitrary, and is therefore complexity.

No, the set of operations is not arbitrary. They are the set of
operations that most people learn in high school and are basically the
same set in every other mainstream programming language in the universe.

By the way, if we are going to add a bunch of formally meaningless
operators to the language, are we going to add unary, binary, ternary
and quaternary ones?

> Haven't we already talked this through?  Text processing already got its
> special syntax, even of the first level, which is quoted string.  

You have got to be joking. Quoted strings are a "special syntax?" Then I
guess matrices got in their special syntax also:

[[5,4,3],[2,8,5],[9,7,1]]

In fact, it really is the case that there is special syntax in the
language for matrix processsing. But you are asking for a whole new
level.

> Within a
> quoted string you could put in any text sequence.  In this specific domain
> it happens that only very limited number of binary operators are required,
> and they are duly provided, like string + string, string % string, or string
> * number.  

Not true at all. Perl provides a much, much richer set of operators for
working with strings. The most obvious binary operator Python is
"missing" is "does this string exist in that string". But text
processors learned to live with functional syntax (".find") and so can
matrix users. Python's core string operators are not really everythin
gyou need for "text processing" any more than they are everything you
need for matrix processing. Text processors just learned to survive with
functions and methods. Matrix processors will too. Moshe has some good
ideas in this vein. (.Element()*...

> All the other things you mentioned could be built on top of this.
> This domain is not even as mature as matrix computation - in many earlier
> languages it was though that special syntax is needed for printing, formats
> and regular expressions, which turned out to be just ordinary string
> operations and functions, as python shows.

Perhaps that rather shows that matrix computation is not as mature as
string processing.

"In many earlier languages it ws thought that special syntax is needed
for element wise computation, which turned out to be just ordinary
matrix functions, as MatPy shows."

Anyhow, it isn't that Python showed that other string operators are not
important. It's that Python showed that moving those operations to a
library makes text processing *more verbose* but makes *Python simpler*.
The same holds for matrices.

> On the other hand, for proper matrix operation, there is not much need for
> any additional first level structure, but there does exist a great need for
> a larger supply of binary operators.  What we are saying is that extending
> the number of operators overridable by applications represents a much
> smaller risk of incompatability than giving everyone a complete parser.

A smaller risk of incompatibility but a larger risk of making Python
complex and reducing its long-term popularity.

> With the given operators, all the fields like scientific computation,
> graphics, statistical analysis and artificial intelligence could also be
> built on top of this.

What if they want a completely different set of operators syntactically?
What if they want unary and ternary ones? Could I design the operators
with an eye to XML and then force you to make them fit matrix
processing?

> Before you dismiss numerical computation as just another domain, why not try
> a few packages and get a feeling of how large the domain is?

It doesn't matter how large the domain is. It is nevertheless just
another domain. Most people doing matrix computation with Python
acknowledge this and have been conservative in their requests on the
core. People have been doing numerical processing in Python for a long
time you know. 

-- 
 Paul Prescod - Not encumbered by corporate consensus
It's difficult to extract sense from strings, but they're the only
communication coin we can count on. 
	- http://www.cs.yale.edu/~perlis-alan/quotes.html