when should inv(factorization) be another factorization?

[StefanKarpinski]

This question came up here: #32094. I observed that once you've gone to the trouble of taking the SVD of a matrix and then taking an inverse (or pseudo-inverse), you may very well want to keep it in factorization form. Moreover, if we return a factorization object for an inverse, you can call Matrix on it to materialize the actual inverse, whereas we don't currently have a generic way of asking for the inverse factorization of a given factorization, but that is often something that can be computed efficiently.

[StefanKarpinski]

cc @crstnbr, @dkarrasch, @kshyatt, @stevengj, @andreasnoack

[stevengj]

I guess. In many cases, like LU, computing the inverse factorization is more expensive than computing the inverse matrix, so it is nice to be able to get the latter without the former. There is also a question of motivation — I can’t recall ever needing or wanting the inverse factorization (at least, not explicitly: \ is enough).

[andreasnoack]

As Steve points out, in quite a few cases it's not simple to compute/represent the inverse with another factorization. Even something as simple as the inverse of a Cholesky can't currently be represented with our factorization since our Cholesky is ◣◥ whereas the inverse is a "backward" Cholesky ◥ ◣.

My gut feeling is that, in general, you are interested in the elements of inverse, i.e. the dense matrix representation, when calling inv. In the special cases where it would be useful with, e.g. then inverse as an Eigen, it should be fairly simple to construct explicitly so I think I'd be in favor of always returning an AbstractMatrix from inv.

[dkarrasch]

I agree. In #32094 I think I was mislead by the specifics of the SVD.