# WCA Scramble Algorithm



## Fishcake (Jun 20, 2009)

I tried searching for it in Google and in this forum before posting this thread, but no luck.
My question is, what is the algorithm that is used for generating scrambles in WCA competitions/Cube Explorer?
Is it just some random sequence of maneuvers, or some other sort of complex algorithm to avoid easy scrambles or something?
I need to know this because I'm going to make a Rubik's cube scrambler and timer for my PSP 
to improve my programming skills and so that I can practice cubing anywhere (damn, I have no life ). 

And hopefully, I'm posting in the correct category.


----------



## qqwref (Jun 20, 2009)

For the 3x3, it chooses a random position and then finds a fast way to create that position using the advanced Kociemba algorithm. (This is really hard to program, so I suggest just using 25 random moves.)


----------



## Johannes91 (Jun 20, 2009)

qqwref said:


> Kociemba algorithm. (This is really hard to program, so I suggest just using 25 random moves.)


I don't think it's hard at all, especially if efficiency isn't too important and solutions a few moves longer than 20 are good enough.


----------



## spdqbr (Jun 20, 2009)

qqwref said:


> For the 3x3, it chooses a random position and then finds a fast way to create that position using the advanced Kociemba algorithm. (This is really hard to program, so I suggest just using 25 random moves.)



If it's important to you to have an "even" pool of scrambles to choose from, an analysis I ran some time ago suggested that 40 moves (HTM) is about as low as you can go for #of random scrambles to get this. 25 moves only generates a truly random position with about 20% confidence.


----------



## Lucas Garron (Jun 20, 2009)

spdqbr said:


> If it's important to you to have an "even" pool of scrambles to choose from, an analysis I ran some time ago suggested that 40 moves (HTM) is about as low as you can go for #of random scrambles to get this. 25 moves only generates a truly random position with about 20% confidence.


So 1/5 of the time it'll be truly random? 

(Really, what do you mean?)


----------



## d4m4s74 (Jun 20, 2009)

Lucas Garron said:


> spdqbr said:
> 
> 
> > If it's important to you to have an "even" pool of scrambles to choose from, an analysis I ran some time ago suggested that 40 moves (HTM) is about as low as you can go for #of random scrambles to get this. 25 moves only generates a truly random position with about 20% confidence.
> ...


I think he means certain positions will come up more often then others if you scramble useing 25 moves


----------



## brunson (Jun 20, 2009)

This has been discussed before. Any sequence of random moves will tend towards a set of scrambles a certain distance away from solved (0htm) while tending away from a "maximal" scramble (20htm-23htm). Adding more random moves doesn't push you farther away from solved, in fact it would statistically increase the likelihood of ending up in the area of "pretty much scrambled".

Randomly choosing a cube state guarantees an identical probability of any state. The chance of generating a solved cube is exactly the same as generating a superflip or any other state.


----------



## Cride5 (Jun 20, 2009)

brunson said:


> This has been discussed before. Any sequence of random moves will tend towards a set of scrambles a certain distance away from solved (0htm) while tending away from a "maximal" scramble (20htm-23htm). Adding more random moves doesn't push you farther away from solved, in fact it would statistically increase the likelihood of ending up in the area of "pretty much scrambled".
> 
> Randomly choosing a cube state guarantees an identical probability of any state. The chance of generating a solved cube is exactly the same as generating a superflip or any other state.



I've noticed this phenomenon with edge orientation cases in ZZ. Using a sequence of random moves to scramble usually results in a bias towards a lower number of bad (misoriented) edges. Although 4 and 8 bad edges should be equally probable, I seem to get more 4-edge than 8-edge cases (similarly for 2 and 10 edge cases).

Does anyone know which programs use a proper WCA-style scramble, rather than just a random sequence of moves?


----------



## spdqbr (Jun 20, 2009)

Lucas Garron said:


> spdqbr said:
> 
> 
> > If it's important to you to have an "even" pool of scrambles to choose from, an analysis I ran some time ago suggested that 40 moves (HTM) is about as low as you can go for #of random scrambles to get this. 25 moves only generates a truly random position with about 20% confidence.
> ...



