adding randomized algorithms #665
Conversation
|
Hi @deneick, this is looking good. Is there some literature you can reference? If yes, it would go in |
|
Hi @pmli, I added the literature. |
There was a problem hiding this comment.
@deneick Below are some (mostly minor) comments.
Some unit tests would be nice. They don't have to be complicated, e.g. checking the probabilistic error bound would be too much. They could just check that the result is a vector array of expected dimensions and dtype.
There are also a few PEP8 errors. You can run flake8 src/pymor/algorithms/randrangefinder.py to see them.
|
I guess I covered everything. |
|
Increasing the test coverage would be nice. You could add some simple tests to def test_rrf():
A = ...
Q = rrf(A)
assert Q in A.range
assert len(Q) == 2 |
|
Just a few minor remarks:
Otherwise, looks good to me. Sphinx documentation is rendering nicely and code coverage is excellent (98%). |
|
I don't have a reference for approximate_operatornorm, so I added some explanation. |
|
Sorry, I need some time to think about this, and I don't have any right now. Will try to submit a review by the end of next week. |
|
FYI: Slycot switched their build system to |
|
|
||
| def mvinv(v): | ||
| return source_product.apply_inverse(source_product.range.from_numpy(v)).to_numpy() | ||
| L = LinearOperator((source_product.source.dim, source_product.range.dim), matvec=mv, matmat=mv) |
There was a problem hiding this comment.
Is matmat=mv really correct? I would expect scipy to use column vectors, but from_numpy/to_numpy uses column vectors (@pmli, I know, I know ...).
There was a problem hiding this comment.
I just realized scipy does not use matmat in eigsh, but only in svds, so I will leave this out here.
| def mvinv(v): | ||
| return source_product.apply_inverse(source_product.range.from_numpy(v)).to_numpy() | ||
| L = LinearOperator((source_product.source.dim, source_product.range.dim), matvec=mv, matmat=mv) | ||
| Linv = LinearOperator((source_product.range.dim, source_product.source.dim), matvec=mvinv, matmat=mvinv) |
| This is an implementation of Algorithm 4.4 in [HMT11]_. | ||
|
|
||
| Given the |Operator| `A`, the return value of this method is the |VectorArray| | ||
| `Q` whose vectors form an orthonomal basis for the range of `A`. |
There was a problem hiding this comment.
Please cherry pick this commit to your branch to fix the CI issues with Slycot: 751bc64
| return source_product.apply(source_product.source.from_numpy(v)).to_numpy() | ||
|
|
||
| def mvinv(v): | ||
| return source_product.apply_inverse(source_product.range.from_numpy(v)).to_numpy() |
There was a problem hiding this comment.
Is adaptive_rrf actually supposed to work if source_product.space.from_numpy is not implemented? Or is from_numpy always implemented for source_products in applications?
There was a problem hiding this comment.
Or is from_numpy always implemented for source_products in applications?
No, this cannot be expected. In that case you would need to specify lambda_min. For the future, I would hope that at some point we reimplement something like ARPACK in pyMOR. Not sure how much effort would be required, however.
I added randomized range finder algorithms: one adaptive algorithm and one with power iterations.