Serialize random state/seed?

[Jan Wielemaker]

Hi Pedro,

Thanks for the response.

On 11/10/2011 04:02 PM, Pedro Gimeno wrote:
> Jan Wielemaker wrote:
>> I'm using the GMP random functions in SWI-Prolog. I'm trying to emulate
>> the API of an old but de-facto standard random library for Prolog. One
>> of the operations there is to fetch the state of the random generator
>> and later restore it. The state is an arbitrary Prolog term, so you can
>> store it, or read/write it to a file.
>
> There's no provision for exporting/importing the state in the current
> version. I've pushed for it but it didn't seem to be favourably received.
>
> See for example:
> http://gmplib.org/list-archives/gmp-discuss/2010-September/004283.html
> but I seem to remember older discussion.
>
>> which half-way (the remark about _mp_d is suspicious) suggests to fetch
>> the _mp_seed member. Alas, when handled as a mpz_t, it is considered 0
>> because _mp_size is always 0.
>>
>> I can set _mp_size to _mp_alloc in the seed to get a nice big number and
>> write a function to set this back using mpz_set on the _mp_seed member.
>
> That would be tying your application to the internals of the generator,
> which is not a very good idea. That structure is inherited from the
> first GMP random generation functions, which had to be reused to
> accommodate a more flexible random number generation infrastructure, and
> should be changed as soon as binary compatibility is decided to be
> broken, if that ever happens, together with other legacy stuff.

To be honest, that is just one of my worries. Getting the GMP objects
properly managed by Prolog's stack and garbage collection already forced
me to dig into the mpz_t type. I serialize them into the mpz_t struct
itself, _immediately_ followed by the limbs. Prolog puts a header and a
footer word around these. From there on they are read-only large
integers. Prolog may throw the memory away, move it around or may ask
some GMP operation where the thing is an input operand. In that case I
simply fix the limbs pointer and pass the mpz_t to a GMP function.

For short, If things change I have to redo some work anyway. My only
worry is that the state is inside the limbs of the _mp_seed. As long as
the data in there are just bits being manipulated, all is fine. If they
happen to be pointers to other structures, things go hopelessly wrong
:-(  The choice for using mpz_t suggests that the state can be seen as
one array.  Right?

> The state is considered opaque, to allow for other kinds of generators
> in future. My initial idea was to provide for import/export functions as
> part of each generator (see the message above), but I did not submit it
> as part of the initial patch, and now it would seem like an unwanted
> addition.

I'd use that if it was present and feel a lot better :-)

	Cheers --- Jan

> But just in case I am wrong in my assessment, I have to ask again: would
> a patch to implement functionality for importing/exporting the random
> state of each generator, be accepted?
>
> If not, or in the meanwhile, you can try to learn about the structure of
> each generator and write your own reader for the internal storage format
> of the state depending on the generator type.
>
> -- Pedro Gimeno