An explanation of the analysis can be found here.


----------



## fundash (Jun 20, 2009)

Fishcake said:


> I need to know this because I'm going to make a Rubik's cube scrambler and timer for my PSP




Can You plese PM me that program (i've been searching FOREVER for a timer PSP)

It doesn't matter what firmware it's meant for, i have a pandora battery and so i have hybrid 1.50/5.xx M33 firmware (yes i know what homebrew is)


----------



## JBCM627 (Jun 21, 2009)

spdqbr said:


> Lucas Garron said:
> 
> 
> > spdqbr said:
> ...


That is an interesting analysis, and very ingenious way of testing the scrambles. I haven't read through all the replies yet, but I am assuming the experimental St Dev column has an error, since you only performed the test on 10^6 scrambles. Do you know what this error would be?

I'd also be curious to see this done for big cube scrambles using a different scramble algorithm: misalign each break on an axis, switch to another, and repeat. Normalizing these scrambles by the number of HTM moves performed, it would be nice to see how much more (or less) efficiently this method scrambles than the WCA scrambler for big cubes. It would also be nice to compare the WCA algorithm to one that randomly misaligns breaks (without backtracking) (note that the WCA scrambler doesn't actually do this - it has a bias in that it tends to perform turns on the same axis more often than the aforementioned alg would).


----------



## Fishcake (Jun 21, 2009)

fundash said:


> Fishcake said:
> 
> 
> > I need to know this because I'm going to make a Rubik's cube scrambler and timer for my PSP
> ...



I'll be happy to share this program when it's done


----------



## Sakarie (Jun 21, 2009)

Just to add something to the CCT discussion:
It doesn't make a new random state every time, since I've had the same scramble twice. Actually, _I_ haven't, but I have gotten a very good bld-scramble from this forum _and_ another forum, which are exactly the same! And both givers says that they have gotten it straight from CCT.


----------



## TomZ (Jun 22, 2009)

Sakarie said:


> It doesn't make a new random state every time, since I've had the same scramble twice.



The WCA scrambler can also come up with the same scramble twice, the previous picks do not affect the next ones.


----------



## Stefan (Jun 23, 2009)

Cride5 said:


> I've noticed this phenomenon with edge orientation cases in ZZ. Using a sequence of random moves to scramble usually results in a bias towards a lower number of bad (misoriented) edges. Although 4 and 8 bad edges should be equally probable, I seem to get more 4-edge than 8-edge cases (similarly for 2 and 10 edge cases).


You're right. From my 3x3 scramble analyzer:


```
scramble length: 25
  probability for  0 flipped edges: 0.00134544044252748545
  probability for  2 flipped edges: 0.03673557940805194881
  probability for  4 flipped edges: 0.25615535099536977496
  probability for  6 flipped edges: 0.44489037738355416974
  probability for  8 flipped edges: 0.23149165891662189241
  probability for 10 flipped edges: 0.02895679378114915976
  probability for 12 flipped edges: 0.00042479907272556887
  state 2047 is least probable with 0.00042479907272556887
  state    0 is most  probable with 0.00134544044252748545
```


----------



## rokicki (Jun 23, 2009)

JBCM627 said:


> spdqbr said:
> 
> 
> > An explanation of the analysis can be found here.
> ...


----------



## JBCM627 (Jun 24, 2009)

rokicki said:


> spdqbr said:
> 
> 
> > An explanation of the analysis can be found here.
> ...


What do you mean by this, as in, where does that number come from?



rokicki said:


> Interestingly, in the quarter turn metric, things were not nearly so dire; in the quarter turn metric, the distribution was incredibly smooth after many fewer moves. Indeed, I think that the distribution was actually smoother for 25 QTM moves than for 25 HTM moves (except for the parity of course). I'll have to verify this of course but this is what I recall.


Would this hold true for big cubes too? If so, the WCA scrambler could be redone a bit


----------



## rokicki (Jun 24, 2009)

JBCM627 said:


> What do you mean by this, as in, where does that number come from?


Symmetry. Consider the corner facelet URF (the Up facelet of the
URF cubie). It can be of one of six colors, but by symmetry, the
chance of it being F is the same as R, the chance of it being B is
the same as L. So that's a total of four variables there.

