octave-maintainers
[Top][All Lists]
Advanced

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

Re: fzero vectorization?


From: Olaf Till
Subject: Re: fzero vectorization?
Date: Wed, 1 Dec 2010 22:41:07 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Wed, Dec 01, 2010 at 10:26:14PM +0100, Jaroslav Hajek wrote:
> On Wed, Dec 1, 2010 at 10:46 AM, Olaf Till <address@hidden> wrote:
> > Hi,
> >
> > consider a function of n variables and n outputs, but consisting of n
> > _independent_ "sub"functions, i.e. each relating one of the variables
> > to one of the outputs (and the indices of variable and output are the
> > same, so that the gradient of the whole function would be a diagonal
> > matrix).
> >
> > In finding a zero of such a function, algorithms working on the
> > deviation from zero of all subfunctions together (e.g. sum of squared
> > residuals) don't seem to be very good (e.g., some elements of the zero
> > may be very poorly approximated). And such algorithms are actually not
> > meant for such a case.
> >
> > A more natural, and probably more successful, approach would be to use
> > fzero independently on each of the subfunctions. But:
> >
> > 1. Extracting the subfunctions may be inconvenient. (E.g., I now have
> >   such a case, where finding the zeros of similar subfunctions is
> >   needed within an overall modell, and the parameters of the
> >   subfunctions are provided by some function, but in groups for
> >   subsets of the subfunctions.)
> >
> > 2. This might be not so efficient. (This can be decisive if the zero
> >   finding is part of an "outer" optimization.)
> >
> > So I suggest "vectorizing" fzero to deal with such cases. (In fact
> > I've already done it ...). Technically, the user function should
> > return an n-element vector, and the initial bracketing (or one side of
> > it) can be given as a matrix of n rows and 2 (or 1, respectivly)
> > column(s). There would be the problem that fzero allows the initial
> > bracketing to be a 2-element column _or_ row vector for 1-valued user
> > functions; I'd suggest that an additional option (e.g. "fzero_vector"
> > -> true for vectorized handling) is used to distinguish a single side
> > of initial bracketing for a 2-valued user function from a complete
> > initial bracketing of a 1-valued user function.
> >
> > There are two disadvantages:
> >
> > 1. The code of fzero gets more difficult to read (this might be
> >   subjective).
> >
> > 2. Zero finding of simple single functions will get slower (for me
> >   factor 4--5 for the test-example "fzero(@cos, [0, 3])").
> >
> > Olaf
> >
> 
> Avoid making functions overbloated with features. Why not just make
> this a separate function?

I'll do that on Octave Forge.


reply via email to

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