Here's all the Practrand gridding data. I haven't made any spreadsheet.
Something suspect though: Full period repeat is 64 KB so Practrand should be maxing out at 128 KB, but there is plenty of 512 KB!
Thanks for these results, Evan.
We've had a few impossible scores before, but not in such profusion! 1 bit samples included. Would it be better to clamp the scores to the maximum possible when calculating grid totals?
The only reason I asked about how the P2 xor??? algorithm differed from any published algorithm is that sometimes it is useful to be able to run the same code with the same seeds on different machines and get the same results. Just for software testing for example.
Just now the whole situation confuses me because I just read that the P2 PRNG should be seeded by some real randomness at boot up. So even if you know the algorithm you don't know where it starts. Or is there a way to seed it how you like?
Heater,
That's the free-running Xoroshiro128**. Because it never stops iterating it would be tricky to even map it even if it always started at the same seed.
That's the free-running Xoroshiro128**. Because it never stops iterating it would be tricky to even map it even if it always started at the same seed.
I see. Sounds good.
Is it also possible to use that Xoroshiro128** hardware with ones own known seed? Or do we have to revert back to using a known PRNG algorithm in our software?
You can certainly load seed data into the free-running generator but don't count on that being an exact seeding state. Only 32 bits (1/4 the state bits) I think and while it is already running.
That's the free-running Xoroshiro128**. Because it never stops iterating it would be tricky to even map it even if it always started at the same seed.
I see. Sounds good.
Is it also possible to use that Xoroshiro128** hardware with ones own known seed? Or do we have to revert back to using a known PRNG algorithm in our software?
No and no, use XORO32. Do you not trust this instruction? It uses the published xoroshiro++ algorithm.
It is possible to seed xoroshiro128** only partially.
Or do we have to revert back to using a known PRNG algorithm in our software?
The ** scrambler has that invertible issue that drew a tongue lashing from Melissa. I'm thinking that's not a big concern with the free-running nature here, but if you are wanting to work with a controllable software version of Xoroshiro or Xoshiro without that weakness then I'd go for the ++ scrambler we're using in XORO32.
To do a Xoroshiro128++ would probably need Dave and Seba to conjuror up the four constants. Although, if Tony is really on to something with this distribution scoring, then that should indicate that the first three constants don't change from the original Xoroshiro128+.
To do a Xoroshiro128++ would probably need Dave and Seba to conjuror up the four constants. Although, if Tony is really on to something with this distribution scoring, then that should indicate that the first three constants don't change from the original Xoroshiro128+.
Strictly speaking, it should be "pair distribution" not just "distribution" as my tests only apply to pairs of successive outputs.
I doubt anyone will ever use xoroshiro128++ now the ** scrambler exists. Quote below is copied from a PM just before a bug fix let us change from xoroshiro128+ to xoroshiro128**.
No and no, use XORO32. Do you not trust this instruction? It uses the published xoroshiro++ algorithm.
It's not a question of trust.
If I have a program using XO??? whatever algorithm that I can seed and run and get reproducible results on my PC. Can I then run the same program on the P2 using the XO??? whatever instruction and get the same results?
This may be a picky, quibbly question that nobody cares about. I'd just like to know how it works.
No and no, use XORO32. Do you not trust this instruction? It uses the published xoroshiro++ algorithm.
It's not a question of trust.
If I have a program using XO??? whatever algorithm that I can seed and run and get reproducible results on my PC. Can I then run the same program on the P2 using the XO??? whatever instruction and get the same results?
This may be a picky, quibbly question that nobody cares about. I'd just like to know how it works.
If you rely on the free-running generator then the answer is no.
If you rely on the XORO32 instruction then the answer is yes.
No and no, use XORO32. Do you not trust this instruction? It uses the published xoroshiro++ algorithm.
It's not a question of trust.
If I have a program using XO??? whatever algorithm that I can seed and run and get reproducible results on my PC. Can I then run the same program on the P2 using the XO??? whatever instruction and get the same results?
This may be a picky, quibbly question that nobody cares about. I'd just like to know how it works.
The pseudo-code for the xoroshiro32++ algorithm as used in XORO32 is at the end of the first post. XORO32 does a double-iteration, with the first output in the low word and the second in the high. [a,b,c,d] is now [13,5,10,9] and there are test outputs here: http://forums.parallax.com/discussion/comment/1447884/#Comment_1447884
As far as I understand we have one free running xoroshiro128++, seeded at bootup from something variable I did not understand. But the goal here is to have a non repeatable random sequence.
Then we have a seed-able and thus repeatable xoroshiro32 (per COG?).
But maybe I am completely wrong here, has happened before,
As far as I understand we have one free running xoroshiro128++, seeded at bootup from something variable I did not understand. But the goal here is to have a non repeatable random sequence.
Then we have a seed-able and thus repeatable xoroshiro32 (per COG?).
But maybe I am completely wrong here, has happened before,
Mike
The XORO32 instruction in each cog is independent of any other cog. There could be dozens of different XORO32 instances running in the same cog at the same time, hundreds even!
60+ forum pages of research, implementation and testing just for the PRNG functions. Truly an impressive effort from you guys! I hope this makes some ripples amongst the RND() aficionados. :thumb:
I doubt anyone will ever use xoroshiro128++ now the ** scrambler exists.
The way Melissa sounded, no one should ever start using the ** scrambler. It's not hard to see the flaw - There is only one variable contributor to invert back to uncover the much weaker engine.
Comments
Thanks for these results, Evan.
We've had a few impossible scores before, but not in such profusion! 1 bit samples included. Would it be better to clamp the scores to the maximum possible when calculating grid totals?
SmallCrush results aren't very good, so no point trying Crush.
Probably should just look at the size 8 apertures ... I'll redo the grid tables this way ...
Just now the whole situation confuses me because I just read that the P2 PRNG should be seeded by some real randomness at boot up. So even if you know the algorithm you don't know where it starts. Or is there a way to seed it how you like?
That's the free-running Xoroshiro128**. Because it never stops iterating it would be tricky to even map it even if it always started at the same seed.
#include <stdint.h> #define ACCUM_SIZE 16 #define CONSTANT_A 13 #define CONSTANT_B 5 #define CONSTANT_C 10 #define CONSTANT_D 9 typedef uint16_t rngword_t; static inline rngword_t rotl( rngword_t value, int shift ) { return (value << shift) | (value >> (ACCUM_SIZE - shift)); } // Seed the state array. Seed MUST not be all zero. static rngword_t s[2] = {1, 0}; static rngword_t nextxoro( void ) { rngword_t s0 = s[0]; rngword_t s1 = s[1]; rngword_t result = s0 + s1; // output hash (scrambler) for Xoroshiro+ //New addition from authors: Rotation and second summing result = rotl( result, CONSTANT_D ) + s0; s1 ^= s0; s[0] = rotl( s0, CONSTANT_A ) ^ s1 ^ (s1 << CONSTANT_B); s[1] = rotl( s1, CONSTANT_C ); return( result ); }Is it also possible to use that Xoroshiro128** hardware with ones own known seed? Or do we have to revert back to using a known PRNG algorithm in our software?
No and no, use XORO32.
It is possible to seed xoroshiro128** only partially.
Are impossible scores still there?
The ** scrambler has that invertible issue that drew a tongue lashing from Melissa. I'm thinking that's not a big concern with the free-running nature here, but if you are wanting to work with a controllable software version of Xoroshiro or Xoshiro without that weakness then I'd go for the ++ scrambler we're using in XORO32.
Nothing higher than 128 KB. [2 6 7 2] is an average good PR grid score, similar to how XORO32 measured up.
Strictly speaking, it should be "pair distribution" not just "distribution" as my tests only apply to pairs of successive outputs.
I doubt anyone will ever use xoroshiro128++ now the ** scrambler exists. Quote below is copied from a PM just before a bug fix let us change from xoroshiro128+ to xoroshiro128**.
{s1,s0} = 128-bit state
PRN = 64-bit output
If I have a program using XO??? whatever algorithm that I can seed and run and get reproducible results on my PC. Can I then run the same program on the P2 using the XO??? whatever instruction and get the same results?
This may be a picky, quibbly question that nobody cares about. I'd just like to know how it works.
If you rely on the free-running generator then the answer is no.
If you rely on the XORO32 instruction then the answer is yes.
Heater.
Here is the thread I created for important xoroshiro announcements:
http://forums.parallax.com/discussion/168188/xoroshiro-random-number-generator
Sadly I can't seem to edit it now.
The pseudo-code for the xoroshiro32++ algorithm as used in XORO32 is at the end of the first post. XORO32 does a double-iteration, with the first output in the low word and the second in the high. [a,b,c,d] is now [13,5,10,9] and there are test outputs here:
http://forums.parallax.com/discussion/comment/1447884/#Comment_1447884
Then we have a seed-able and thus repeatable xoroshiro32 (per COG?).
But maybe I am completely wrong here, has happened before,
Mike
The XORO32 instruction in each cog is independent of any other cog. There could be dozens of different XORO32 instances running in the same cog at the same time, hundreds even!
The way Melissa sounded, no one should ever start using the ** scrambler. It's not hard to see the flaw - There is only one variable contributor to invert back to uncover the much weaker engine.
Ask Publison to unlock it for you. It will be a new automatic locking feature to prevent necro'ing.
For crypto / security related things, that one flaw being unfavorable makes some sense.
But, for the other purposes, like improving DAC effective resolution by adding noise, what we have in the P2 now is robust, yes?
Or, no?