Every corner facelet will have the same set of variables all with the
same values. So no more variables from the corners.

For the edgies, you get by the corresponding argument five more
variables.

Another way to say it is, there are 48x6 variables, but only 9 (or fewer)
distinct values at any given time.

Indeed, you can reduce the 9 down to 7 by the algebraic identity
that the sum of all the probabilities must be one.


JBCM627 said:


> Would this hold true for big cubes too? If so, the WCA scrambler could be redone a bit



It's hard to say, and maybe worth the analysis!

I've checked my numbers, and I'm preparing a longer report, but I can say
with pretty good confidence that 30 random QTM moves scrambles the cube better than 30 random FTM moves, by almost any metric (except of course in the QTM case you need to flip a coin on whether to add another move
or not to change the parity; doing the same to FTM doesn't significantly
improve the distribution.) So offhand, yes, I'd say your big cube scrambling
algorithms should use only quarter turns and never half turns.

It's kind of counterintuitive because a half turn is "further", it requires two
quarter turns, but the statistics are pretty convincing.

I think I'll be able to do an exhaustive analysis on a 2x2x2 to prove this for
certain.


----------



## rokicki (Jun 24, 2009)

This will take some time to write up reasonably well, but here's a simple thought experiment.

Consider the group (U,F2,R2,D,B2,L2) and the obvious ten generators (half turn metric). The size of this group is about 20B; cosets of this group partition the cube space into about 2B distinct sets.

Now, consider a random sequence of length n of moves taken from the normal 18 generators in the half turn metric. Ten of those generators are in the group above, so the chance that *all* the generators lie within the group is (10/18)^n. This is a lower bound on the probability that after n moves, the resulting position is in the group above.

If we intend that the position be "random" that means the probability it lie in the group above needs to be roughly 1/2B (since there are 2B distinct sets all with the same size). So we need that (10/18)^n <= 1/2B. (Note that this is only a lower bound, because there are sequences that exit the group and then re-enter it). Solving this, we find that n >= 36.4. Restated, with fewer than 36 moves, the chances that the position to be solved lies within the above group is too high.

For the case of 25, the chances that the position lies within the group is about 1 in 2.4M, which is nearly a thousand times higher than it should be. 

On the other hand, experimentally, random QTM moves do much better at leaving the group since only 4 of the 12 QTM moves remain in the group.


----------



## Johannes91 (Jun 25, 2009)

rokicki said:


> Consider the group (U,F2,R2,D,B2,L2) and the obvious ten generators (half turn metric). The size of this group is about 20B; cosets of this group partition the cube space into about 2B distinct sets.
> 
> Now, consider a random sequence of length n of moves taken from the normal 18 generators in the half turn metric. Ten of those generators are in the group above, so the chance that *all* the generators lie within the group is (10/18)^n.


I posted a similar calculation a couple of years ago in the yahoo group, and Chris pointed out that it's not exactly correct because the random moves aren't independent.

The chance is 10/18 only for the very first move. After that, it depends on previous moves; if they are F2 U, the probability is 7/15, if U D, 4/12, if U F2, 9/15, and if F2 B2, then it's 8/12. I made a finite state machine to get exact numbers for different scramble lengths: http://codepad.org/dR6uOWtG. For 25 moves, the chance is about 1 in 15.8M, so a bit better than what you got, but still much too big.

I used a C scrambler to test that the state machine works correctly, and the results are fairly close, but not quite: from 2^34 25-move scrambles, 1333 stayed in the group, which is about 1 in 12.9M. Could be because the built-in PRNG sucks or because the sample is too small. Or maybe I made a mistake.


----------



## Cride5 (Jun 25, 2009)

StefanPochmann said:


> Cride5 said:
> 
> 
> > I've noticed this phenomenon with edge orientation cases in ZZ. Using a sequence of random moves to scramble usually results in a bias towards a lower number of bad (misoriented) edges. Although 4 and 8 bad edges should be equally probable, I seem to get more 4-edge than 8-edge cases (similarly for 2 and 10 edge cases).
> ...



