> >> >> 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 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. -Travis
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
