[Numpy-discussion] Casting Bug or a "Feature"?

Olivier Delalleau shish@keba...
Fri Jan 18 06:26:57 CST 2013

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

> On Thu, Jan 17, 2013 at 5:19 PM, Olivier Delalleau <shish@keba.be<javascript:;>>
> wrote:
> > 2013/1/16  <josef.pktd@gmail.com <javascript:;>>:
> >> On Wed, Jan 16, 2013 at 10:43 PM, Patrick Marsh
> >> <patrickmarshwx@gmail.com <javascript:;>> wrote:
> >> I could live with an exception for lossy down casting in this case.
> I'm not sure what the idea here is -- would you only get an exception
> if the value was such that the downcast would be lossy? If so, a major
> -1
> The other option would be to always raise an exception if types would
> cause a downcast, i.e:
> arr = np.zeros(shape, dtype-uint8)
> arr2 = arr + 30 # this would raise an exception
> arr2 = arr + np.uint8(30) # you'd have to do this
> That sure would be clear and result if few errors of this type, but
> sure seems verbose and "static language like" to me.
> > Long story short, +1 for warning, -1 for exception, and +1 for a
> > config flag that allows one to change to exceptions by default, if
> > desired.
> is this for value-dependent or any casting of this sort?

What I had in mind here is the situation where the scalar's dtype is
fundamentally different from the array's dtype (i.e. float vs int, complex
vs float) and can't be cast exactly into the array's dtype (so,
value-dependent), which is the situation that originated this thread.
I don't mind removing the second part ("and can't be cast exactly...") to
have it value-independent.
Other tricky situations with integer arrays are to some extent related to
how regular (not in-place) additions are handled, something that should
probably be settled first.

-=- Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20130118/16bd1dd4/attachment.html 

More information about the NumPy-Discussion mailing list