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

[Hameer Abbasi]

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 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
<sebastian at 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 <sebastian at 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 at gmail. > > > > com> > > > > wrote: > > > > > > > >
It turns out I mispoke - functools.reduce calls the argument > > > >
`initial` > > > > > > > > On Mon, 26 Mar 2018 at 00:17 Stephan Hoyer
<shoyer at 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 at 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 at python.org > > > > > > >
https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > >
> > > > > > _______________________________________________ > > > > >
> NumPy-Discussion mailing list > > > > > >
NumPy-Discussion at python.org > > > > > >
https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > >
> > > > _______________________________________________ > > > > >
NumPy-Discussion mailing list > > > > > NumPy-Discussion at python.org >
> > > > https://mail.python.org/mailman/listinfo/numpy-discussion > >
> > > > > > _______________________________________________ > > > >
NumPy-Discussion mailing list > > > > NumPy-Discussion at python.org > >
> > https://mail.python.org/mailman/listinfo/numpy-discussion > > > >
> > _______________________________________________ > > >
NumPy-Discussion mailing list > > > NumPy-Discussion at python.org > > >
https://mail.python.org/mailman/listinfo/numpy-discussion > > > >
_______________________________________________ > > NumPy-Discussion
mailing list > > NumPy-Discussion at python.org > >
https://mail.python.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ > NumPy-Discussion
mailing list > NumPy-Discussion at python.org >
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion
mailing list NumPy-Discussion at python.org
https://mail.python.org/mailman/listinfo/numpy-discussion