Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Mon, 6 Mar 2017 14:50:32 +0000 (UTC)
From: "Eric Barnhill (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.13037003.1485169198000.7280.1488811832875@Atlassian.JIRA>
In-Reply-To: <JIRA.13037003.1485169198000@Atlassian.JIRA>
References: <JIRA.13037003.1485169198000@Atlassian.JIRA> <JIRA.13037003.1485169198597@jira-lw-us.apache.org>
Subject: [jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 06 Mar 2017 14:50:40 -0000


    [ https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897428#comment-15897428 ] 

Eric Barnhill commented on NUMBERS-10:
--------------------------------------

"What do other libraries do when conversion would provide some advantage?"

Complex.js calls "parse" within the constructor, which can be for Cartesian or Polar, then only stores Cartesian, and all operations are cartesian. This is basically what the old Complex did, with slightly smoother usage.

C++ 11 has an Imaginary object with its own behavior. This is mathematically more rigorous as many of the complex trig functions have "slits" where the result depends which side of the phase-circle slit you are on. The key for replicating that sort of behavior is to have a signed zero.

As far as I can tell, a method that allowed retention of the polar state of the complex number is not in any other library. It's always converted to real and imaginary.

> Revamp "Complex" representation ?
> ---------------------------------
>
>                 Key: NUMBERS-10
>                 URL: https://issues.apache.org/jira/browse/NUMBERS-10
>             Project: Commons Numbers
>          Issue Type: Wish
>            Reporter: Gilles
>              Labels: API, design, review
>             Fix For: 1.0
>
>         Attachments: CartesianRepresentation.java, Complex.java, MixedRepresentation.java, PolarRepresentation.java
>
>
> This is a proposal to enhance the internal representation of complex numbers.
> The purpose is to allow usage of both cartesian and polar representations, with the aim that calculations are performed (transparently) with the one that will be more accurate and/or faster. 
> The API would certainly be improved, from
> {code}
>         final Complex c1 = Complex.valueOf(1, 2);
>         final Complex c2 = ComplexUtils.polar2Complex(2, 7);
>         final Complex r = c1.add(c2);
>  {code}
> with the current code, to
> {code}
>         final Complex c1 = Complex.createCartesian(1, 2);
>         final Complex c2 = Complex.createPolar(2, 7);
>         final Complex r = c1.add(c2);
> {code}
> Please refer to the attached files (they are self-documenting, but of course, Javadoc must be added if the proposal is validated).
> Would there be merit in pursuing in that direction?
> Or is there any show-stopper?


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)