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 <sebast...@sipsolutions.net > wrote: > 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 thrown if the reduction is empty. If ``a.dtype`` is > ``object``, then the initializer is _only_ used if reduction is > empty. > > I would actually like to say that I do not like the object special case > much (and it is probably the reason why I was confused), nor am I quite > sure this is what helps a lot? Logically, I would argue there are two > things: > > 1. initializer/start (always used) > 2. default (oly used for empty reductions) > > For example, I might like to give `np.nan` as the default for some > empty reductions, this will not work. I understand that this is a > minimal invasive PR and I am not sure I find the solution bad enough to > really dislike it, but what do other think? My first expectation was > the default behaviour (in all cases, not just object case) for some > reason. > > To be honest, for now I just wonder a bit: How hard would it be to do > both, or is that too annoying? It would at least get rid of that > annoying thing with object ufuncs (which currently have a default, but > not really an identity/initializer). > > Best, > > Sebastian > > > On Mon, 2018-03-26 at 08:20 -0400, Hameer Abbasi wrote: > > 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 initial value among which the reduction > > is performed. > > > > This was the reason to call it initializer in the first place. I like > > `initial` and `initial_value` as well, and `start` also makes sense > > but isn’t descriptive enough. > > > > Hameer > > Sent from Astro for Mac > > > > > On Mar 26, 2018 at 12:06, Sebastian Berg <sebast...@sipsolutions.ne > > > t> wrote: > > > > > > 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. However, "start" seems a bit like > > > solving > > > a different issue in any case. > > > > > > Anyway, mostly noise. I really like adding this, the only thing > > > worth > > > discussing a bit is the name :). > > > > > > - Sebastian > > > > > > > > > On Mon, 2018-03-26 at 05:57 -0400, Hameer Abbasi wrote: > > > > It calls it `initializer` - See https://docs.python.org/3.5/libra > > > > ry/f > > > > unctools.html#functools.reduce > > > > > > > > Sent from Astro for Mac > > > > > > > > > On Mar 26, 2018 at 09:54, Eric Wieser <wieser.eric+numpy@gmail. > > > > > com> > > > > > wrote: > > > > > > > > > > It turns out I mispoke - functools.reduce calls the argument > > > > > `initial` > > > > > > > > > > On Mon, 26 Mar 2018 at 00:17 Stephan Hoyer <sho...@gmail.com> > > > > > 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 with functools.reduce makes a compelling case > > > > > > for > > > > > > "initializer". > > > > > > > > > > > > On Sun, Mar 25, 2018 at 1:15 PM Eric Wieser <wieser.eric+nump > > > > > > y@gm > > > > > > ail.com> wrote: > > > > > > > To reiterate my comments in the issue - I'm in favor of > > > > > > > this. > > > > > > > > > > > > > > It seems seem especially valuable for identity-less > > > > > > > functions > > > > > > > (`min`, `max`, `lcm`), and the argument name is consistent > > > > > > > with > > > > > > > `functools.reduce`. too. > > > > > > > > > > > > > > The only argument I can see against merging this would be > > > > > > > `kwarg`-creep of `reduce`, and I think this has enough use > > > > > > > cases to justify that. > > > > > > > > > > > > > > I'd like to merge in a few days, if no one else has any > > > > > > > opinions. > > > > > > > > > > > > > > Eric > > > > > > > > > > > > > > On Fri, 16 Mar 2018 at 10:13 Hameer Abbasi <einstein.edison > > > > > > > @gma > > > > > > > il.com> wrote: > > > > > > > > Hello, everyone. I’ve submitted a PR to add a initializer > > > > > > > > kwarg to ufunc.reduce. This is useful in a few cases, > > > > > > > > e.g., > > > > > > > > it allows one to supply a “default” value for identity- > > > > > > > > less > > > > > > > > ufunc reductions, and specify an initial value for > > > > > > > > reductions > > > > > > > > such as sum (other than zero.) > > > > > > > > > > > > > > > > Please feel free to review or leave feedback, (although I > > > > > > > > think Eric and Marten have picked it apart pretty well). > > > > > > > > > > > > > > > > https://github.com/numpy/numpy/pull/10635 > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Hameer > > > > > > > > Sent from Astro for Mac > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > NumPy-Discussion mailing list > > > > > > > > NumPy-Discussion@python.org > > > > > > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > > > > > > > > _______________________________________________ > > > > > > > NumPy-Discussion mailing list > > > > > > > NumPy-Discussion@python.org > > > > > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > > > > > > _______________________________________________ > > > > > > NumPy-Discussion mailing list > > > > > > NumPy-Discussion@python.org > > > > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > > > > _______________________________________________ > > > > > NumPy-Discussion mailing list > > > > > NumPy-Discussion@python.org > > > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > > _______________________________________________ > > > > NumPy-Discussion mailing list > > > > NumPy-Discussion@python.org > > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > _______________________________________________ > > > NumPy-Discussion mailing list > > > NumPy-Discussion@python.org > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
