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