8000 Deprecate ndim > 2 behavior in dot for 1.9 · Issue #4397 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Deprecate ndim > 2 behavior in dot for 1.9 #4397

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
ewmoore opened this issue Feb 28, 2014 · 12 comments
Closed

Deprecate ndim > 2 behavior in dot for 1.9 #4397

ewmoore opened this issue Feb 28, 2014 · 12 comments
Labels
17 - Task component: numpy._core Proposal

Comments

@ewmoore
Copy link
Contributor
ewmoore commented Feb 28, 2014

Given that numpy is moving toward allowing its linear algebra routines to operate on (k, m,n) arrays where the array represents a stack of k, (m, n) matrices, it is important to provide a matrix multiply that can operate on such objects without unnecessary contortions. The current behavior for np.dot with ndim > 2 doesn't provide this. As the first step to providing it, the ndim > 2 behavior should be deprecated in the next release so that it can be changed sooner rather than later.

I would suggest that this be a 1.9 blocker.
@pv
Copy link
Member
pv commented Feb 28, 2014

There is an implementation for this in umath_linalg that can be
resurrected from the (removed) _umath_linalg.py file.

@pv
Copy link
Member
pv commented Feb 28, 2014

Also, changing behavior of dot sounds a bit annoying change from the POV of downstream users. It might be better for backward compatibilty to add a new function (matmul or something) with the new behavior.

@abalkin
Copy link
Contributor
abalkin commented Feb 28, 2014

.. to add a new function (matmul or something) with the new behavior.

+1

I think a new function should be implemented regardless of any deprecations to nail down the new semantics.

I will open a separate issue for that unless someone beats me to it.

@jaimefrio
Copy link
Member

The functionality is already available, even if undocumented, in umath_tests:

>>> np.__version__
'1.8.0'
>>> from numpy.core.umath_tests import matrix_multiply
>>> print(matrix_multiply.__doc__)
matrix_multiply(x1, x2[, out])

matrix multiplication on last two dimensions 
     "(m,n),(n,p)->(m,p)" 
>>> matrix_multiply(np.random.rand(100, 5, 6),
...                 np.random.rand(100, 6, 9)).shape
(100L, 5L, 9L)

If a new function was created and exposed, it should probably use DGEEM, which matrix_multiply currently doesn't, and having some form of .reduce method for square matrices would also be a nice to have.

@pv
Copy link
Member
pv commented Feb 28, 2014

@jaime: There's a proper BLAS implementation that can be resurrected
from umath_linalg 0f51682

@njsmith
Copy link
Member
njsmith commented Feb 28, 2014

I suggest:
Step 1: deprecate >2d dot; add a broadcasting version under a different name
Step 2: make >2d dot an error
Step 3: make dot switch to broadcasting; deprecate the older broadcasting
version, which is now just an alias for dot

Different steps as intended to occur some time apart, like a year maybe.

Eventually we could as step 4 remove the matrix_multiply alias, but there
wouldn't really be any cost to leaving it in indefinitely.
On 28 Feb 2014 10:31, "Pauli Virtanen" notifications@github.com wrote:

@jaime: There's a proper BLAS implementation that can be resurrected
from umath_linalg 0f51682

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4397#issuecomment-36361633
.

@jaimefrio
Copy link
Member

Why did matrix_multiply and inner1d get the ax? The versions in umath_tests can be easily replaced with np.einsum, but a properly implemented BLAS version of a function encompassing both would be great to have. Even if there is no agreement on the deprecation of dot, I'm all +1 on the new function.

@seberg
Copy link
Member
seberg commented Feb 28, 2014

It didn't, it just never existed in the public API.

@jaimefrio
Copy link
Member

Yes, I understand that, but it was ready to be included in the gufuncs version of linalg but never made it.

@njsmith
Copy link
Member
njsmith commented Feb 28, 2014

I don't remember what happened, but probably we decided we didn't want to
commit to supporting it until we'd made a decision on how dot and gufuncs
should work. Which we now have, I guess.

T 8000 here's also the problem that the gufunc as written doesn't handle 1d
arguments correctly. Probably we don't have to fix that before deprecating
the >2d behaviour for dot though. If there is anyone doing dot(>2d, 1d),
then they can probably live with a slightly more elaborate call for a bit.
On 28 Feb 2014 18:10, "Jaime" notifications@github.com wrote:

Yes, I understand that, but it was ready to be included in the gufuncs
version of linalg but never made it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4397#issuecomment-36404266
.

@pv
Copy link
Member
pv commented Feb 28, 2014

The point was that the stuff was not ready to be included, and nobody at the time wanted to spend time cleaning the stuff up. There is an issue tracking the situation: gh-3217

@pv pv mentioned this issue Mar 9, 2014
Closed
@mattip
Copy link
Member
mattip commented Jul 19, 2018

Closing this, we cannot deprecate the dot multi-dimensional behaviour. matmul provides a gufunc-freindly version of matrix multiplication. Please reopen if I missed the point.

@mattip mattip closed this as completed Jul 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
17 - Task component: numpy._core Proposal
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@pv @seberg @abalkin @njsmith @mattip @ewmoore @jaimefrio
0