Add QR and RRQR interface methods

[pmli]

• adds pymor.algorithms.qr module with qr and rrqr methods
• replaces most usage of gram_schmidt in pymor/src (the exception is VectorArrayOperator.apply_inverse, because it uses reiterate=False, and it should anyway probably use an SVD method)
• parameter copy in qr and rrqr is commonly used, parameter check is only used in reductors.basic and algorithms.svd_va

[sdrave]

Make a lot of sense to me. If we can agree on the interface (see my comments), we can merge this before the release IMHO.

• tests are still missing ..
• the check args in gram_schmidt could be deprecated.

[sdrave]

This implies that an error is always raised. I don't think that will be the case in general?

[pmli]

I'm not sure what you mean exactly. I would say that "detected" does a lot of heavy lifting here (V with linearly dependent vectors may not be detected due to numerical roundoff).

[sdrave]

If I understood @drittelhacker correctly, a 'good' QR method should not raise an error if there a linearly dependent vectors, but replace the dependent vector by, e.g., a random vector. So even if linearly dependence is detected, it is not necessarily expected behavior that an error is raised. We might even disallow this. (In gram_schmidt we could replace the dependent vector by a random vector if a flag is set or so.)

[drittelhacker]

I think @sdrave misunderstood some comment I made. I do not think I suggested random basis extensions, but may have talked about random pivoting.

[pmli]

It was I who made a comment that a thin QR can be computed using gram_schmidt by adding random vectors. But, after thinking about it, the implementation would not be that simple (I think the simplest way would be to first run gram_schmidt, then replace the vectors flagged for removal with random vectors and insert zero rows into the R matrix, and finally orthonormalize the added random vectors w.r.t. the other vectors; almost doubling the code in gram_schmidt). Therefore, my suggestion is to assume in qr that the vectors are linearly independent.

[sdrave]

I think @sdrave misunderstood some comment I made. I do not think I suggested random basis extensions, but may have talked about random pivoting.

But do you expect qr(A), where A is rank deficient to fail or not, @drittelhacker?

Therefore, my suggestion is to assume in qr that the vectors are linearly independent.

I think we should first decide on the behavior we'd expect. I'm pretty sure we can come up with an acceptable solution for gram_schmidt if needed.

[artpelling]

Maybe this and delete line 211?

Suggested change

	rrqr(image, offset=gram_schmidt_offset, product=product, copy=False)
	rrqr(image, offset=len(image), product=product, copy=False)

[pmli]

Something is appended to image in line 212, so maybe it should be as is.

[artpelling]

Oh I see, I just thought it would be good to remove the specific reference to gram_schmidtsince now it could be also a different algorithm. Maybe just offset would do?

[pmli]

Aha, yes, that's a good point. I changed it now.

[artpelling]

Suggested change

	rrqr(basis, offset=basis_length, product=product, copy=False, check=False)
	rrqr(basis, offset=basis_length, product=product, copy=False, check=False, method='gram_schmidt')

[artpelling]

Either this or rephrase line 477

[pmli]

That's an interesting question. Maybe extend_basis should have method in ('trivial', 'rrqr', 'pod'). What do you think, @sdrave?

[sdrave]

Hmm, I guess we should not break the existing interface. So 'gram_schmit' should remain a possible method. But I would be ok with deprecating it and adding 'rrqr' as as method.

[sdrave]

See my comments to the ongoing discussions. I'd say we are almost good to go ..