Re: improved QR & Cholesky updating

[Jaroslav Hajek]

On Wed, Jan 21, 2009 at 4:21 PM, John W. Eaton <address@hidden> wrote:
> On 21-Jan-2009, Jaroslav Hajek wrote:
>
> | Sorry, this should have been part of the patch, but somehow I forgot
> | to do the last refresh (also sorry for the message).
> | It's now uploaded. fsolve will simply check for qrupdate at first
> | start, and if not found, it will update the qr factorization by
> | recalculation. For large systems, of course, that's going to be much
> | slower, but will work.
> |
> | I intend to do the same thing anywhere the updating routines will be
> | used (due to their nature, they can be always replaced). That's why I
> | disabled their compiling entirely when qrupdate is not present - so
> | that their presence can be checked with the "exist" function.
>
> Instead of
>
>  persistent have_qrupdate = exist ('qrupdate') == 5;
>
>  [...]
>
>  ## Update the QR factorization.
>  if (have_qrupdate)
>    [q, r] = qrupdate (q, r, u, v);
>  else
>    [q, r] = qr (q*r + u*v');
>  endif
>
> in fsolve.m and every other function that might use qrupdate, why not
> check HAVE_QRUPDATE in the QR::update functions and do this operation
> there?  Then the check would only have to occur in one place rather
> than in every part of Octave that uses qrupdate.
>
> jwe
>

I'm not really sure. The point is that in this way, you have, in an
m-file, a clear indication that the qrupdate funcs are unavailable.
Sometimes there may be better workarounds. For instance, the fix I
committed to fsolve is really simplistic; in fact, if qrupdate is not
available, it is better to not form the qr factorization explicitly at
all and simply pass the original jacobian to __dogleg__. This is
something I want to do eventually.
A similar case is lsqnonneg. The current code forms and solves a
system in each step; I'd like to allow it to form a qr or cholesky
factorization once and update it; however, if the updating functions
are not available, then the current code is better than what would
result from replacing the factorizations.

I think this rule applies in general - IMHO, if a functionality is not
available, it's better to disable a function than to provide a version
that always fails, because the former condition can be checked
gracefully and allows for possible workarounds.

regards

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz