Rewrite Rand functions #867
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We now use a generic Rand structure which abstracts the core functions from the backing engine. The old Mersenne Twister engine is removed and replaced instead with three alternatives: - Pcg32 - Xoroshiro128+ - Isaac64 These should provide sufficient coverage for most purposes, including a CSPRNG using Isaac64. Consumers of the library that do not care about the actual engine implementation should use DefaultPrng and DefaultCsprng.
|
brilliant |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We now use a generic Rand structure which abstracts the core functions
from the backing engine.
The old Mersenne Twister engine is removed and replaced instead with
three alternatives (Mersenne Twister isn't the best we could do):
These should provide sufficient coverage for most purposes. Consumers of the library that do not care about the actual engine implementation should use
DefaultPrngandDefaultCsprng. (Might look further into Isaac64 as a CSPRNG actually since some literature possibly suggests otherwise on its applicability there, will revisit).I've tried to keep the usage as simple as possible whilst ensuring you can't really use these incorrectly. I don't want to over abstract and end up with something like C++11 and it's random interface. Seed values are limited as a result to
u64and are extended as needed using a generator. This should be perfectly fine for and is recommended for Xoroshiro128+ and I've used the same technique for Pcg.