[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?

["Eric Barnhill (JIRA)" <ji...@apache.org>]

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

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

I'm starting to move this along -- had some hold-ups.

The following is in the commons-math Complex documentation. Is this a behavior that needs to be changed? It looks well thought out to me. 

/**
 * Representation of a Complex number, i.e. a number which has both a
 * real and imaginary part.
 * <p>
 * Implementations of arithmetic operations handle {@code NaN} and
 * infinite values according to the rules for {@link java.lang.Double}, i.e.
 * {@link #equals} is an equivalence relation for all instances that have
 * a {@code NaN} in either real or imaginary part, e.g. the following are
 * considered equal:
 * <ul>
 *  <li>{@code 1 + NaNi}</li>
 *  <li>{@code NaN + i}</li>
 *  <li>{@code NaN + NaNi}</li>
 * </ul><p>
 * Note that this contradicts the IEEE-754 standard for floating
 * point numbers (according to which the test {@code x == x} must fail if
 * {@code x} is {@code NaN}). The method
 * {@link org.apache.commons.numbers.core.Precision#equals(double,double,int)
 * equals for primitive double} in class {@code Precision} conforms with
 * IEEE-754 while this class conforms with the standard behavior for Java
 * object types.</p>
 *
 */




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