Re: fzero vectorization?

[Jaroslav Hajek]

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?