Seed RNGs with a uniform type

[SiegeLord]

I think it would be convenient to have a uniform way to reseed all RNGs. Currently, each RNG could potentially use (and often does so in practice) a different seed type for the SeedableRng trait implementation. I propose that trait to have the following two methods (and an associated function) added:

/// Number of bits needed to completely reseed the generator
fn get_seed_size(&self) -> uint;

/// Reseeds the RNG using an array of u64's, padded with 0's if needed.
/// If more data is given than could be used, it is first reduced using a hash.
fn reseed(&mut self, &[u64]);
fn from_seed(&[u64]) -> Self;

The current methods could either be removed, or renamed to reseed_exact etc. It currently appears that some RNGs already do something similar to what the proposed functions do, while others (e.g. XorShiftRng) require the complete state.

[huonw]

We discussed this on IRC a little at the time:

Apr 29 23:20:47 <SiegeLord> huon, what do you think of this: https://github.com/mozilla/rust/issues/13663
Apr 29 23:22:09 <huon>  SiegeLord: I thought about it when creating the interface
Apr 29 23:22:40 <huon>  SiegeLord: I thought expressing the true seed type was nice
Apr 29 23:23:02 <huon>  SiegeLord: but the non-uniformity is a little annoying
Apr 29 23:23:13 <huon>  SiegeLord: so... I guess I'm kinda ok with it?
Apr 29 23:23:15 <SiegeLord> Not all RNGs actually implement that trait with the true seed
Apr 29 23:23:45 <huon>  that's a "true seed" for those RNGs
Apr 29 23:24:03 <huon>  i.e. it's legitimate them to see them with partial data
Apr 29 23:24:09 <huon>  *seed
Apr 29 23:24:15 <SiegeLord> I'd think the same would work for XorShift one
Apr 29 23:24:20 <huon>  I guess?
Apr 29 23:24:27 <SiegeLord> The only dissallowed value is all 0's for it
Apr 29 23:25:31 <huon>  I think the seed type would have to be u8
Apr 29 23:25:42 <huon>  hm, actually that's a lie
Apr 29 23:26:17 <huon>  SiegeLord: using a uniform seed type possibly introduces endianness issues
Apr 29 23:26:26 <huon>  (but it's late so I'm not thinking quickly atm...)
Apr 29 23:26:41 <SiegeLord> That's a good point...
Apr 29 23:26:48 <SiegeLord> I'll think about it some more...
Apr 29 23:27:25 <SiegeLord> I just want to be able to pass the seed as a command line argument and it seems... odd for me to create a shim between that number and these implementation-specific values

[SiegeLord]

I actually don't think it's as big of an issue today, because all of the RNGs implement Rand, so you can do:

let seed_rng = XorShiftRng::from_seed([1, 2, 3, 4]);
let your_real_rng: IsaacRng = seed_rng.gen();

By routing your seeding through XorShiftRng you obtain the desired uniform seeding interface. The seed for XorShiftRng is a bit large, and it's not clear to me how to easily seed it from a command line argument, but to me it seems to be a separate issue. Perhaps a simpler RNG that only takes a u64 as a seed would work here, but it will naturally be a poor RNG, so maybe it's a bad idea to do this.

[vks]

@SiegeLord This is very nice, I did not know that! I think this example should be added to the docs.

However, this is not exactly the desired interface, because it only works for seeds that are of type [u32, ..4]. It excludes two important use cases:

• Seeding just an integer.
• Seeds larger than 2^128.

The latter is maybe not that important (still, some user might want to have a larger seed space), but it would be covered by a &[u32] interface.

[huonw]

You can turn a single integer into a larger seed, e.g. XorShiftRng::from_seed([x, x, x, x]) (as long as x != 0), and for seeds larger than 2¹²⁸, you can use a seeding RNG that takes a &[u32].

[vks]

For some RNGs it is not necessary to use a seeding RNG, because the bytes can be fed directly into them.

[steveklabnik]

@huonw is planning on stabilizing rand soon, so this concern might be part of that.

[huonw]

RFC rust-lang/rfcs#722, the current design there is to not provide SeedableRng in std and so punt this question out of the standard library to avoid having to consider it in detail for 1.0.

[abonander]

@huonw @steveklabnik Should this be closed now that rand is out-of-tree?

[vks]

I think the issue should rather be moved there.

[steveklabnik]

filed as rust-random/rand#80