Hello. > > > > Referring to: > > https://issues.apache.org/jira/browse/MATH-768 > > > > It seems that cleanly fixing that issue would require to create several > > new classes inside the "o.a.c.m.complex" package (like > > "UnivariateComplexFunction", "PolynomialComplexFunction", > > "BaseAbstractUnivariateSolver", etc.) all of which would mostly duplicate > > code in existing classes that manipulate primitive "double"s (instead of > > "Complex" objects). > > For now, I think there is only one complex solver. Would it really be > necessary in this case to pull in the full interfaces/generics > framework? This framework does make sense for primitive numbers because > there are a lots of different implementations, but this is not the case > with complex solver.
The alternative is to put all the duplicate code in the single class that would be in the (new) package "o.a.c.m.complex.analysis.solvers". [Tah would nevertheless be duplicate code...] > > > I'm wary to undertake this duplication without a deeper analysis of what > > would be a good design of utilities for "complex" analysis. [And when we > > talk about that, the very first issue to resolve would be MATH-667 > > (representation of the complex numbers).] > > > > Hence, in order to resolve MATH-768 for the time being, and though it is not > > satifactory, I'd make the "solveAll" public again (but marked as deprecated, > > without any better replacement for now). > > I would also suggest to make this method public, but in fact here I > would also remove the deprecated marker. We don't have reason to > deprecate it after all. It is the only implementation, and we do not > even have a plan for replacing it. > >From a design point of view, it is awkward to mix an API ("solve") that aims to return a single "double" value with an extended one ("solveAll") that returns an array of "Complex" numbers. For MATH-768, the initial assumption was that we would eventually grow the complex counterpart of the "analysis" package. If we don't intend to do that, and "LaguerreSolver" is a special case, then that might be the "-0" solution. [Hopefully, the next specal case will not come too soon.] Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org