[Numpy-discussion] subtract.reduce behavior

Alan G Isaac aisaac@american....
Fri Jul 23 10:17:56 CDT 2010


> 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



More information about the NumPy-Discussion mailing list