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

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

On 10/18/06, Travis Oliphant <oli...@ie...> wrote:
>
>
> >
> > 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.
> The flag is the there as a quick check for interfacing.  The order
> keyword grew because it was useful to avoid the arbitrariness of
> C-contiguous order for those who prefer to think of it differently.
> Remember the .T attribute for .transpose() was a recent addition and
> sticking .transpose() everywhere is a lot more ugly.   But, yes, many
> uses of the order keyword could be replaced by preceding with
> .transpose() --- this is not without cost, however.
>
> >
> > 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.
>
> What?   You're not understanding something.  The order flag definitely
> does something here.   First of all it seems like you are not
> understanding the meaning of the CONTIGUOUS flag.   CONTIGUOUS means
> "C-order contiguous"  while FORTRAN means "FORTRAN-order contiguous".
> That's why I use the word single-segment to talk about FORTRAN-order or
> C-contiguous order.  For Numeric, CONTIGUOUS always meant C-order
> contiguous and we are continuing that tradition.  All we've done is
> notice that there is such a think as FORTRAN-order contiguous and copies
> do not need to be made in all circumstances when you have FORTRAN-order.
>
> Look at the difference between:
>
> a = array([[1,2,3],[4,5,6]],order='F').data[:]
>
> b = array([[1,2,3],[4,5,6]]).data[:]
>
> Notice the layout is definitely different between a and b.
>
> > 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
>
> Because you requested a C-contiguous array --- that's what contiguous
> means in NumPy (exactly what it meant in Numeric).
>
> >
> > 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.
>
> Yes, like I said before, all kinds of operations alter the "layout" of
> data.  You can't assume all operations will preserve FORTRAN ordering.
> FORTRAN-order has meaning beyond how the data is actually set out in
> memory.  Sometimes it indicates how you think it is layed out when you
> are doing re-shaping operations.
>
> >
> > 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.
> No it doesn't.  Please show your evidence.  Look:
>
> a = array([[1,2,3],[4,5,6]])
>
> print a.ravel()
> [1 2 3 4 5 6]
>
> print a.ravel('F')
> [1 4 2 5 3 6]


I'm not talking about the keyword in the ravel call, I'm talking about the
flag in a. The question is: do we *need* a fortran flag. I am argueing not,
because the only need is for fortran contiguous arrays to pass to fortran
function, or translation from fortran contiguous arrays to numpy arrays.
What I am saying is that things are unnecessarily complicated. None of the
LaPack stuff seems to use the Fortran stuff, they just transpose and copy. I
don't even think I want to change that, because it is *clear* what is going
on. Interfacing to fortran is all about memory layout, nothing more or less.

Chuck