[
https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890480#comment-15890480
]
Gilles commented on NUMBERS-10:
-------------------------------
bq. As I code this up I am not seeing much use to the CartesianRepresentation
and PolarRepresentation subclasses.
This is the rationale indeed:
bq. the Complex object contains two additional doubles and that is something to
consider.
The {{MixedRepresentation}} is for performing the fast/accurate computation (as
you remarked from the outset). A priori, it is not intended for storage
whenever doubling the size in memory might matter (as for the arrays in
{{ComplexUtils}}?).
Beforing "storing", one should do
{code}
Complex result = ... // Some computation.
Complex fat = result.asCartesian();
Complex thin = Complex.createCartesian(fat.re(), fat.im());
{code}
Of course we could make this easier to use by defining syntactic sugar, say
{{trimToCartesian(Complex result)}}.
bq. To make the CartesianRepresentation worth using there would also have to be
an overloaded multiply()
Why?
For a single operation the overload will be faster but for a sequence, the
conversion to polar will require less additions and multiplications.
bq. we expect the user to strategize,
No, we don't expect it; but he certainly can.
The alternative (current design) is to always perform the same computation even
if the other representation is faster or more accurate.
bq. This is needlessly complicated.
There is certainly room for improvement but it is not complicated (for the
user).
And the purpose is exactly to avoid storing 4 values instead of 2 but also to
not drop the other 2 values if they happen to have been computed already.
I think that actual examples of the problems you see are necessary in order to
avoid premature optimization (or worse "de-optimization").
Flattening the design will be easier than recoding again.
What do other libraries do when conversion would provide some advantage?
> 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)
