Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Unexpected behavior of compound assignment -= #4802

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.

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

Closed
suuuehgi opened this issue Jun 11, 2014 · 5 comments
Closed

Unexpected behavior of compound assignment -= #4802

suuuehgi opened this issue Jun 11, 2014 · 5 comments

Comments

@suuuehgi
Copy link

Hello together,

the -= assignment seems to break for matrices > (90,90).

Reproduction

import numpy as np
    for a in xrange(200):
    px=np.arange(a)
    #px=np.random.random(a)
    dx = np.repeat(px[np.newaxis, :], a, axis=0) - np.repeat(px[:, np.newaxis], a, axis=1)
    dx2 = np.repeat(px[np.newaxis, :], a, axis=0)
    dx2 -= dx2.T
    if len(np.nonzero(dx-dx2)[0]) != 0:
        print a
        break

I'm using numpy version 1.8.1.

Cheers,
Stephan

-------

Edit: I tested it on different machines:

It gives out

  • 91 onnumpy version 1.6.2, 1.8.0 and 1.8.1.
  • 3 on 1.3.0
@charris
Copy link
Member

charris commented Jun 11, 2014

You are overwriting dx2 while the assignment is being made from dx2.

dx2 -= dx2.T

I expect the size dependence comes from buffering. Note that dx2.T is a view, not a copy. In this case you would do just as well with

dx2 = dx2 + dx2.T

@suuuehgi
Copy link
Author

Yes, I also think so.

But it is was quite unexpected (to me) and therefore took me a while to find. It wouldn't be good when this stays unnoticed in someones code.

@seberg
Copy link
Member

seberg commented Jun 12, 2014

True, it is a problem... Closing as duplicate of gh-2667 (an certainly others, I think we have one issue with a patch attached that tries to do something about it, and might be interesting if someone wants to get an idea of what is necessary)

@seberg seberg closed this as completed Jun 12, 2014
@pv
Copy link
Member

pv commented Jun 12, 2014

gh-2667 is about something else as that occurs without views. The issue
here is dealing with operations where input and output overlap in memory
(so probably duplicate of some different issue), which has been so far
left to the user's responsibility to get right.

@seberg
Copy link
Member

seberg commented Jun 12, 2014

Opps, somewhat yes. This issue happens there as well, I guess it is more a duplicate of gh-1683...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants