[Numpy-discussion] Do we want scalar casting to behave as it does at the moment?
Sun Jan 6 20:17:14 CST 2013
2013/1/6 Nathaniel Smith <firstname.lastname@example.org>:
> On Mon, Jan 7, 2013 at 1:43 AM, Olivier Delalleau <email@example.com> wrote:
>> 2013/1/5 Nathaniel Smith <firstname.lastname@example.org>:
>>> On Fri, Jan 4, 2013 at 5:25 PM, Andrew Collette
>>> <email@example.com> wrote:
>>>> I agree the current behavior is confusing. Regardless of the details
>>>> of what to do, I suppose my main objection is that, to me, it's really
>>>> unexpected that adding a number to an array could result in an
>>> I think the main objection to the 1.5 behaviour was that it violated
>>> "Errors should never pass silently." (from 'import this'). Granted
>>> there are tons of places where numpy violates this but this is the one
>>> we're thinking about right now...
>>> Okay, here's another idea I'll throw out, maybe it's a good compromise:
>>> 1) We go back to the 1.5 behaviour.
>>> 2) If this produces a rollover/overflow/etc., we signal that using the
>>> standard mechanisms (whatever is configured via np.seterr). So by
>>> default things like
>>> np.maximum(np.array([1, 2, 3], dtype=uint8), 256)
>>> would succeed (and produce [1, 2, 3] with dtype uint8), but also issue
>>> a warning that 256 had rolled over to become 0. Alternatively those
>>> who want to be paranoid could call np.seterr(overflow="raise") and
>>> then it would be an error.
>> That'd work for me as well. Although I'm not sure about the name
>> "overflow", it sounds generic enough that it may be associated to many
>> different situations. If I want to have an error but only for this
>> very specific scenario (an "unsafe" cast in a mixed scalar/array
>> operation), would that be possible?
> I suggested "overflow" because that's how we signal rollover in
> general right now:
> In : np.int8(100) * np.int8(2)
> /home/njs/.user-python2.7-64bit/bin/ipython:1: RuntimeWarning:
> overflow encountered in byte_scalars
> Out: -56
> Two caveats on this: One, right now this is only implemented for
> scalars, not arrays -- which is bug #593 -- and two, I actually agree
> (?) that integer rollover and float overflow are different things we
> should probably add a new category to np.seterr() for integer rollover
> But the proposal here is that we not add a specific category for
> "unsafe cast" (which we would then have to define!), but instead just
> signal it using the standard mechanisms for the particular kind of
> corruption that happened. (Which right now is overflow, and might
> become something else later.)
Hehe, I didn't even know there was supposed to be a warning for arrays... Ok.
But I'm not convinced that re-using the "overflow" category is a good
idea, because to me the overflow is typically associated to the result
of an operation (when it goes beyond the dtype's supported range),
while here the problem is with the unsafe cast an input (even if it
makes no difference for addition, it does for some other ufuncs). I
may also want to have different error settings for operation overflow
vs. input overflow.
It may just be me though... let's see what others think about it.
>> Also, do we all agree that "float32 array + float64 scalar" should
>> cast the scalar to float32 (thus resulting in a float32 array as
>> output) without warning, even if the scalar can't be represented
>> exactly in float32?
> I guess for consistency, if this proposal is adopted then a float64
> which ends up getting cast to 'inf' or 0.0 should trigger an overflow
> or underflow warning respectively... e.g.:
> In : np.float64(1e300)
> Out: 1.0000000000000001e+300
> In : np.float32(_12)
> Out: inf
> ...but otherwise I think yes we agree.
Sounds good to me.
More information about the NumPy-Discussion