On 15/07/2012 04:21, Gilles Sadowski wrote: > 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. > 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. best regards, Luc > > Any objections? Better ideas? > > > Regards, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
