Le 12/09/2012 16:32, Gilles Sadowski a écrit :
>
> I think that "silly classes" should not be allowed in CM!
As all I am able to do is silly work, I should stop working for [math]
then ;-)
> ;-)
>
>> 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?
Yes. What I wanted to do is implement both top level interfaces. The
fact there is an intermediate abstract class is irrelevant to me
>
> I think that the problem is with the "implements" clause:
>
> public abstract class AbstractLeastSquaresOptimizer
> extends
> BaseAbstractMultivariateVectorOptimizer<DifferentiableMultivariateVectorFunction>
> implements DifferentiableMultivariateVectorOptimizer { /* ... */ }
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yes.
>
> 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?
Yes, it is the problem.
>
>>
>> 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...
Here is a really striped down version. Suppose we have a paremeterized
interface:
interface TheInterface<T> { public void f(T t); }
Then I could write this:
class MyClass {
public void f(A a) { ... }
public void f(B b) { ... }
}
But I could not write the following despite there are no type conflicts:
class MyClass implements TheInterface<A>, TheInterface<B> {
public void f(A a) { ... }
public void f(B b) { ... }
}
The workaround I propose is to write this:
class MyClass implements TheInterface<A> {
public void f(A a) { ... }
public void f(B b) { ... }
}
I will do this with MyClass replaced by AbstractLeastSquaresOptimizer
and TheInterface replaced by BaseAbstractMultivariateVectorOptimizer. So
users will already be able to provide either a
DifferentiableMultivariateVectorFunction or a
MultivariateDifferentiableVectorFunction. This will help transition when
4.0 is out, and should not break compatibility between 3.0 and 3.1.
best regards,
Luc
>
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
