Raymond Hettinger <rhettin...@users.sourceforge.net> added the comment:
> complex(repr(..)) roundtrip should work, Nice-to-have but not a requirement that the entire input domain be supported. > it is supported for float, so why not for complex ? It made sense for floats because of prevalence of use cases and because we wanted to match IEEE-754R as much as possible. Unfortunately, the support for Infs and NaNs has already negatively impacted the float world by making the math module harder to maintain and test. I would not like to see that extended to cmath or complex() unless compelling real-world use cases arise. > ... for scientific people, it is a crucial to have proper support > of nan (which may mean missing data depending on the context) and inf. Mark, does Inf have a standard interpretation for complex numbers? Do all infinities meet or do they radiate, each with their own phase angle? Also, do you want to stick with the 754 interpretation of NaNs as the result of invalid operations or are you comfortable with the MatLab/Octave notion of using NaNs to indicate missing values (something they do as an optimization because it is the only way to flag a non-numeric value in a floating point register or C double)? > it does not add complexity: That depends on whether handling of NaNs and Infs creeps into cmath. Mainly, I'm just questioning whether there exist compelling use cases for parsing NaNs and Infs in the context of complex numbers. ---------- assignee: -> marketdickinson _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue2121> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
