commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] silly classes naming question
Date Wed, 12 Sep 2012 14:32:49 GMT

I think that "silly classes" should not be allowed in CM!

> 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.

But those are not interfaces: a given class cannot extend both.
And if you wanted to replace one parametric type by the other, wouldn't that
break compatibility?

I think that the problem is with the "implements" clause:

public abstract class AbstractLeastSquaresOptimizer
    extends BaseAbstractMultivariateVectorOptimizer<DifferentiableMultivariateVectorFunction>
    implements DifferentiableMultivariateVectorOptimizer { /* ... */ }

because "DifferentiableMultivariateVectorOptimizer" inherits from a
parameterized interface:

public interface DifferentiableMultivariateVectorOptimizer
    extends BaseMultivariateVectorOptimizer<DifferentiableMultivariateVectorFunction>

So indeed "AbstractLeastSquaresOptimizer" cannot implement both

Is that correct?

> 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.

I use it; namely I need the "getCovariances" functionality to compute them
at a point not necessarily obtained after running an optimizer that requires

> 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?

That seems safe. But I don't fully understand the issue...

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message