[Numpy-discussion] Overloading numpy's ufuncs for better type coercion?
Charles R Harris
Wed Jul 22 13:30:05 CDT 2009
2009/7/22 Hans Meine <firstname.lastname@example.org>
> (This mail is a reply to a personal conversation with Ullrich Köthe, but is
> obviously of a greater concern. This is about VIGRA's new NumPy-based
> bindings.) Ulli considers this behaviour of NumPy to be a bug:
> In : a = numpy.array(, numpy.uint8)
> In : a + a
> Out: array(, dtype=uint8)
> However, this is well-known, often-discussed, and IMHO not really
> for computer programmers who ever worked with C-like languages (even Java
> many such problems). Christian even said this is what he wants.
> OTOH, I agree that it is a missing feature that NumPy performs "coercion
> before the operation" (to be more precise: the temporary data type should
> promoted from the operand types, and /then/ the coercion - which can also
> reduce the number of bits - should happen), to fix this strange behaviour:
> In : numpy.add(a, a, numpy.empty((1, ), dtype = numpy.uint32))
> Out: array(, dtype=uint32)
> Now, our opinions differ on how to deal with this - Ulli planned to
> (more or less) all ufuncs in vigranumpy in order to return float32 (which
> sort of a common denominator and the type nearly all other vigranumpy
> functions should accept). I see two main disadvantages here:
> a) Choosing float32 seems to be arbitrary, and I'd like as much as possible
> vigranumpy to be independent from VIGRA and its particular needs. I have
> so many requests (e.g. on the c++-sig mailing list) for *good* C++/boost-
> python <-> numpy bindings that it would be a pity IMO to add special cases
> VIGRA by overloading __add__ etc.
> b) Also, I find it unexpected and undesirable to change the behaviour of
> basic operations as addition on our ndarray-derived image types. IMO this
> brings the danger of new users being confused about the different
> and even experienced vigranumpy users might eventually fall in the trap
> dealing with plain ndarrays and our derived types side-by-side.
> Ideally, I'd like numpy to be "fixed" - I hope that the "only" obstacle is
> that someone needs to do it, but I am afraid of someone mentioning the term
> "backward-compatibility" (Ulli would surely call it "bug-compatibility"
> ;-) ).
The rule here is that the output is computed as the common input type, then
cast to the type of the output array. It will also be downcast if the output
array is of lesser precision. This has been discussed on the list, my
preference would have been to raise an error on mismatched types but the
consensus was to keep the current casting behaviour. What you are asking for
is that the ufunc upcast the arrays before the addition if the output array
is of higher precision. This complicates the logic. I think it is better in
this case to explicitly make a of higher precision before the call. Note
that the ufunc loops don't generally handle mixed types with the exception
of logical functions and, IIRC, the exponent/mantissa functions.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion