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, or improving the cross-platform plotting capabilities. I agree that it can be most confusing when you are talking about matrix math since we are so used to thinking of matrix multiplication as A * B = C with a shape analysis of: M X N * N X L = M X L If the matrix multiplacation code is in Fortran, then it expects to get an (M,N) array and a (N,L) array and returns an (M,L) array. But from Python you would pass it arrays with shape (N,M) and (L,N) and get back an (L,M) array which can be confusing to our "understanding" of shape analysis in matrix multiplication: Python matrix multiplication rule if calling a Fortran routine to do the multiplication: (N,M) (L,N) = (L, M) I think a Python-only class could solve this problem much more easily than changing the underlying C-code. This new Python Fortran-array class would just make the user think that the shapes were (M,N) and (N,L) and the output shape was (M,L). For future reference, any array-processing codes that somebody writes should take a strides array as an argument, so that it doesn't matter what "order" the array is in. --Travis