@TonyB There is no third sum (spoken like Picard's line from Star Trek).
The narrow B=1 with inversion, along with other constants (5 and 14), seems to make up once ++ logic is applied.
Larger values of B leave more bits of s1 untouched, which might explain much of the improvement I see.
I also found it superior using the simple output scrambler (x + y) * 5 for both this and the original, which is useful in masking binary matrix rank and related failures.
I'm too close to this, so must take my hands off to let others see if it is useful.
@evanh Oh, I see the confusion. From C++ docs:
~ NOT Unary complement (bit inversion)
~s1 ^ (s1 >> Constant_B )
Could also be written (and executes faster) as:
0xffff ^ s1 ^ (s1 >> Constant_B )
When B=1, all but one bit changes in the result if s1 were incremented by 1.
Whereas Gray Code would be simply:
s1 ^ (s1 >> 1)
Which would only cause only 1 bit to change if s1 were incremented by 1.
How using an inverted Gray Code in this context improves randomness, I am not entirely certain. However, the escape from zero benefit is somewhat obvious, thus perhaps related.
I also found it superior using the simple output scrambler (x + y) * 5 for both this and the original, which is useful in masking binary matrix rank and related failures.
I'm too close to this, so must take my hands off to let others see if it is useful.
I'm confident Melisa would dis the * 5 on the scrambler. It keeps Practrand happy but fails in a different way than quality - because it's a non-iterated constant it's too invertible. I think that's the basic idea.
Kind of pointless having the higher res when all you end up doing is increasing the font size. Sigh.
I could barely tolerate 4K at standard scale on my old Seiki 39" with my poor vision .
I switched to a 49" Sony, which works very well, but my wife keeps taking my mouse away from it (to keep me from ruining my eyes... too late).
So here I sit, RDPing into my main workstations to post here from a 12yo PC with a 27" HD monitor. The tilde character is quite large.
I'm not sure if that would work or not. I was only using the * scrambler to help characterize randomness before applying a plusplus scrambler.
Even Seba seemingly cannot predict what will happen once the plusplus scrambler is applied (especially at larger state sizes) with a given set of constants, other than two possible outcomes: Improved randomness or damaged randomness?
I wish the solution to that question would be mathematically provable, as I think the ++ scrambler can be fantastic.
I will note here that in general: D = Width/2+1 (e.g. 9 for 16-bit output), but obviously there are choices for ABC that would prevent that generalized solution from working best, as you have found.
Here are some tables from my group post:
Escape-from-zero behavior with only 1 state bit set (in average bits set per for 10 consecutive 16-bit outputs):
The output scrambler has not changed, only the engine.
Besides constants, the only change from xoro32++ is that ‘s1 ^ (s1 << B )’ becomes ‘~s1 ^ (s1 >> B )’.
The ‘g’ in ppg refers to that change when B=1, but the name may be altered if other B are found more suitable.
I hate naming conventions, as they never seem to expand the way one intends.
I mean where does (x + y) * 5 fit in? Initially, it seemed like you were talking about an alternative scrambler. My response about Melisa was pertaining to it replacing the ++ scrambler.
Sorry about the confusion, as (x + y) * 5 was only used as part of the vetting process when making changes to the engine. It is not in the source code I posted. Using it seemed to save time, since I didn’t have to consider a D constant until I explored all valid A and C (with B=1, since I was testing inverted Gray codes on a hunch).
The ++ scrambler is like a turbo-charger... you only use it once you are sure the engine is sound.
Comments
The narrow B=1 with inversion, along with other constants (5 and 14), seems to make up once ++ logic is applied.
Larger values of B leave more bits of s1 untouched, which might explain much of the improvement I see.
I also found it superior using the simple output scrambler (x + y) * 5 for both this and the original, which is useful in masking binary matrix rank and related failures.
I'm too close to this, so must take my hands off to let others see if it is useful.
~ NOT Unary complement (bit inversion)
Could also be written (and executes faster) as: When B=1, all but one bit changes in the result if s1 were incremented by 1.
Whereas Gray Code would be simply: Which would only cause only 1 bit to change if s1 were incremented by 1.
How using an inverted Gray Code in this context improves randomness, I am not entirely certain. However, the escape from zero benefit is somewhat obvious, thus perhaps related.
I'm confident Melisa would dis the * 5 on the scrambler. It keeps Practrand happy but fails in a different way than quality - because it's a non-iterated constant it's too invertible. I think that's the basic idea.
I switched to a 49" Sony, which works very well, but my wife keeps taking my mouse away from it (to keep me from ruining my eyes... too late).
So here I sit, RDPing into my main workstations to post here from a 12yo PC with a 27" HD monitor. The tilde character is quite large.
I'm not sure if that would work or not. I was only using the * scrambler to help characterize randomness before applying a plusplus scrambler.
Even Seba seemingly cannot predict what will happen once the plusplus scrambler is applied (especially at larger state sizes) with a given set of constants, other than two possible outcomes: Improved randomness or damaged randomness?
I wish the solution to that question would be mathematically provable, as I think the ++ scrambler can be fantastic.
I will note here that in general: D = Width/2+1 (e.g. 9 for 16-bit output), but obviously there are choices for ABC that would prevent that generalized solution from working best, as you have found.
Escape-from-zero behavior with only 1 state bit set (in average bits set per for 10 consecutive 16-bit outputs): Here are the standard (+) and inverted Gray modified (+g) escape-from-zero values for comparison: Post back if you do any further testing on this or have any questions.
Be aware that existing ++ scrambler is already a longer logic path than the engine is. Adding to it is pushing things to fit in a single clock cycle.
Besides constants, the only change from xoro32++ is that ‘s1 ^ (s1 << B )’ becomes ‘~s1 ^ (s1 >> B )’.
The ‘g’ in ppg refers to that change when B=1, but the name may be altered if other B are found more suitable.
I hate naming conventions, as they never seem to expand the way one intends.
The ++ scrambler is like a turbo-charger... you only use it once you are sure the engine is sound.
None of them is very good, sadly.
Worth trying some other candidates of the algorithm? I'm polishing up the full-period search right now ...
Could be, only way to find out ...