Tracker: 0.6 release

[dhardy]

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_ratio Add API for getting a bool with chance of exactly 1-in-10 or 2-in-3 #491
• Make Uniform support Borrow-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 u64 Convenient 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 XorShiftRng to its own crate Move XorShiftRng to 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 SmallRng algorithm SmallRng algorithm #603
• Add performance metrics to documentation? Use real PRNG benchmarks in documentation #450
• Reorganise PRNG documentation PRNG module documentation #622

Documentation

• See Documentation organisation #634

Optional items:

ThreadRng

• Future of thread_rng (algorithms) Future of thread_rng #463
• ThreadRng::new vs thread_rng Rename thread_rng to ThreadRng::new()? #404
• Make available without std Make thread_rng() available without std #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::choose could use size_hint Optimise IteratorRandom::choose for size_hint or ExactSizeIterator #511 Implement SeedableRng::seed_from_u64 #537
• Make fill work on derived array types Implement Fill for derived array types #489
• Optimise Rng::gen on arrays Optimise Rng::gen on arrays? #269

other

• New rust-random organisation Project organisation #578
• Add fork protection to ReseedingRng Add Unix fork protection #466
• Add support for WASM-bindgen Add support for wasm-bindgen #541

[pitdicker]

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 #522
• SeedableRng::split(&mut self, split_level: usize). Add rayon support #399 (comment). The PRNG can implement splitting using streams, jumping, or self-reseeding.
• rngs::adapter::SplittableRng Add rayon support #399 (comment). Splits the PRNG on clone(). Can have multiple uses, but intended for Rayon.
• basic SIMD support Investigate SIMD support #377. At least the ability to generate SIMD types (using fill_bytes).

New PRNGs (dhardy#60 (comment)):

• addition of PCG-XSL-RR 128/64 (MCG) and PCG-XSH-RR 64/32 (LCG).
• addition of SFC-32 and SFC-64.
• maybe addition of XoroshiroMT.
• maybe addition of Xoroshiro128+.
• deprecation of XorShiftRng.

It would be nice if we could make some progress with no_std support (#313):

• I was playing with a lock-free shared CSPRNG (to use for thread_rng with no_std).
• have a way to set another fallback in EntropyRng, like RDRAND.

[dhardy]

I opened #522, but this actually concerns rand_core and can be completely independent of Rand 0.6.

[vks]

• I agree that SeedableRng::new_from_u64 would be a great usability improvement.
• I'm a bit sceptical about streams. They don't seem as well tested as the RNGs, and some people claim their statistical quality is poor.
• I think xoshiro should be considered as well.

[dhardy]

I'm a bit sceptical about streams

To what are you referring?

[pitdicker]

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]

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.

I think xoshiro should be considered as well.

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]

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]

I'd like to see a more thoughtful look at what the Rng trait looks like. #483 did some big revisions there and proposed we go down a path where Rng mainly 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]

@sicking we already worked on Rng a lot last year, leading up to the current Rng: RngCore design. 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]

I opened #552 for one of the two backwards-breaking changes that I'd like to consider for Rng.

[sicking]

And #553 for the other one.

[sicking]

FWIW, I'd also love to rename gen_range to just range. But it feels like the transition process would be very painful.

[dhardy]

At least at the moment gen_range, gen_bool and gen_ratio are somewhat consistent.