Cheers for confirming the stats, I'm not going mad after all 



qqwref said:


> For the 3x3, it chooses a random position and then finds a fast way to create that position using the advanced Kociemba algorithm. (This is really hard to program, so I suggest just using 25 random moves.)



After a bit of searching, I'm quite sure there are no online WCA-style 3x3 scramblers. The only thing which seems to come close is using Johannes's Cube Solver to scramble then solve and applying the solution's inverse. The only problem is its hard to tell if the scrambler actually chooses a random state or whether it applies a random sequence of moves.

If I can find the time, I might try implementing a scrambler in Javascript which randomly generates a cube state, ensuring its orientation and permutations are compliant with the laws of the cube. A basic implementation of the Kociemba algorithm will then generate an efficient solution and provide its inverse for the scramble. Is this something that folk would find useful?


----------



## rokicki (Jun 25, 2009)

> Could be because the built-in PRNG sucks or because the sample is too small. Or maybe I made a mistake.

I suspect your code is not taking into account sequences that leave the group and re-enter it later; that might account for the difference.

By the way, the quick analysis I posted was indeed assuming independent moves; my longer analysis handles both independent moves (which are fairly common in some cube "scramblers", as well as being interesting from a theoretical perspective) and the "restrict subsequent moves" in various ways.

I have exact numbers for the entire Kociemba group (this required many gigabytes of RAM and hundreds of gigabytes of disk space) for various twist combinations. It's a lot of data to crunch through.


----------



## rokicki (Jun 25, 2009)

That sounds like an excellent challenge: who can write a JavaScript WCA scrambler that (however it wants to) generates reasonably short scrambles for random cube positions? The program has to start from scratch (no loading pruning tables from disk). This is similar to my cube solving contest a few years ago, but different because we want shorter lengths than those algorithms would generate.

Kociemba's algorithm is super fast, but generating the pruning tables take a while; what's the best balance between precalculating and solving?


----------



## mrCage (Jun 26, 2009)

rokicki said:


> That sounds like an excellent challenge: who can write a JavaScript WCA scrambler that (however it wants to) generates reasonably short scrambles for random cube positions? The program has to start from scratch (no loading pruning tables from disk). This is similar to my cube solving contest a few years ago, but different because we want shorter lengths than those algorithms would generate.
> 
> Kociemba's algorithm is super fast, but generating the pruning tables take a while; what's the best balance between precalculating and solving?


 
What is reasonably short in this respect? A typical Roux/Heise solve would take about 40 turns (htm). I guess the best bet would be to port the two-phase algorithm to JavaScript. And why cannot pruning tables be used with JavaScript?

Seriously, i dont think random state scrambling will have any great impact. It mostly only complicates matters. What's wrong with the occasional lucky solve? What matters is fairness!!

Per

PS! There are great practical implications with random state scrambling. It cannot be elegantly used for most "larger" puzzles like 4x4x4, 5x5x5, etc. The scrambles would be rather longish. So why being so picky about 3x3x3 scrambling? 

What is the current state of 4x4x4 god's algorithm search? There are some solvers generating decently short scrambles, but they do not claim at all be opimal or even near optimal. The idea is yet again nested subgroups, not humanlike solving.

Per


----------



## Stefan (Jun 26, 2009)

mrCage said:


> What is reasonably short in this respect?


Well, he said the solutions of his cube solver contest aren't good enough, and the winners used Thistlethwaite which averages 31.3 moves.



mrCage said:


> I guess the best bet would be to port the two-phase algorithm to JavaScript.


I suspect Thistlethwaite searching alternatives like Kociemba does might be better.



mrCage said:


> And why cannot pruning tables be used with JavaScript?


He didn't say that.



mrCage said:


> So why being so picky about 3x3x3 scrambling?


What? We aren't. Random state scrambling is ideal and the simple rule is that we want to use it whenever possible. Remember we don't just do it for 3x3x3 but also already for 2x2x2, clock and pyraminx:
http://www.worldcubeassociation.org/regulations/#scrambling


----------



## AvGalen (Jun 26, 2009)

