From: Konrad H. <hi...@cn...> - 2002-03-08 11:37:51
|
> 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 ------------------------------------------------------------------------------- |