New mpn random generators (Was: Re: mpz_limbs interface)

Torbjorn Granlund tg at gmplib.org
Tue Jan 21 15:52:54 UTC 2014


nisse at lysator.liu.se (Niels Möller) writes:

  Torbjorn Granlund <tg at gmplib.org> writes:
  
  > nisse at lysator.liu.se (Niels Möller) writes:
  >
  >   I see. In this particular case, I think the right gmp interface change
  >   is to add mpn_urandomb and mpn_rrandomb (similar to current mpn_random
  >   and mpn_random2, but with a randstate argument). If I understand this
  >   correctly, the main obstacle is that random number internals use mpz
  >   functions, which is an undesirable dependency for mpn functions.
  >   
  > We should indeed do this.
  
  After 5.2?
  
Probably, but you're welcome to fix it today also.  :-)

Or would you suggest that we postpone the release?

I am not sure exactly how a revamped mpn random interface would look
like.  Perhaps mpn_urandomb and mpn_rrandomb, with bit counts (giving
machine indep results).

Current mpn random function take limb counts.  I assume it will be good
enough to have just bit counts in the new generators, even at the limb
oriented mpn level.  A count like n*GMP_NUMB_BITS is not that bad.

A subtle difference between the current functions and such new functions
would be that the new functions would not make the result "normalised".
At least not mpn_urandomb.  (For mpn_rrandomb we might define the most
significant set bit to be defined by the bit count argument.)

We could consider mpn_urandomm, but I am not sure that's a good idea.

  > For testing the result, I'd write a wrapper C program that run old and
  > new code in separate processes, and compare that the results are
  > identical for the same (now and then regenerated) seeds.
  
  If the generation is intended to be machine-independent, it would also
  make sense to also add tests generating some random numbers from a few
  fixed seeds, and compare to expected (constant) numbers.

Sure, but I think that has been established for the current
implementation already.  Thus my suggested test woudl indirectly
establish that for an mpn rewrite.  (I am talking about mpz_*random*
here, not new mpn_*random* functions.)


Torbjörn
Please encrypt, key id 0xC8601622


More information about the gmp-devel mailing list