Thread starter
#1
tl;dr: centres are significantly easier with 60randommove scrambles, so stop using that.
In 2013, @cuBerBruce generated the distance distribution for solving a single face's centres in multiple metrics. I have confirmed the results for OBTM (since my code supports only OBTM).
I generated a million random states and measured the following statistics: mean move count for optimal first centre with fixed colour (6 million samples), for optimal first centre with dual CN (3 million samples), and for optimal first centre with full CN (1 million samples). The first one agrees with the theoretical distribution, of course, but we reproduce it as a sanity check.
These stats have also been measured with one million randommove scrambles of lengths from 50 to 100 (inclusive), in increments of 5.
(Note that as only 1000000 scrambles were used for each category, the results should be treated as having only three decimal places of accuracy.)
TNoodle and most timing apps generate scramble sequences with 60 moves by default, but this is clearly inadequate—the mean move count for full CN is significantly lower than with randomstate scrambles.
Even with 100 random moves, it is significantly more likely to get a scramble with a first centre solvable within 4 moves compared to a randomstate scramble (0.3294% vs 0.2709%), although this is still a lot less bad than just 60 random moves (1.5542%). This discrepancy in the distribution persists until around 170 random moves, at which point the difference is drowned out by sampling error.
Using 80 moves for randommove scrambles seems like a reasonable compromise between the scrambling not taking forever and having a smaller deviation from randomstate scrambles, in lieu of the existence of an actual 5×5×5 randomstate scrambler. (A randomstate scrambler would generate scramble sequences of around 85 moves anyway—using a randommove scramble longer than that would be pointless.)
In 2013, @cuBerBruce generated the distance distribution for solving a single face's centres in multiple metrics. I have confirmed the results for OBTM (since my code supports only OBTM).
Code:
total states: 112911876 (112911876 legal)
distance 0: 1 nodes
distance 1: 12 nodes
distance 2: 190 nodes
distance 3: 3210 nodes
distance 4: 47444 nodes
distance 5: 635642 nodes
distance 6: 6870327 nodes
distance 7: 41671278 nodes
distance 8: 59387592 nodes
distance 9: 4296076 nodes
distance 10: 104 nodes
average distance: 7.528574
These stats have also been measured with one million randommove scrambles of lengths from 50 to 100 (inclusive), in increments of 5.
(Note that as only 1000000 scrambles were used for each category, the results should be treated as having only three decimal places of accuracy.)
scramble type  fixed  dual CN  full CN  

random state  7.529103  7.177083  6.662767  50 moves  7.213838  6.820150  6.210132  55 moves  7.293460  6.908271  6.326780  60 moves  7.351421  6.972744  6.410915  65 moves  7.392481  7.019370  6.472139  70 moves  7.424484  7.055387  6.516806  75 moves  7.447765  7.082416  6.551436  80 moves  7.465664  7.103329  6.576018  85 moves  7.478492  7.117689  6.593856  90 moves  7.489543  7.130386  6.608734  95 moves  7.497782  7.140359  6.620608  100 moves  7.503685  7.147343  6.629239 
TNoodle and most timing apps generate scramble sequences with 60 moves by default, but this is clearly inadequate—the mean move count for full CN is significantly lower than with randomstate scrambles.
Even with 100 random moves, it is significantly more likely to get a scramble with a first centre solvable within 4 moves compared to a randomstate scramble (0.3294% vs 0.2709%), although this is still a lot less bad than just 60 random moves (1.5542%). This discrepancy in the distribution persists until around 170 random moves, at which point the difference is drowned out by sampling error.
Using 80 moves for randommove scrambles seems like a reasonable compromise between the scrambling not taking forever and having a smaller deviation from randomstate scrambles, in lieu of the existence of an actual 5×5×5 randomstate scrambler. (A randomstate scrambler would generate scramble sequences of around 85 moves anyway—using a randommove scramble longer than that would be pointless.)
Attachments

28.2 KB Views: 2
Last edited: