On 9/3/11 2:30 AM, Gilles (JIRA) wrote:
> [
> https://issues.apache.org/jira/browse/MATH-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096621#comment-13096621
> ]
>
> Gilles commented on MATH-657:
> -----------------------------
>
> I've just posted a mail on "dev".
Should be discussed on the dev list. We should not be trying to
have discussions on API changes on JIRA tickets. That is not what
JIRA is for. It is an unwritten (well, probably is actually written
down somewhere by now) rule @apache that if a decision "did not
happen on the dev list, then it did not happen." We should be
talking about API design issues on this list, not opening JIRAs each
time we think an API should be changed and trying to have the
discussion on the JIRA ticket.
>
> IMO, the main argument is consistency. Also with how reals (i.e. {{double}})
> work; IIUC, MATH-164 triggered a change for that same reason.
>
> Arne Plöse is a user and [reported|MATH-620] that the previous behaviour was
> not fine for him.
What exactly was the practical problem? Arne, care to elaborate?
>
> I don't think that this one change can have a discernible performance impact.
> It might not be necessary to map all {{Complex}} instances that have an
> infinite component to a single object. I pointed it as a convenient
> justification for fixing a bug
Not so clear it is a "bug" - the only way to characterize it as such
is to model the space as compactified.
I notice now that multiply sort of behaves this way, and as I said
on the ticket, we have already defined "INF" so an argument could be
made that we are partly there already. I would like to understand
the practical arguments pro and con - and by "practical" I mean
examples of how the proposed change and any others impact actual
uses of the class in applications. I have reviewed my own
applications and for those, there is no immediate impact (other than
performance hit in division and complex construction), but I worry a
little about losing the ability to represent directed infinities if
we decide to really aim for "consistency" here. I guess we could
retain directed infinities by adding a directed INF with an argument
attribute, but that would again add overhead to several operations.
At this point, I would like to see r1164756 reverted until we have
agreed on this change.
Phil
> (and for not fixing the other two points reported by Arne in MATH-620).
>
>
>> Division by zero
>> ----------------
>>
>> Key: MATH-657
>> URL: https://issues.apache.org/jira/browse/MATH-657
>> 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
>> [here|http://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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
