The NumPy Fortran-ordering quiz

Charles R Harris charlesr.harris at gmail.com
Wed Oct 18 14:08:07 EDT 2006


On 10/18/06, Tim Hochberg <tim.hochberg at ieee.org> wrote:
>
> Charles R Harris wrote:
>
> [SNIP]
> >
> > 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,
>
> There are two things here. One is the order keyword and one is the
> FORTRAN flag. The latter is mainly an optimization for use at the
> C-level so that one doesn't have to check whether a given array is in
> contiguous FORTRAN order by examining the strides, in the same way that
> the CONTIGUOUS flag allows you to skip examining the strides when you
> need a contiguous C-order matrix.


That sounds like the two flags should be named f-contiguous and
c-contiguous. Then they would be orthogonal and one could have all four
combinations. Is that the case now? Perhaps I am misunderstanding the
meaning of the flags.


I believe it is the former that you
> are objecting to, but it would help if you could specify whether you are
> talking about the order keyword or whether you are talking about the
> FORTRAN flag.


Both. I was argueing against the FORTRAN flag, and of limiting the order
keyword to those cases where f or c contiguous arrays were the output or
input.

I'll also note that the order keyword could probably have been used to
> fix a performance problem someone was having a few weeks ago. We ended
> up transposing the data, but the individual felt that obscured the
> intent of the algorithm. I believe the same effect could probably have
> been been achieved without re jiggering the algorithm by using the order
> parameter.


Some more details would be helpful. It would be good to know what problem
the order keyword should solve.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20061018/e488d3b0/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