...and for pyraminx the provided scramble isn't optimal (not even close). I didn't know that clock-scrambles were randomstates. Are you sure?

I do suspect that generating and using the "Kociemba 2 step alg pruning tables" wouldn't be possible in yesteryears browsers. IE (even 8) already gives problems (timeouts) with the 2x2x2 pruning tables. All other (presentdays) major browsers seem to handle javascript increasingly fast but I have never seen a browser handle such huge javascript.

I wrote a web-interface for Cube Explorer a couple of years ago. I had Cube Explorer running as a service on my webserver and its webinterface was used for solving the provided state. I am sure that implenting that would be the simplest solution, but it would require a server were Cube Explorer was actually running.


----------



## Cride5 (Jun 26, 2009)

mrCage said:


> Seriously, i dont think random state scrambling will have any great impact. It mostly only complicates matters. What's wrong with the occasional lucky solve? What matters is fairness!!



Going by the statistics here I don't really trust a sequence of 25 random moves to scramble my cube properly. Of course, I could simply add more random moves, but that will get tedious. The nice thing about implementing a random state scrambler is that the scramble moves you're applying are efficient at scrambling the cube. Its not just a sequence of 25 random moves, but a sequence of 25 (or so) moves to bring the cube to a truly random state. 



AvGalen said:


> I do suspect that generating and using the "Kociemba 2 step alg pruning tables" wouldn't be possible in yesteryears browsers. IE (even 8) already gives problems (timeouts) with the 2x2x2 pruning tables. All other (presentdays) major browsers seem to handle javascript increasingly fast but I have never seen a browser handle such huge javascript.
> 
> I wrote a web-interface for Cube Explorer a couple of years ago. I had Cube Explorer running as a service on my webserver and its webinterface was used for solving the provided state. I am sure that implenting that would be the simplest solution, but it would require a server were Cube Explorer was actually running.



I'm pretty sure that's how Johannes's online solver works as well. I've had a wee look through his Javascript and solve requests are being passed to cgi scripts on the server-side. 

This could be the best (or only) way to do it, but the fandamental problem is scalability. Imagine a popular site like cubetimer.com handling thousands of solve requests in order to generate nice scrambles for its users. I doubt their service providers would be happy 

Anyway, I think I'm going to have a look at possible client-side options. If Javascript doesn't work then it may have to be an applet.


----------



## Stefan (Jun 26, 2009)

AvGalen said:


> ...and for pyraminx the provided scramble isn't optimal (not even close).


Right. Would be desirable to not have scrambles more than 12 moves plus tip moves.



AvGalen said:


> I didn't know that clock-scrambles were randomstates. Are you sure?


Pretty sure. Well, not in the sense that we first pick a random state and then compute a generating scramble for it, but in the sense that the scrambles we generate result in a uniform distribution.


----------



## AvGalen (Jun 26, 2009)

StefanPochmann said:


> AvGalen said:
> 
> 
> > ...and for pyraminx the provided scramble isn't optimal (not even close).
> ...


For Pyraminx I love to play "beat the scramble" so I like the longer scrambles 

For Clock I have had this feeling for quite some time that the scrambles aren't actually that good and certainly aren't "random state". Do you know of a study about this or do I have to do this research myself?


----------



## Stefan (Jun 26, 2009)

AvGalen said:


> For Clock I have had this feeling for quite some time that the scrambles aren't actually that good and certainly aren't "random state". Do you know of a study about this or do I have to do this research myself?


I just checked it (probably have before). I'm sure now. A proof is actually quite easy, at least if you know how to solve the clock. I can give my proof, but I'm sure you can do it as well and I'd like to see (how) you do it.


----------



## mrCage (Jun 29, 2009)

Hi 

I see a possible future clash between the wca preferred scrambling notation and optimality. A random state optimal scrambler would (probably) use all notation tokens on larger cubes, not solely outer block notation. There are a few puzzles where random state scrambling is easy and feasible. So by all means go ahead and scramble like that. Noone has yet convinced me what is the gain in doing so. KISS

Per


----------



## AvGalen (Jul 1, 2009)

StefanPochmann said:


