Gilles Sadowski <gil...@harfang.homelinux.org> a écrit :
>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.
Most importantly, it forces data copies, which is a problem for large data sets.
Best regards
Luc
>
>
>Regards,
>Gilles
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org
--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
