[Numpy-discussion] [SciPy-Dev] 1.8.0rc1

[Charles R Harris]

On Tue, Oct 1, 2013 at 7:25 AM, Nathaniel Smith <njs at pobox.com> wrote:

> On Tue, Oct 1, 2013 at 1:56 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> > On Tue, Oct 1, 2013 at 4:43 AM, Nathaniel Smith <njs at pobox.com> wrote:
> >>
> >> On Mon, Sep 30, 2013 at 10:51 PM, Christoph Gohlke <cgohlke at uci.edu>
> >> wrote:
> >> > 2) Bottleneck 0.7.0
> >> >
> >> >
> https://github.com/kwgoodman/bottleneck/issues/71#issuecomment-25331701
> >>
> >> I can't tell if these are real bugs in numpy, or tests checking that
> >> bottleneck is bug-for-bug compatible with old numpy and we just fixed
> >> some bugs, or what. It's clearly something to do with the
> >> nanarg{max,min} rewrite -- @charris, do you know what's going on here?
> >>
> >
> > Yes ;) The previous behaviour of nanarg for all-nan axis was to cast nan
> to
> > intp when the result was an array, and return nan when a scalar. The
> current
> > behaviour is to return the most negative value of intp as an error
> marker in
> > both cases and raise a warning. It is a change in behavior, but I think
> one
> > that needs to be made.
>
> Ah, okay! I kind of lost track of the nanfunc changes by the end there.
>
> So for the bottleneck issue, it sounds like the problem is just that
> bottleneck is still emulating the old numpy behaviour in this corner
> case, which isn't really a problem. So we don't really need to worry
> about that, both behaviours are correct, just maybe out of sync.
>
> I'm a little dubious about this "make up some weird value that will
> *probably* blow up if people try to use it without checking, and also
> raise a warning" thing, wouldn't it make more sense to just raise an
> error? That's what exceptions are for? I guess I should have said
> something earlier though...
>
>
I figure the blowup is safe, as we can't allocate arrays big enough that
the minimum intp value would be a valid index. I considered raising an
error, and if there is a consensus the behavior could be changed. Or we
could add a keyword to determine the behavior.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20131001/6eae5808/attachment.html>