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 <[email protected]> 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 <[email protected]> > 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 <https://www.helloastro.com> for Mac >> >> _______________________________________________ >> NumPy-Discussion mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] https://mail.python.org/mailman/listinfo/numpy-discussion
