Re: [eigen] Parameters in Levenberg Marquard algorithm of wrong type?

["Claas H. Köhler" <claas.koehler@xxxxxx>]

Hi Thomas and Tim!

Thanks for the quick reply.

I see your point to store temporaries, which pass information from one 
loop to the next at class scope. However this is not the case for
- gnorm
- temp1, temp2 and temp
- ratio
- pnorm
- fnorm1
- actred
- dirder
- prered

As far as performance is concerned, I am not sure whether making these 
scalars local would incur a measurable performance penalty, especially 
in light of the fact that the temporary vectors wa1 and wa2 are 
re-allocated on every call of lmpar2 (by the way why?).

As far as gnorm and ratio are concerned, you might argue that they could 
provide information to the user during runtime, so they may be useful as 
class members. I am not sure, whether the same argument holds for any 
other variable above (they are all private and inaccessible to the user).

One more thought on gnorm and fnorm: I suggest making them private and 
accessible via a public read-only function. This is in my opinion 
especially important for fnorm, which --if modified by the user-- might 
really jeopardize the iteration.

Regards
Claas

On 20/03/12 21:35, orzel@xxxxxxxxxxxxxxx wrote:
> They way the class is used is to do something along
>      lm.minimizeOptimumStorageInit()
>      while (...) {
>           lm.minimizeOptimumStorageOneStep(x);
>      }
>
> That is, the loop is handled 'from outside'. To do this, you need the
> class to store all temporaries
>
> Thomas
>
>
>
> On 20/03/2012 19:47, Tim Holy wrote:
> > Hi Claas,
> >
> > On Tuesday, March 20, 2012 07:19:31 am Claas H. Köhler wrote:
> > > - Is there a reason why all local temporary variables (e.g temp, temp1,
> > > pnorm...) are defined as class members, instead of defining locally
> > > where needed?
> > I don't know specifically for this case, but in general it's for cases where
> > you call the same algorithm many times in one program. If you put them in the
> > class, you only have to allocate the storage once, when you first construct the
> > solver. If they are local to the function, you have to allocate them each time
> > the function is called. In many cases, that's a major overhead and
> > significantly hurts performance.
> >
> > Best,
> > --Tim