Re: [Numpy-discussion] The NumPy Fortran-ordering quiz

[Charles R H. <cha...@gm...>]

On 10/17/06, Travis Oliphant <oli...@ie...> 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