[
https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15878654#comment-15878654
]
Gilles commented on NUMBERS-10:
-------------------------------
bq. JAVA standard: returns x == x as true if both are NaN
True iff {{x}} is an object instance (of the class {{Double}}).
The test will evaluate to _false_ if {{x}} is a {{double}} (primitive).
The question is: Which one is relevant for an instance of {{Complex}}?
It seems consistent to have {{v.equals(v)}} return _true_ when {{v}} is a
{{Complex}}.
bq. So I propose just making two equals methods, equals() and equalsIEEE()
Is it necessary?
Is there a "complex" in IEEE?
> 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)
