[Numpy-discussion] Need help for implementing a fast clip in numpy (was slow clip)

[Charles R Harris]

On 1/11/07, David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
>
> Timothy Hochberg wrote:
> >
> >
> > On 1/11/07, *Christopher Barker* <Chris.Barker at noaa.gov
> > <mailto:Chris.Barker at noaa.gov>> wrote:
> >
> > [CHOP]
> >
> >
> >     I'd still like to know if anyone knows how to efficiently loop
> through
> >     all the elements of a non-contiguous array in C.
> >
> >
> > First, it's not that important if the array is contiguous for this
> > sort of thing. What you really care about is whether it's
> > simply-strided (or maybe single-strided would be a better term).
> > Anyway, the last dimension of the array can be strided without making
> > things more difficult. All you need to be able to do is to address the
> > elements of the array as thedata[offset + stride*index].
> I don't understand why we need to do thedata[offset + stride * index]
> instead of thedata[index] when the data are aligned ? It looks like I
> seriously misunderstood the meaning of alignement...


I think you are confusing aligned for contiguous. Aligned normally means the
data occurs on natural address boundaries for the architecture and item
size, say multiples of 4 for 32 bit words on 32 bit machines. This contrasts
with the case where a word is split across natural boundaries: some
architectures support that with decreased performance, others don't. Then
there are endianess issues, etc, etc.  Anyway, the easiest data to deal with
is contiguous data where the data items lie one after the other in (virtual)
memory. The next easiest is where the spacing between data elements is
fixed, an lastly there is the case  of generally strided data.

Chuck

David
> >
> > That being said, the strategy that the ufuncs use, and possibly other
> > functions as well, is to have the core functions operate only on
> > simply-strided chunks of data. At a higher level, there is some magic
> > that parcels up non-contiguous array into simply-strided chunks and
> > feeds them to core functions. How efficient this is obviously depends
> > on how large the chunks that the magic parceler manages to extract
> > are, but typically it seems to work pretty well.
> >
> > I don't know whether the magic that does the parcelling is available
> > for use by random functions or whether it's specific to the ufunc
> > machinery, I never delved into that end of the ufuncs.
> >
> > -tim
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpy-discussion at scipy.org
> > http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20070111/2929d9c1/attachment.html>