You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've continued to fiddle with our RNG's. It may not be prudent to expose the implementation details of them and instead just call them something like FastRng and CryptoRng, to give us flexibility to change which algorithms are used in the future. On the other hand, an RNG like XorShift in particular has some peculiar properties that are implementation specifc, so it may be harder to replace. Opinions?
There is some value in knowing the specific algorithm used, particularly if one wants to replay or independently generate specific seeded sequences of random numbers. I have done this from time to time for games.
Another possibility could be typedefs to more generic names, which would allow replacing the default algorithms for people who don't care about the specific algorithm, but would still make removing specific ones difficult.
This would prevent users from seeding the RNGs with fixed values and getting a fixed output stream across Rust versions. If I'm writing an automated test of some mathematical routine that uses random numbers, I may seed it so I will get the same results each time; if Rust changes the RNG under me, my tests will break.
(For example, I may have some algorithm for sampling from a weird probability distribution. I could seed the RNG and compare Rust's output to a known-good algorithm, but then the output would change a few versions later.)
Activity
zkamsler commentedon Oct 24, 2013
There is some value in knowing the specific algorithm used, particularly if one wants to replay or independently generate specific seeded sequences of random numbers. I have done this from time to time for games.
Another possibility could be typedefs to more generic names, which would allow replacing the default algorithms for people who don't care about the specific algorithm, but would still make removing specific ones difficult.
capnrefsmmat commentedon Oct 24, 2013
An opinion from left field:
This would prevent users from seeding the RNGs with fixed values and getting a fixed output stream across Rust versions. If I'm writing an automated test of some mathematical routine that uses random numbers, I may seed it so I will get the same results each time; if Rust changes the RNG under me, my tests will break.
(For example, I may have some algorithm for sampling from a weird probability distribution. I could seed the RNG and compare Rust's output to a known-good algorithm, but then the output would change a few versions later.)
huonw commentedon Oct 24, 2013
We have
StdRngandTaskRngtypes for this purpose. I'm not 100% sure we need to add more aliases.alexcrichton commentedon Jun 5, 2014
Closing, I agree with @huonw, the current names are really all we need.
Auto merge of rust-lang#10053 - naosense:fix_9933, r=xFrednet
Merge rust-lang#10053