<br><br><div class="gmail_quote">On Tue, Sep 18, 2012 at 9:13 PM, Benjamin Root <span dir="ltr"><<a href="mailto:ben.root@ou.edu" target="_blank">ben.root@ou.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div class="h5">On Tue, Sep 18, 2012 at 2:47 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div class="h5"><div><div>On Tue, Sep 18, 2012 at 11:39 AM, Benjamin Root <span dir="ltr"><<a href="mailto:ben.root@ou.edu" target="_blank">ben.root@ou.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div>On Mon, Sep 17, 2012 at 9:33 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div>On Mon, Sep 17, 2012 at 3:40 PM, Travis Oliphant <span dir="ltr"><<a href="mailto:travis@continuum.io" target="_blank">travis@continuum.io</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
On Sep 17, 2012, at 8:42 AM, Benjamin Root wrote:<br>
<br>
> Consider the following code:<br>
><br>
> import numpy as np<br>
> a = np.array([1, 2, 3, 4, 5], dtype=np.int16)<br>
> a *= float(255) / 15<br>
><br>
> In v1.6.x, this yields:<br>
> array([17, 34, 51, 68, 85], dtype=int16)<br>
><br>
> But in master, this throws an exception about failing to cast via same_kind.<br>
><br>
> Note that numpy was smart about this operation before, consider:<br>
> a = np.array([1, 2, 3, 4, 5], dtype=np.int16)<br>
> a *= float(128) / 256<br>
<br>
> yields:<br>
> array([0, 1, 1, 2, 2], dtype=int16)<br>
><br>
> Of course, this is different than if one does it in a non-in-place manner:<br>
> np.array([1, 2, 3, 4, 5], dtype=np.int16) * 0.5<br>
><br>
> which yields an array with floating point dtype in both versions. I can appreciate the arguments for preventing this kind of implicit casting between non-same_kind dtypes, but I argue that because the operation is in-place, then I (as the programmer) am explicitly stating that I desire to utilize the current array to store the results of the operation, dtype and all. Obviously, we can't completely turn off this rule (for example, an in-place addition between integer array and a datetime64 makes no sense), but surely there is some sort of happy medium that would allow these sort of operations to take place?<br>
><br>
> Lastly, if it is determined that it is desirable to allow in-place operations to continue working like they have before, I would like to see such a fix in v1.7 because if it isn't in 1.7, then other libraries (such as matplotlib, where this issue was first found) would have to change their code anyway just to be compatible with numpy.<br>
<br>
</div></div>I agree that in-place operations should allow different casting rules. There are different opinions on this, of course, but generally this is how NumPy has worked in the past.<br>
<br>
We did decide to change the default casting rule to "same_kind" but making an exception for in-place seems reasonable.<br></blockquote></div></div><div><br>I think that in these cases same_kind will flag what are most likely programming errors and sloppy code. It is easy to be explicit and doing so will make the code more readable because it will be immediately obvious what the multiplicand is without the need to recall what the numpy casting rules are in this exceptional case. IISTR several mentions of this before (Gael?), and in some of those cases it turned out that bugs were being turned up. Catching bugs with minimal effort is a good thing.<br>
<br>Chuck <br></div><br></div></blockquote></div></div><div><br>True, it is quite likely to be a programming error, but then again, there are many cases where it isn't. Is the problem strictly that we are trying to downcast the float to an int, or is it that we are trying to downcast to a lower precision? Is there a way for one to explicitly relax the same_kind restriction?<br>
</div></div></blockquote></div></div></div></div><div><div><div class="h5"><br>I think the problem is down casting across kinds, with the result that floats are truncated and the imaginary parts of imaginaries might be discarded. That is, the value, not just the precision, of the rhs changes. So I'd favor an explicit cast in code like this, i.e., cast the rhs to an integer.<br>
<br>It is true that this forces downstream to code up to a higher standard, but I don't see that as a bad thing, especially if it exposes bugs. And it isn't difficult to fix.<br><br></div></div>Chuck <br></div><br>
</div></blockquote>
<div><br>Mind you, in my case, casting the rhs as an integer before doing the multiplication would be a bug, since our value for the rhs is usually between zero and one. Multiplying first by the integer numerator before dividing by the integer denominator would likely cause issues with overflowing the 16 bit integer.<br>
</div></div></blockquote><div><br>Then you'd have to do<br><br>>>> a = np.array([1, 2, 3, 4, 5], dtype=np.int16)<br>>>> np.multiply(a, 0.5, out=a, casting="unsafe")<br>array([0, 1, 1, 2, 2], dtype=int16)<br>
<br></div></div>Ralf<br>