> AvGalen said:
> 
> 
> > For Clock I have had this feeling for quite some time that the scrambles aren't actually that good and certainly aren't "random state". Do you know of a study about this or do I have to do this research myself?
> ...


I am actually not quite sure that clock scrambles are indeed random state. I will look into this on sunday. I am especially worried about the quality of the scrambles when there are 0's in it. I hope that on Sunday I will realise that I shouldn't worry.

And Per: You should realise that for blind and FMC it is unfair if chances of 8 misoriented edges are smaller than 4 misoriented edges. For speed, this might also be an advantage if you use methods like EOLine. I am not saying this is a big problem, but if we have the capabilities to avoid it without big downsides...why not?


----------



## qqwref (Jul 3, 2009)

The way the clock scramble should work is that it generates 14 random numbers (from -5 to 6 inclusive) and then does a specific set of 14 linearly independent moves with those amounts. That is, as there are 14 clocks, we should be able to solve every position by doing each of those moves once, and similarly we can scramble to any position by doing each of those moves once. As long as the function we use to generate the 14 numbers is truly random, the scrambles also will be.


----------



## Cride5 (Jul 8, 2009)

Looks like the simple idea of implementing Kociemba in Javascript wasn't to be. As I suspected, Javascript with its very loose type system made it difficult to store the lookup tables efficiently. The program consumed far too much memory to be usable. Looks like its back to the drawing board...

In the mean time, I've posted up a simple random state scramble generator as a Java applet if anyone's interested.

I'd still like to get an efficient solver (25 moves or less) working in Javascript, something with a much leaner memory footprint. Currently very short on time, so I'll put it on the back burner for now


----------



## mrCage (Jul 11, 2009)

AvGalen said:


> And Per: You should realise that for blind and FMC it is unfair if chances of 8 misoriented edges are smaller than 4 misoriented edges. For speed, this might also be an advantage if you use methods like EOLine. I am not saying this is a big problem, but if we have the capabilities to avoid it without big downsides...why not?


 
Have i misunderstood the concept of fairness?! As long as all competitors get the same scramble(s) it would be fair, right ???

Seriously, explain to me what is wrong with the occasional easy/lucky scramble as long as everyone get that same scramble??

Per


----------



## Lucas Garron (Jul 12, 2009)

mrCage said:


> AvGalen said:
> 
> 
> > And Per: You should realise that for blind and FMC it is unfair if chances of 8 misoriented edges are smaller than 4 misoriented edges. For speed, this might also be an advantage if you use methods like EOLine. I am not saying this is a big problem, but if we have the capabilities to avoid it without big downsides...why not?
> ...


It's not fair because the solves enter a database where solves are compared with people's who didn't get a chance at the same scrambles. "Fair" at the competition, not fair worldwide.

Also, it's unfair because it changes the nature of the event. The idea is to assess the ability to solve any cube in few moves. With an uneven scramble distribution, we're giving competitors a chance to prepare to perform better in this event than their ability to solve arbitrary cubes.


----------



## qqwref (Jul 12, 2009)

Lucas Garron said:


> It's not fair because the solves enter a database where solves are compared with people's who didn't get a chance at the same scrambles. "Fair" at the competition, not fair worldwide.



This is the same reason that I have advocated removing scrambles that give a position which is too close to solved. Even if everyone in a competition has the opportunity to solve an incredibly easy scramble, not everyone in the world will, and so it's not fair to everyone who wasn't at that competition. For some events this is no problem at all, but for short events such as 2x2 and pyraminx it is a huge deal. I don't want to have to compete with someone who averages 8-9 seconds on 2x2 but got a 2-second solve because the scramble was 4 or 5 moves; unless I was world-class at 2x2, there's no way I could beat a time like that without also being lucky.


----------



## mrCage (Jul 14, 2009)

Lucas Garron said:


> mrCage said:
> 
> 
> > AvGalen said:
> ...


 
That is taking fairness a bit far ... Then one could say cubing contests are by nature unfair (unless online ... ) Would you also include method independence in your perfect fairness definition?

Per


----------



## AvGalen (Jul 15, 2009)

mrCage said:


> ...Would you also include method independence in your perfect fairness definition?
> 
> Per


