On 12/12/2019 13:50, Gilles Sadowski wrote:
Hello.
Le jeu. 12 déc. 2019 à 10:04, Alex Herbert <alex.d.herb...@gmail.com> a écrit :
There is a factory constructor:
Complex.ofReal(double)
For completeness I think we should add:
Complex.ofImaginary(double)
I wonder whether we should remove "ofReal".
It's a shortcut that does not save a lot of typing, IMHO not worth adding
to the API.
I like the ofReal() constructor. I was leaning on the other side for
completeness. So I already added ofImaginary(). But both could be removed.
It allows construction of a Complex from a double using lambda
functions, e.g. for streams:
List<Complex> numbers = Arrays.stream(new double[] {0, 1, 2})
.mapToObj(Complex::ofImaginary)
.collect(Collectors.toList());
It may be useful and does not add much bloat to the API.
We also have negate() as a helper. I think the following are also useful:
Complex multiplyI()
Complex multiplyNegativeI()
Applicability (and name) is not straightforward, other than where it is
used internally. I'd keep those "private".
For the API, perhaps a more general
---CUT---
public Complex multiplyImaginary(double im) {
return ofCartesian(-im * imaginary, im * real);
}
---CUT---
?
That is slated to be added for NUMBERS-139 [1].
I put in the extra add and subtract functions for ISO C99 Annex G.5.2. I
have not done the multiplication and divisions from Annex G.5.1 yet. I
will do those soon.
However unlike add/subtract I do not think that there is an issue with
maintaining or negating the sign of 0.0 if multiplied by 1 or -1 rather
than by leaving it as it or just inverting the sign. So perhaps the
optimisation multiplyI() is redundant, i.e:
1 * -0.0 = -0.0
-1 * -0.0 = 0.0
1 * 0.0 = 0.0
-1 * 0.0 = -0.0
I go through the edge cases when I write the tests.
[1]
https://issues.apache.org/jira/projects/NUMBERS/issues/NUMBERS-139?filter=allopenissues
Gilles
These two operations appear a lot in the formulas for the trigonomic functions.
They essentially just swap the real and imaginary parts and update the sign
appropriately.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org