Gram-Schmidt with R

[pmli]

Closes #491.

• adds an option to compute the R matrix
• some improvements (no more flake8 issues with old_norm)
• adds unit tests

[codecov]

Codecov Report

Merging #577 into master will decrease coverage by <.01%.
The diff coverage is 94.44%.

Impacted Files	Coverage Δ
src/pymor/algorithms/gram_schmidt.py	98% <94.44%> (+0.12%)	⬆️
src/pymor/reductors/residual.py	69.72% <0%> (-0.62%)	⬇️

[codecov]

Codecov Report

Merging #577 into master will decrease coverage by 0.36%.
The diff coverage is 93.75%.

Impacted Files	Coverage Δ
src/pymor/algorithms/gram_schmidt.py	97.89% <93.75%> (+0.02%)	⬆️
src/pymor/reductors/residual.py	69.72% <0%> (-0.62%)	⬇️
src/pymor/models/iosys.py	61.48% <0%> (ø)
src/pymor/models/mpi.py	26.66% <0%> (ø)
src/pymor/models/basic.py	85.93% <0%> (ø)
src/pymor/models/interfaces.py	83.33% <0%> (ø)
src/pymor/reductors/bt.py	66.08% <0%> (+1.5%)	⬆️
src/pymor/discretizers/fv.py	88.38% <0%> (+4.92%)	⬆️

[sdrave]

LGTM. Just one remark: Since computing R is mostly for free, I would simplify the code by always computing R and renaming the parameter from compute_R to return_R

[pmli]

Could allocating additional memory cause issues when return_R == False? Or can len(A) always be assumed to be "small"? I was also wondering if R should be constructed row by row, instead of creating a square matrix and deleting rows at the end.

[sdrave]

I would say that if len(A) is so large, that storing len(A)**2 doubles is problematic, then a VectorArray is the wrong data structure.

[pmli]

Ok, good. I made the changes.