Yes, that is exactly what this is about. If the number of oriented edges should be 6 on average, but it is 10 on average (these numbers are exagerated) then you could optimise training by learning all 2-flip algs but only 1 or 2 6 flip algs.

If a truly random puzzle state is generated first and then a scramble is calculated for it that would be the fairest way


----------



## qqwref (Jul 15, 2009)

AvGalen said:


> If a truly random puzzle state is generated first



Ah, Arnaud, didn't you know, that's the hardest part ;-)


----------



## okayama (Oct 18, 2010)

I have questions about the scramble-length.

The scramble-length is defined as:

(3x3: 25)
4x4: 40
5x5: 60
6x6: 80
7x7: 100
Mega: 70
Sq-1: 40

and I want to know

- History (how was the scramble-length defined?)
- Fact (is the length truly enough to get a random position?)

I'm interested in the Latch Cube, and I want to think/know the proper scramble-length for it based on the same idea as the puzzles above.


----------



## FMC (Oct 18, 2010)

im interested in this latch cube....can you please tell me how different is this from 3x3x3 cube?
i think all anti clockwise turns can be replaced by 3 clockwise turns but there must be something
else that makes it different from normal 3x3x3..can i just use some arrow marks on my normal 3x3x3 cube 
to simulate a latch cube or is it something more?thanks


----------



## Lucas Garron (Oct 18, 2010)

okayama said:


> - History (how was the scramble-length defined?)


Something that looks random enough and doesn't take too long.



okayama said:


> - Fact (is the length truly enough to get a random position?)


(3x3: No)
4x4: No
5x5: No
6x6: No
7x7: No
Mega: No
Sq-1: No

No number of moves is enough; even if the distribution approaches the correct one, there will always be small deviations. The definition of "random" is subjective, and can be demonstrated to be quite high for some reasonable definitions of "random enough."

Although for the huge cubes what matters in practice is center distribution, and for Megaminx the star piece distribution (colors are solver-dependent).


----------



## joey (Oct 18, 2010)

What if you don't start with centres or stars?


----------



## qqwref (Oct 18, 2010)

I think the number of turns is enough to adequately scramble any piece type (centers, corners, edges (for star/cross), whatever). You will only notice a difference if you look at more complex things like block building (on centers, say), parity (on Square-1 it actually occurs well under 50% for our current scrambler, if you use optimal cubeshape), etc.

In all cases but Megaminx, there are more possible scrambles than possible positions. So at least that is good.

Lucas brings up a good point but also a useless one, because even though we would like to use a random position scrambler for all puzzles, it is not yet possible (computationally) to do this in a small number of moves for 5x5, 6x6, 7x7, and megaminx. (4x4 is debatable; there is a Thistlethwaite-like solver out there which almost has an acceptable movecount.)


----------



## okayama (Oct 18, 2010)

FMC said:


> im interested in this latch cube....can you please tell me how different is this from 3x3x3 cube?
> i think all anti clockwise turns can be replaced by 3 clockwise turns but there must be something
> else that makes it different from normal 3x3x3..can i just use some arrow marks on my normal 3x3x3 cube
> to simulate a latch cube or is it something more?thanks



Big feature: If there are both (black and white) arrows on the same face, the face is locked!




Lucas Garron said:


> okayama said:
> 
> 
> > - History (how was the scramble-length defined?)
> ...



Hmm, is there no theoretical ground?
For example, a friend of mine expects that there are 6 faces in 3x3x3, and
6^25 = 2.8 x 10^19 ~ 4.3 x 10^19 (approximately equals to the number of all states)
was probably the reason for 25 moves in the case of 3x3x3. (aside from the following fact)



Lucas Garron said:


> okayama said:
> 
> 
> > - Fact (is the length truly enough to get a random position?)
> ...



OK, aside from the fact, I want to know why WCA defined the following moves

(3x3: 25)
4x4: 40
5x5: 60
6x6: 80
7x7: 100
Mega: 70
Sq-1: 40

make the puzzle "looks random enough and doesn't take too long." Is there anyone who knows the (theoretical/mathematical) background?


----------

