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?
Possibly. I brushed it off as too security oriented at first too.
But if the random numbers are sequentially sourced for use in a large data set for statistics I suspect then there is a case for what Melissa is on about.
Yeah, I'm okay with it in the Prop2 for I/O applications. Particularly the free-running generator as it is much harder to end up with sequential numbers.
Then we have a seed-able and thus repeatable xoroshiro32 (per COG?).
There could be dozens of different XORO32 instances running in the same cog at the same time, hundreds even!
This is a notable point. XORO32, as just another cog instruction, uses any cogram for its state store. A mere 32 bits, hence the name. So you, the programmer, can mess with or reseed as you like.
Would it be better to clamp the scores to the maximum possible when calculating grid totals?
Probably should just look at the size 8 apertures ... I'll redo the grid tables this way ...
Are impossible scores still there?
Nothing higher than 128 KB. [2 6 7 2] is an average good PR grid score, similar to how XORO32 measured up.
The reason for mentioning xoroshiro16 again is that someone asked on the prng forum yesterday for a 16-bit state xoroshiro-style generator. Evan, which candidate(s) would you recommend?
[2,6,7,2] is best for simulating a 16-bit PRN. Is the d = 0 binary slot for xoroshiro16+? If so, [2,6,7] is not the best for pair distributions, as shown by the worst scores:
EDIT:
I can edit newer and older posts with numbers 14xxxxx.
Try it again. I just opened and closed an edit without changing anything.
Thanks for helping. Edit box still empty but here's how I edited the post:
1. Click Quote
2. Copy quoted text into blank edit box
3. Delete quote and /quote
4. Click Save Comment
Sounds good for now.
I do not have permissions to dig any deeper. I'll have to get Parallax to look at it. Probably something to do with the last Forum Upgrade
My method doesn't work. It adds a new post to the end of the thread. I edited the first post again and another post was added to the end. I didn't check the whole thread the first time and didn't notice what it did.
EDIT:
I can edit newer and older posts with numbers 14xxxxx.
Try it again. I just opened and closed an edit without changing anything.
Thanks for helping. Edit box still empty but here's how I edited the post:
1. Click Quote
2. Copy quoted text into blank edit box
3. Delete quote and /quote
4. Click Save Comment
Sounds good for now.
I do not have permissions to dig any deeper. I'll have to get Parallax to look at it. Probably something to do with the last Forum Upgrade
My method doesn't work. It adds a new post to the end of the thread. I edited the first post again and another post was added to the end. I didn't check the whole thread the first time and didn't notice what it did.
I'll try closing the thread and re-open it to see if it gets reset.
[2,6,7,2] is best for simulating a 16-bit PRN. Is the d = 0 binary slot for xoroshiro16+? If so, [2,6,7] is not the best for pair distributions, as shown by the worst scores:
The reason for such a small state space is Chip wanted to fit it in a single cogram register. Keeps it simple and fast instruction. No independent hardware needed.
EDIT: And it allowed Tony and myself to realistically do our experimenting directly with the target candidates.
OK, the penny dropped. The "32" refers to the number of state bits not the width of the output.
Now I wonder why do this? Isn't the cycle length now down to 4 billion?
From confused to disgusted?
You could try xoroshiro64++ [26,9,13,17].
The paper mentions the xoroshiro64 [26,9,13] engine and the +, * and ** scramblers. + is not good enough and ++ would be a much better alternative if there are no multipliers available. In an email to me Seba suggested 15 or 17 for the ++ rotation, i.e. half the output width +/- 1.
EDIT:
First 16 outputs for xoroshiro64++ [26,9,13,17] when seed = 1 {s1 = 0, s0 = 1}
PRN calculated at start of algorithm before new state generated
No, not disgusted. A teeny, tiny bit disappointed at the cycle length but otherwise happy I have something that does what the P2 does as a reference. I hope!
Comments
Man, I am having a hard time waiting for the Parallax boards...
And notice the interest. Remember way back when we all talked about, "build something cool and they will come?" We are here, and it appears they will.
Possibly. I brushed it off as too security oriented at first too.
But if the random numbers are sequentially sourced for use in a large data set for statistics I suspect then there is a case for what Melissa is on about.
Yeah, I'm okay with it in the Prop2 for I/O applications. Particularly the free-running generator as it is much harder to end up with sequential numbers.
This is a notable point. XORO32, as just another cog instruction, uses any cogram for its state store. A mere 32 bits, hence the name. So you, the programmer, can mess with or reseed as you like.
Do you mean there is not an "Edit" button? I show the thread is open and I can edit.
I'll see what I can do.
The edit box is blank. I can edit more recent posts.
http://forums.parallax.com/discussion/168188/xoroshiro-random-number-generator
EDIT:
I can edit newer and older posts with numbers 14xxxxx.
Try it again. I just opened and closed an edit without changing anything.
The reason for mentioning xoroshiro16 again is that someone asked on the prng forum yesterday for a 16-bit state xoroshiro-style generator. Evan, which candidate(s) would you recommend?
[2,6,7,2] is best for simulating a 16-bit PRN. Is the d = 0 binary slot for xoroshiro16+? If so, [2,6,7] is not the best for pair distributions, as shown by the worst scores:
Thanks for helping. Edit box still empty but here's how I edited the post:
1. Click Quote
2. Copy quoted text into blank edit box
3. Delete quote and /quote
4. Click Save Comment
I do not have permissions to dig any deeper. I'll have to get Parallax to look at it. Probably something to do with the last Forum Upgrade
That has been reported a few days ago. I'll recheck.
I "Attached" a picture yesterday, and it only showed up once.
I think it varies.
My method doesn't work. It adds a new post to the end of the thread. I edited the first post again and another post was added to the end. I didn't check the whole thread the first time and didn't notice what it did.
I'll try closing the thread and re-open it to see if it gets reset.
Can you delete a post if it adds one to the end again?
Yes
Still no good. Please delete this post
http://forums.parallax.com/discussion/comment/1448914/#Comment_1448914
Yep, d=0 is the single summing (+) scrambler. Hmm, maybe need to verify generated number sequences like Heater is ...
Continuing from the xoro announcements thread.... Thanks for the C source earlier. My C++ class now looks like this:
class Xoroshiro32PlusPlus { const uint16_t a = 13; const uint16_t b = 5; const uint16_t c = 10; const uint16_t d = 9; static inline uint16_t rol(uint16_t x, uint16_t bits) noexcept { return (x << bits) | (x >> ((sizeof(uint16_t) * 8) - bits)); } uint16_t s0; uint16_t s1; public: explicit Xoroshiro32PlusPlus(uint16_t s0 = 1, uint16_t s1 = 0) noexcept : s0(s0), s1(s1) { } inline uint16_t operator()() noexcept { uint16_t result = rol(s0 + s1, d) + s0; s1 ^= s0; s0 = rol(s0, a ) ^ s1 ^ (s1 << b); s1 = rol(s1, c); return result; } };With results: Which now matches TonyB_'s on the other thread.
Next up... a version in SpinalHDL.
Now I wonder why do this? Isn't the cycle length now down to 4 billion?
EDIT: And it allowed Tony and myself to realistically do our experimenting directly with the target candidates.
From confused to disgusted?
You could try xoroshiro64++ [26,9,13,17].
The paper mentions the xoroshiro64 [26,9,13] engine and the +, * and ** scramblers. + is not good enough and ++ would be a much better alternative if there are no multipliers available. In an email to me Seba suggested 15 or 17 for the ++ rotation, i.e. half the output width +/- 1.
EDIT:
First 16 outputs for xoroshiro64++ [26,9,13,17] when seed = 1 {s1 = 0, s0 = 1}
PRN calculated at start of algorithm before new state generated
I'll have to read that paper again...