Mark Dickinson added the comment: > Is the issue with complex superficial
Unfortunately not: something like this is fairly inescapable. The problem is that when you do (for example) 5 - 6j you're in effect subtracting complex(0.0, 6.0) from complex(5.0, 0.0): you've invented a real part of 0.0 for the second term and an imaginary part of 0.0 for the first term. And since 0.0 is *not* an identity for addition (-0.0 + 0.0 is 0.0, not -0.0, under the usual rounding modes), signs of zeros tend to get lost. So the safe way to construct a complex number is to avoid any actual arithmetic by using complex(real_part, imag_part) rather than real_part + imag_part*1j. I rather like Serhiy's idea of making the complex repr have this form, except that the change would probably break existing code. (And the str should really stay in the current expected human-readable format, so the problems with infj and nanj don't go away.) Another possible "fix" is to introduce a new 'imaginary' type, such that the type of an imaginary literal is now 'imaginary' rather than 'complex', and arithmetic operations like addition can special-case the addition of a float to an 'imaginary' instance to produce a complex number with exactly the right bits. The C standardisation folks already tried this: C99 introduces optional "imaginary" types and a new _Imaginary keyword, but last time I looked almost none of the popular compilers supported those types. (I think Intel's icc might be an exception.) While this works as a technical solution, IMO the cure is worse than the disease; I don't want to think about the user-confusion that would result from having separate "complex" and "imaginary" types. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23229> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
