mat: Should Factorization routines check for the condition number?

[btracey]

It may be that factorization routines should check the condition number and return an error. This would make the failure happen earlier. For example, when using chol.Factorize(), and then SolveCholesky.

In most cases we cannot find the condition number before doing the factorization (since factorizing is how one frequently finds the condition number), but we can compute the condition number (like we already do) and return an ErrCond.

[kortschak]

It's not clear to me how this would work better than what we have. The factorisation routines that we have that can fail return a boolean indicating success. Those that cannot do not. If the routine fails it should not be used, and the condition number can be obtained from the Cond method if the factorisation has calculated that. There may be places where the condition number could be used earlier in solvers (some of these are marked with TODOs), but these are not API-changing changes.

Are you suggesting the success booleans be replaced with error returns that are Condition? I'm not sure that makes things simpler.

[kortschak]

ping

[btracey]

That was my thought. It's mostly about future-proofing. For example, if we switched to an algorithm that also finds the set of vectors that cause that condition number (I know some of them exist, but don't know the runtime details). Or with respect to a future errors package, it might be nice to implant more context. In the map/type assignment case, there's no extra information, it is or it isn't. In the factorization there's plausibly more information (most notably the condition number). An error type future-proofs against a lot of changes, a boolean doesn't, especially if the future is going to look like:

ok := chol.Factorize(a)
if !ok {
return chol.Cond()
}
(or something like that)

[kortschak]

OK

[btracey]

I mean, it's not clear the benefit is there, I was just explaining the thought.

[kortschak]

We need a decision one way or the other though.

[btracey]

It sounds like you still lean toward the boolean version?

[btracey]

Looking at the methods, it seems like the ok system is much more in line with the existing algorithms, for instance we don't compute the condition number if the matrix is singular. The error comes when actually solving the system. It seems like the current design is the most natural. As mentioned above, if you want to check on the condition number when the matrix is non-singular, you can do that. If you do not wish to (for instance printing components of the matrix), then it's not really an error to factorize it (even though some of the numbers could be crazy). Seems better to stick with the API that's natural for the algorithm we have.

[kortschak]

It sounds like you still lean toward the boolean version?

Yep. With that we can be free with API. Even though error contents should not be relied on, they are (we do in tests for example), so making error returns a thing makes that more constrictive.