Check for truncation in eigendecomposition

[andreasnoack]

The symmetric/Hermitian eigensolvers support finding only some of the eigenvalues. Consequently, the returned factorization might represent a low rank version of the input matrix. Method defined for Eigen (det, inv, isposdef) should therefore check the number of values and vectors.

[tkelman]

Might be a clearer separation of concerns if truncated eigenfactorizations were a different type.

[andreasnoack]

Maybe. I'm not sure it is worth it when so few methods are defined for Eigen and the check is so simple.

[tkelman]

If we leave it as-is, then every single piece of code that does anything with an Eigen object will need to be aware of this possibility and handle it specifically. For the sake of writing generic code that operates on eigenfactorizations, it would be good if the meaning of the type is predictable. "Represents the entire matrix, except when it doesn't" isn't great.

[andreasnoack]

When using the fields of a factorization directly, you'd always have to check if the factorization is valid. E.g. the LU or BK might have failed so you should remember to check the info field. The generic programming argument applies to generic functions which is exactly what this issue is about. If you really want to discuss this further then come up with a credible example (but it's not an invitation since I think we can both make better use of our time).

[tkelman]

The generic programming argument applies to generic functions which is exactly what this issue is about.

Base isn't the only place that generic functions get defined. User code will write them too - a few packages do make use of the Eigen type.

credible example

Algorithms that get passed a factorization object to reuse it over multiple iterations, for example. Anything that extracts the vectors and values and assumes they will be of a size that makes sense for a complete factorization (since we haven't documented the possibility of anything else happening, have we?).