On Sun, Dec 02, 2012 at 11:23:58PM +0100, Luc Maisonobe wrote:
>
>
>
> 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.
I actually wanted to get agreement on starting to implement the proposal I
outlined above (possibly with other names if there are suggestions).
The remark about "DerivativeStructure" serving as storage was asking whether
it's correct that it _would be_ able to replace the "ValueAndGradient" data
structure. [Even if it is over-engineered for this task (and thus
unsatisfactory for users of the "optimization" package).]
My intention is indeed to not use it.
No copying is necessarily "forced", on the condition that users write their
code with "DerivativeStructure" objects. [Before any flaming, I agree that
it is not the way to go!] However, even if they did so, copying would still
occur in the current implementation[1] and that is indeed not nice and I
now understand that you probably meant to correct this when you proposed to
revert your changes.[2]
Also, I'd like some input about the "optimization" package name change and
reorganization.
I proposed to create an new "optim" package (and deprecate "optimization").
Under "optim", the layout is subject to discussion (cf. alternate proposal
by Konstantin Berlin).
Changing the API as proposed above might naturally lead to some layout...
so let's decide about that first.
Thanks,
Gilles
[1] Cf. line 182 in "AbstractLeastSquaresOptimizer".
[2] +1 to do it. Let me know whether you want some help with this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
