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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- 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. Re-using 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 high-dimensional 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. Re-using 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 high-dimensional 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. Re-using 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 high-dimensional 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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- 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 non-starter in others. Python doesn't have optimizations in the first place, and in-place 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 non-starter in others. Python doesn't have optimizations in the first place, and in-place 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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, 2013-05-23 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. Re-using 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 high-dimensional 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 in-place 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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
participants (7)
-
Chris Barker - NOAA Federal -
josef.pktd＠gmail.com -
Matthieu Brucher -
Nathaniel Smith -
Nicolas Rougier -
Pierre Haessig -
Sebastian Berg