[Numpy-discussion] Proposal: Chaining np.dot with mdot helper function

[Nathaniel Smith]

On Thu, Feb 20, 2014 at 1:35 PM, Stefan Otte <stefan.otte at gmail.com> wrote:
> Hey guys,
>
> I quickly hacked together a prototype of the optimization step:
> https://github.com/sotte/numpy_mdot
>
> I think there is still room for improvements so feedback is welcome :)
> I'll probably have some time to code on the weekend.
>
> @Nathaniel, I'm still not sure about integrating it in dot. Don't a
> lot of people use the optional out parameter of dot?

The email you're replying to below about deprecating stuff in 'dot'
was in reply to Eric's email about using dot on arrays with shape (k,
n, n), so those comments are unrelated to the mdot stuff.

I wouldn't mind seeing out= arguments become kw-only in general, but
even if we decided to do that it would take a long deprecation period,
so yeah, let's give up on 'dot(A, B, C, D)' as syntax for mdot.

However, the suggestion of supporting np.dot([A, B, C, D]) still seems
like it might be a good idea...? I have mixed feelings about it -- one
less item cluttering up the namespace, but it is weird and magical to
have two totally different calling conventions for the same function.

-n

> On Thu, Feb 20, 2014 at 4:02 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> If you send a patch that deprecates dot's current behaviour for ndim>2,
>> we'll probably merge it. (We'd like it to function like you suggest, for
>> consistency with other gufuncs. But to get there we have to deprecate the
>> current behaviour first.)
>>
>> While I'm wishing for things I'll also mention that it would be really neat
>> if binary gufuncs would have a .outer method like regular ufuncs do, so
>> anyone currently using ndim>2 dot could just switch to that. But that's a
>> lot more work than just deprecating something :-).
>>
>> -n
>>
>> On 20 Feb 2014 09:27, "Eric Moore" <ewm at redtetrahedron.org> wrote:
>>>
>>>
>>>
>>> On Thursday, February 20, 2014, Eelco Hoogendoorn
>>> <hoogendoorn.eelco at gmail.com> wrote:
>>>>
>>>> If the standard semantics are not affected, and the most common
>>>> two-argument scenario does not take more than a single if-statement
>>>> overhead, I don't see why it couldn't be a replacement for the existing
>>>> np.dot; but others mileage may vary.
>>>>
>>>>
>>>> On Thu, Feb 20, 2014 at 11:34 AM, Stefan Otte <stefan.otte at gmail.com>
>>>> wrote:
>>>>>
>>>>> Hey,
>>>>>
>>>>> so I propose the following.  I'll implement a new function `mdot`.
>>>>> Incorporating the changes in `dot` are unlikely. Later, one can still
>>>>> include
>>>>> the features in `dot` if desired.
>>>>>
>>>>> `mdot` will have a default parameter `optimize`.  If `optimize==True`
>>>>> the
>>>>> reordering of the multiplication is done.  Otherwise it simply chains
>>>>> the
>>>>> multiplications.
>>>>>
>>>>> I'll test and benchmark my implementation and create a pull request.
>>>>>
>>>>> Cheers,
>>>>>  Stefan
>>>>> _______________________________________________
>>>>> NumPy-Discussion mailing list
>>>>> NumPy-Discussion at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>
>>>>
>>> Another consideration here is that we need a better way to work with
>>> stacked matrices such as np.linalg handles now.  Ie I want to compute the
>>> matrix product of two (k, n, n) arrays producing a (k,n,n) result.  Near as
>>> I can tell there isn't a way to do this right now that doesn't involve an
>>> explicit loop. Since dot will return a (k, n, k, n) result. Yes this output
>>> contains what I want but it also computes a lot of things that I don't want
>>> too.
>>>
>>> It would also be nice to be able to do a matrix product reduction, (k, n,
>>> n) -> (n, n) in a single line too.
>>>
>>> Eric
>>>
>>> _______________________________________________
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion



-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org