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