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

[Olivier Delalleau]

Le vendredi 18 janvier 2013, Chris Barker - NOAA Federal a écrit :

> On Thu, Jan 17, 2013 at 5:34 PM, Olivier Delalleau <shish at keba.be<javascript:;>>
> wrote:
> >> Yes, I do understand that.  The difference - as I understand it - is
> >> that back in the day, numeric did not have the the float32 etc
> >> scalars, so you could not do:
> >>
> >> another_array = my_array * np.float32(4.0)
> >>
> >> (please someone correct me if I'm wrong).
>
> correct, it didn't have any scalars, but you could (and had to) still
> do something like:
>
> another_array = my_array * np.array(4.0, dtype=np.float32)
>
> a bit more verbose, but the verbosity wasn't the key issue -- it was
> doing anything special at all.
>
> >>> Casual users will use the defaults that match the Python types anyway.
> >>
> >> I think what we are reading in this thread is that even experienced
> >> numpy users can find the scalar casting rules surprising, and that's a
> >> real problem, it seems to me.
>
> for sure -- but it's still relevant -- if you want non-default types,
> you need to understand the rules an be more careful.
>
> >> The person with a massive float32 array certainly should have the
> >> ability to control upcasting, but I think the default should be the
> >> least surprising thing, and that, it seems to me, is for the casting
> >> rules to be the same for arrays and scalars.   In the very long term.
>
> "A foolish consistency is the hobgoblin of little minds"
>
> -- just kidding.
>
> But in all seriousness -- accidental upcasting really was a big old
> pain back in the day -- we are not making this up. We re using the
> term "least surprising", but I now I was often surprised that I had
> lost my nice compact array.
>
> The user will need to think about it no matter how you slice it.
>
> > Since most of the related issues seem to come from integer arrays, a
> > middle-ground may be the following:
> > - Integer-type arrays get upcasted by scalars as in usual array /
> > array operations.
> > - Float/Complex-type arrays don't get upcasted by scalars except when
> > the scalar is complex and the array is float.
>
> I'm not sure that integer arrays are any more of an an issue, and
> having integer types and float typed behave differently is really
> asking for trouble!


"A foolish consistency is the hobgoblin of little minds" :P

If you check again the examples in this thread exhibiting surprising /
unexpected behavior, you'll notice most of them are with integers.
The tricky thing about integers is that downcasting can dramatically change
your result. With floats, not so much: you get approximation errors
(usually what you want) and the occasional nan / inf creeping in (usally
noticeable).

I too would prefer similar rules between ints & floats, but after all these
discussions I'm starting to think it may be worth acknowledging they are
different beasts.

Anyway, in my mind we were discussing what might be the desired behavior in
the long term, and my suggestion isn't practical in the short term since it
may break a significant amount of code. So I'm still in favor of
Nathaniel's proposal, except with exceptions replaced by warnings by
default (and no warning for lossy downcasting of e.g. float64 ->
float32 except for zero / inf, as discussed at some point in the thread).
-=- Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130118/b9f00c5b/attachment.html>