Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <505077CF.2040105@spaceroots.org>
Date: Wed, 12 Sep 2012 13:53:51 +0200
From: Luc Maisonobe <luc@spaceroots.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: [math] silly classes naming question
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi all,

Continuing the work on the new differentiation framework, I am facing a
silly naming problem. This problem is exactly the same I encountered
while I updated the solvers: the Java language does not allow to inherit
from the same parameterized interface with two different parameters.

So when I want to update class LevenbergMarquardtOptimizer which extends
AbstractLeastSquaresOptimizer which itself extends
BaseAbstractMultivariateVectorOptimizer<DifferentiableMultivariateVectorFunction>,
I hit the problem. I cannot have
BaseAbstractMultivariateVectorOptimizer<MultivariateDifferentiableVectorFunction>
in the same hierarchy.

For solvers, we decided to duplicate the hierarchy, and I ended up
creating a new NewtonRaphsonSolver while deprecating the older
NewtonSolver. I would like to do the same for the optimizers.

As the intermediate class AbstractLeastSquaresOptimizer is not really
something most users will use, a simple name change to
AbstractLSOptimizer seems sufficient. Such simple name changes would not
be good for end-users classes like LevenbergMarquardtOptimizer,
NonLinearConjugateGradientOptimizer or GaussNewtonOptimizer. Note that
the core algorithms do not change at all, only the signatures change as
well as one line in AbstractLeastSquaresOptimizer (to be precise, the
changed line is from: "jF = f.jacobian()" to "jf = jF = new
JacobianFunction(f)").

Does someone has clever name changes to propose or should I simply keep
only the existing classes, add the new signatures but do not declare
them as implementing top level parameterized interfaces?

I'm sorry to ask such silly questions, but I am stuck with this Java
limitation.

best regards,
Luc

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org