Hello.
> >
> > I would propose to simply revert my changes on the optimization package
> > and prepare for a reorganization for 4.0. I understand I focused only on
> > the type of problems Gilles and myself routinely use, i .e. small size
> > problems
> > where the cost of the evaluation is several orders of magnitude larger than
> > the
> > data copying. I forgot the dual case with very large data sets. I
> > apologize for that.
>
> In the context of an FLOSS project, I don't think that you should apologize
> for that. We all do our best (and sometimes beyond) and the lack of full
> problem coverage should certainly not rest on the usual suspects (eh,
> contributors, I mean. ;-)
>
> >
> > When 3.1 will be out, we will have to solve this so both cases are handled
> > efficiently,
> > and this would probably be implemented in 4.0.
> >
> > Does this seems reasonable?
>
> At this point, no!
>
> I really want to understand what is wrong, and improve the API on all
> accounts (the issues you had, the one I raised, and the feedback from
> Konstantin, plus advice from others if possible).
If I understood correctly, the main API problem is that the objective
function and gradient or Jacobian are accessed separately. This forces users
who have code to compute the value and Jacobian together to create an adapter
that can return the two functions (objective and Jacobian) required by the
API but would avoid the computation if the a call to the other was already
made with the same parameter values.
For example, instead of passing a "DifferentiableMultivariateVectorFunction"
to the method "optimize" in "AbstractLeastSquareOptimizer", a type like the
following would be required:
-----
interface VectorFunctionWithJacobian {
ValueAndGradient[] computeValueAndJacobian(double[] parameters);
}
-----
with
-----
public class ValueAndGradient {
/** Value of a function at a given point. */
private final double value;
/** Gradient of the function at the same point. */
private final double[] gradient;
/**
* Creates an instance for the given value and gradient.
* Note that no copy is performed: this instance will contain references
* to the original data.
*
* @param value Value.
* @param gradient Vector.
*/
public ValueAndGradient(double value,
double[] gradient) {
this.value = value;
this.gradient = gradient;
}
/**
* @eturn a reference to the value.
*/
public double getValue() {
}
/**
* @eturn a reference to the gradient.
*/
public double[] getGradient() {
return gradient;
}
}
-----
Is that a better approach?
IIUC, the "DerivativeStructure" can also be used if just as a storage layout
equivalent to "ValueAndGradient". If so, then the new proposed API
(where the objective function is a "MultivariateDifferentiableVectorFunction")
is indeed better than the old, except for the (perhaps major) caveat that
from the "optimization" package, it indeed looks over-engineered and quite
unfamiliar.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
