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

[ Thread Index | Date 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 08:50:09 -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=fLmtNUxh0fC62EsYPQkcENS9t00eCcenxJZMHESw680=; b=NkXEMXsED1OmIIhZ2DqmGA//x/Uonn2ILxWPVg/syJszElVHYFNlKu+QRq5dpUyxlY JTXLlTZIjDcAXSaxFbBJgDpoxBLwEd3gdKnkRKHdyS1zGXw8Eb2tb113PUzCFHO7jN4S qinC9/8JlViucMT05AaMiqA/kepXpP4XeKl9Y=*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=kDfRQjhqldbbjySsCyWuTfT9Z3rPHUPTG2fQzDzYSeNrFwQRBGuXjN5GvWxImJDxSu AEFoMMpQL5qSj6BE6jhb/DZGySeKKv12kgtV2wv4OCl0+8+8VXgiTk5ZtGLRUIHgc6gR niHKnNnCJP+iDZf7bZQxEWSo+r3RluLh2Z3Xw=

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 >

**Follow-Ups**:**Re: [eigen] port of (c)minpack to eigen : status***From:*Thomas Capricelli

**References**:**Re: [eigen] port of (c)minpack to eigen : status***From:*Hauke Heibel

**Re: [eigen] port of (c)minpack to eigen : status***From:*Benoit Jacob

**Re: [eigen] port of (c)minpack to eigen : status***From:*Thomas Capricelli

**Re: [eigen] port of (c)minpack to eigen : status***From:*Benoit Jacob

**Re: [eigen] port of (c)minpack to eigen : status***From:*Gael Guennebaud

**Re: [eigen] port of (c)minpack to eigen : status***From:*Benoit Jacob

**Re: [eigen] port of (c)minpack to eigen : status***From:*Gael Guennebaud

**Re: [eigen] port of (c)minpack to eigen : status***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] ei_aligned_new problem on MSVC 2008 with 2.06** - Next by Date:
**Re: [eigen] ei_aligned_new problem on MSVC 2008 with 2.06** - Previous by thread:
**Re: [eigen] port of (c)minpack to eigen : status** - Next by thread:
**Re: [eigen] port of (c)minpack to eigen : status**

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