New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add random_state
and seed
arguments to rrf
and adaptive_rrf
#1564
Conversation
seed
argument to rrf functionseed=None
argument to rrf
Codecov Report
|
Looks good to me so far. Would you also add Hopefully, this doesn't cause strange git conflicts with #1552... |
We actually have the policy that
ensures that by default a global random state is used, which is seeded by a pyMOR default. Of course, that mens that calling |
I also came across this part of the code when getting to the bottom of the inner workings of What bugs me a little bit with the latest version is the encapsulated redundancy of the assertions and generation of random states in the
In the latest commit f05fcc6, calling Another issue is that I am still struggling with the |
Yes.
I implemented this locally in order to test that PR and I think this is a handy feature. I don't think this should interfere functionally as the arguments are set to |
seed=None
argument to rrf
random_state
and seed
arguments to rrf
and adaptive_rrf
I'm not sure if I understand what you mean. If you pass
Yes, that should also be the case. However, if you call
No, the idea is to have single seed for the entire program run which is a default for |
Ok great, then I think I understood it correctly.
What I meant was that pymor/src/pymor/vectorarrays/interface.py Lines 856 to 857 in a0b0a8e
is now done in the It shouldn't be a problem really, just lets me think about whether its cleaner to manually do the seeding when necessesary and then only pass |
I quite like the idea of removing the |
Up to randomization that is difficult or expensive to avoid (e.g., parallelization in BLAS), I think having as much determinism as possible is desirable (e.g., to have more-or-less reproducible code for publications). So, although it might seem unintuitive, I would be for methods, that use random numbers, to return the same result on consecutive calls. I was actually thinking that we should discuss JAX's approach (basically, making |
Let's continue the big design discussion in #1577. |
This can be closed since merging #1736, right? |
Yes! |
This PR adds
random_state=None
andseed=None
to the arguments ofrrf
andadaptive_rrf
in order to enable reproducible computations and fixes a typo in the docstring ofVectorArray.random
.