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
A suggested change #66722
Comments
Take a complex number n = 3+4j. n.real is taken as 3.0 & n.imag as 4.0 in Python3. One has to use the int(0 function to get back the parts as integers. I guess this is a compiler error? |
From the documentation: "Complex numbers have a real and imaginary part, which are each a floating point number." Needing to use int() to convert these floats to integers is not a bug, it's the expected behavior. |
Dear Mr SpearThanks for the prompt response & clarification.(in Python) If the real & imaginary parts of numbers you deal with are integers, results of operations (except division) - like +, -, *, **, - appear with respective integers as real & imginary parts. In line with these, changes in '.real' & '.imag' may be desirable?
Changes by Eric V. Smith <eric@trueblade.com>: ---------- Python tracker <report@bugs.python.org> |
1 similar comment
Dear Mr SpearThanks for the prompt response & clarification.(in Python) If the real & imaginary parts of numbers you deal with are integers, results of operations (except division) - like +, -, *, **, - appear with respective integers as real & imginary parts. In line with these, changes in '.real' & '.imag' may be desirable?
Changes by Eric V. Smith <eric@trueblade.com>: ---------- Python tracker <report@bugs.python.org> |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: