On 31/05/16 14:12, Gilles wrote:
Short as can be and close to math notation.
Another possibility may be to keep long names and to add syntactic
sugar such as
-----
public static double im(Complex c) {
return c.getImaginary();
}
-----
I have been looking at std::complex to get some ideas. Connected to the
issue (coming soon in another thread) of conforming the Complex to C99.
(http://en.cppreference.com/w/cpp/numeric/complex)
Do you see any value in conforming to this reference? If so, this could
mostly be accomplished by adding a few syntactic sugar methods, while
leaving in longer-name methods that follow the commons style, to which I
also see benefit.
These would include real, imag, abs, arg, conj .
Then a few methods are missing which are not much trouble -- log10 and
norm are easy, but I am not familiar with proj, which is only in C11 anyway.
This leaves only the question of a constructor that takes polar
representations which I think is already well handled by the present
method
ComplexUtils.polar2Complex, for either Complex or Complex[] .
Shall we consider making the constructors "private" and define
factory methods (like those currently in "ComplexUtils")?
public static Complex createCartesian(double re,
double im) {
return new Complex(re, im);
}
public static Complex createPolar(double r,
double theta) {
return new Complex(r * FastMath.cos(theta),
r * FastMath.sin(theta));
}
It seems to follow the criteria for factory pattern, in that we want to
give the user ways to create the object that are most convenient
(cartesian or polar), uncoupled from object structure.
And suppress the ambiguous methods "createComplex" and
"valueOf".
definitely
Actually I think that only one constructor should stay that
is tied to the underlying representation (and for that reason
it should not be "public").
What do you think?
I figure one goal is for the Complex to not be much bigger than two
doubles. So real and imag are probably what should be in the structure,
with the polar values calculated, and a factory method used to construct
complex from polar.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
