[Numpy-discussion] Re: Proclamation: column-wise arrays
pearu at ioc.ee
Wed Jan 26 12:58:58 CST 2000
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.
More information about the Numpy-discussion