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

[Stefan Otte]

Hey guys,

I just pushed an updated version to github:
https://github.com/sotte/numpy_mdot

Here is an ipython notebook with some experiments:
http://nbviewer.ipython.org/urls/raw2.github.com/sotte/numpy_mdot/master/2014-02_numpy_mdot.ipynb

- I added (almost numpy compliant) documentation.
- I use a function for len(args) == 3 to improve the speed.
- Some general cleanup.

Before I create a pull request I have a few questions:
- Should there be an "optimize" argument or should we always optimize
the parentheses? There is an overhead, but maybe we could neglect it?
I think we should keep the flag, but set it to True by default.
- I currently use a recursive algorithm to do the multiplication. Any
objections?
- In which file should `mdot` live?
- I wrote a function `print_optimal_chain_order(D, A, B, C,
names=list("DABC"))` which determines the optimal parentheses and
print out a numpy expression. It's kinda handy but do we actually need
it?


Beste Grüße,
 Stefan



On Thu, Feb 20, 2014 at 8:39 PM, Nathaniel Smith <njs at pobox.com> wrote:
> 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
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion