Re: [Numpy-discussion] big picture? One proposal

[Konrad H. <hi...@cn...>]

> situation. My general point is that a _good_ solution is simple,
> if a solution is not simple, then it is probably a bad solution.

Agreed. So we just need to agree on what is "simple".

> I find separating array and matrix instances (in a sense of raising
> exception when doing <matrix> <op> <array>) not a very simple solution:
>   New concepts are introduced that actually do not solve the simplicity
> problem of representing matrix operations. As I see it, they

I disagree there, separating the concepts of matrix and array *does*
solve the simplicity problem in my opinion. Matrices use operators for
common matrix operations, and arrays use the same operators for common
array operations.

> only introduce restrictions and the main assumption behind the rationale
> is that "users are dumb and they don't know what is best for them".

No, not at all. On the contrary, the rationale is "users are smart and
know that arrays and matrices are different"  ;-)

Unfortunately, I have the impression that there are two schools of
thought in collision here (and not just when it comes to programming).
There is the "mathematical" school that defines matrices and arrays
as abstract entities with certain properties and associated operations.
And there is the "engineering" school that sees arrays as a convenient
data structure to express certain operations, of which "matrix operations"
are a subset.

As a student, I had a friend who studied mechanical engineering, and
his math exercises made me go mad more than once. When I read "...the
vector of the masses...", I just had to scream ;-)  Many engineering
textbooks have the same effect on me.

Now obviously I belong to the "mathematical" school, but I don't
expect to convert everyone else to it. So my arguments will remain
pythonic and pragmatic: the "mathematical" approach solves the problem
without asking for new operators, and thus has a better chance of
getting realized.

> This is how I interpret the raised exception as behind the scenes matrix
> and array are the same (in the sense of data representation). 

But data representation and data semantics are two different things.
Readibility of code depends on semantics, not on internal
representations or even implementation. Using the same representation
merely implies that conversion should be efficient, but not
necessarily implicit.

> The main objection to this proposal seems to be that it deviates from a
> good pythonic style (ie don't mess with attributes in this way).
> I'd say that if python does not provide a good solution to our problem,
> then we are entitled to deviate from a general style. After all, in doing

That's another point where I disagree. I use Python for many different
uses, numerics is only one of them (though the most important one).
Uniformity of style is an important value for me.

Moreover, I claim that Python *does* provide a good solution, it is
merely a very different one.

> numerics the efficiency issue has a rather high weight. And a generally
> good style of Python cannot always support that.

Computational efficiency is not the issue here. If that's all you
want, call a BLAS routine for matrix multiplication with two array
arguments - doable today, without any modification of whatsoever.
Even Fortran programmers do that, instead of suggesting that Fortran
2002 should add a "multiply-by-calling-BLAS" operator.

> define
> 
> T = TransposeOp()
> H = TransposeOp(conjugate=1)

Does that work? I'd expect that a**T would first call .__pow__(T)
which quite probably crashes... (Not that it matters to me, I find
this almost as abusive as the matrix attributes.)

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------