[Numpy-discussion] C vs. Fortran order -- misleading documentation?

[Charles R Harris]

On Tue, Jun 8, 2010 at 9:27 AM, Pavel Bazant <MaxPlanck at seznam.cz> wrote:

>
> > > Correct me if I am wrong, but the paragraph
> > >
> > > Note to those used to IDL or Fortran memory order as it relates to
> > > indexing. Numpy uses C-order indexing. That means that the last index
> > > usually (see xxx for exceptions) represents the most rapidly changing
> memory
> > > location, unlike Fortran or IDL, where the first index represents the
> most
> > > rapidly changing location in memory. This difference represents a great
> > > potential for confusion.
> > >
> > > in
> > >
> > > http://docs.scipy.org/doc/numpy/user/basics.indexing.html
> > >
> > > is quite misleading, as C-order means that the last index changes
> rapidly,
> > > not the
> > > memory location.
> > >
> > >
> > Any index can change rapidly, depending on whether is in an inner loop or
> > not. The important distinction between C and Fortran order is how indices
> > translate to memory locations. The documentation seems correct to me,
> > although it might make more sense to say the last index addresses a
> > contiguous range of memory. Of course, with modern processors, actual
> > physical memory can be mapped all over the place.
> >
> > Chuck
>
> To me, saying that the last index represents the most rapidly changing
> memory
> location means that if I change the last index, the memory location changes
> a lot, which is not true for C-order. So for C-order, supposed one scans
> the memory
> linearly (the desired scenario),  it is the last *index* that changes most
> rapidly.
>
> The inverted picture looks like this: For C-order,  changing the first
> index
> leads to the most rapid jump in *memory*.
>
>
Good point, I can see that that could be a source of potential confusion.
Perhaps something along the lines that 1) the memory is in one contiguous
slab, and 2) it is accessed in order by changing the rightmost indices
fastest, would be better.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20100608/5fec3220/attachment.html>