Hello. > > 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.
Not completely separate from the optimizer implementation point-of-view: The "DerivativeStructure" can legitimately be used internally. > In a proper OO design you would not mix the two together. As Luc said, they are not mixed. The reason I started this thread is that there seems to be a "gap" (or "barrier" as you called it) between the old and new API so that it is indeed more awkward than it should probably. I think that we all agree on that point. > Computation of the derivatives is a separate component from optimization. Yes. > 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. With the converter in place, _nothing_ changes for the users. The issue is that we shouldn't indeed remove the more natural interfaces (i.e. similar to the one you described, and which already exist). > Everyone component should only have necessary and sufficient requirements for > use. Certainly. > Automatic differentiation is not necessary for optimization so it should not > exist in the interface. The "MultivariateDifferentiableFunction" interface extends "MultivariateFunction"; so, for direct methods, _nothing_ changes. For derivative-based methods, the "problem" IMO is (or, more exactly, would have been) the _explicit_ appearance of "DerivativeStructure" even in a context where it cannot bring anything (finite differences). The fact that the "MultivariateDifferentiableFunction" appears in the optimization interface makes it possible to use the "autodiff" feature: _possible_ but not _obligatory_ if the other interface to the derivatives is kept. > > I would like to add, that if my function is simple enough, I am very capable > of > running autdiff package a priori myself. I don't understand what you mean here. The whole point is that CM will do everything. [Thanks, Luc. :-)] > The real need for finite-difference is > when you cannot analytically compute the derivative. That's my case, and the reason for raising the issue on the ML. > 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. This is a moot point. [We'll have to do benchmarks but I doubt that the "DerivativeStructure" will be the bottleneck is real-life cases.] > 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. Well I think that this is summary of the _opposite_ of what we are saying. ;-) Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
