[Matrix-SIG] Proclamation: column-wise arrays (fwd)

[hinsen@dirac.cnrs-orleans.fr]

> OK, this is my second attempt for the subject as there was little response
> from the numpy-discussion list.

I have never seen the first posting!

> I would like to hear from the experts why it 'is not possible to
> implement' the column-wise arrays or why it 'should not be implemented' in

It is definitely possible, so the question is whether such an option
should be implemented.

> Proposal sketch:
> 	1) Introduce a new flag `row_order'to PyArrayObject structure:
> row_order == 1  -> the data is stored in row-wise order (default, as it is
> 		now)
> row_order == 0  -> the data is stored in column-wise order
> Note that now the concept of contiguousness depends on this flag. 

Implementing column-wise arrays via a flag in the array structure
is of course the easiest solution, but raises a serious compatibility
problem: existing C code that works on arrays will happily accept
the column-order arrays, but interpret them wrongly.

Alternative: create a new Python object type. It could share most
of the implementation with the current array type, but a routine
that checks an argument for PyArray_Type would report an error,
instead of producing wrong results.

However, that leads to a confusing situation: there will be two data
types that look the same to a Python programmer, but some extension
module will accept one and some the other one, which makes combining
libraries rather messy.

> What is the good of this?
> 	1) The fact is that there is a large number of very good scietific
> tools freely available written in Fortran (Netlib, for instance). And I
> don't mean only Fortran 77 codes but also Fortran 90/95 codes.

How much of this code really needs column-order arrays? It isn't needed
for 1d arrays, nor for routines that can work on "transposed" arrays
(like most of LAPACK).

> 	4) I don't see any reason why older C/API modules would broke
> because of this change if it is carried out carefully enough. So,
> back-ward compability should be there.

I'd like to see how this could be done!

> What are against of this?
> 	1) Lots of work but with current experience it should not be a
> problem.
> 	2) The size of the code will grow.

Perhaps it would be a good idea to clean up the current code before
any such radical modification/addition. Otherwise there is a serious
risk of bug inflation.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------