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

[David Cournapeau]

David Cournapeau wrote:
> 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.
Sorry, this last sentence is incomplete and does not really make sense: 
I meant

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 new array when using the numpy C Api function PyArray_ConvertToCommonType.

David