Looping or Repeating Algorithms?

[Stefan]

I have a degree from a US university and your generalization is insulting at best.

Ok, sorry, I apologize. I did know I had little data and might be wrong generalizing, as I said myself. In any case, whether it's true or not doesn't really bother me, it's more of a light-hearted, bit amusing issue for me. Because of that, the initial utterance was intended more jokingly, now I see it wasn't so funny (and quite possibly wrong). I tend to cross lines when I don't care. Sorry about that.

 

[shelley]

I like how people are still suggesting move sequences after we've established that any sequence of moves will eventually get you back to the original position.

I'll join in too.
F2 D L D2 B F' L2 U' L' R' D' F' D L F D' R2 B2 F U L' R U' L R2

 

[qqwref]

That sequence has to be done 40 times to return to solved. Ew.

 

[Lorenzo]

I like how people are still suggesting move sequences after we've established that any sequence of moves will eventually get you back to the original position.

I'll join in too.
F2 D L D2 B F' L2 U' L' R' D' F' D L F D' R2 B2 F U L' R U' L R2

Is this some random computer scramble?

 

[Cride5]

I like how people are still suggesting move sequences after we've established that any sequence of moves will eventually get you back to the original position.

I'll join in too.
F2 D L D2 B F' L2 U' L' R' D' F' D L F D' R2 B2 F U L' R U' L R2

Is this some random computer scramble?

More than likely. It takes 40 repetitions to return to the original state.

 

[ardiantoarsadi]

So, i just wondering how if we repeat same moves many times to a solved rubik's cube, it will be back to the solve position again
simple example: if i do U four times it will be back to a solve state
other obvious example is PLL
so just now i do RU' many many times and its solved again
then i try RU and RUL and after many many many times (yeah i have no life) it also back to the solved state

is there any logical/combinatorical explanation of this?

sorry for my bad english btw​

 

[Tao Yu]

Thereare not an infinite number of positions to the rubik's cube

This means that when you repeat moves the positions you encounter must be seem again .

Somebody could probably give a better explanation

Lucas gave a good explanation of this here

 

[aronpm]

Any sequence of moves performs cycles on the cube. Any cycle performed enough times, will return to the original state.

Take RU for example. It twists URF (which needs to be done 3 times to return to solved), and does a 5-cycle of corners (5 times to be solved). To solve the corners again, the number of times needed to be repeated would be the lowest common multiple of these (which is 15). Edges do a 7-cycle (7 repeats to be solved again). So the total number of times is the LCM of 3,5,7 (or LCM of 15,7) which is 105.

 

[ardiantoarsadi]

Any sequence of moves performs cycles on the cube. Any cycle performed enough times, will return to the original state.

Take RU for example. It twists URF (which needs to be done 3 times to return to solved), and does a 5-cycle of corners (5 times to be solved). To solve the corners again, the number of times needed to be repeated would be the lowest common multiple of these (which is 15). Edges do a 7-cycle (7 repeats to be solved again). So the total number of times is the LCM of 3,5,7 (or LCM of 15,7) which is 105.

wow.. great explanation

 

[Stefan]

Any sequence of moves performs cycles on the cube.
Any cycle performed enough times, will return to the original state.

You replaced one claim with two others (granted, they're somewhat smaller, but still...).

Take RU for example. It twists URF (which needs to be done 3 times to return to solved), and does a 5-cycle of corners (5 times to be solved).

More like "twisted" 5-cycle that takes 15 times.

 

[aronpm]

You replaced one claim with two others (granted, they're somewhat smaller, but still...).

More like "twisted" 5-cycle that takes 15 times.

Definitely. I should have included that tracing the 'sticker cycle' is a 15-cycle, but that's why I mentioned the corner being twisted.

 

[Stefan]

I should have included that tracing the 'sticker cycle' is a 15-cycle, but that's why I mentioned the corner being twisted.

That corner is not part of that cycle, though. And such an explanation could make someone think for example that a twisted 5-cycle and a twisted 3-cycle need LCM(5,3)=15 instead of the correct LCM(15,9)=45.

 

[aronpm]

Yes, you are correct You won't be getting a pointless attempt at an argument from me, if that's what you're after.

 

[Stefan]

You won't be getting a pointless attempt at an argument from me, if that's what you're after.

No, I do prefer a quick resolution. I don't argue because I want to argue, but because I care about the topic/people/correctness. In this case, I didn't want people to see this and "learn" that all they have to do is counting pieces.

 

[vcuber13]

this may be useful to you: http://solvethecube.110mb.com/tools.html#order

 

[Erdos]

Any sequence of moves performs cycles on the cube. Any cycle performed enough times, will return to the original state..

Here's a slightly rigorous proof for that claim.

Consider any sequence of moves as element a in the cube group, which I shall denote as G. Since |G| is finite, the cyclic subgroup <a> has a finite order (more specifically, by Lagrange, |a| divides |G|). So a^m = e for some m in Z. Done.

 

[qqwref]

this may be useful to you: http://solvethecube.110mb.com/tools.html#order

Also my version (which can handle cubes of other sizes): http://mzrg.com/rubik/ordercalc.shtml

I like the proof Erdos posted - quick and to the point.

 

[Tim Major]

Think, if it never came back to the starting position, that'd mean it would endlessly change. Which would mean the rubik's cube has limitless cube states.

 

[Lucas Garron]

Think, if it never came back to the starting position, that'd mean it would endlessly change. Which would mean the rubik's cube has limitless cube states.

Your reasoning is incomplete. Does "endlessly change" mean "never reach a position that was reached before"?
(R)(UUUUUUUUUUUU...) never comes back to the starting position, but it doesn't endlessly change. Why can't this happen if R and U are replaced by the same alg?

 

[qqwref]

Why can't this happen if R and U are replaced by the same alg?

The only change in your example is that the solved state isn't included in the cycle; although Tim's wording wasn't so great, I don't think anyone would expect an arbitrary cycle starting from an arbitrary point to go back to solved, just to go back to the initial state.

One line of reasoning (without using group theory) to show that doing the same set of moves from solved must always lead back to solved is to understand that any algorithm can be inverted (un-done). This means that, in the sequence of positions we get from applying a sequence over and over, you know what positions come before and after any given position, no matter where you see it in the sequence, since you can just apply the move sequence to get the position after, and the inverse of the move sequence to get the position before. So, you can't enter into an infinite loop like w -> x -> y -> z -> x -> y -> z -> ... (all the letters being different positions) because then x comes after both w and z. In fact the only way to go forever without getting back to the initial state is to go through an infinite number of different positions, and we know this is impossible because there aren't that many positions to begin with.