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
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
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
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
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
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
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
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
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
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.
10 matches
Mail list logo