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

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

For what it's worth, I've now created a wiki page from "pedagogical"
material that I wrote earlier:

http://eigen.tuxfamily.org/index.php?title=Functors

hope it's useful,
Benoit

2009/9/25 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 2009/9/25 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> On Fri, Sep 25, 2009 at 1:17 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>> 2009/9/25 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>>>> 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).
>>>
>>> But just because the scalar type and sizes need to be template
>>> parameters, doesn't have to mean that the functor type must too.
>>> Currently, Thomas already passes the scalar type as a separate
>>> template parameter. If there's a need to also pass sizes, then perhaps
>>> what is really wanted is to pass a MatrixType instead as template
>>> parameter? This would carry at compile time, the information of the
>>> scalar type and size.
>>>
>>> I'm not saying that things should be made a certain way, i'm just
>>> suggesting that so far, i don't see anything that requires knowing the
>>> functor type at compile time :)
>>
>> I agree, but I think my proposal is more flexible and scalable because
>> I'm not sure a matrix type will be enough to provide all the required
>> compile time information, especially when we'll start to support
>> sparse matrices.
>
> OK, I didn't think of that. Again here all i can do is work at the
> general c++ level ;)
>
>> Again, note that that's not because the functor type
>> is a template parameter that you cannot take advantage of runtime
>> polymorphism: as I said, you just to instantiate your solver with a
>> pure virtual base function type.
>
> OK, true.
>
>> Anyway, those are really details
>> which can be very easily changed once the solver will be refactored to
>> use the functor for both the values and the Jacobian, that is in my
>> opinion the first thing to do to make the code maintainable.
>>
>>> Speaking with Thomas on IRC yesterday, there was also a separate issue
>>> where he was considering factoring code: the minimizeOneStep and
>>> minimizeNumericalDiffOneStep are almost the same, the diff is just:
>>>
>>> -    if (functor.df(x, fjac) < 0)
>>> +    if ( ei_fdjac2(functor, x, fvec, fjac, parameters.epsfcn) < 0)
>>>         return UserAsked;
>>> -    ++njev;
>>> +    nfev += n;
>>>
>>> so it's just a different functor call, and that call is made only once
>>> in an otherwise complicated function. So this seems like a perfect
>>> candidate for factoring code out by making the functor type resolved
>>> at runtime via virtual inheritance.
>>
>> yes, in my previous post, all the stuff about putting the auto-diff
>> capability into the functor was to address this issue.
>
> OK. Then indeed if we want this code factoring to also include binary
> code factoring, then we can give the functors a common virtual base
> and instantiate with respect to the pure virtual base.
>
> Benoit
>