|Re: [eigen] port of (c)minpack to eigen : status|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] port of (c)minpack to eigen : status
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Fri, 25 Sep 2009 07:49:18 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=4w4yDtJyDFGdEtvQaYDMtMukGA9DDgCClchNF72tTag=; b=JA7O5YEpnp73sYoyGMJNCwPBrcpqmQfa4FO8L+RlOj7Ra9UpL6/qDEHQNLpgx1opyS hz8xZ/M85qyekAaoZLrKZ9lvgomsLP3ksAfBWbv25YbrVuTzdYUe+lw4I5jHnJIrv1cY DcCVhXZLH1v1eK7c/MQKevZvSQQjL6PHmtcYw=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=IM+rK6lBZKzXCIxm5DpGSGA5y48K92XBr60ecHOO5e6OL2oC8QnRcdWuL8vA6f6RIe KlUROghWQmzMUhyVkAW5Pgk9Dc4GTU0sXmuJqYSwpgBJvfMeUaLfolI7cvjLK/xj/M+Z 74F9QS27Lau0QxNytG3SrwcR+6v9m8LTZUCCE=
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>:
>>> 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
>> 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.
> 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.