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

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

gael.

> Benoit
>
>
>