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

Skip to content

Inconsistent behavior when using float on complex number vs complex quantity #10010

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
namurphy opened this issue Mar 4, 2020 · 7 comments
Closed

Inconsistent behavior when using float on complex number vs complex quantity #10010

namurphy opened this issue Mar 4, 2020 · 7 comments
Labels
units Upstream Fix Required

Comments

@namurphy
Copy link
Contributor

namurphy commented Mar 4, 2020

Description

Using float or numpy.float on a complex number results in a TypeError. Using float or numpy.float on that complex number represented as a dimensionless Quantity results in the real part being returned and a ComplexWarning being issued. The consequence is that code using complex numbers and complex quantities may behave differently, so it may be necessary to write separate code to handle complex numbers and complex quantities. Code that relies on the current behavior for quantities should instead use numpy.real.

Expected behavior

I would expect that using float or numpy.float on a complex number represented as a dimensionless Quantity would raise a TypeError also.

Actual behavior

Using float on a complex number multiplied with astropy.units.dimensionless_unscaled returns the real part while issuing a ComplexWarning.

Steps to Reproduce

>>> import numpy as np
>>> import astropy.units as u
>>> complex_number = 5 + 6j
>>> complex_quantity = complex_number * u.dimensionless_unscaled

>>> float(complex_number)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't convert complex to float

>>> float(complex_quantity)  # would expect a TypeError for consistency
/media/Scratch/namurphy/envs/empty_for_astropy/lib/python3.8/site-packages/astropy/units/quantity.py:1077: ComplexWarning: Casting complex values to real discards the imaginary part
  return float(self.to_value(dimensionless_unscaled))
5.0

The TypeError came from this line in quantity.py.

System Details

Linux-3.10.0-957.27.2.el7.x86_64-x86_64-with-glibc2.10
Python 3.8.2 | packaged by conda-forge | (default, Mar  4 2020, 21:29:16) 
[GCC 7.3.0]
Numpy 1.18.1
astropy 4.1.dev703+g3c88b57e3
ModuleNotFoundError: No module named 'scipy'
@bsipocz bsipocz added the units label Mar 4, 2020
@mhvk
Copy link
Contributor

mhvk commented Mar 5, 2020

@namurphy - that is an annoying inconsistency, though it originates with numpy, not astropy:

float(np.complex_(5 + 6j))                                                                    
/usr/bin/ipython3:1: ComplexWarning: Casting complex values to real discards the imaginary part
  #!/usr/bin/python3
# 5.0

So, if we were to make Quantity consistent with python, we would become inconsistent with numpy. Since Quantity is an ndarray subclass, my sense is that that would be worse than just keeping things as they are.

Arguably, best would be for numpy to fix this (if they want to fix it; it is not completely obvious what the right behaviour is). Might it make sense to raise a numpy issue?

@pllim
Copy link
Member

pllim commented Mar 5, 2020

If you open a Numpy issue, please cross-link to this issue. Thank you!

@namurphy
Copy link
Contributor Author

namurphy commented Mar 5, 2020

Thanks! There was already a similar issue that I replied to: numpy/numpy#13007

I suppose we could close this since it's an upstream issue with NumPy, though another possibility would be adding it at the end of the list of known issues in the docs. At the very least, people in the future who run into float vs complex weirdness will at least have this issue to refer to. Good luck, future scientists of the world!

This issue brought to you by writing tests for edge cases that will probably never happen... 😹

@pllim
Copy link
Member

pllim commented Mar 5, 2020

@namurphy , I think documenting it in known issues is a great idea. Would you be interested to open a PR? 😄

@namurphy
Copy link
Contributor Author

namurphy commented Mar 5, 2020

@namurphy , I think documenting it in known issues is a great idea. Would you be interested to open a PR? smile

I just volunteered for something again, didn't I? 🙀

@namurphy namurphy mentioned this issue Mar 5, 2020
Merged
@bsipocz bsipocz mentioned this issue Mar 5, 2020
Open
@namurphy
Copy link
Contributor Author

namurphy commented Mar 6, 2020

The PR was just merged, so it's now in the docs as a known issue.

@mhvk
Copy link
Contributor

mhvk commented Mar 6, 2020

Thanks, @namurphy - Since I think this is more or less the best we can do, I'll close this issue.

@mhvk mhvk closed this as completed Mar 6, 2020
@namurphy namurphy mentioned this issue Nov 13, 2023
Merged
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
units Upstream Fix Required
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@pllim @mhvk @bsipocz @namurphy