ma64: Cholesky and LU need a Reset method

[vladimir-ch]

Both methods panic when the size of the receiver and argument mismatch:

    if orig != c {
        if c.isZero() {
            c.chol = NewTriDense(n, matrix.Upper, nil)
        } else if c.chol.mat.N != n {
            panic(matrix.ErrShape)
        }
        c.chol.Copy(orig.chol)
    }

Wouldn't reusing it be more natural and useful?:

    if orig != c {
        if c.isZero() {
            c.chol = NewTriDense(n, matrix.Upper, nil)
        } else {
            c.chol = NewTriDense(n, matrix.Upper, use(c.chol.mat.Data, n*n))
        }
        c.chol.Copy(orig.chol)
    }

Otherwise the only way to reuse a factorization is through Factorize. The panic error ErrShape does not feel right either.

[vladimir-ch]

Perhaps I should have made it a question: Should factorizations be dimensionally restricted like matrices? Maybe they should but then they need a Reset method.

[btracey]

I agree with your last sentence, they should but with a reset method. @kortschak ?

[kortschak]

That would be consistent with the rest of the API. Yes.

[vladimir-ch]

Ok, I changed the title of this issue. Now it seems obvious.

Another couple of questions comes to my mind:

• now all Factorize methods overwrite the receiver irrespective of its dimensions. Is this the right behaviour, shouldn't it behave like the other methods? On the other hand, Factorize is different because it creates the factorization. They could be standalone functions (but their name would not be nice), or they could require a zero receiver.
• If the overwriting behaviour is kept, should the receiver be overwritten even if the factorization fails?
• A related question, take for example Cholesky.SymRankOne, should it modify/invalidate the reciever if the update fails? It seems like it should not.

I'm not sure if this issue is the best place for these questions but at least I write them here before they escape my mind. Also, it seems to me that this issue and the above questions fall under the API stability effort.

[kortschak]

1. I think this is OK as is.
2. Probably not, though I'm not adamant about this. A workspace could be used to make the operations atomic.
3. Making the operation atomic would solve this.

[vladimir-ch]

Closed by #378 and #382