Re: [Numpy-discussion] Bringing order to higher dimensional operations

2013-07-22 Thread Stéfan van der Walt
On Sat, Jul 20, 2013 at 7:44 AM, wrote: > related: is there any advantage to np.add.reduce? > I find it more difficult to read than sum() and still see it used sometimes. I think ``np.add.reduce`` just falls out of the ufunc implementation--there's no "per ufunc" choice to remove certain parts o

Re: [Numpy-discussion] Bringing order to higher dimensional operations

2013-07-19 Thread josef . pktd
On Fri, Jul 19, 2013 at 12:10 PM, Sebastian Berg wrote: > On Fri, 2013-07-19 at 16:14 +0100, Nathaniel Smith wrote: >> On Thu, Jul 18, 2013 at 2:23 PM, Sebastian Berg >> wrote: >> > On Thu, 2013-07-18 at 13:52 +0100, Nathaniel Smith wrote: >> >> Hi all, >> >> > >> >> What I mean is: Suppose we w

Re: [Numpy-discussion] Bringing order to higher dimensional operations

2013-07-19 Thread Nathaniel Smith
On Thu, Jul 18, 2013 at 2:23 PM, Sebastian Berg wrote: > On Thu, 2013-07-18 at 13:52 +0100, Nathaniel Smith wrote: >> Hi all, >> > >> >> So: >> >> QUESTION 1: does that sound right: that in a perfect world, the >> current gufunc convention would be the only one, and that's what we >> should work

Re: [Numpy-discussion] Bringing order to higher dimensional operations

2013-07-19 Thread Sebastian Berg
On Fri, 2013-07-19 at 16:14 +0100, Nathaniel Smith wrote: > On Thu, Jul 18, 2013 at 2:23 PM, Sebastian Berg > wrote: > > On Thu, 2013-07-18 at 13:52 +0100, Nathaniel Smith wrote: > >> Hi all, > >> > > What I mean is: Suppose we wrote a gufunc for 'sum', where the > intrinsic operation took a vec

Re: [Numpy-discussion] Bringing order to higher dimensional operations

2013-07-19 Thread Sebastian Berg
On Fri, 2013-07-19 at 16:31 +0100, Nathaniel Smith wrote: > On Thu, Jul 18, 2013 at 2:23 PM, Sebastian Berg > wrote: > > It is so difficult because of the fact that dot is basically a > > combination of many functions: > > o vector * vector -> vector > > o vector * matrix -> matrix (add dimens

Re: [Numpy-discussion] Bringing order to higher dimensional operations

2013-07-19 Thread Stéfan van der Walt
On Fri, Jul 19, 2013 at 5:31 PM, Nathaniel Smith wrote: > 3) Extend the gufunc machinery to understand the idea that some core > dimensions are allowed to take on a special "nonexistent" size. So the > signature for dot would be: > (m*,k) x (k, n*) -> (m*, n*) > where '*' denotes dimensions who

Re: [Numpy-discussion] Bringing order to higher dimensional operations

2013-07-19 Thread Nathaniel Smith
On Thu, Jul 18, 2013 at 2:23 PM, Sebastian Berg wrote: > It is so difficult because of the fact that dot is basically a > combination of many functions: > o vector * vector -> vector > o vector * matrix -> matrix (add dimensions to vector on right) > o matrix * vector -> matrix (add dimensio

Re: [Numpy-discussion] Bringing order to higher dimensional operations

2013-07-19 Thread Stéfan van der Walt
On Thu, Jul 18, 2013 at 2:52 PM, Nathaniel Smith wrote: > Compare: > gu_dot_leftwards(ones((10, 11, 4)), ones((11, 12, 3, 4))) -> (10, 12, 3, 4) > versus > gu_dot_rightwards(ones((4, 10, 11)), ones((3, 4, 11, 12))) -> (3, 4, 10, 12) The second makes quite a bit more sense to me, and fits with

Re: [Numpy-discussion] Bringing order to higher dimensional operations

2013-07-18 Thread Sebastian Berg
On Thu, 2013-07-18 at 13:52 +0100, Nathaniel Smith wrote: > Hi all, > > > So: > > QUESTION 1: does that sound right: that in a perfect world, the > current gufunc convention would be the only one, and that's what we > should work towards, at least in the cases where that's possible? > Sounds

[Numpy-discussion] Bringing order to higher dimensional operations

2013-07-18 Thread Nathaniel Smith
Hi all, I hadn't realized until Pauli just pointed it out that np.dot and the new gufuncs actually have different rules for how they handle extra axes: https://github.com/numpy/numpy/pull/3524#issuecomment-21117601 This is turning into a big mess, and it may take some hard decisions to fix it.