[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[ 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. * * 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: * * {@code 1 + NaNi} * {@code NaN + i} * {@code NaN + NaNi} * * 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. * */ > 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)
[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[ https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15876969#comment-15876969 ] Gilles commented on NUMBERS-10: --- I assume that you refer to the handling of a {{Complex}} NaN (and not to the class as a whole). If you do not have a better alternative, then, of course, keep the same design decision. A question is whether such a NaN is useful in actual code, beyond signalling a failure. I mean, are there algorithms that can recover when passed such a {{Complex}} instance? If not, I wonder whether it would not be better to throw an exception. Alternatively, we should explore the cost and benefit of handling this NaN instance as is done with an [Optional|https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html] value. > 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)
[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[ https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15878203#comment-15878203 ] Eric Barnhill commented on NUMBERS-10: -- Here is what I have come to after reading Java, IEEE and C99 standards JAVA standard: returns x == x as true if both are NaN IEEE standard: returns x == x as false if both are NaN These matters only come up during equals() methods. So I propose just making two equals methods, equals() and equalsIEEE() . I don't think it is worth making subclasses or enums just to handle this one issue. Other than that there are no IEEE standards for complex numbers so that sorts IEEE. Regarding Nan handling, see the C99 JIRA issue I submit in a few minutes. > 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)
[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[ 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)
[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[ https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15878740#comment-15878740 ] Eric Barnhill commented on NUMBERS-10: -- No IEEE has no complex standards. Necessary for whom? Seems like a useful enough method and not much trouble. > 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)
[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[ https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15878750#comment-15878750 ] Gilles commented on NUMBERS-10: --- bq. Necessary for whom? I meant: Necessary for what? IOW: Is there a use case? If not, let's wait until it is required in order to solve one. bq. Seems like a useful enough method Only if you can come up with a situation when it is useful. For one, I find it awkward to define {{equalsIEEE}} when there is nothing in IEEE to compare its behaviour with! ;) > 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)
[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[ https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890381#comment-15890381 ] Eric Barnhill commented on NUMBERS-10: -- As I code this up I am not seeing much use to the CartesianRepresentation and PolarRepresentation subclasses. For example take multiplication. In the draft template for Complex.multiply() provided by Gilles, multiplication only operates on polar representations. If Cartesian representations are submitted, they get converted to polar representations, and a polar representation is returned. But, if the point of creating a CartesianRepresentation in particular, is to have some sort of greater efficiency than having everything be a MixedRepresentation, then the multiplication method is suboptimal. To make the CartesianRepresentation worth using there would also have to be an overloaded multiply() e.g. multiply(CartesianRepresentation c1, Cartesian Representation c2) { (ac-bd) + (ad+bc)i } This leads down a road of overloading multiply to handle all possible cases of CartesianRepresentation, PolarRepresentation and MixedRepresentation. And if it doesn't, then we expect the user to strategize, in his code design, to only call CartesianRepresentation when he is sure there will be no multiplication! This is needlessly complicated. Complex.createPolar() and Complex.createCartesian(), definitely should be separate factory methods. But, these should both be part of the same MixedRepresentation, whose state contains re, im, abs and arg at all times. and so this might as well all be part of the class Complex(). The only downside I see to this approach is that the Complex object contains two additional doubles and that is something to consider. But I think it is well worth it for the greater simplicity of usage. > 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)
[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[ 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)
[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[ https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897428#comment-15897428 ] Eric Barnhill commented on NUMBERS-10: -- "What do other libraries do when conversion would provide some advantage?" Complex.js calls "parse" within the constructor, which can be for Cartesian or Polar, then only stores Cartesian, and all operations are cartesian. This is basically what the old Complex did, with slightly smoother usage. C++ 11 has an Imaginary object with its own behavior. This is mathematically more rigorous as many of the complex trig functions have "slits" where the result depends which side of the phase-circle slit you are on. The key for replicating that sort of behavior is to have a signed zero. As far as I can tell, a method that allowed retention of the polar state of the complex number is not in any other library. It's always converted to real and imaginary. > 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)
[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[ https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899484#comment-15899484 ] Gilles commented on NUMBERS-10: --- It may have been interesting to benchmark a few cases (FFT, fractals, ...) but I won't have the time to delve more into this. Do what you think is best. > 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)
[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[ https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15901242#comment-15901242 ] Eric Barnhill commented on NUMBERS-10: -- Gilles, Thanks for suggesting this interesting idea for Complex, however having worked it through I think we should pass on it for these reasons: - The previous math crew worked out the math of all the Complex functions rigorously, I would rather stick with what has already been carefully validated than put in the time to reinvent the math in polar coordinates - Related libraries in other languages have found satisfactory performance using real and imaginary storage only - I think getting the "syntactical sugar" in place so that public users can call familiar c++ methods, and conforming all special cases to the c++ 11 standard, and bringing in a shaded JTransforms FFT are the more important issues For these reasons I think we should close the ticket. I will try to keep to a one month timetable for the rest of the goals, so that Complex can finally be done. Eric > 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)
[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[ https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907551#comment-15907551 ] Eric Barnhill commented on NUMBERS-10: -- I would also add, as I am working to conform to c++11 standards now, that in c++11, there is a method polar(). However, this is only to construct a complex from polar coordinates, and not to return one. This makes me think the C++ working group struggled with the same headaches, and came to the same solution, however reluctantly. > 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)
[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[ https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839604#comment-15839604 ] Eric Barnhill commented on NUMBERS-10: -- This sounds great to me. I would think while speed could be an advantage to this approach a bigger advantage would be that some mathematical quantities are much more numerically stable in one representation or the other. I would lean toward adding to this, the creation of a simple constructor c = new Complex(1, 1); that creates a mixed representation for people who don't care. > 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.4#6332)
[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[ https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839753#comment-15839753 ] Gilles commented on NUMBERS-10: --- The proposal aims at avoiding direct calls to a constructor ("builder" pattern). As {{Complex}} is abstract, this statement {code} c = new Complex(1, 1); {code} is forbidden. The user has to program against the interface ({{Complex}}), not the actual representation. Moreover, as blatant shortcoming of the above constructor is that you get tied to a single representation since you cannot overload it for polar (that also would require a constructor that takes to "double" arguments. Or start to use an {{enum}} or the like, which becomes much longer to write than the factory method. > 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.4#6332)