[
https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15876128#comment-15876128
]
Gilles edited comment on NUMBERS-10 at 2/21/17 10:59 PM:
---------------------------------------------------------
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.
{noformat}
/**
* 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>
*
*/
{noformat}
was (Author: ericbarnhill):
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)
