Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

This looks like a very logical addition to the reduce interface. It has my support! I would have preferred the more descriptive name "initial_value", but consistency with functools.reduce makes a compelling case for "initializer". On Sun, Mar 25, 2018 at 1:15 PM Eric Wieser wrote: > To reiterat

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

It turns out I mispoke - functools.reduce calls the argument `initial` On Mon, 26 Mar 2018 at 00:17 Stephan Hoyer wrote: > This looks like a very logical addition to the reduce interface. It has my > support! > > I would have preferred the more descriptive name "initial_value", but > consistency

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

It calls it `initializer` - See https://docs.python.org/3.5/library/functools.html#functools.reduce Sent from Astro for Mac On Mar 26, 2018 at 09:54, Eric Wieser wrote: It turns out I mispoke - functools.reduce calls the argument `initial` On Mon, 26 Mar 2018 at

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

Initializer or this sounds fine to me. As an other data point which I think has been mentioned before, `sum` uses start and min/max use default. `start` does not work, unless we also change the code to always use the identity if given (currently that is not the case), in which case it might be nice

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

Actually, the behavior right now isn’t that of `default` but that of `initializer` or `start`. This was discussed further down in the PR but to reiterate: `np.sum([10], initializer=5)` becomes `15`. Also, `np.min([5], initializer=0)` becomes `0`, so it isn’t really the default value, it’s the in

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

Huh, looks like it has different names in different places. `help(functools.reduce)` shows "initial". On Mon, Mar 26, 2018, 02:57 Hameer Abbasi wrote: > It calls it `initializer` - See > https://docs.python.org/3.5/library/functools.html#functools.reduce > > > Sent from Astro

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

OK, the new documentation is actually clear: initializer : scalar, optional The value with which to start the reduction. Defaults to the `~numpy.ufunc.identity` of the ufunc. If ``None`` is given, the first element of the reduction is used, and an error is throw

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

Hmm, this is neat. I imagine it would finally give some people a choice on what np.nansum([np.nan]) should return? It caused a huge hullabeloo a few years ago when we changed it from returning NaN to returning zero. Ben Root On Mon, Mar 26, 2018 at 11:16 AM, Sebastian Berg wrote: > OK, the new

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

That is the idea, but NaN functions are in a separate branch for another PR to be discussed later. You can see it on my fork, if you're interested. On 26/03/2018 at 17:35, Benjamin wrote: Hmm, this is neat. I imagine it would finally give some people a choice on what np.nansum([np.nan]) should retu

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

On Mon, 2018-03-26 at 11:39 -0400, Hameer Abbasi wrote: > That is the idea, but NaN functions are in a separate branch for > another PR to be discussed later. You can see it on my fork, if > you're > interested. Except that as far as I understand I am not sure it will help much with it, since it i

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

It'll need to be thought out for object arrays and subclasses. But for Regular numeric stuff, Numpy uses fmin and this would have the desired effect. On 26/03/2018 at 17:45, Sebastian wrote: On Mon, 2018-03-26 at 11:39 -0400, Hameer Abbasi wrote: That is the idea, but NaN functions are in a separat

Re: [Numpy-discussion] nditer as a context manager (reformatted?)

Given the lack of objections, we are probably going forward with this change to nditer. Anyone who uses nditers may have to update their code slightly if they want to avoid deprecation warnings, but otherwise old nditer code should work for a long time from now. Allan On 03/22/2018 01:43 PM, Mat

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

On Mon, 2018-03-26 at 11:53 -0400, Hameer Abbasi wrote: > It'll need to be thought out for object arrays and subclasses. But > for > Regular numeric stuff, Numpy uses fmin and this would have the > desired > effect. I do not want to block this, but I would like a clearer opinion about this issue,

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

On Mon, 2018-03-26 at 18:48 +0200, Sebastian Berg wrote: > On Mon, 2018-03-26 at 11:53 -0400, Hameer Abbasi wrote: > > It'll need to be thought out for object arrays and subclasses. But > > for > > Regular numeric stuff, Numpy uses fmin and this would have the > > desired > > effect. > > I do not

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

That may be complicated. Currently, the identity isn't used in object dtype reductions. We may need to change that, which could cause a whole lot of other backwards incompatible changes. For example, sum actually including zero in object reductions. Or we could pass in a flag saying an initializer

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

On Mon, 2018-03-26 at 12:59 -0400, Hameer Abbasi wrote: > That may be complicated. Currently, the identity isn't used in object > dtype reductions. We may need to change that, which could cause a > whole lot of other backwards incompatible changes. For example, sum > actually including zero in obje

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

