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