On Apr 6, 2012, at 1:01 AM, Charles R Harris wrote: > > > On Thu, Apr 5, 2012 at 11:57 PM, Travis Oliphant <tra...@continuum.io> wrote: > As of 1.5.1 this worked: > > >>> numpy.__version__ > 1.5.1 > >>> numpy.uint64(5) & 3 > 1L > > > So, this is a regression and a bug. It should be fixed so that it doesn't > raise an error. I believe the scalars were special cased so that a raw 3 > would not be interpreted as a signed int when it is clearly unsigned. > The casting rules were well established over a long period. They had issues, > but they should not have been changed like this in a 1.X release. > > Fortunately there are work-arounds and these issues arise only in corner > cases, but we should strive to do better. > > > I disagree, promoting to object kind of destroys the whole idea of bitwise > operations. I think we *fixed* a bug.
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. In this particular case, what should the behavior be? It would be ideal if the scalar math did not just re-use the array-math machinery. Let's say that scalars had their own bit-wise operator. What should the output of numpy.uint64(5) & 3 actually be? I think it should interpret the 3 as unsigned and perform the operation (but not promote to an object). -Travis > > Chuck > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
