You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gilles (JIRA)" <ji...@apache.org> on 2017/01/26 18:00:30 UTC

[jira] [Comment Edited] (NUMBERS-10) Revamp "Complex" representation ?

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

Gilles edited comment on NUMBERS-10 at 1/26/17 6:00 PM:
--------------------------------------------------------

The proposal intentionally avoids direct calls to a constructor ("builder" pattern).
As {{Complex}} is abstract, this statement
{code}
c = new Complex(1, 1); 
{code}
would not compile.
The user has to program against the interface ({{Complex}}), not the actual representation.
Moreover, a blatant shortcoming of the above constructor is that it ties the concept to a specific representation since you cannot overload it for polar (that also would require a constructor that takes two "double" arguments). An alternative is to use an {{enum}}, but this becomes uglier than the factory method.


was (Author: erans):
The proposal aims at avoiding direct calls to a constructor ("builder" pattern).
As {{Complex}} is abstract, this statement
{code}
c = new Complex(1, 1); 
{code}
is forbidden.
The user has to program against the interface ({{Complex}}), not the actual representation.
Moreover, as blatant shortcoming of the above constructor is that you get tied to a single representation since you cannot overload it for polar (that also would require a constructor that takes to "double" arguments. Or start to use an {{enum}} or the like, which becomes much longer to write than the factory method.

> 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.4#6332)