[Numpy-discussion] Should non ufunc numpy functions behave like ufunc regarding casting to output argument ?
david at ar.media.kyoto-u.ac.jp
Mon Jan 15 21:44:48 CST 2007
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
>> > 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 : import numpy
>> > In : a = numpy.linspace(0, 10, 101)
>> > In : b = numpy.zeros(a.shape, dtype = numpy.int32)
>> > In : print a.dtype
>> > float64
>> > In : 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
>> 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
> 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:
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.
More information about the Numpy-discussion