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

Skip to content

Wrong std for implicitly complex input #13110

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.

Sign up for GitHub

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

Jump to bottom
Closed
sedefe opened this issue Mar 12, 2019 · 8 comments
Closed

Wrong std for implicitly complex input #13110

sedefe opened this issue Mar 12, 2019 · 8 comments
Labels
00 - Bug

Comments

@sedefe
Copy link

sedefe commented Mar 12, 2019

Standart deviation formula could give unexpected result (e.g. imaginary values) when input is implicitly complex.

Reproducing code example:

import numpy as np
a = np.array([None, 0])
a[0] = 1j
b = np.array([1j, 0])

print(f'res={np.std(a)}, dtype={a.dtype}') # gives imaginary std
print(f'res={np.std(b)}, dtype={b.dtype}')

Error message:

Numpy/Python version information:

numpy 1.16.2
python 3.7

res=0.5j, dtype=object
res=0.5, dtype=complex128
@eric-wieser
Copy link
Member

I'd bet this is a somewhat pervasive issue...

@sedefe sedefe changed the title STD Wrong std for implicitly complex input Mar 12, 2019
@ewmoore
Copy link
Contributor

ewmoore commented Mar 12, 2019

I’m not sure that you could make object arrays still useful and prevent this kind of thing.

Types can only help you if you actually use them. Making an object array is opting out of that help.

@eric-wieser
Copy link
Member

eric-wieser commented Mar 15, 2019 •
edited
Loading

@ewmoore: The only reason this is a problem is an incorrect optimization that avoids calling conjugate on non-complex arrays (which would make an unnecessary copy):

numpy/numpy/core/_methods.py

Lines 118 to 121 in 6b3ea20

if issubclass(arr.dtype.type, nt.complexfloating):
x = um.multiply(x, um.conjugate(x), out=x).real
else:
x = um.multiply(x, x, out=x)

If the optimization is reframed as avoiding calling conjugate on floating or integer arrays, then this problem would go away.

@seberg
Copy link
Member

seberg commented Mar 15, 2019

I think conjugate on object used to be broken, but it is not anymore, so we should fix this!

@ewmoore
Copy link
Contributor

ewmoore commented Mar 15, 2019

@eric-wieser, sorry for the noise then. I didn't look, and assumed what the bug was.

@seberg
Copy link
Member

seberg commented Mar 15, 2019

Hmmm, of course fixing it could in principle break arrays with object types that do not support .conjugate(), although decimal.Decimal and the built-in numerical types all do (at least by now) I believe.

cnighut added a commit to cnighut/numpy that referenced this issue Mar 22, 2019
@cnighut
BUG: Closes numpy#13110. Fixed the incorrect optimization for complex…
d5aae9c 
… arrays
@cnighut cnighut mentioned this issue Mar 22, 2019
Merged
cnighut added a commit to cnighut/numpy that referenced this issue Mar 22, 2019
@cnighut
Closes numpy#13110. Removedd incorrect optimisation for complex type …
d68e620 
…array. Removed a typo from initial commit.
cnighut added a commit to cnighut/numpy that referenced this issue Mar 22, 2019
@cnighut
Closes numpy#13110. Removedd incorrect optimisation for complex type …
494ed9d 
…array.
cnighut added a commit to cnighut/numpy that referenced this issue Mar 22, 2019
@cnighut
BUG: Closes numpy#13110. Fixed the incorrect optimization for varianc…
7ec463c 
…e calculation
cnighut added a commit to cnighut/numpy that referenced this issue Mar 25, 2019
@cnighut
BUG: Closes numpy#13110. Fix of method for complex arrays
9edffa3
@bsipocz
Copy link
Member

bsipocz commented Aug 16, 2019

Please close.

This has been fixed, but the github autoclosing didn't kick in. I think the reason is that the "closes" keyword was in a commit message, and the committer doesn't have write access to the repo. Had it been in the PR's description the auto closing would have worked.

@rgommers
Copy link
Member

thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
00 - Bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@seberg @rgommers @eric-wieser @ewmoore @bsipocz @sedefe