help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Financial:Grid search + leasqr to fit 3 parameters. How to speed up?


From: Olaf Till
Subject: Re: Financial:Grid search + leasqr to fit 3 parameters. How to speed up?
Date: Mon, 1 Aug 2011 13:29:02 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, Jul 18, 2011 at 10:37:08AM -0700, KRadomaƄski wrote:
> ...
> I know that execution time does not grow linearly with the size of data when
> we work on matrices instead of running the same procedure multiple times.
> Unfortunately the leasqr function only accepts one set of observations and
> returns one vector of parameters. 
> 
> Is there any way to overcome this? 
> 

Hi Krzysztof,

first, we are talking about a function of Octave Forge (which actually
has its own mailing list ...). leasqr is in the package 'optim'.

With optim version 1.0.16, you are free in chosing the dimensions of
the matrix of independents and the matrix of observations (yes, the
documentation string "x = vector or matrix of independent variables, 1
entry or row per observation." is wrong with this respect, I'll fix
that). The only restriction is that, if you specifiy weights, their
dimensions must match those of the observations.

So you can specify any matrix of observations (and of independents) to
leasqr, and leave it to your model function how to deal with them
(e.g. use them column by column for the same problem).

If you have a matrix of parameters, you can turn it into a vector
before passing it to leasqr. Within your model function, you could
regenerate the parameter matrix with reshape() and use it column by
column for the same problem, as with the observations.

If you can't specify a function for analytical computation of the
Jacobian of the residuals, but rely on the default function of leasqr
for finite differences (i.e. 'dfdp.m'), there will be still much
unnecessary computation. 'dfdp' will slightly change each parameter
and call your model function each time. But your model function will
compute results for each instance of the problem, although the
currently changed parameter only applies to one instance. You might
get a time reduction by factor 2 by letting dfdp compute a 'one-sided'
gradient (see documentation of leasqr).

A better, but more laborous, solution to the latter problem is to
avoid unneccessary computations within the function for finite
differencing. If you use nonlin_residmin or nonlin_curvefit, which
should offer all optimizing functionality of leasqr and a cleaner and
more functional interface, the users model function by default gets an
additional argument when called during finite differencing. This
argument enables it to identify the parameter to which the currently
computed partial derivative belongs, and so to avoid the above
unnecessary computation.

> Is using Matlab instead of Octave any chance for improvement? I read it
> deals with loops much quicker.

Optimized interpreted loops will not help here, since this time-saving
is negligible with respect to the time spent during one invocation of
your model function.

Olaf


reply via email to

[Prev in Thread] Current Thread [Next in Thread]