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

Reply via email to