Re: [Numpy-discussion] big picture? One proposal
On Fri, 8 Mar 2002, Konrad Hinsen wrote: <snip>
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.
I see arrays as a convenient data structure (being implemented in computer programs) to hold matrices (being members of a mathematical concept). I guess that my views are narrow-minded (but willing to widen it) regarding to consider arrays as a mathematical concept too. Just in mathematics I never (need to) use arrays in that way (my fields are mathematical analysis, integrable systems, and not computer science nor engineering). So, I also belong to the school of "mathematics", but may be into a different one. <snip>
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.
Me too. Just I am not too crazy about the constant style but more of if something can be accomplished efficiently. To be honest, I don't like programming in Python because it has a nice style, but because I can accomplish a lot with it in a very efficient way (and not only by using efficient algorithms). Writing, for example, Numeric.transpose(a) instead of a**T, a.T, a`, or whatever just reduces this efficiency. I also realize and respect that for computer scientists (that I presume the developers of Python are) it is crucial to have consistent style for their reasons. Sometimes this style makes some site-specific simple tasks too verbose to follow.
Moreover, I claim that Python *does* provide a good solution, it is merely a very different one.
So, what is it? <snip>
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.)
Yes, it works:
from Numeric import * class T: __rpow__ = lambda s,o: transpose(o) ... print array([[1,2],[3,4]]) ** T() [[1 3] [2 4]]
And I don't understand why it is abusive (because it is a different approach?). It's just an idea. Pearu
regarding to consider arrays as a mathematical concept too. Just in mathematics I never (need to) use arrays in that way (my fields are mathematical analysis, integrable systems, and not computer science nor
I meant "mathematical" as a school of thought (going from the abstract to the concrete), not as a domain of research. I don't know any area of mathematics either that uses the array concept, but it is definitely common in computer science (as a structured collection of similar data). Image data is a good example.
something can be accomplished efficiently. To be honest, I don't like programming in Python because it has a nice style, but because I can accomplish a lot with it in a very efficient way (and not only by using
I want both :-)
Moreover, I claim that Python *does* provide a good solution, it is merely a very different one.
So, what is it?
Separate matrix and array objects, with computationally efficient but explicit (verbose) interconversion.
Yes, it works:
from Numeric import * class T: __rpow__ = lambda s,o: transpose(o) ... print array([[1,2],[3,4]]) ** T() [[1 3] [2 4]]
Right, it works as long as the left argument doesn't try to do the power operation itself.
And I don't understand why it is abusive (because it is a different approach?). It's just an idea.
For me, "power" is a shorthand for repeated multiplication, with certain properties attached to it. I have no problem with using the ** operator for something else, but then on different data types. The idea that a**b could be completely different operations for the same a as a function of b is not very appealing to me. In fact, the idea that an operand instead of the operator defines the operation is not very appealing to me. There's also a more pragmatic objection which is purely technical, I like to stay away from playing tricks with the binary operator type coercion system in Python. Sooner or later it always bites back. And the details have changed over Python releases, which is a compatibility nightmare. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr 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 -------------------------------------------------------------------------------
On Fri, 8 Mar 2002, Konrad Hinsen wrote:
regarding to consider arrays as a mathematical concept too. Just in mathematics I never (need to) use arrays in that way (my fields are mathematical analysis, integrable systems, and not computer science nor
I meant "mathematical" as a school of thought (going from the abstract to the concrete), not as a domain of research. I don't know any area of mathematics either that uses the array concept, but it is definitely common in computer science (as a structured collection of similar data). Image data is a good example.
Just my 2c worth: I count myself in the "mathematical" school despite being a physicist. I look at matrices as having a specific algebra which, for instance, cannot be easily made to apply to higher-dimensional arrays. Therefore they are not just arrays looked at in a different way. For object-oriented thinkers this means they are different objects. They may "inherit" a lot of attributes from arrays but are not arrays. Another point to note is that a specific complaint earlier in the thread was the computational inefficiency of using numpy arrays for matrix-intensive operations. It seems to me that it would be far easier to write an optimised set of code for matrices if they were known to be a separate class. An example (which is probably not useful, but serves for illustration) is that one could "cache" or delay transposes etc, knowing that a matrix-multiply was likely to be about to come up. This sort of thing would be more difficult if the result of the transpose would have to be sensible when followed by a generic array operation. David
participants (3)
-
David Buscher -
Konrad Hinsen -
Pearu Peterson