You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles Sadowski <gi...@harfang.homelinux.org> on 2012/07/15 04:21:41 UTC
[Math] About MATH-768
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).
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).
Any objections? Better ideas?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] About MATH-768
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] About MATH-768
Posted by Luc Maisonobe <Lu...@free.fr>.
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org