[Numpy-discussion] Regression: in-place operations (possibly intentional)
Charles R Harris
Tue Sep 18 18:52:24 CDT 2012
On Tue, Sep 18, 2012 at 5:02 PM, Travis Oliphant <email@example.com>wrote:
>>> That is sort of the point of all this. We are using 16 bit integers
>>> because we wanted to be as efficient as possible and didn't need anything
>>> larger. Note, that is what we changed the code to, I am just wondering if
>>> we are being too cautious. The casting kwarg looks to be what I might
>>> want, though it isn't as clean as just writing an "*=" statement.
>> I think even there you will have an intermediate float array followed by
>> a cast.
>> This is true, but it is done in chunks of a fixed size (controllable by a
>> thread-local variable or keyword argument to the ufunc).
>> How difficult would it be to change in-place operations back to the
>> "unsafe" default?
> Probably not too difficult, but I think it would be a mistake. What
> keyword argument are you referring to? In the current case, I think what is
> wanted is a scaling function that will actually do things in place. The
> matplotlib folks would probably be happier with the result if they simply
> coded up a couple of small Cython routines to do that.
> In particular, the extobj keyword argument or the thread-local variable at
Hmm, the ufunc documentation that comes with the functions needs an
> But, the problem is not just for matplotlib. Matplotlib is showing a
> symptom of the problem of just changing the default casting mode in one
> release. I think this is too stark of a change for a single minor
> release without some kind of glide path or warning system.
I think we need to change in-place multiplication back to "unsafe" and then
> put in the release notes that we are planning on changing this for 1.8.
> It would be ideal if we could raise a warning when "unsafe" castings occur.
I think that raising a warning would be appropriate, maybe with a note
concerning the future change since I expect few to read the release notes.
The new casting modes were introduced in 1.6 so code that needs to work
with older versions of numpy won't be able to use that option to work
around the default.
Type specific functions for scaling integers would be helpful, although I'd
probably restrict it to float32/float64 scaling factors to avoid
combinatorial bloat. Having such a function do the normal broadcasting
would probably be desirable.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion