Le jeu. 12 déc. 2019 à 15:20, Alex Herbert <alex.d.herb...@gmail.com> a écrit :
>
>
> 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.
Yet, id' rather wait until we have a compelling use-case.
It's easy to add to the API; impossible to remove from it...
The above example falls in the realm of the "ComplexList"
discussed in another thread. And such factories will likely
be defined there, e.g.
---CUT---
double[] re = new double[] {1, 2, 3};
double[] im = new double[] {4, 5, 6};
ComplexList numbers = ComplexList.ofCartesian(re, im);
---CUT---
and
---CUT---
double[] interleaved = new double[][] {1, 4, 2, 5, 3, 6};
ComplexList numbers = ComplexList.ofCartesian(interleaved);
---CUT---
etc.
> >
> >> 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:
It is redundant with the above method; so I'd keep it private (and later
drop it, if benchmarks don't show that there is a performance improvement
over multiplication by 1).
Overall, I'd think that performance considerations should not impact on the
API for the first release.
Regards,
Gilles
>
> 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
