Re: [eigen] port of (c)minpack to eigen : status

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


Thomas:

about the Functor discussion, actually the static versus dynamic
polymorphism is up to the user. Indeed, in any case the functor type
must be a template parameter which will also specify the scalar type
and the sizes of the problem (which ideally could be be compile time
sizes). Then in any case you also have to create a functor object and
pass it to the non linear solver, e.g.:

MyFunctorType func(some, parameters, ...);

// setup func.

LevMarq<MyFunctorType> solver(func);


then that's up to the user to define a MyBaseFunctorClass with the f()
and df() function being pure virtual. Then the user instantiate his
generic solver:

LevMarq<MyBaseFunctorClass> solver;

which can be used with any functor inheriting MyBaseFunctorClass:

class Func1 : public MyBaseFunctorClass
{
  f() { /* ... */ }
  // ...
};

solver.setFunction(Func1());

and of course we can also provide such a generic base class (generic
wrt the scalar type).

Then there is the issue of making easy to the user to implement its
own jacobian computation, or to use any auto-diff tools (including
central/forward differences). To this end have a look at what I did in
unsupported.

The idea is to implement the auto diff classes such that they inherit
the functor type which is itself a template parameter, e.g.:

template<typename Functor> class ForwardDiff : public Functor
{
 // ...
};

then someone write its own functor without and df() function:

class MyFunc
{
 Scalar operator() (....) { ... }
};

and when you want to use it with an algorithm which requires the
jacobian, you simply declare:

typedef FoarwardDiff<MyFunc> MyFuncFD;

LevMarq<MyFuncFD> solver;


Another design choice would be to make the Functor inherits the
auto-diff class, but then it is a bit less trivial to transform a
simple functor to a functor with Jacobian computation capability. I
think that's why I made that design choice after a lot of hesitations,
but that does not mean we should stick to it. Maybe there exist a
better solution.

hope that helps.

gael.


On Fri, Sep 25, 2009 at 1:57 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> Thanks for the answers!
>
> 2009/9/24 Thomas Capricelli <orzel@xxxxxxxxxxxxxxx>:
>>> The code seems to be only for double, right? Is there a good reason to
>>> forbid float and other types?
>>
>> On the contrary it should not, why do you say so ? The tests are only using
>> double, cf next answer. The code is using the template parameter 'Scalar'
>> everywhere (or should, anyway)
>
> Sorry, I misread your code (misread default template parameter value
> as partial specialization).
>
> Benoit
>
>
>



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/