# The NumPy Fortran-ordering quiz

Charles R Harris charlesr.harris at gmail.com
Wed Oct 18 11:38:32 CDT 2006

```On 10/17/06, Travis Oliphant <oliphant.travis at ieee.org> wrote:
>
> Stefan van der Walt wrote:
> > One last case, which confuses me still (probably because it is
> > 04:16am):
>
> Please continue to question.  All the code needs as much review as it
> can get.

I am really starting to wonder why we need an order keyword at all except
when order matters for interfacing, i.e., in contiguos arrays where one
wants fortran contiguous or c contiguous. For output type stuff:

tofile
tostring
ravel
flatten

These all need the keyword so that they can be used to produce files and
arrays to interface to fortran. Right now the fortran interface can be
achieved by:

a.T.tofile
a.T.tostring
a.T.ravel
a.T.flatten

The order keyword is just syntatic sugar that makes the intent clearer. For
the input type stuff

fromfile
fromstring
reshape-1d-array (unravel?)

Currently, the key operation is reshape, which only needs to return a view
in fortran order and doesn't even need to mark the resulting array as
fortran order because, well, because it works just fine in numpy as is, it
just isn't contiguous. If the other functions took shape and order, reshape
wouldn't even need the order keyword.

I don't see why the array constructor needs the order keyword, it doesn't
*do* anything. For instance

a = array([[1,2,3],[4,5,6]], order='F')

doesn't produce a fortran contiguous array, it produces the same array as
the 'C' form, just sets the fortran flag and marks contiguous as False. What
is the use of that? It is just a generic non-contiguous numpy array. And

In [131]: ascontiguousarray(array([[1,2,3],[4,5,6]], dtype=int8,
order='F')).flags
Out[131]:
CONTIGUOUS : True
FORTRAN : False
OWNDATA : True
WRITEABLE : True
ALIGNED : True
UPDATEIFCOPY : False

Doesn't produce a fortran contiguous array, so what use was the flag? And

In [141]: array([1,2,3,4,5,6], dtype=int8).reshape((2,3),
order='F').astype(int16).flags
Out[141]:
CONTIGUOUS : True
FORTRAN : False
OWNDATA : True
WRITEABLE : True
ALIGNED : True
UPDATEIFCOPY : False

reorders stuff in memory, so is a bug looking to happen in a fortran
interface.

mmapped files are the only thing I can think of where one might want vary an
operation depending on Fortran ordering because seeking out of order is very
expensive. But that means adapting algorithms depending on order type,
better I think to just stick to using the small strided dimensions when
appropriate.

It would be helpful in debugging all this order stuff if it was clear what
was supposed to happen in every case. Ravel, for instance, ignores the
FORTRAN flag, again begging the question as to why we *have* the flag.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20061018/42453a81/attachment.html
-------------- next part --------------
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier