On 10/17/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
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
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
------------------------------------------------------------------------- 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
