[Octave-bug-tracker] [bug #58800] BIST for rng sometimes fails

[Michael Leitner]

Follow-up Comment #22, bug #58800 (project octave):

"Reliable random patterns" in the sense of k-equidistribution and so on should
never be a problem -- there is quite a number of transformations done on the
entries of the state vector before the result is returned. So there should be
no problems as to how it is seeded, provided the seed is different. Yes, even
if you use a constant seed of 0 (which is what I do always if the Monte Carlo
simulations are self-averaging, using random seeds only if I really need
different, independent streams) the numbers should be as pseudo-random as they
can be.

As to a close Hamming distance of two state vectors: as I read the wikipedia
entry, x_k, x_k+1 and x_k+m (with m in the C++ reference implementation being
397) determine x_k+n. So if you put all your entropy into x_0 and initialize
all the other entries of the state vector with (say) 0, you would still carry
over some entropy (around 32/2 bits) into x_n+1 and thus x_n+2 and so on. In
the proposed initialization from a single seed value, its entropy is
propagated into all entries of the initial state vector. Putting your entropy
at the end of the state vector  would indeed be a bad thing to do. Something
that should be okay is to first initialize the state vector with a constant
seed (but  of course doing the initialization bit shuffling and so on, that
is, not having 625 times the same entries!), then XOR the clock time into the
first entry of the state vector, the PID into the second, and all other
sources of entropy you can think of in default of /dev/urandom in the
following ones, and then draw a corresponding number of pseudo-random numbers
from the generator and discard the results. This should mix all your entropy
into the state vector, so that we should then really have a very large number
of possible streams (and the initial bug that for equal clock time the results
are equal would affect only the first pseudo-random number, which is discarded
anyway).

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58800>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/