On Wed, 26 Jan 2000, Travis Oliphant wrote:
Proclamation: Introduce a column-wise array to Numeric Python where data is stored in column-wise order that can be used specifically for fortran routines.
This is a very interesting proposal that we should consider carefully. I seem to recall reading that Jim Hugunin originally had this idea in mind when he established the concept of contiguousness, etc.
My current thoughts on this issue are that it is of only syntatic value and seems like a lot of extra code has to be written in order to provide this "user-friendliness." I don't see why it is so confusing to recognize that Fortran just references it's arrays "backwards" (or Python references them backwards --- whatever your preference). How you index into an array is an arbitrary decision. Numerical Python and Fortran just have opposite conventions. As long as that is clear, I don't see the real trouble. If the Fortran documentation calls for an array of dimension (M,N,L) you pass it a contiguous Python array of shape (L,N,M) --- pretty simple.
Perhaps someone could enlighten me as to why this is more than just a aesthetic problem. Right now, I would prefer that the time spent by someone to "fix" this "problem" went to expanding the availability of easy-to-use processing routines for Numerical Python,
I think that this expansion would be quicker if the Python/Fortran connection would not introduce this additional question to worry about.
or improving the cross-platform plotting capabilities. Here I agree with you completely.
I can see the following problems when two different conventions are mixed: 1) if your application Python code is larger than "just an example that demonstrates the correct usage of two different conventions" and it can call other C/API modules that do calculations in C convention then you need some kind of book keeping where your matrices need to be transposed and where not, and where to insert additional code for doing transposition. I think this can be done in lower level and more efficiently than most ordinary users would do anyway. 2) Another but minor drawback of having two conventions is that if you have square matrix that is non-symmetric, then its misuse would be easy and (may be) difficult to discover. On the other hand, I completely understand why my proposal would not be implemented --- it looks like it needs lots of work and in short term the gain would not be visible to most users. Pearu