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
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
-------------- next part --------------
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
More information about the Numpy-discussion
mailing list