Re: [Numpy-discussion] subtract.reduce behavior

2010-07-27 Thread Alan G Isaac
On 7/26/2010 9:41 AM, Johann Hibschman wrote: > if reduce were defined as a *right* fold, then it would make sense for > subtract (and divide) to use the right identity Instead of deviating from the Python definition of reduce, it would imo make more sense to introduce new functions, sayfoldl and

Re: [Numpy-discussion] subtract.reduce behavior

2010-07-26 Thread Johann Hibschman
Pauli Virtanen writes: >> 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... > > I think I see your point now. I know this is unlikely to happen, since it would break things for a

Re: [Numpy-discussion] subtract.reduce behavior

2010-07-23 Thread Pauli Virtanen
Fri, 23 Jul 2010 11:17:56 -0400, Alan G Isaac wrote: [clip] > I also do not understand why there would have to be any special cases. That's a technical issue: e.g. prod() is implemented via np.multiply.reduce, and it is not clear to me whether it is possible, in the ufunc machinery, to leave the

Re: [Numpy-discussion] subtract.reduce behavior

2010-07-23 Thread Alan G Isaac
> 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

Re: [Numpy-discussion] subtract.reduce behavior

2010-07-23 Thread Pauli Virtanen
Fri, 23 Jul 2010 10:29:47 -0400, Alan G Isaac wrote: [clip] > >>> np.subtract.reduce([]) > 0.0 > > Getting a right identity for an empty array is surprising. Matching > Python's behavior (raising a TypeError) seems desirable. (?) I don't think matching Python's behavior is a suf

Re: [Numpy-discussion] subtract.reduce behavior

2010-07-23 Thread Alan G Isaac
On 7/22/2010 4:00 PM, Johann Hibschman wrote: > I'm trying to understand numpy.subtract.reduce. The documentation > doesn't seem to match the behavior. The documentation claims > >For a one-dimensional array, reduce produces results equivalent to: > >r = op.identity >for i in xrange(l

Re: [Numpy-discussion] subtract.reduce behavior

2010-07-22 Thread Johann Hibschman
Pauli Virtanen writes: > The documentation is incorrect. Thanks. The observed behavior is more like: if len(A) == 0: return op.identity else: r = A[0] for i in xrange(1, len(A): r = op(r, A[i]) return r -Johann ___ NumPy-D

Re: [Numpy-discussion] subtract.reduce behavior

2010-07-22 Thread Pauli Virtanen
Thu, 22 Jul 2010 15:00:50 -0500, Johann Hibschman wrote: [clip] > Now, I'm on an older version (1.3.0), which might be the problem, but > which is "correct" here, the code or the docs? The documentation is incorrect. -- Pauli Virtanen ___ NumPy-Discus

Re: [Numpy-discussion] subtract.reduce behavior

2010-07-22 Thread Warren Weckesser
John Salvatier wrote: > I get the same result on 1.4.1 > > On Thu, Jul 22, 2010 at 1:00 PM, Johann Hibschman > mailto:jhibschman%2bnu...@gmail.com>> wrote: > > I'm trying to understand numpy.subtract.reduce. The documentation > doesn't seem to match the behavior. The documentation claims

Re: [Numpy-discussion] subtract.reduce behavior

2010-07-22 Thread John Salvatier
I get the same result on 1.4.1 On Thu, Jul 22, 2010 at 1:00 PM, Johann Hibschman < jhibschman+nu...@gmail.com > wrote: > I'm trying to understand numpy.subtract.reduce. The documentation > doesn't seem to match the behavior. The documentation claims > > For a one-dimensional array, reduce prod

[Numpy-discussion] subtract.reduce behavior

2010-07-22 Thread Johann Hibschman
I'm trying to understand numpy.subtract.reduce. The documentation doesn't seem to match the behavior. The documentation claims For a one-dimensional array, reduce produces results equivalent to: r = op.identity for i in xrange(len(A)): r = op(r,A[i]) return r However, numpy.subtra