[Numpy-discussion] Bitwise operations and unsigned types

[Ralf Gommers]

On Sat, Apr 7, 2012 at 8:07 PM, Travis Oliphant <travis at continuum.io> wrote:

> If we just announce that there has been some code changes that alter
> corner-case casting rules, I think we can move forward.
>

Sounds good to me.


> 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?
>

I've opened http://projects.scipy.org/numpy/ticket/2101 so we remember to
do this before the 1.7 release.

Ralf


>
> On Apr 7, 2012, at 7:43 AM, Ralf Gommers <ralf.gommers at googlemail.com>
> wrote:
>
>
>
> On Fri, Apr 6, 2012 at 3:50 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>>
>>
>> On Fri, Apr 6, 2012 at 3:57 AM, Nathaniel Smith <njs at pobox.com> wrote:
>>
>>> On Fri, Apr 6, 2012 at 7:19 AM, Travis Oliphant <travis at continuum.io>
>>> 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,
>>> e.g.:
>>>
>>> In [4]: a
>>> Out[4]: array([0, 1, 2, 3])
>>>
>>> In [5]: a -= 1.5
>>>
>>> In [6]: a
>>> Out[6]: 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
>
>
>>
>>>
>>> https://github.com/charlton/charlton/commit/d58c72529a5b33d06b49544bc3347c6480dc4512
>>>
>>> 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.
>
> Ralf
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120410/3757ecaf/attachment.html>