On Sat, Apr 7, 2012 at 8:07 PM, Travis Oliphant <tra...@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.gomm...@googlemail.com> > wrote: > > > > On Fri, Apr 6, 2012 at 3:50 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Fri, Apr 6, 2012 at 3:57 AM, Nathaniel Smith <n...@pobox.com> wrote: >> >>> On Fri, Apr 6, 2012 at 7:19 AM, Travis Oliphant <tra...@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@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 > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
