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 <https://www.helloastro.com> for Mac On Mar 26, 2018 at 12:06, Sebastian Berg <sebast...@sipsolutions.net> 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/library/f unctools.html#functools.reduce Sent from Astro for Mac On Mar 26, 2018 at 09:54, Eric Wieser <wieser.eric+nu...@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+numpy@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
