3 ms·

I think Vigna's claim is that if you ignore the PractRand tests that fail, it passes. (Really!) O'Neill has instructions on how to test with PractRand and wit

I think Vigna's claim is that if you ignore the PractRand tests that fail, it passes. (Really!) O'Neill has instructions on how to test with PractRand and with TestU01 on her blog (http://www.pcg-random.org/blog/ http://www.pcg-random.org/blog/). I had a go with TestU01 on Vigna's generators, and when you test the low 32 bits reversed (for 64-bit PRNGs, you have to test the high 32, the low 32, both forwards and reversed), I found that all Vigna's generators fail. Given the PractRand results it makes sense, I guess, but I had read that Vigna's generators were supposed to pass TestU01. Does anyone else wants to have a go at testing so I can know if I screwed up somehow?

rockdoe 9y ago
I think Vigna's claim is that if you ignore the PractRand tests that fail, it passes. (Really!) The code does explain exactly what the issue is, i.e. that the last bit isn't random: This generator passes the PractRand test suite up to (and included) 16TB, with the exception of binary rank tests, which fail due to the lowest bit being an LFSR; all other bits pass all tests. We suggest to use a sign test to extract a random Boolean value. But I'm tempted to agree this isn't a desirable property for a generic RNG. How many users of JavaScript know about this property? (it's the default RNG for most browser engines) Or does it not matter because they return 53-bit floats?
- FabHK 9y ago
  In the comment section to the V8 JavaScript blog post [1], Vigna writes: - Technically, it would be better if you used the upper 52 bits, rather than the lower 52 bits, to generate a double. The lowest bit of a xorshift128+ generator is an LSFR, and while people has been happy using LSFR for decades, it is slightly inferior in quality to all other bits. This is really OCD, as computational errors makes the lowest bit almost irrelevant, but now you know. I don't know whether that's been implemented, but the maintainer replied: Thanks for the suggestions! I will definitely revisit the current implementation with your tips in mind. [1] https://v8project.blogspot.nl/2015/12/theres-mathrandom-and-then-theres.html?showComment=1452592903162#c1549004517443909784 https://v8project.blogspot.nl/2015/12/theres-mathrandom-and-...

rockdoe 9y ago

I think Vigna's claim is that if you ignore the PractRand tests that fail, it passes. (Really!) The code does explain exactly what the issue is, i.e. that the last bit isn't random: This generator passes the PractRand test suite up to (and included) 16TB, with the exception of binary rank tests, which fail due to the lowest bit being an LFSR; all other bits pass all tests. We suggest to use a sign test to extract a random Boolean value. But I'm tempted to agree this isn't a desirable property for a generic RNG. How many users of JavaScript know about this property? (it's the default RNG for most browser engines) Or does it not matter because they return 53-bit floats?

FabHK 9y ago
In the comment section to the V8 JavaScript blog post [1], Vigna writes: - Technically, it would be better if you used the upper 52 bits, rather than the lower 52 bits, to generate a double. The lowest bit of a xorshift128+ generator is an LSFR, and while people has been happy using LSFR for decades, it is slightly inferior in quality to all other bits. This is really OCD, as computational errors makes the lowest bit almost irrelevant, but now you know. I don't know whether that's been implemented, but the maintainer replied: Thanks for the suggestions! I will definitely revisit the current implementation with your tips in mind. [1] https://v8project.blogspot.nl/2015/12/theres-mathrandom-and-then-theres.html?showComment=1452592903162#c1549004517443909784 https://v8project.blogspot.nl/2015/12/theres-mathrandom-and-...