41021Re: Statistical analysis of (mostly megaminx) scramblers

Expand Messages
• May 1, 2008
As requested: I have only included the cases that I deem interesting,
but I have many more

This scrambler permits only 2/5 turns when making "Puzzle breaking"
twists, and only 1/5 turns when making puzzle rotations. The
rotations are randomly included throughout the scramble instead of at
fixed intervals.
Turns | Std Dev | Expected Std Dev | Confidence
10 | 93628.55| 279 | 0.3%
50 | 14191.19| 279 | 2.0%
100 | 2310.15| 279 | 12.1%
150 | 463.14| 279 | 60.3%
175 | 318.79| 279 | 87.6%
180 | 303.87| 279 | 91.9%
190 | 296.05| 279 | 94.3%
200 | 283.16| 279 | 98.6%
210 | 278.01| 279 | 99.6%
500 | Pending| These are not included as it
1000 | Pending| seems to even out around

It would appear that with this scheme, 190 moves is about the minimum
for random.

This prompted me to test again, this time allowing both 1/5 and 2/5
puzzle rotations:
Turns | Std Dev | Expected Std Dev | Confidence
10 | 98269.43| 279 | 0.3%
50 | 15582.28| 279 | 1.8%
100 | 2760.56| 279 | 10.1%
150 | 550.70| 279 | 50.7%
190 | 302.10| 279 | 92.4%
200 | 282.31| 279 | 98.9%

So here, it seems like 190 is not quite enough, but 200 is.

I don't have time tonight, but I will run my scrambler with both 1/5
and 2/5 twist, but only 1/5 puzzle rotations tomorrow.

The conclusions I feel I can draw: restricting the puzzle to only ++
and -- twists is a less accurate approximation of random than allowin
g both 1/5 and 2/5 twists. However, restricting to 1/5 puzzle
rotations appears, at least in the 2/5 only twists case, to provide a
small gain in terms of randomness.

And yes, when I re run trials, I seem to get a swing of as much as
15-25 in either direction for the ~95% range cases.

Over the weekend I plan to run some cases using more trials and more
twists as suggested. I'll let you know if I need any help getting the
older megaminx scramble tracker programmed, and I appreciate the offer!

Best,
Daniel

--- In speedsolvingrubikscube@yahoogroups.com, d_funny007
>
> Okay, I've now fully read though your post, and I don't see anything
> wrong statistically with the number crunchings, except like I said
> before the idea of sticker-distribution is not ideal, but it's very
> practical, quick, and easy. One obvious problem is that if say a
> corner piece is in place and oriented, it somehow triple counts in
> this scheme, and it's unclear what a more 'correct/useful' *weight*
> should be for it. This is a simple method of tracking, because it
> pays no attention to distinguising pieces as corners or as edges,
> which may or maynot be problematic as well.
>
> One thing I'd really like to see done, is to make a simple tweak of
> your program to do only 2/5 turns and not 1/5 turns and post the
> results here side-by-side with the other one. This is becasue I am
> very curious about Stefan's assertion that 2/5 are so much more
> superior that doing 1/5 is a waste. Initally, I thought this to be
> counter-intuitive, but everything I've found so far agrees with the
> claim. Perfoming your anlaysis on it, would be enough to put that
> debate to a rest for me, so I would appreciate it.
>
> The other thing I am not 100% sure of, is something you pointed out.
> You are using observed values, albeit out of 1 million trials, and
> the actual SD values can not be realistically calculated. What
> happens if you change this to 2 million? Well if you are curious
> about a trend, then I suggest somehow estimating the *limit*. Try it
> at 250000, 500000, 1000000, 2000000, 4000000 and see if it settles.
>
> Also, you could re-run them at 1 million trials, and pssibly get
> differnt results. Compare the two data sets and see if 1 million was
> significant.
>
> Anyhow, I have some time to code these days, if there's some
> tedious/bulk/manual entering of tables for various things, I'd be
> happy to do it if given an example.
>
>
> -Doug
• Show all 13 messages in this topic