Le jeu. 7 nov. 2019 à 12:59, Alex Herbert <alex.d.herb...@gmail.com> a écrit :
>
>
> On 07/11/2019 11:45, Gilles Sadowski wrote:
> > Hello.
> >
> >>> [...]
> >>>
> >>>> Also looking at Complex it would benefit from:
> >>>>
> >>>> public Complex subtractFrom(double minuend) {
> >>>> return new Complex(minuend - real, imaginary);
> >>>> }
> >>> Is it part of the "standard"?
> >>> IMHO, it's fairly confusing, as nothing in the name indicates
> >>> that the operation only applies to the real part.
> >> The same applies for the add(real) and subtract(real) methods.
> >>
> >> What is confusing is the unconventional reverse ordering of
> >> z.subtractFrom(a) == a - z. I’m not happy about it but the javadoc can
> >> explain the outcome.
> > Actually, what confuses me is that the above equality does not hold:
> > double a = 5;
> > Complex z = Complex.of(1, 3);
> > Complex z2 = z.subtractFrom(a);
> > would yield
> > 4 + 3 i
> > whereas
> > Complex z2 = Complex.of(a).subtract(z);
> > would yield
> > 4 - 3 i
>
> You are right, I had my use of Complex incorrect. Sorry.
>
> The imaginary part should also be subtracted from zero thus the code
> should be an equivalent with an imaginary of 0:
>
> public Complex subtractFrom(double minuend) {
> return new Complex(minuend - real, 0 - imaginary);
> }
>
> Equivalent to (as you state):
>
> double a = ...;
>
> Complex z = ...;
>
> Complex y = Complex.ofReal(a).subtract(z);
So this would spare one instantiation.
Not sure it would gain much in absolute time for most uses, but there
is no arguing that it is a gain. [Although, if nit-picking, one could imagine
that the JIT optimization will kick in later if subtraction usage is spread
among the two methods, and thus could be a loss in absolute time for
some uses...]
> There is a matrix for real/imaginary/complex all-vs-all additive and
> multiplicative operators in the standard (tables in G.5.1 and G.5.2).
> The question is do we want to support the entire matrix:
This a more straightforward possible requirement.
> Covered:
>
> Complex.multiplyReal(double x) as Complex.multiply(double x)
> Complex.divideReal(double x) as Complex.divide(double x)
> Complex.addReal(double x) as Complex.add(double x)
> Complex.subtractReal(double x) as Complex.subtract(double x)
>
> Not covered:
>
> Complex.multiplyImaginary(double x)
> Complex.divideImaginary(double x)
> Complex.addImaginary(double x)
> Complex.subtractImaginary(double x)
> Complex.subtractFromReal(double x)
> Complex.subtractFromImaginary(double x)
I'm fine with adding these methods for consistency and completeness.
It may have the advantage to make it slightly easier to port algorithms
written in C++ if all the methods have their exact counterpart in Java.
Regards,
Gilles
>
>
> I am going through Complex now to fix code coverage and make it in line
> with the C.99 standard. I will push all the config changes with the
> update to Complex. Should be done be end of today.
>
> Then we can look at fixing checkstyle and PMD.
>
>
>>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
