LinearAlgebra Solve() changes input array, gives wrong answer about chapel

[damianmoz]

Try

proc solve(A: [?Adom] ?eltType, ref b: [?bdom] eltType) {
  var (LU, ipiv) = lu(A);
  var y = permute (ipiv, b, true);
  var z = solve_tril(LU, y);
  var x = solve_triu(LU, z);
  return x;
}

in LinearAlgebra. That will not affect the original parameter b.

[damianmoz]

One could argue that the behavior be changed to not alter that input vector.

[bradcray]

Echoing Scott, thanks for the assists here, Guiillaume and Damian! It sounds as though all here agree that it would be better for the routine not to modify the b input argument, is that right? (or, if not, to at least document that it will be changed).

I think the way I'd achieve the "don't modify b" would be to change its argument into to in, which would give the routine a local copy of b to play with if need be (or to steal the actual argument if it is dead after this), while documenting the potential for a copy. So:

proc solve(A: [?Adom] ?eltType, in b: [?bdom] eltType) {
  var (LU, ipiv) = lu(A);
  b = permute(ipiv, b, true);
  var z = solve_tril(LU, b);
  var x = solve_triu(LU, z);
  return x;
}

[damianmoz]

As an aside, the approach taken by LinearAlgebra generally follows the style of MATLAB and does not overwrite the space used by matrix and vector parameters. This gobbles up memory, sometimes inordinately so if used without care.

The other approach is to overwrite space, i.e. the LU decomposition of A replaces A, the solution of Ax=b is overwritten in b, etc. If there is a need to keep a copy of the original data, that must be copied explicitly and saved elsewhere. This is a more fine grained approach. It avoids memory blowouts but requires slightly more work. This is the approach taken by tools such as LAPACK.

[bradcray]

@sdbachman : Apart from the answer, the fact that B changed definitely seems suspect, right? [edit: Ah yes, you say so, right in the title. I focused in on the incorrect answer at first]. I'm noticing that it seems to have shifted by an element, which is odd, and suggests some sort of 0/1 indexing issue to me. What version of Chapel are you using? (I see this with both chpl version 1.34.0 pre-release (8371b2af80) and chpl version 1.31.0, so it seems this has been around for awhile).

I'm tagging @Guillaume-Helbecque on this, knowing that he worked on this routine recently, on the off-chance that he has any insights. (Otherwise, will take a look when it's not so late).

[Guillaume-Helbecque]

As far as I know, the changes of the input vector B is the expected behaviour of the solve procedure. More precisely, solve computes an LU factorization of M using partial pivoting, and for some reasons, the permutation is then applied to B. I don't know what motivates this behaviour, but I agree that it is strange and would not be expected in practice.

For the wrong answer, I suspect an issue with the precision of floating-point numbers. Indeed, you expected 0.0 as first element of tmp, but you get -8.83858e-11, which is essentially zero.

[damianmoz]

As Guillaume correctly notes, solve does in fact alter its original B argument due to the pivoting strategy. Why this is exposed to the user, I do not know.
I see a slightly worse answer in the first element of the solution vector, -2.53552e-10 with the latest compiler. But, yes, that is the result of the underlying algorithm.. If you normalize the solution vector, the first element is just slightly more than 4 times the machine precision. So you have only lost 2 binary digits in accuracy which is extremely close to zero, again as correctly noted by Guillaume. A single pass of an enhanced precision iterative improvement might reduce that discrepancy

[sdbachman]

Thanks everyone! In my real code I was writing out B as a sanity check, so you can imagine my stress when I was B was changing after the Solve. It is good to confirm that this is expected behavior.

[damianmoz]

Scott, what error did you expect in your solution vector?

[vasslitvinov]

@sdbachman How do the following address this issue?

• With #24294, solve() no longer modifies its actual arguments.

• The the last element of tmp in your test code is 0; the first element of tmp is close to zero.

Can this issue be closed now?

[bradcray]

@vasslitvinov : Thanks for the fix here! I'm going to assert that we're in better shape now w.r.t. this issue and close this, but Scott, please let us know if you find or think otherwise. Thanks for reporting the issue!