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