Proposed deprecations for 1.10: dot corner cases
Hi all, I'd like to suggest that we go ahead and add deprecation warnings to the following operations. This doesn't commit us to changing anything on any particular time scale, but it gives us more options later. 1) dot(A, B) where A and B *both* have *3 or more dimensions*: currently, this does a weird "outer product" thing, where it computes all pairwise matrix products. We've had numerous discussions about why this is suboptimal, and it contradicts the PEP 465 semantics for @, which broadcast + vectorize over extra dimensions. (If you have a vectorized version, then the outer product one is easy to derive; if you have only the outer product version .) While dot() is widely used in general, this particular varient is very, very rarely used. I propose we issue a FutureWarning here, so as to lay the groundwork for someday eventually making dot() and @ the same. 2) dot(A, B) where one of the argument is a scalar: currently, this does scalar multiplication. There is no logically consistent motivation for this, it violates TOOWTDI, and again it is inconsistent with the PEP semantics for @ (which are that this case should be an error). (NB for those still using np.matrix: scalar * np.matrix will still be supported regardless; this would only affect expressions where you actually call the dot() function.) I propose to make this a DeprecationWarning. -- Nathaniel J. Smith -- http://vorpus.org
On 5/9/2015 4:26 PM, Nathaniel Smith wrote:
dot(A, B) where one of the argument is a scalar: currently, this does scalar multiplication. There is no logically consistent motivation for this, it violates TOOWTDI, and again it is inconsistent with the PEP semantics for @ (which are that this case should be an error).
Do I recall incorrectly: I thought that reconciliation of `@` and `dot` was explicitly not part of the project on getting a `@` operator? I do not mean this to speak for or against the change above, which I only moderately oppose, but rather to the argument offered. As for the "logic" of the current behavior, can it not be given a tensor product motivation? (Otoh, it conflicts with the current behavior of `vdot`.) Alan
On May 11, 2015 12:44 PM, "Alan G Isaac"
On 5/9/2015 4:26 PM, Nathaniel Smith wrote:
dot(A, B) where one of the argument is a scalar: currently, this does scalar multiplication. There is no logically consistent motivation for this, it violates TOOWTDI, and again it is inconsistent with the PEP semantics for @ (which are that this case should be an error).
Do I recall incorrectly: I thought that reconciliation of `@` and `dot` was explicitly not part of the project on getting a `@` operator?
I do not mean this to speak for or against the change above, which I only moderately oppose, but rather to the argument offered.
Not sure what you mean. It's true that PEP 465 doesn't say anything about np.dot, because it's out of scope. The argument here, though, is not "PEP 465 says we have to do this". It's that it's confusing to have two different subtly different sets of semantics, and the PEP semantics are better (that's why we chose them), so we should at a minimum warn people who are getting the old behavior
As for the "logic" of the current behavior, can it not be given a tensor product motivation? (Otoh, it conflicts with the current behavior of `vdot`.)
Maybe? I don't know of any motivation that doesn't require treating it as a special case added only to duplicate existing behavior, but that doesn't mean one doesnt exist... -n
On 5/11/2015 3:52 PM, Nathaniel Smith wrote:
Not sure what you mean. It's true that PEP 465 doesn't say anything about np.dot, because it's out of scope. The argument here, though, is not "PEP 465 says we have to do this". It's that it's confusing to have two different subtly different sets of semantics, and the PEP semantics are better (that's why we chose them), so we should at a minimum warn people who are getting the old behavior
I would have to dig around, but I am pretty sure there were explicit statements that `@` would neither be bound by the behavior of `dot` nor expected to be reconciled with it. I agree that where `@` and `dot` differ in behavior, this should be clearly documented. I would hope that the behavior of `dot` would not change. Alan
On Mon, May 11, 2015 at 2:53 PM, Alan G Isaac
I agree that where `@` and `dot` differ in behavior, this should be clearly documented. I would hope that the behavior of `dot` would not change.
Even if np.dot never changes (and indeed, perhaps it should not), issuing these warnings seems like a good idea to me, once we have @ implemented with the new behavior (and the @ operator backported from Python <3.5 as a numpy function). I expect that this warning would serve the useful purpose of reminding users writing code intended to be used on earlier versions of numpy/python that @ and np.dot don't work exactly the same way. As Nathaniel already mentioned, it is quite straightforward to implement the "outer product" behavior using the new @ behavior, so it will not be much of a hassle to update code to remove the warning. Stephan
On Sat, May 9, 2015 at 1:26 PM, Nathaniel Smith
I'd like to suggest that we go ahead and add deprecation warnings to the following operations. This doesn't commit us to changing anything on any particular time scale, but it gives us more options later.
These both get a strong +1 from me. How long has the "outer product" behavior for np.dot been around?
participants (3)
-
Alan G Isaac -
Nathaniel Smith -
Stephan Hoyer