State of PRNG code in GMP

[Pedro Gimeno]

Torbjörn Granlund wrote on 2020-06-02 11:22:

> Surely the field _lc could be be renamed to something less confusing
> without dire compatibility consequences.  :-)

Since it was still used like that for the backwards-compatible generator, and access was done through the macros anyway, this was regarded as unnecessary beyond the comment.

>    The plan was to get rid of the struct issues in the next ABI breakage,
>    but I guess no one took note of that with respect to the generators,
>    or at least no one did anything about it (we've broken the ABI since
>    GMP 4.0.1, right?)
> 
> What breakage happened for 4.0.1?

Sorry, my wording was a bit confusing. I mean, we've broken the ABI at some point between 4.0.1 and now, right? 4.0.1 is the first version where I worked on the patch. I remember Kevin mentioning a list of changes to make in case of an ABI incompatible release, but I never saw that list until 2012.

This thread talks about this kind of cleanup and mentions a list.

https://gmplib.org/list-archives/gmp-devel/2012-June/002373.html

The list is here:

https://gmplib.org/devel/incompatibility

Cleaning up the random state struct is in the list, but it needs a more extensive cleanup than mentioned there, because the function pointers are allocated separately, which is a waste.

>    I'm not too sure why I removed gmp_randinit_lc, but something about it
>    being broken rings a bell, so it's possible that Kevin told me to do
>    that.
> 
> It's strange, but I cannot recall the reasons either.

I don't think it was ever documented, so it was probably in the works and planned, but considered obsolete later, and since it wasn't documented, it was removed.

>    I don't know for sure why gmp_randinit was not adapted to the new
>    generators. Probably Kevin told me to do that but I don't remember the
>    rationale.
> 
> Perhaps it was to avoid more code than necessary to be pulled into a
> user binary?

Very likely, yes.

> Unfortunately, Mersenne Twister uses mpz, and I am not saying that that
> was a bad choice when you implemented it.

It's not used if you don't call gmp_randseed[_ui](). gmp_randinit_mt includes a table with the initial state in order to avoid calling it. The gmp_randseed interface itself needs mpz.

>  But in order to provide
> reentrant mpn PRNG functions, we either rewrite the relevant parts of MT
> to use mpn, or exclude it from a new mpn PRNG interface.

As Marco said, this is solved by using XXTEA for seeding.