Mercurial > hg > octave-lyh
changeset 8616:3d75d717cbe0
do not pivot by default in fsolve
author | Jaroslav Hajek <highegg@gmail.com> |
---|---|
date | Wed, 28 Jan 2009 13:01:57 +0100 |
parents | 7baacb6a8a65 |
children | 4b26e9fbbb37 |
files | scripts/ChangeLog scripts/optimization/fsolve.m |
diffstat | 2 files changed, 11 insertions(+), 13 deletions(-) [+] |
line wrap: on
line diff
--- a/scripts/ChangeLog +++ b/scripts/ChangeLog @@ -1,3 +1,8 @@ +2009-01-28 Jaroslav Hajek <highegg@gmail.com> + + * optimization/fsolve.m: Don't use pivoting at all (for the time + being). + 2009-01-28 Jaroslav Hajek <highegg@gmail.com> * optimization/fsolve.m: Use more adaptive rescaling.
--- a/scripts/optimization/fsolve.m +++ b/scripts/optimization/fsolve.m @@ -154,18 +154,12 @@ useqr = updating && m >= n && n > 10; if (useqr) - ## Get QR factorization of the jacobian, optionally with column pivoting. - ## TODO: pivoting is only done in the first step, to get invariance - ## w.r.t. permutations of variables. Maybe it could be beneficial to - ## repivot occassionally? - if (niter == 1) - [q, r, p] = qr (fjac, 0); - ## p is a column vector. Blame Matlab for the inconsistency. - ## Octave can handle permutation matrices gracefully. - p = eye (n)(:, p); - else - [q, r] = qr (fjac*p, 0); - endif + ## FIXME: Currently, pivoting is mostly useless because the \ operator + ## cannot exploit the resulting props of the triangular factor. + ## Unpivoted QR is significantly faster so it doesn't seem right to pivot + ## just to get invariance. Original MINPACK didn't pivot either, at least + ## when qr updating was used. + [q, r] = qr (fjac, 0); endif ## Get column norms, use them as scaling factors. @@ -327,7 +321,6 @@ if (useqr) u = (fvec1 - q*w) / sn; v = dg .* ((dg .* s) / sn); - v = p' * v; ## Update the QR factorization. [q, r] = qrupdate (q, r, u, v);