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
BaseMultivariateVectorOptimizer<DifferentiableMultivariateVectorFunction>
and
BaseMultivariateVectorOptimizer<MultivariateDifferentiableVectorFunction>
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
derivatives.
> 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.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
