Hi, From the dot documentation, I tried something simple: a = np.array([[1, 2], [3, 4]]) b = np.array([[1, 2], [3, 4]]) np.dot(a, b) > array([[ 7, 10], [15, 22]]) And I got expected result but if I use either a or b as output, results are wrong (and nothing in the dot documentation prevents me from doing this): a = np.array([[1, 2], [3, 4]]) b = np.array([[1, 2], [3, 4]]) np.dot(a,b,out=a) > array([[ 6, 20], [15, 46]]) a = np.array([[1, 2], [3, 4]]) b = np.array([[1, 2], [3, 4]]) np.dot(a,b,out=b) > array([[ 6, 10], [30, 46]]) Can anyone confirm this behavior ? (tested using numpy 1.7.1) Nicolas
Hi Nicolas, Le 23/05/2013 15:45, Nicolas Rougier a écrit :
if I use either a or b as output, results are wrong (and nothing in the dot documentation prevents me from doing this):
a = np.array([[1, 2], [3, 4]]) b = np.array([[1, 2], [3, 4]]) np.dot(a,b,out=a)
> array([[ 6, 20], [15, 46]])
Can anyone confirm this behavior ? (tested using numpy 1.7.1) I just reproduced the same weird results with numpy 1.6.2
best, Pierre
Hi, It's to be expected. You are overwritten one of your input vector while it is still being used. So not a numpy bug ;) Matthieu 2013/5/23 Pierre Haessig <pierre.haessig@crans.org>
Hi Nicolas,
Le 23/05/2013 15:45, Nicolas Rougier a écrit :
if I use either a or b as output, results are wrong (and nothing in the dot documentation prevents me from doing this):
a = np.array([[1, 2], [3, 4]]) b = np.array([[1, 2], [3, 4]]) np.dot(a,b,out=a)
> array([[ 6, 20], [15, 46]])
Can anyone confirm this behavior ? (tested using numpy 1.7.1) I just reproduced the same weird results with numpy 1.6.2
best, Pierre
_______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
 Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher Music band: http://liliejay.com/
On Thu, May 23, 2013 at 3:19 PM, Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
Hi,
It's to be expected. You are overwritten one of your input vector while it is still being used. So not a numpy bug ;)
Sure, that's clearly what's going on, but numpy shouldn't let you silently shoot yourself in the foot like that. Reusing input as output is a very common operation, and usually supported fine. Probably we should silently make a copy of any input(s) that overlap with the output? For highdimensional dot, buffering temprary subspaces would still be more memory efficient than anything users could reasonably accomplish by hand. n
Sure, that's clearly what's going on, but numpy shouldn't let you silently shoot yourself in the foot like that. Reusing input as output is a very common operation, and usually supported fine. Probably we should silently make a copy of any input(s) that overlap with the output? For highdimensional dot, buffering temprary subspaces would still be more memory efficient than anything users could reasonably accomplish by hand.
Also, from a user point of view it is difficult to sort out which functions currently allow 'out=a' or out=b' since nothing in the 'dot' documentation warned me about such problem. Nicolas
In my point of view, you should never use an output argument equal to an input argument. It can impede a lot of optimizations. Matthieu 2013/5/23 Nicolas Rougier <Nicolas.Rougier@inria.fr>
Sure, that's clearly what's going on, but numpy shouldn't let you silently shoot yourself in the foot like that. Reusing input as output is a very common operation, and usually supported fine. Probably we should silently make a copy of any input(s) that overlap with the output? For highdimensional dot, buffering temprary subspaces would still be more memory efficient than anything users could reasonably accomplish by hand.
Also, from a user point of view it is difficult to sort out which functions currently allow 'out=a' or out=b' since nothing in the 'dot' documentation warned me about such problem.
Nicolas
_______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
 Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher Music band: http://liliejay.com/
On Thu, May 23, 2013 at 3:57 PM, Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
In my point of view, you should never use an output argument equal to an input argument. It can impede a lot of optimizations.
This is a fine philosophy in some cases, but a nonstarter in others. Python doesn't have optimizations in the first place, and inplace operations are often critical for managing memory usage. '+=' is an important operator, and in numpy it's just 'np.add(a, b, out=a)' under the hood. On Thu, May 23, 2013 at 3:50 PM, Nicolas Rougier <Nicolas.Rougier@inria.fr> wrote:
Also, from a user point of view it is difficult to sort out which functions currently allow 'out=a' or out=b' since nothing in the 'dot' documentation warned me about such problem.
That's because AFAIK all functions allow out=a and out=b, except for those which contain bugs :). Can you file a bug in the bug tracker so this won't get lost? n
On Thu, May 23, 2013 at 11:14 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Thu, May 23, 2013 at 3:57 PM, Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
In my point of view, you should never use an output argument equal to an input argument. It can impede a lot of optimizations.
This is a fine philosophy in some cases, but a nonstarter in others. Python doesn't have optimizations in the first place, and inplace operations are often critical for managing memory usage. '+=' is an important operator, and in numpy it's just 'np.add(a, b, out=a)' under the hood.
Isn't dot handled by Lapack, and whatever optimized version is available? Josef
On Thu, May 23, 2013 at 3:50 PM, Nicolas Rougier <Nicolas.Rougier@inria.fr> wrote:
Also, from a user point of view it is difficult to sort out which functions currently allow 'out=a' or out=b' since nothing in the 'dot' documentation warned me about such problem.
That's because AFAIK all functions allow out=a and out=b, except for those which contain bugs :).
Can you file a bug in the bug tracker so this won't get lost?
n _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Thu, May 23, 2013 at 7:19 AM, Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
It's to be expected. You are overwritten one of your input vector while it is still being used. So not a numpy bug ;)
It's a doc bug, at least. Chris  Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 5266959 voice 7600 Sand Point Way NE (206) 5266329 fax Seattle, WA 98115 (206) 5266317 main reception Chris.Barker@noaa.gov
On Thu, 20130523 at 15:42 +0100, Nathaniel Smith wrote:
On Thu, May 23, 2013 at 3:19 PM, Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
Hi,
It's to be expected. You are overwritten one of your input vector while it is still being used. So not a numpy bug ;)
Sure, that's clearly what's going on, but numpy shouldn't let you silently shoot yourself in the foot like that. Reusing input as output is a very common operation, and usually supported fine. Probably we should silently make a copy of any input(s) that overlap with the output? For highdimensional dot, buffering temprary subspaces would still be more memory efficient than anything users could reasonably accomplish by hand.
Not sure whether you can easily implement buffering of subspaces with the (g)ufunc machinery, but that shouldn't worry much. The other thing is, that this problem generally exists for all ufuncs, only that for normal ones it is more difficult to trigger. This is after all much like the old, common and completely warranted complaint that `a += a.T` is not well defined. Only that for np.dot fixing it is a bit more obvious since nobody would abuse such inplace behaviour. Personally I think detecting this and at least warning for now in the (g)ufunc machinery would make a lot of sense. We can just hope someone feels like attempting such a feature :).  Sebastian
n _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
participants (7)

Chris Barker  NOAA Federal

josef.pktd＠gmail.com

Matthieu Brucher

Nathaniel Smith

Nicolas Rougier

Pierre Haessig

Sebastian Berg