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

[David Cournapeau]

On 1/13/07, Charles R Harris <charlesr.harris at gmail.com> wrote:
>
>
> On 1/12/07, David Cournapeau <cournape at gmail.com> wrote:
> > On 1/13/07, Christopher Barker <Chris.Barker at noaa.gov> wrote:
> > > I think it may have all been cleared up now, but just in case:
> > >
> >
> > > but how do you get single strided? this is what always made it hard for
> > > me to know how to write this kind of code.
>
> <snip>
>
> Make a copy of the array. New copies are C_CONTIGUOUS by default. There is
> also the ascontiguousarray function:
>
> ascontiguousarray(a, dtype=None)
>     Return 'a' as an array contiguous in memory (C order).
>
> Which makes a copy only when required. Since clip returns a new array
> anyway,
This is not always true: clip as a array member functions accepts out
as a keyword, even is out is the same than input. Something like

a.clip(min, max, a)

does work. I actually do not understand this out argument. Doing
a.clip(min, max, a) for in place is a bit strange, isn't it ?

Part of the problem is that I get the impression that clip has some
behaviour which really depends on the current implementation (using
addition and so on). For example, a.clip(0., 1.) does return a float32
array when a is a float32, and fails if a is an integer. There is no
upcast, and I don't see any reason why; I thought that numpy was
supposed to (try to ) upcast any necessary inputs when necessary ?

Doing an equivalent of putmask(a, a<m. m) and putmask(a, a>M, M) is
easier, but is not compatible with the current clip for many cases.

this shouldn't be a problem except when clipping against another
> array, which you would also want to be contiguous. In practice, I don't
> think using ascontiguousarray for the clipping array would add much overhead
> as the array would likely be contiguous in the first place. You would
> probably want to match data types also. I think the needed ops are already
> implemented for the types at the c-level, __gt__ for instance, and in that
> case you can simply use the function pointer with some loss of speed. If you
> can determine the corresponding c-type, and I think you can, then it
> shouldn't be too much trouble to implement type specific clipping, but it
> might not be worth the effort.

Having type specific clip operation is really trivial compared to all
other problems: a few lines of templated code, and generating them for
all basic C types.

The problem really is to know when you can use those functions, and
the rules for conversion while keeping the same semantics than the
original clip function which are quirky in some cases,

David