commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Barnhill (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
Date Wed, 01 Mar 2017 15:29:45 GMT

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

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

As I code this up I am not seeing much use to the CartesianRepresentation and PolarRepresentation
subclasses. 

For example take multiplication. In the draft template for Complex.multiply() provided by
Gilles, multiplication only operates on polar representations. If Cartesian representations
are submitted, they get converted to polar representations, and a polar representation is
returned.

But, if the point of creating a CartesianRepresentation in particular, is to have some sort
of greater efficiency than having everything be a MixedRepresentation, then the multiplication
method is suboptimal. To make the CartesianRepresentation worth using there would also have
to be an overloaded multiply() e.g.

multiply(CartesianRepresentation c1, Cartesian Representation c2) {
    (ac-bd) + (ad+bc)i
}

This leads down a road of overloading multiply to handle all possible cases of CartesianRepresentation,
PolarRepresentation and MixedRepresentation.

And if it doesn't, then we expect the user to strategize, in his code design, to only call
CartesianRepresentation when he is sure there will be no multiplication!

This is needlessly complicated. Complex.createPolar() and Complex.createCartesian(), definitely
should be separate factory methods. But, these should both be part of the same MixedRepresentation,
whose state contains re, im, abs and arg at all times. and so this might as well all be part
of the class Complex(). The only downside I see to this approach is that the Complex object
contains two additional doubles and that is something to consider. But I think it is well
worth it for the greater simplicity of usage.

> 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)

Mime
View raw message