[ https://issues.apache.org/jira/browse/MATH657?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=13096572#comment13096572
]
Phil Steitz commented on MATH657:

This is probably best discussed on the mailing list before making changes to contracts in
the code.
There are two things going on here. First, this  possibly  represents another case where
the computational formula documented in the code returns NaN and it an argument could be made
that another value would be better. The tradeoff is complexity in documentation and overhead
in computation. I would like to see a real practical use case justifying adding this overhead
and added complexity in both the code and javadoc.
The second question is more interesting. Again, decision should be based on practical use
cases. That question is, do we view our complex class as representing the compactified space,
including a designated single point at infinity. One could argue that the answer is yes already,
because we have "INF" defined. But to really do this, we need to identify all of the other
infinite points (i.e., change equals) and also modify arithmetic operations uniformly. I
am not sure we really want to do that  first because of performance impacts and second because
some users may in fact want to preserve directed infinities. I would like to hear from users
and see actual use cases justifying the changes before we walk down this path.
> Division by zero
> 
>
> Key: MATH657
> URL: https://issues.apache.org/jira/browse/MATH657
> Project: Commons Math
> Issue Type: Bug
> Reporter: Gilles
> Assignee: Gilles
> Priority: Minor
> Fix For: 3.0
>
>
> In class {{Complex}}, division by zero always returns NaN. I think that it should return
NaN only when the numerator is also {{ZERO}}, otherwise the result should be {{INF}}. See
[herehttp://en.wikipedia.org/wiki/Riemann_sphere#Arithmetic_operations].

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
