On Tue, Sep 18, 2012 at 5:02 PM, Travis Oliphant <tra...@continuum.io>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. > > > http://docs.scipy.org/doc/numpy/reference/ufuncs.html#ufunc > > In particular, the extobj keyword argument or the thread-local variable at > umath.UFUNC_PYVALS_NAME > Hmm, the ufunc documentation that comes with the functions needs an upgrade. > > 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. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
