Re: [eigen] Levenberg-marquardt and dogleg minimizer

[ Thread Index | Date Index | More Archives ]

FYI, I just added a proof of concept helper class to compute the Jacobian using adolc:

and the test/example:

from this very simple piece of code all variants can be imagined.

However there are severe limitations:

1 - the max number of "directions" must be set at compile time using a #define (this is an adolc limitation)
2 - all the functions which are called from your function must either be templated on the scalar type or have an explicit overload for the adolc's adouble type (this is already the case for most mathematical functions)

Note that the current support is for adolc's tapeless forward mode. Adolc also has a tape-based mode which offers many more features (e.g., sparsity analysis) and does not suffer from the 1st stupid limitation (on the other hand, perf and memory accesses are usually much worse)



On Thu, Feb 26, 2009 at 1:36 PM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

On Thu, Feb 26, 2009 at 1:13 PM, Jos van den Oever <jvdoever@xxxxxxxxx> wrote:
2009/2/26 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> adolc internally uses dense vector to store each derivatives, so it
> cannot deal with large - sparse problem. What would be nice is to
> implement our own autodiff tool based on eigen's dense and sparse
> objects but that happens only if someone interested in doing that
> shows up...

Reduced storage in the Jacobian is not the main benefit I'm aiming for.
The solver uses a dense Jacobian storage wise, but can do faster
iteration steps if it knows which parts of the Jacobian are zero or
You are right that using a sparse matrix would probably improve
performance more.

yes, in mind the goal is to be able to instantiate Lev-Marq with sparse-matrices, then the conversion from adolc derivatives to the jacobian will generate a real sparse Jacobian... Note that I think the memory overhead needed by adolc might prevent its use for relatevly large problems.

If I understand the autodiff Jacobian correctly, the derivative
functions are calculated at compile time. So would it be possible to
find out which part of it are zero or linear?

yes, in forward mode the derivative are more or less computed at compile time using operator overloading, but this is not enough to be able to determine the zeros at compile-time. Likewise, you cannot determine linear parts at compile time, but, at runtime, I think this would be easy to flag the coefficients which are not linear (adolc does not provide that, but this is theoratically possible to add that).


Mail converted by MHonArc 2.6.19+