From dev-return-129077-apmail-commons-dev-archive=commons.apache.org@commons.apache.org Sat Sep 3 15:11:29 2011
Return-Path:
X-Original-To: apmail-commons-dev-archive@www.apache.org
Delivered-To: apmail-commons-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id A4E65897D
for ; Sat, 3 Sep 2011 15:11:29 +0000 (UTC)
Received: (qmail 9726 invoked by uid 500); 3 Sep 2011 15:11:28 -0000
Delivered-To: apmail-commons-dev-archive@commons.apache.org
Received: (qmail 9604 invoked by uid 500); 3 Sep 2011 15:11:28 -0000
Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: "Commons Developers List"
Delivered-To: mailing list dev@commons.apache.org
Received: (qmail 9596 invoked by uid 99); 3 Sep 2011 15:11:27 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Sep 2011 15:11:27 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com designates 209.85.210.47 as permitted sender)
Received: from [209.85.210.47] (HELO mail-pz0-f47.google.com) (209.85.210.47)
by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Sep 2011 15:11:22 +0000
Received: by pzk2 with SMTP id 2so7409826pzk.34
for ; Sat, 03 Sep 2011 08:11:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=message-id:date:from:user-agent:mime-version:to:subject:references
:in-reply-to:content-type:content-transfer-encoding;
bh=RK+FU2wCjV3ycPcPZmqVEVmFLxm9ZocQKhI1as8aMUI=;
b=eox8KfBCHvYq0O6xkt8uGbl60bMx70Cvgkx3qHx1m5ul2hFYKsS/A4b+N2AViOiw1F
m52yOTtwDQmFYDmsvobBC4ngv5bheSiBjXRcxVFXkQ6vJoL+Uqo3Br088psVWnWPnG4s
24wiix3sSySFWZAA5TSHwftctP/dhURD77JBU=
Received: by 10.68.10.227 with SMTP id l3mr4131232pbb.320.1315062662270;
Sat, 03 Sep 2011 08:11:02 -0700 (PDT)
Received: from [192.168.0.2] (75-171-18-48.phnx.qwest.net. [75.171.18.48])
by mx.google.com with ESMTPS id m1sm6725572pbf.3.2011.09.03.08.11.00
(version=SSLv3 cipher=OTHER);
Sat, 03 Sep 2011 08:11:01 -0700 (PDT)
Message-ID: <4E624383.5070902@gmail.com>
Date: Sat, 03 Sep 2011 08:10:59 -0700
From: Phil Steitz
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: Commons Developers List
Subject: [math] Complex division WASRe [jira] [Commented] (MATH-657) Division
by zero
References: <595751345.14537.1315042209838.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <595751345.14537.1315042209838.JavaMail.tomcat@hel.zones.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org