On 10/18/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
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
>
> 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
------------------------------------------------------------------------- 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 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
