[Python-Dev] [Fwd: Discussion: Introducing new operators formatrix computation]

[Gregory Lielens]

> Okay, but look at the syntactic support complex numbers needed. Just
> "j". The same for string processing. We just reused most of the existing
> operators. If you guys made a really kick-ass matrix package that
> everyone loved and didn't need any new syntax, Guido might be tempted to
> make matrices a built-in type also!

Right, but I think that making a kick-ass matrix package without syntax
modification is not possible...
Indeed, what characterize the numeric languages around (e.g. matlab,
octave, yorick, r-lab, ...) is precisely
the presence of a syntax able to naturrally express linear algebra
expression. All of them introduce
easy matrix concatenation, multiplication, division and
bloc-adressing...By the way, all matrix package are more or less cloning
the matlab way, with minor differences (except for yorick, which have a
more general syntax able to deal
with multidimensional arrays cleanly, but probably make things less easy
with 2D matrix). I think that such convergence comes probably from the
fact that the Matlab way is the good way for numeric stuff... 

> The funny thing is that most of the Python syntax that I don't use today
> is ALREADY for matrix operations:
> 
> foo[x,y:a,b]
> foo()[...]

This is inevitable, I agree that numeric stuff is completely off-topic
for a lot of peoples...But unicode support is also an excess-feature for
numerical code. Of course, when you write something which must compute
linear regressions and you want to ask input to a user which only speek
japanese...In fact, what attracts me in Python the first time I've heard
of it (3 weeks ago, so do not take my words too seriously...) is that it
seems to be able to do numeric stuff quite well, except for matrix...the
Python+NumPy package improve that, but not to the point of beeing
matlab-like. Python+NumPy+MatPy is better in that sense, but still lack
some operators to be THE solution...I tried to implement those operators
as a way to check how python is extensible (a must, as the intended use
of this - or anoteher numeric language) is to serve as command tools for
c++ Finite element software, and I was surprise how easy it was...So
here they are!

I do not really see a problem in adding new operators, except when 
- it slows down the old ones, and I do not think it could be noticed in
the present case...more ifs in the source code is certainly not
something to worry about...
- it makes python code unintelligible, and this is not relevant either:
No numeric -> do not use them, but if you do numeric stuff, everything
becomes clearer.
- it makes python source more complex: true, but so little than I think
it makes no practical difference. It is  really a small change, after
all I was able to implement it in a matter of day after looking for the
fist time in the code...Arguably, this change is of the same order of
magnitude as the 1.0j stuff...perhaps smaller  
- It is a hole which will unleash the craziest operators , and makes
python look like binary with expressions soup like k=(a*$$^b)%/(@~c):
That's the only risk I would be affraid of, but as already mentioned,
linear algebra is a well established field , used almost everywhere in
numerics and we have a bunch of languages which already support these
kind of operators...