{"action":"created","issue":{"url":"https://api.github.com/repos/numpy/numpy/issues/6119","labels_url":"https://api.github.com/repos/numpy/numpy/issues/6119/labels{/name}","comments_url":"https://api.github.com/repos/numpy/numpy/issues/6119/comments","events_url":"https://api.github.com/repos/numpy/numpy/issues/6119/events","html_url":"https://github.com/numpy/numpy/issues/6119","id":97339425,"number":6119,"title":"Broken __iadd__ behavior on views","user":{"login":"akhmerov","id":2069677,"avatar_url":"https://avatars.githubusercontent.com/u/2069677?v=3","gravatar_id":"","url":"https://api.github.com/users/akhmerov","html_url":"https://github.com/akhmerov","followers_url":"https://api.github.com/users/akhmerov/followers","following_url":"https://api.github.com/users/akhmerov/following{/other_user}","gists_url":"https://api.github.com/users/akhmerov/gists{/gist_id}","starred_url":"https://api.github.com/users/akhmerov/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/akhmerov/subscriptions","organizations_url":"https://api.github.com/users/akhmerov/orgs","repos_url":"https://api.github.com/users/akhmerov/repos","events_url":"https://api.github.com/users/akhmerov/events{/privacy}","received_events_url":"https://api.github.com/users/akhmerov/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":19,"created_at":"2015-07-26T18:22:39Z","updated_at":"2015-07-29T17:20:33Z","closed_at":"2015-07-26T18:53:20Z","body":"Using `+=` with a view of the same array sometimes is broken. To reproduce run\r\n\r\n```python\r\nfor n in range(80, 100):\r\n    h = np.random.randn(n, n)\r\n    h += h.T\r\n    print(n, np.linalg.norm(h - h.T))\r\n```\r\n\r\nThis produces a bunch of zeros (correct result), followed by a bunch of finite numbers of order 1 (wrong). For me the result is wrong for `n > 90`.\r\n\r\nReplacing `h += h.T` with `h = h + h.T` or anything equivalent fixes the issue.\r\n\r\nI have verified that the issue appears in linux pip installation of numpy v1.9.2 in python 2, as well as python 3. In particular, it is reproducible on http://try.jupyter.org.\r\n"},"comment":{"url":"https://api.github.com/repos/numpy/numpy/issues/comments/126024897","html_url":"https://github.com/numpy/numpy/issues/6119#issuecomment-126024897","issue_url":"https://api.github.com/repos/numpy/numpy/issues/6119","id":126024897,"user":{"login":"njsmith","id":609896,"avatar_url":"https://avatars.githubusercontent.com/u/609896?v=3","gravatar_id":"","url":"https://api.github.com/users/njsmith","html_url":"https://github.com/njsmith","followers_url":"https://api.github.com/users/njsmith/followers","following_url":"https://api.github.com/users/njsmith/following{/other_user}","gists_url":"https://api.github.com/users/njsmith/gists{/gist_id}","starred_url":"https://api.github.com/users/njsmith/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/njsmith/subscriptions","organizations_url":"https://api.github.com/users/njsmith/orgs","repos_url":"https://api.github.com/users/njsmith/repos","events_url":"https://api.github.com/users/njsmith/events{/privacy}","received_events_url":"https://api.github.com/users/njsmith/received_events","type":"User","site_admin":false},"created_at":"2015-07-29T17:20:33Z","updated_at":"2015-07-29T17:20:33Z","body":"Sorry about getting confused about the different issue threads there.\n.\nThe problem is that without definitely_share_memory, we would be straight\nup no joke removing the ability to efficiently perform operations like a[:,\n0] += a[:, 1] from numpy. Maybe I'm wrong and everyone considers that a\ngood tradeoff but I really doubt you'll be able to get consensus that\nremoving functionality is a good tradeoff. Numpy generally errs on the side\nof exposing the raw metal.\n.\nIf definitely_share_memory is allowed to return False even in cases where\nthe arrays do share memory, then it could still be useful at least for\nissuing warnings. Or if it managed to be both precise and essentially\ninstantaneous for essentially every situation that arises in practice then\nwe might have a case for doing this copies. Certainly it seems plausible\nthat some simple heuristics could catch 99% of the cases, but until someone\ndoes the work it's impossible to know.\nOn Jul 29, 2015 10:07 AM, \"Pauli Virtanen\" <notifications@github.com> wrote:\n\n> I'm not sure it's productive to insist on definitely_share_memory(),\n> given that the scaling is non-polynomial (in the number of dimensions),\n> so it's likely going to be slow for high-dimensional arrays. For a\n> compiler this might be OK, but Numpy has to do the calculation on the fly.\n>\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/numpy/numpy/issues/6119#issuecomment-126020486>.\n>\n"}}