I've just done a compare against your most recent selection of ++ candidates - https://forums.parallax.com/discussion/comment/1468718/#Comment_1468718 - and note that, although the rankings differ, the pfreq/zfreq/nzfreq ChiSquare totals all match. Tony, I assume you've been ranking pfreq with higher priority.
Evan, I've changed the Chi-Square titles in that post to pchi/zchi/nzchi. I give equal weight to prank, zrank and nzrank. I sum the ranks (i.e. prank+zrank+nzrank) to get an overall ranking and the lowest one is given a rank of 1. I do not sum pchi+zchi+nzchi. If prank+zrank+nzrank is the same integer for two different [a,b,c,d] then I use prank as the tie-breaker.
Evan, I've checked my QuickBASIC code in xoro32r.bas (attached) and there is equal weighting, but it can be different if variables pw/zw/nzw are not all 1. Search for "paths" in xoro32r.bas to see where the files go. xoro32.abc lists the 84 full-length candidates as aabbcc. This file and the 84*3=252 binary files (aabbcc.pb, aabbcc.zb and aabbcc.nzb) are needed before xoro32r.bas can run.
Have you created the binary files for scramblers other than ++ yet?
Okay, I had started to write my own sorting and ranking routines while these reruns were underway, but then realised I wanted to put all ChiSquare totals from every algorithm variant in the one database so that they can be sorted as one big group. So, for the moment, I've just opted to merge into one large CSV file and use a spreadsheet to do the sorting. It's easy to make new spreadsheet columns with linear fills for making the ranking columns.
PS: I've adopted using sum of the rankings to make the final sort, thanks.
Done at last, all eight scrambler variations. I had some breaks in the process.
Here's the resulting concatenated CSV file, distscore-s16.csv, and sortable spreadsheet and also a post-sorted exported CSV for easy reading of the example sort: sumRank = 3 x pRank + zRank + nzRank.
Done at last, all eight scrambler variations. I had some breaks in the process.
Here's the resulting concatenated CSV file, distscore-s16.csv, and sortable spreadsheet and also a post-sorted exported CSV for easy reading of the example sort: sumRank = 3 x pRank + zRank + nzRank.
Many thanks, Evan. I think a weighting of 3 is somewhat excessive for prank and csv files with 1 and 2 would be useful to have. xoroshiro32[10,3,11,10]--+ would still be top for all three and the question is how does it perform in PractRand tests?
xoroshiro32[13,5,10,9]--- is slightly better than the ++ in P2 rev B, but the former would need a bit more logic than the latter probably as all as the signs are negative.
Done at last, all eight scrambler variations. I had some breaks in the process.
Here's the resulting concatenated CSV file, distscore-s16.csv, and sortable spreadsheet and also a post-sorted exported CSV for easy reading of the example sort: sumRank = 3 x pRank + zRank + nzRank.
Many thanks, Evan. I think a weighting of 3 is somewhat excessive for prank and csv files with 1 and 2 would be useful to have. xoroshiro32[10,3,11,10]--+ would still be top for all three and the question is how does it perform in PractRand tests?
xoroshiro32[13,5,10,9]--- is slightly better than the ++ in P2 rev B, but the former would need a bit more logic than the latter probably as all as the signs are negative.
Some more thoughts on distscore-s16.csv.txt:
1. As mentioned before, I prefer pchi/zchi/nzchi to pfchi/zfchi/nzfchi.
2. An overall rank orank (1,2,3,etc.) would be a helpful addition or change sumrank to orank.
3. The top 20 contain only seven different [a,b,c,d].
4. The similiarity in positive/negative pairs is obvious, especially [14,2,9,5]++-/--+ which are almost identical.
5. In the absence of a different algorithm with 32-bit state, a P3 could use one of the top three.
Yeah, both --+ and --- would be more logic. Maybe that's why they are slightly better scoring.
I would be curious if any of the those variants would respond even better to rotl(+/-s1 +/-s0, D ) +/- s0 * 5
It would seem that the best case would be a better pchi/zchi/nzchi scoring one that does not use --+ or ---, and yet also excels at PractRand scoring by >= 70% (which we have seen over the current ++).
Yeah, both --+ and --- would be more logic. Maybe that's why they are slightly better scoring.
I would be curious if any of the those variants would respond even better to rotl(+/-s1 +/-s0, D ) +/- s0 * 5
It would seem that the best case would be a better pchi/zchi/nzchi scoring one that does not use --+ or ---, and yet also excels at PractRand scoring by >= 70% (which we have seen over the current ++).
neg(x) = not(x)+1, therefore -s1-s0 = !s1+!s0+2, hence extra logic for carry input (into bit 1) not needed with ++.
I agree that s0 * 5 would be worth testing with full set of +/- scramblers, but I don't do the tests.
Also xoroshiro32[10,3,11,10]--+ might not have a very good PractRand score, despite very good distributions.
Hmm, the gridding scripts are oriented towards running a selection of candidates of a single algorithm at a time. Without rewriting things, I'll have to make a config file for each scrambler variation and run them independently ...
neg(x) = not(x)+1, therefore -s1-s0 = !s1+!s0+2, hence extra logic for carry input (into bit 1) not needed with ++.
I believe that may also be expressed as: 1 + !(s1+s0), if that helps.
Removing the constant sum would likely need to be characterized independently, though probably would have minimal impact.
Assuming the + 1 could be dropped, then just NOT gating the (+s1+s0) result before or after the ROTL.
Edit: Cannot drop constant sum in --+ or --- without bumping into the final output NOT/sum issue again discussed way back (required use of E constant):
Using s1=s0=0 in Tony's example, !0+!0<>0, so missing value in output would no longer be zero.
Ha! I've now got a script that can sort each distribution results. I've realised this is still useful independently of the single large spreadsheet sorting.
It runs quite smoothly. The slowest part is the built-in sort command. Took me a while to learn how to use it. In particular making [tab] as the sole field separator. The IFS variable wasn't playing ball for a while.
d=${#chirecords[*]} # Total number records. Note: @ and * perform the same job in most cases
printf "Sorting pRanking ... "
chirecords=($( sort -nt$'\t' -k3,3 -k4,4 <<<"${chirecords[*]}" )) # The entire array in one go!
a=0; echo $d
while [ $a -lt $d ]; do
chirecords[$a]+=$'\t'$(($a + 1))
a=$(($a + 1))
done
printf "Sorting zRanking ... "
chirecords=($( sort -nt$'\t' -k4,4 -k3,3 <<<"${chirecords[*]}" )) # The entire array in one go!
a=0; echo $d
while [ $a -lt $d ]; do
chirecords[$a]+=$'\t'$(($a + 1))
a=$(($a + 1))
done
printf "Sorting nzRanking ... "
chirecords=($( sort -nt$'\t' -k5,5 -k3,3 <<<"${chirecords[*]}" )) # The entire array in one go!
a=0; echo $d
while [ $a -lt $d ]; do
chirecords[$a]+=$'\t'$(($a + 1))
a=$(($a + 1))
done
printf "Sorting sumRanking ... "
a=0
while [ $a -lt $d ]; do
IFS=$'\t\n' read line line line line line prank zrank nzrank line <<<${chirecords[$a]}
chirecords[$a]+=$'\t'$(($prank * 2 + $zrank + $nzrank))
a=$(($a + 1))
done
chirecords=($( sort -nt$'\t' -k9,9 -k3,3 <<<"${chirecords[*]}" )) # The entire array in one go!
echo $d
Doh! I made a tiny typo in the .cfg file so now have to redo two of the runs.
I didin't notice until comparing the sorted chi rankings and it kind of stood out when three files were byte for byte identical. The first of the three is correct, so not rerunning that one.
Thanks for the last lot of results, Evan. I'll wait to see what the error you found means. It seems there is little difference in PractRand scores for different +/- scrambler options with the same candidate.
I've been doing a lot of tiring demolition work lately but I had a day off today hence my return from lurkdom. I think it could be worthwhile calculating the distributions for the following:
Comments
Evan, I've checked my QuickBASIC code in xoro32r.bas (attached) and there is equal weighting, but it can be different if variables pw/zw/nzw are not all 1. Search for "paths" in xoro32r.bas to see where the files go. xoro32.abc lists the 84 full-length candidates as aabbcc. This file and the 84*3=252 binary files (aabbcc.pb, aabbcc.zb and aabbcc.nzb) are needed before xoro32r.bas can run.
Have you created the binary files for scramblers other than ++ yet?
I had but they're deleted again. I'm doing them over with ChiSquare totals included now.
I'll get back to you later.
PS: I've adopted using sum of the rankings to make the final sort, thanks.
Here's the resulting concatenated CSV file, distscore-s16.csv, and sortable spreadsheet and also a post-sorted exported CSV for easy reading of the example sort: sumRank = 3 x pRank + zRank + nzRank.
Many thanks, Evan. I think a weighting of 3 is somewhat excessive for prank and csv files with 1 and 2 would be useful to have. xoroshiro32[10,3,11,10]--+ would still be top for all three and the question is how does it perform in PractRand tests?
xoroshiro32[13,5,10,9]--- is slightly better than the ++ in P2 rev B, but the former would need a bit more logic than the latter probably as all as the signs are negative.
Some more thoughts on distscore-s16.csv.txt:
1. As mentioned before, I prefer pchi/zchi/nzchi to pfchi/zfchi/nzfchi.
2. An overall rank orank (1,2,3,etc.) would be a helpful addition or change sumrank to orank.
3. The top 20 contain only seven different [a,b,c,d].
4. The similiarity in positive/negative pairs is obvious, especially [14,2,9,5]++-/--+ which are almost identical.
5. In the absence of a different algorithm with 32-bit state, a P3 could use one of the top three.
It would seem that the best case would be a better pchi/zchi/nzchi scoring one that does not use --+ or ---, and yet also excels at PractRand scoring by >= 70% (which we have seen over the current ++).
Evan, thanks for these other weightings. zrank and nzrank should always be the same, I think.
neg(x) = not(x)+1, therefore -s1-s0 = !s1+!s0+2, hence extra logic for carry input (into bit 1) not needed with ++.
I agree that s0 * 5 would be worth testing with full set of +/- scramblers, but I don't do the tests.
Also xoroshiro32[10,3,11,10]--+ might not have a very good PractRand score, despite very good distributions.
Are PractRand scores for [13,5,10,9]--- and [13,5,8,10]--+ better or worse than ++ versions?
Removing the constant sum would likely need to be characterized independently, though probably would have minimal impact.
Edit: Cannot drop constant sum in --+ or --- without bumping into the final output NOT/sum issue again discussed way back (required use of E constant):
Using s1=s0=0 in Tony's example, !0+!0<>0, so missing value in output would no longer be zero.
It runs quite smoothly. The slowest part is the built-in sort command. Took me a while to learn how to use it. In particular making [tab] as the sole field separator. The IFS variable wasn't playing ball for a while.
I didin't notice until comparing the sorted chi rankings and it kind of stood out when three files were byte for byte identical. The first of the three is correct, so not rerunning that one.
I've been doing a lot of tiring demolition work lately but I had a day off today hence my return from lurkdom. I think it could be worthwhile calculating the distributions for the following:
This is twice the work compared to previously, but it does include s0*3 as well as s0*5.