commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")
Date Fri, 30 Nov 2012 20:06:13 GMT

> 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

> 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.

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.


> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message