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

[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