> >
> > I don't know if people are confused about auto-differentation, I
> > think most people working in numerical analysis are very well aware
> > of what it does. The issue here is that it is a completely separate
> > subject from optimizations. In a proper OO design you would not mix
> > the two together. Computation of the derivatives is a separate
> > component from optimization. Optimization only assumes that you can
> > compute one, it shouldn't care or force you two compute one in a
> > specific way. That's bad design. Everyone component should only have
> > necessary and sufficient requirements for use. Automatic
> > differentiation is not necessary for optimization so it should not
> > exist in the interface.
>
> You are right.
>
> >
> > I would like to add, that if my function is simple enough, I am very
> > capable of running autdiff package a priori myself. The real need for
> > finite-difference is when you cannot analytically compute the
> > derivative. Though I think having a wrapper function around autdiff
> > package is a nice tool to help developers quickly write code, if they
> > prefer to have quicker development time but slightly slower code.
>
> >
> > If someone can explain to me why auto-diff package should be directly
> > forced or even be provided as alternative into optimization package
> > when a simple wrapper function can do this task while maintaining
> > much cleaner OO design, please tell me.
>
> You just found the reason and explained it by yourself: it was bad
> design and I am the one to blame for this. I was (and still am) stupid.
I'm not convinced that it was bad design. Maybe I'm completely off now:
I thought that the purpose was internal simplification. I don't think
that it can be inherently wrong to store any sort of derivatives (be it
gradient or Jacobian) into a structure aimed at storing... partial
derivatives (i.e. "DerivativeStructure").
Please let me know whether the problem is more in-depth than what I
described previously (allowing the current way to provide the gradient
and Jacobian).
I would nevertheless have suggested to delete the method
MultivariateFunction partialDerivative(int k);
from "DifferentiableMultivariateFunction".
>
> So I suggest we disconnect differentiation from optimization, but in a
> way that would let users decide how they provide the differentials. This
> means I would not like to reintroduce the former interfaces.
>
> What about having the optimize() methods taking two arguments function,
> a MultivariateFunction for the value and a MultivariateVectorFunction
> for the gradient? It would be up to the user to select how they compute
> each function. They could use direct coding, they could use a finite
> differences wrapper around the first function to implement the second,
> they could use our differentiation framework and put one wrapper to
> extract the value and another one to extract the gradient.
That would also be a nice example of usage of the differentiation
framework.
> What do you think?
Yes. Now I got it (I think). IIUC, we could even introduce the new interface
before 3.1, and deprecated old the older ones (as you wanted to do anyways,
IIRC).
I'll give it a try in the next days. OK?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
