[Numpy-discussion] Do we want scalar casting to behave as it does at the moment?

Olivier Delalleau shish@keba...
Sun Jan 6 19:43:42 CST 2013

2013/1/5 Nathaniel Smith <njs@pobox.com>:
> On Fri, Jan 4, 2013 at 5:25 PM, Andrew Collette
> <andrew.collette@gmail.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
>> exception.
> 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?

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?

-=- Olivier

More information about the NumPy-Discussion mailing list