-
Notifications
You must be signed in to change notification settings - Fork 430
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
Implement PartialEq/Eq on PRNG Generators where possible #964
Comments
This sounds perfectly reasonable to me, even for crypto PRNGs (as you say, it's possible to read the state anyway if one really wants to). First thing would be to apply this to the rngs repo and rng crates in this repo, along with minor version bumps and changelogs (see contributor guide). Finally, we can update the PRs are welcome. (Sorry for not offering to do this myself, but I am a voluntary maintainer and already put quite a bit of time into reviews, communication, etc.) |
Seems fine. I'm curious however: Can you give more context for "validate determinism"? It's not for tests? You want to establish some property of You want basically It'd be cool if rust supported
Anyways.. We do technically encourage one bit leaks about the internal state by doing this, but it appears fine since real exploits seem unlikely. :) I'd think In this vein, there are increasingly |
Interesting idea about supporting I disagree about the proposed |
I agree
|
@burdges my current use case is essentially what the pseudo code at the top is. To ensure that I haven't broken determinism, I run each simulation step twice and assert that the newly produced states are identical. This necessitates that the PRNGs are stored as part of the state, which in turn means they need to be comparable. |
I think we can close this now? |
It's implemented for |
Fixed by rust-random/rngs#7. |
It would be nice if the various PRNG Generators implemented PartialEq/Eq (where possible) so that it's possible to validate determinism in a simulation.
Example
Currently this has to be worked around by introducing a wrapper type that inappropriately peers into the implementation details of the PRNG Generator to do a memory compare.
The text was updated successfully, but these errors were encountered: