> Fri, 23 Jul 2010 10:29:47 -0400, Alan G Isaac wrote:
>> >>> np.subtract.reduce([])
>> 0.0
>>>> Getting a right identity for an empty array is surprising. Matching
>> Python's behavior (raising a TypeError) seems desirable. (?)
On 7/23/2010 10:37 AM, Pauli Virtanen wrote:
> I don't think matching Python's behavior is a sufficient argument for a
> change. As far as I see, it'd mostly cause unnecessary breakage, with no
> significant gain.
>> Besides, it's rather common to define
>> sum_{z in Z} z = 0
> prod_{z in Z} z = 1
>> if Z is an empty set -- this can then be extended to other reduction
> operations. Note that changing reduce behavior would require us to
> special-case the above two operations.
To reduce (pun intended) surprise is always a significant gain.
I don't understand the notion of "extend" you introduce here.
The natural "extension" is to take a start value,
as with Python's ``reduce``. Providing a default start value
is natural for operators with an identity and is not for
those without, and correspondingly we end up with ``sum``
and ``prod`` functions (which match reduce with the obvious
default start value) but no equivalents for subtraction
and division.
I also do not understand why there would have to be any
special cases.
Returning a *right* identity for an operation that is
otherwise a *left* fold is very odd, no matter how you slice it.
That is what looks like special casing ...
Alan Isaac