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);