[Numpy-discussion] Should non ufunc numpy functions behave like ufunc regarding casting to output argument ?

[David Cournapeau]

Charles R Harris wrote:
>
>
> On 1/15/07, *A. M. Archibald* <peridot.faceted at gmail.com 
> <mailto:peridot.faceted at gmail.com>> wrote:
>
>     On 15/01/07, David Cournapeau <david at ar.media.kyoto-u.ac.jp
>     <mailto:david at ar.media.kyoto-u.ac.jp>> wrote:
>     > Hi,
>     >
>     >     I am trying to add support for out argument to one C
>     function using
>     > numpy API (still the clip function). I was wondering about the
>     expected
>     > behaviour when out does not have the "expected" type.
>     >     For example, using again the clip function (but the question
>     is not
>     > specific to this function)
>     >
>     > In [1]: import numpy
>     >
>     > In [2]: a = numpy.linspace(0, 10, 101)
>     >
>     > In [3]: b = numpy.zeros(a.shape, dtype = numpy.int32)
>     >
>     > In [4]: print a.dtype
>     > float64
>     >
>     > In [5]: a.clip(0.1, 0.5, b)
>     >
>     >     Should this be equivalent to b = a.clip(0.1, 0.5); b =
>     > b.astype(numpy.int32) (ie, the casting is done at the end,
>     similar to an
>     > ufunc) ?
>
>     Since the point of output arguments is to avoid allocating new
>     storage,
>
>
>
> If we take that seriously, then an error should be raised on a shape, 
> or type mismatch.
For the shape, there is no problem, I guess. A different shape is an 
error (except if I want to support broadcasting...). The problem is 
really for out having same shape than in, but having different type than 
input.

At first, I wanted to throw an error (for example, clipping an array 
which gives a float, and out is integer), but that would be incompatible 
with current clip behaviour.

Concerning the point of avoiding allocating new storage, I am a bit 
suspicious: if the types do not match, and the casting is done at the 
end, then it means all internal computation will be done is whatever 
type is chosen by the function (I am using PyArray_CommonType for that), 
and the cast done at the end, meaning new storage.

Actually, I find more logical to throw an error of the point is to avoid 
new storage, as giving a mismatched type out buffer would make the 
function create an internal buffer.


David