Mark Dickinson <dicki...@gmail.com> added the comment:
[Raymond]
> I would
> not like to see that extended to cmath or complex() unless compelling
> real-world use cases arise.
Hmm. Have you looked at the cmath module recently? You may be in for a
nasty surprise...
> Mark, does Inf have a standard interpretation for complex numbers? Do
> all infinities meet or do they radiate, each with their own phase
> angle?
Shrug. Mathematically, by far the most common and useful model is the
complex plane plus a single extra point at infinity. But when complexes
are implemented as pairs of floats things look a little strange. Kahan,
in his 'branch cuts' paper identifies 9 'different' complex infinities
in this model, and C99 Annex G specifies exactly how functions should
behave for various different infinities.
It's never really been clear to me how useful it is to be able to
distinguish these infinities. But the cmath module *does* make an
effort to return the 'correct' (according to C99 Annex G) values for
inputs with a special real or imaginary component. On balance, I'd
support making complex('nan + nan*j') do the right thing.
(Though I can't help feeling that the repr of complex(nan, nan)
should have been 'nan + nan*1j' rather than the current 'nan + nan*j'.)
> Also, do you want to stick with the 754 interpretation of NaNs as the
> result of invalid operations
I've never much liked the use of NaN to represent missing values, and
I don't think Python should embrace that usage.
_______________________________________
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
