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