The difficulty in supporting object arrays is that func.reduce(arr, initial=func.identity) and func.reduce(arr) have different meanings - whereas with the current patch, they are equivalent. ​ On Mon, 26 Mar 2018 at 10:10 Sebastian Berg wrote: > On Mon, 2018-03-26 at 12:59 -0400, Hameer Abbasi w

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

On Mon, 2018-03-26 at 17:40 +, Eric Wieser wrote: > The difficulty in supporting object arrays is that func.reduce(arr, > initial=func.identity) and func.reduce(arr) have different meanings - > whereas with the current patch, they are equivalent. > True, but the current meaning is: func.redu

[Numpy-discussion] Right way to do fancy indexing from argsort() result?

I seem to be losing my mind... I can't seem to get this to work right. I have a (N, k) array `distances` (along with a bunch of other arrays of the same shape). I need to resort the rows, so I do: indexs = np.argsort(distances, axis=1) How do I use this index array correctly to get back distance

Re: [Numpy-discussion] Right way to do fancy indexing from argsort() result?

On Mon, Mar 26, 2018 at 11:24 AM, Benjamin Root wrote: > > I seem to be losing my mind... I can't seem to get this to work right. > > I have a (N, k) array `distances` (along with a bunch of other arrays of the same shape). I need to resort the rows, so I do: > > indexs = np.argsort(distances, axi

Re: [Numpy-discussion] Right way to do fancy indexing from argsort() result?

Ah, yes, I should have thought about that. Kind of seems like something that we could make `np.take()` do, somehow, for something that is easier to read. Thank you! Ben Root On Mon, Mar 26, 2018 at 2:28 PM, Robert Kern wrote: > On Mon, Mar 26, 2018 at 11:24 AM, Benjamin Root > wrote: > > > >

Re: [Numpy-discussion] Right way to do fancy indexing from argsort() result?

https://github.com/numpy/numpy/issues/8708 is a proposal to add such a function, with an implementation in https://github.com/numpy/numpy/pull/8714 Eric On Mon, 26 Mar 2018 at 11:35 Benjamin Root wrote: > Ah, yes, I should have thought about that. Kind of seems like something > that we could m

Re: [Numpy-discussion] round(numpy.float64(0.0)) is a numpy.float64

Even knowing that, it's still confusing that round(np.float64(0.0)) isn't the same as round(0.0). The reason is a Python 2 / Python 3 thing: in Python 2, round returns a float, while on Python 3, it returns an integer – but numpy still uses the python 2 behavior everywhere. I'm not sure if it's po

Re: [Numpy-discussion] round(numpy.float64(0.0)) is a numpy.float64

On Mon, Mar 26, 2018 at 6:24 PM, Nathaniel Smith wrote: > Even knowing that, it's still confusing that round(np.float64(0.0)) > isn't the same as round(0.0). The reason is a Python 2 / Python 3 > thing: in Python 2, round returns a float, while on Python 3, it > returns an integer – but numpy stil

Re: [Numpy-discussion] round(numpy.float64(0.0)) is a numpy.float64

On Mon, Mar 26, 2018 at 6:28 PM, Nathaniel Smith wrote: > > On Mon, Mar 26, 2018 at 6:24 PM, Nathaniel Smith wrote: > > Even knowing that, it's still confusing that round(np.float64(0.0)) > > isn't the same as round(0.0). The reason is a Python 2 / Python 3 > > thing: in Python 2, round returns a

Re: [Numpy-discussion] round(numpy.float64(0.0)) is a numpy.float64

On Mon, Mar 26, 2018 at 10:29 PM, Robert Kern wrote: > On Mon, Mar 26, 2018 at 6:28 PM, Nathaniel Smith wrote: >> >> On Mon, Mar 26, 2018 at 6:24 PM, Nathaniel Smith wrote: >> > Even knowing that, it's still confusing that round(np.float64(0.0)) >> > isn't the same as round(0.0). The reason is a

Re: [Numpy-discussion] round(numpy.float64(0.0)) is a numpy.float64

On Mon, Mar 26, 2018 at 10:03 PM, wrote: > > On Mon, Mar 26, 2018 at 10:29 PM, Robert Kern wrote: > > On Mon, Mar 26, 2018 at 6:28 PM, Nathaniel Smith wrote: > >> > >> On Mon, Mar 26, 2018 at 6:24 PM, Nathaniel Smith wrote: > >> > Even knowing that, it's still confusing that round(np.float64(0.