Cournapeau David <da...@ar.media.kyoto-u.ac.jp> added the comment: > Nice-to-have but not a requirement that the entire input domain be > supported.
Ok. > It made sense for floats because of prevalence of use cases and > because we wanted to match IEEE-754R as much as possible. But why shouldn't this apply to complex numbers ? I am biased because I mainly use python for scientific work, but complex numbers are not more special than float in my mind. > Unfortunately, the support for Infs and NaNs has already negatively > impacted the float world by making the math module harder to maintain > and test. Yes, it is difficult to handle nan and inf, there are a lot of corner cases. But I fail to see how this applies here: my patch is essentially a rewrote of the parsing, and the code to handle nan/inf is only 7 lines. This is independent of the handling of how nan/inf is handled by math operations on it. > Mark, does Inf have a standard interpretation for complex numbers? > Do all infinities meet or do they radiate, each with their own phase > angle? Hm, not sure what you mean here by standard interpretation, but infinities "do not meet", in the sense that (x,inf) and (inf,x) for example can never been 'near' from each other (in the distance sense), except if x is inf. It does not make more sense to talk about phase of complex numbers with inf than for 0. But again, I don't see how this is relevant to the proposed feature. > Mainly, I'm just questioning whether there exist compelling use cases > for parsing NaNs and Infs in the context of complex numbers. For any task where parsing complex makes sense. Since many numerical operations may end up with nan or inf, this is relatively common I would say. It this can make the review easier, I can split the patch in two: first the refactoring (+ tests once someone tells me how to), and then inf/nan handling (with additional tests). _______________________________________ 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
