I want to be able to save and load the state of an RNG so I can reproduce the same random values from a given point (application save/snapshot).
I see there is an operator << and >> overload, which seems to save to a string as a sequence of numbers.
- Is that the best/only way to save? I wouldn't mind just having the fixed-size binary state value not this space separated string thing that I then need to prefix or put delimiters around for my file format.
- Is this at all portable? e.g. can I transfer this between different compiler versions, or even between MSVC and GCC to produce the same data set given identically configured distributions (to a small margin of error in the case of floating point, and exact for integer maths)?
Yes, operator<<
and operator>>
are the only way to import or export a random number generator's state. You can easily convert the textual representation to and from binary, if you'd like.
De-serializing and serializing mt19937
state should be portable between implementations. The result of reading and writing the engine's state via the streaming operators is well defined by the standard, as long as you ensure the streams are imbued with the same locale.
See § 26.5.1.5 for the requirements of operator<<
and operator>>
, followed by § 26.5.3.2 for the textual representation of mersenne_twister_engine
, which mt19937
is a well defined typedef of.
On top of the previous answer:
exporting textual representation via op<< will only save proper RNG state if it is read back via op>> using the same locale. Changing locale will cause problem
the choice of default_random_engine
is implementation defined. It is a typedef, but it is allowed to be set to different real engines on different platforms ( § 26.5.5 ). Thus, using op<< and op>> to save/restore states pretty much prohibits using default engine
while generators are specified pretty rigorously, I do not believe distributions are required to be identical between platforms. Saving state might not help you much with reproducibility here
I would recommend to have this document handy, just in case http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf