Random number generators not serializable

[maciejkula]

It would be nice for the rand number generators to implement RustcEncodable and RustcDecodable.

While I am not familiar with the possible implementation difficulties, serializability of random number generators is quite useful in Python's numpy for instance --- where the Mersenne twister implementation is easily serializable given that its state is just a regular numpy array.

[thomcc]

Seconding this. For a lot of applications (well, this is a common requirement for games, at least) that require a seedable RNG, you want to be able to save and restore the state as well, as simply reseeding with the same seed used initially won't pick up where the RNG left off (obviously).

[rsaarelm]

I need this as well. The implementation should be no problem. If you look at eg. XorShiftRng, it's just a 128-bit plain-old-data blob.

I'm currently working around this with my own type that just wraps XorShiftRng and then uses unsafe code to cast the XorShift instance into a binary blob and back for serialization.

[UnderTheCarpet]

Maybe the simplest way to go would be adding a way to extract the seed from SeedableRng:

pub trait SeedableRng<Seed>: Rng {    
    fn reseed(&mut self, Seed);
    fn from_seed(seed: Seed) -> Self;
    fn extract_seed(&self) -> Seed; //new
}

This way, you can resume simply with

let rng = SeedableRng::from_seed(old_rng.extract_seed())

I don't know, if this would work for every implementation of this trait out there. And it is obviously a none backward compatible change.

[dhardy]

Thanks to @LinearZoetrope serialisation is now available for the ISAAC and Xorshift generators. This will be part of the 0.5 release, although that isn't ready yet. Back-porting to 0.4 should be possible, if someone wants it sooner.

Cryptographic generators are not serialisable due to a difference of opinion on whether they should leak state (undecided).

[dhardy]

Regarding cryptographic generators, see this issue: dhardy#31

[UserAB1236872]

@dhardy If possible, backporting would be nice. I was running with waiting until 0.5 for a while, but some of my users are having problems with my patch pointing to this repository and that cargo bug where it hangs on updating the registry. The cargo update -p foo workaround doesn't seem to work if you're pointing to a git repo.

[dhardy]

0.5 is going to a bit longer yet, so backporting sounds sensible. I don't think there are any major issues (although the PRNG code got moved around a bit). Will you open a PR against the 0.4 branch?