[Numpy-discussion] Bitwise operations and unsigned types
Sat Apr 7 13:07:59 CDT 2012
If we just announce that there has been some code changes that alter corner-case casting rules, I think we can move forward.
We could use a script to document the changes and create a test case which would help people figure out their code.
Please speak up if you have another point of view?
(on a mobile)
On Apr 7, 2012, at 7:43 AM, Ralf Gommers <firstname.lastname@example.org> wrote:
> On Fri, Apr 6, 2012 at 3:50 PM, Charles R Harris <email@example.com> wrote:
> On Fri, Apr 6, 2012 at 3:57 AM, Nathaniel Smith <firstname.lastname@example.org> wrote:
> On Fri, Apr 6, 2012 at 7:19 AM, Travis Oliphant <email@example.com> wrote:
> > That is an interesting point of view. I could see that point of view.
> > But, was this discussed as a bug prior to this change occurring?
> > I just heard from a very heavy user of NumPy that they are nervous about
> > upgrading because of little changes like this one. I don't know if this
> > particular issue would affect them or not, but I will re-iterate my view
> > that we should be very careful of these kinds of changes.
> I agree -- these changes make me very nervous as well, especially
> since I haven't seen any short, simple description of what changed or
> what the rules actually are now (comparable to the old "scalars do not
> affect the type of arrays").
> But, I also want to speak up in favor in one respect, since real world
> data points are always good. I had some code that did
> def do_something(a):
> a = np.asarray(a)
> a -= np.mean(a)
> If someone happens to pass in an integer array, then this is totally
> broken -- np.mean(a) may be non-integral, and in 1.6, numpy silently
> discards the fractional part and performs the subtraction anyway,
> In : a
> Out: array([0, 1, 2, 3])
> In : a -= 1.5
> In : a
> Out: array([-1, 0, 0, 1])
> The bug was discovered when Skipper tried running my code against
> numpy master, and it errored out on the -=. So Mark's changes did
> catch one real bug that would have silently caused completely wrong
> numerical results!
> As a second datapoint, it did catch real bugs in scikit-learn too. On the other hand, it required a workaround in ndimage. http://thread.gmane.org/gmane.comp.python.numeric.general/44206/focus=44208
> Yes, these things are trade offs between correctness and convenience. I don't mind new warnings/errors so much, they may break old code but they don't lead to wrong results. It's the unexpected and unnoticed successes that are scary.
> We discussed reverting the unsafe casting behavior for 1.7 in the thread I linked to above. Do we still want to do this? As far as I can tell it didn't really cause problems so far.
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion