On 1/13/07, Charles R Harris <[EMAIL PROTECTED]> wrote: > > > On 1/12/07, David Cournapeau <[EMAIL PROTECTED]> wrote: > > On 1/13/07, Christopher Barker <[EMAIL PROTECTED]> 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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
