Good post-processing methods of PRNG outputs

Discussion in 'Scientific Statistics Math' started by Mok-Kong Shen, Oct 6, 2011.

  1. Mok-Kong Shen

    Maaartin G Guest

    I don't get this.

    With 32 bits generated each time, you can e.g. take a single byte,
    which makes for 4 possibilities. This way 3/4 of the data get wasted.

    You can also take all of them giving you a single possibility. I like
    this most.

    You seem to be concatenating all the words into a single bitstream and
    always taking 8 bits and throwing 24 bit away. Are you doing this?
    But this shouldn't matter, should it?
    With rho=0.01 a perfect PRNG should fail 10 times on the average, so
    yours comes close and mine is terrible.
    These are the recommended values, however it doesn't seem to be

    I tested the following stupid PRNG

    public int nextInt() {
    long multiplier = 0x5DEECE66DL;
    long addend = 0xBL;
    state = multiplier * state + addend;
    return (int) (state>>11) & 255;

    using you numbers and it failed 6 times out of 1000 tries. Using K =
    2560000 it failed 1000 times.

    Note that I'm using Java where long is always 64 bits and int is
    always 32 bits. Note that using long makes no sense in the above, int
    would suffice.
    Thanks, mine are the same, so I think I've got it right.
    What about combining different PRNGs like in KISS?
    Maaartin G, Oct 16, 2011
    1. Advertisements

  2. Am 16.10.2011 15:38, schrieb Maaartin G:
    Let's number the bits from the right, starting 0. My first window
    contains bits 7-0, 2nd window 8-1, etc. So from each word I obtain 32
    bytes for use in 32 different tests.
    The Maurer's test for one window applies only to that window. Adding,
    say, the failure counts of two windows and dividing that by 2 gives
    some information but doesn't tell the worst case (which I think is
    critical), which is indicated by the maximum of the two counts.
    The output from the pool is naturally more or less imperfect, so one
    section of it conceivably could differ somewhat in quality from the
    other and that difference could hence influence the postprocessed
    stuff. In order to obtain an entirely fair comparison of two variants,
    I use the same data.
    Though I had carefully implemented your scheme, I couldn't exclude
    eventual errors absolutely. So you might want to check my computation
    of your variant and even of my variant.
    ok. I'll take your hint and repeat the computations with the larger
    K value and inform you of that when it is done.
    I am an ignorant of Java. Dumb question: Does it have "unsigned int"
    of 32 bits?
    If a second type of PRNG is used, I suppose the proper way is
    to xor the final (post-processed, if any) bits of each type.
    Putting different types in the same pool wouldn't be a good idea,
    I guess. But any such combination also costs something. (There is
    no free lunch, unfortunately.)

    M. K. Shen
    Mok-Kong Shen, Oct 16, 2011
    1. Advertisements

  3. Am 16.10.2011 17:39, schrieb Mok-Kong Shen:
    Sorry, I wrongly understood your question. I must confess that I
    haven't yet read KISS, excepting having quite a time ago quickly
    glanced over it. What's your opinion about that issue? (At the
    moment I am concentrating my time on trying out further potential
    variants of my own scheme.)

    M. K. Shen
    Mok-Kong Shen, Oct 16, 2011
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.