Compile error when composing linear algebra functions about chapel

[mppf]

IMO this is an API design issue in the linear algebra module.

Looking at proc inv specifically:

proc inv(ref A: [?Adom] ?eltType, overwrite=false) where usingLAPACK { ... }

Here it seems that the LAPACK calls modify the array in-place. At some point in history, it might have been the case that if overwrite=true, this routine would not return a copy of A. However, today, it copies A either way (with overwrite=false, it does it with var A_clone = A; and with overwrite=true it does it with return A;. So, I don't think the design of having overwrite as an optional argument here is reasonable. It doesn't offer much benefit (in terms of reducing copying in some cases, at least) and it means that the function needs to accept A with ref intent (because it might mutate it).

Instead, I'd recommend that we change proc inv (and any LinearAlgebra routine in a similar situation) into two routines with different names:

• A routine that never modifies the array passed in, always copies it and returns the new array (the result of inverting). E.g. proc inv(const ref A:[]): A.type.
• Another routine that never returns anything and mutates the array in place to compute the inverse. E.g. proc invInPlace(ref A:[]).

[damianmoz]

I agree with Michael that there is an issue with the design of the API. I would go so far as as to say there is an issue with its use.

I am assuming that you are intending these routines for use in real applications, not just toy (or purely pedagogic) applications.

Most of the time, you won't need a copy. In those situations where you really do need a copy of the original matrix as well as the mutated one, or probably more precisely, a factored or transformed one,, you really need to make those copies blatantly obvious in the code, not hidden under the hood so you never know the real overhead!

As a user of LINPACK and now LAPACK for a long time, and having rewritten them in C and C++ for real world use, the default name should refer to modify in place. Having the reverse convention encourages very (very very) bad programming practices.

I regularly get given MATLAB code that gobbles up memory like it is going out of style because there are copies of arrays all over the place. It makes such codes impractical for production work. The bane of my life.

Memory is expensive (from numerous perspectives even if its dollar cost has dropped). Don't waste it on lazy programming practices.

That advice is worth a lot more than my usual 2c.

[vasslitvinov]

@redhatturtle - until we have a better API for inv, your working variant is the same what used to happen in v1.31 under the covers for AtB_inv = inv(dot(A,B));.

I would suggest a minor tweak to your solution: move the declaration of AtB_inv to where it gets the output of inv(). This will ensure that AtB_inv takes over the outcome of inv():

var A, B : [1..n, 1..n] real;

var AtB = dot(A,B);
var AtB_inv = inv(AtB);

Cf. here the array produced by inv() is copied into the array AtB_inv then discarded:

var A, B, AtB_inv : [1..n, 1..n] real;
writeln(AtB_inv);

var AtB = dot(A,B);
AtB_inv = inv(AtB);