Repository navigation
Tracker: 0.6 release #520
Description
Existing and planned changes for 0.6 (excluding things already merged into the 0.5 series). @pitdicker do you have more to add?
Required items:
sequences
- Revise API for choose/choose_multiple/shuffle Sequence functionality: API revisions #483, Improve tests for some seq APIs #515
- Revise weighted sampling Implement weighted sampling API #518
distributions
- Add Dirichlet distribution Support for Dirichlet distribution #485
- Add
gen_ratioAdd API for getting a bool with chance of exactly 1-in-10 or 2-in-3 #491 - Make
UniformsupportBorrow-ed arguments Make Uniform and its helper traits use arguments of type Borrow<X> #506, Fix ambiguity issues in use of Borrow<T> #509 - Add basic SIMD support Add basic SIMD support #523
- Sampling from unit sphere and circle Implement sampling from the unit sphere and circle #567
Core
- Seeding via
u64Convenient PRNG construction:seed_from_u64/from_hashable#522, Implement SeedableRng::seed_from_u64 #537 - Merge into master (+ bug fix) Merge 0.5 #599
- Publish rand_core 0.3 [0.5 branch] Prepare rand_core 0.3 release #614
PRNGs
- Move ISAAC generators to thei own crate Move ISAAC generators to their own crate #551
- Move
XorShiftRngto its own crate MoveXorShiftRngto its own crate #557 - Move ChaCha and Hc128 RNGs to their own crates Move ChaChaRng and Hc128Rng to their own crates #607
- Publish above crates
- Replace
SmallRngalgorithmSmallRngalgorithm #603 - Add performance metrics to documentation? Use real PRNG benchmarks in documentation #450
- Reorganise PRNG documentation PRNG module documentation #622
Documentation
Optional items:
ThreadRng
- Future of
thread_rng(algorithms) Future ofthread_rng#463 -
ThreadRng::newvsthread_rngRenamethread_rngtoThreadRng::new()? #404 - Make available without
stdMakethread_rng()available withoutstd#313 ThreadRng / EntropyRng improvements #579
Seeding
- Seeding via hashable value Convenient PRNG construction:
seed_from_u64/from_hashable#522, Universal seeder #554
Optimisations and extensions
-
IteratorRandom::choosecould usesize_hintOptimiseIteratorRandom::chooseforsize_hintorExactSizeIterator#511 Implement SeedableRng::seed_from_u64 #537 - Make
fillwork on derived array types ImplementFillfor derived array types #489 - Optimise
Rng::genon arrays OptimiseRng::genon arrays? #269
other
- New
rust-randomorganisation Project organisation #578 - Add fork protection to
ReseedingRngAdd Unix fork protection #466 - Add support for WASM-bindgen Add support for wasm-bindgen #541
Activity
pitdicker commentedon Jun 21, 2018
There are a couple of things I would like to see, but my time is getting a little more limited...
A few things I have on my personal wish list:
SeedableRng::new_from_u64(seed: u64). Seeding PRNGs (traits and bit size) dhardy/rand#18 (comment). Depending on the PRNG it can use the seed unmodified (for CSPRNGs), use some form of seed extension, or just run the PRNG for a couple of rounds using the unmodified seed. Convenient PRNG construction:seed_from_u64/from_hashable#522SeedableRng::split(&mut self, split_level: usize). Add rayon support #399 (comment). The PRNG can implement splitting using streams, jumping, or self-reseeding.rngs::adapter::SplittableRngAdd rayon support #399 (comment). Splits the PRNG onclone(). Can have multiple uses, but intended for Rayon.fill_bytes).New PRNGs (dhardy#60 (comment)):
XorShiftRng.It would be nice if we could make some progress with
no_stdsupport (#313):thread_rngwithno_std).EntropyRng, like RDRAND.dhardy commentedon Jun 21, 2018
I opened #522, but this actually concerns
rand_coreand can be completely independent of Rand 0.6.vks commentedon Jun 21, 2018
SeedableRng::new_from_u64would be a great usability improvement.dhardy commentedon Jun 22, 2018
To what are you referring?
pitdicker commentedon Jun 22, 2018
I think it is about a comment by Vigna about PCG streams. I can see why he thought it would have problems, because Xorshift and Xoroshiro are sensitive to the choice of constants, and he put a lot of effort into finding good ones.
A post on the PCG blog proved streams implemented using different increment constants are all of similar quality, but with different multiplier constants are questionable.
dhardy commentedon Jun 22, 2018
Ah, so that comment was about splitting RNGs. I'm not convinced on this issue either (more with regards to utility & applicability to threading). It would be good to create a new issue on that topic for further discussion.
Again, the PRNGs we pick is not a topic to discuss in the tracking issue. We already have a couple of threads on this: dhardy#52, dhardy#60 (and related: dhardy#58, #431). If need be create yet another issue.
vks commentedon Jun 25, 2018
This is the criticism of PCG streams: Vigna, Blackman, O'Neil
This does not make me comfortable using them, especially since they are not really tested as rigorously as the RNG itself.
sicking commentedon Jun 26, 2018
I'd like to see a more thoughtful look at what the
Rngtrait looks like. #483 did some big revisions there and proposed we go down a path whereRngmainly has functions for directly generating values. I'd like to see what it'd look like to follow through on that more consistently.I won't propose any changes here in order to keep this discussion on track. But I'll file a separate issue on this topic. Implementation work for this is trivial if we can get agreement (big "if", obviously), so might be doable relatively quickly.
Relatedly, we have a number of issues filed on the future and name of
thread_rng(). This is similarly API-breaking so would be good to get done sooner rather than later. But I don't have any full proposals here, so might be too optimistic to get done for 0.6.dhardy commentedon Jun 27, 2018
@sicking we already worked on
Rnga lot last year, leading up to the currentRng: RngCoredesign. We've already removed all core trait functions and all remaining methods do appear to be simple wrappers, as mentioned in #483. Yes, open another issue if you like.Good point on
thread_rng.sicking commentedon Jul 13, 2018
I opened #552 for one of the two backwards-breaking changes that I'd like to consider for
Rng.sicking commentedon Jul 13, 2018
And #553 for the other one.
sicking commentedon Jul 13, 2018
FWIW, I'd also love to rename
gen_rangeto justrange. But it feels like the transition process would be very painful.dhardy commentedon Jul 13, 2018
At least at the moment
gen_range,gen_boolandgen_ratioare somewhat consistent.dhardy commentedon Aug 23, 2018
According to the new milestone we're half way to 0.6, though one or two items (specifically thread-rng) may slip to later; probably we're well past half way in terms of work.
dhardy commentedon Sep 3, 2018
Progress note: we have now completed the most important stuff for 0.6 (in my opinion), except for limited progress on introducing new PRNG crates, and
SmallRng.coltfred commentedon Sep 18, 2018
@dhardy Do you have any idea when 0.6 would be available? We're currently working off master, but would like to stabilize on a release version soon if we can. Our main driver is WASM support.
dhardy commentedon Sep 19, 2018
@coltfred it would be nice to have 0.6 ready soon but I can't promise anything. Possibly around the end of the month, but that still requires some effort from those involved.
coltfred commentedon Sep 19, 2018
@dhardy It seems unclear to me which of the things listed here are going to be in 0.6. I'd also be happy to help in any way I can to drive this to the finish line.
dhardy commentedon Sep 22, 2018
@coltfred thanks for the offer of help. I've updated the above list to clarify the required changes for 0.6. If you like, review open PRs or have a look at #603.
coltfred commentedon Sep 25, 2018
@dhardy I can give it a look this Friday if others haven't gotten to it. Thanks so much for this library!
dhardy commentedon Oct 4, 2018
rand_xorshiftandrand_pcghave now been published.I started updating
SmallRngand removingrand_xorshiftfrom this repo, but hit a weird compile error.I just created #622 regarding PRNG documentation; this isn't critical for the 0.6 release but it would be very nice to have some help with this.
dhardy commentedon Oct 16, 2018
I think we're getting close to being able to make a release! Help with the following please:
dhardy commentedon Oct 17, 2018
I published:
rand_isaac0.1.0rand_hc1280.1.0rand_chacha0.1.0The last three have had no recent changes and should be ready.
Rand itself hopefully has code in sufficiently good shape for 0.6, but I'll wait two weeks before marking it final. In the mean-time, some documentation work is needed (see previous post).
dhardy commentedon Oct 23, 2018
I added an item to the tracker: #634. Please help out!
hcpl commentedon Nov 12, 2018
Can
i128_supportfeature be removed now that compile-time detection has been merged?dhardy commentedon Nov 12, 2018
That flag doesn't do anything any more; it's only there to avoid breakage. Probably we'll remove it for 0.7.
dhardy commentedon Nov 12, 2018
That flag doesn't do anything any more; it's only there to avoid breakage. Probably we'll remove it for 0.7.
Other news: I've scheduled the 0.6 release for Wednesday. The following two PRs will be merged first: