# (R2 y)24



## Rocky0701 (Sep 26, 2013)

Has anyone ever noticed that if you hold a solved cube and do R2 Y 24 times the cube solves it self again, i know that stuff like R U R' U' or R U R' U do, but has anyone ever seen this?


----------



## Coolster01 (Sep 26, 2013)

Rocky0701 said:


> Has anyone ever noticed that if you hold a solved cube and do R2 Y 24 times the cube solves it self again, i know that stuff like R U R' U' or R U R' U do, but has anyone ever seen this?



Any repetitive sequence of moves eventually solves itself, actually.


----------



## Renslay (Sep 26, 2013)

Rocky0701 said:


> Has anyone ever noticed that if you hold a solved cube and do R2 Y 24 times the cube solves it self again, i know that stuff like R U R' U' or R U R' U do, but has anyone ever seen this?



Yes. Every movements brings you back to the solved state if you repeat it enough (and if you started from the solved state). It's fun to play with this, try to figure out the repetition numbers for different movements (but there are also softwares to calculate it for you). I think everybody does that or did that a few times for short movements.


----------



## Noahaha (Sep 26, 2013)

This is an interesting but painful challenge. I got 12.18. 

And I think you mean R2 *y* 


EDIT: I guess there was no challenge...


----------



## Mollerz (Sep 26, 2013)

8.437


----------



## YddEd (Sep 26, 2013)

16.46 ;_;



Noahaha said:


> EDIT: I guess there was no challenge...


Who cares, lets turn this into a challenge anyway xD


----------



## Rocky0701 (Sep 26, 2013)

Renslay said:


> Yes. Every movements brings you back to the solved state if you repeat it enough (and if you started from the solved state). It's fun to play with this, try to figure out the repetition numbers for different movements (but there are also softwares to calculate it for you). I think everybody does that or did that a few times for short movements.


Yeah, i wonder how many it would be if you did R y repetitively. Gonna try it now.
Got: 18.93 for the "challenge" and which software?


----------



## Stefan (Sep 26, 2013)

4.67 seconds:






Holding two corner stickers with left thumb and middle finger and two center stickers with the right thumb and middle finger, then doing something like (Uw2 Rw2')12 without ever letting go.



Rocky0701 said:


> Yeah, i wonder how many it would be if you did R y repetitively. Gonna try it now.



That might take you a while...


----------



## qqwref (Sep 26, 2013)

Rocky0701 said:


> Yeah, i wonder how many it would be if you did R y repetitively. Gonna try it now.


http://mzrg.com/rubik/ordercalc.shtml says 1260 times.


----------



## Rocky0701 (Sep 26, 2013)

Stefan i tried this, couldnt hold it like that though, still using a store-bought Rubik's. Our two ilnot really algorithms but repetitive sequences are really similar. I did notice that 6 times doing yours and 12 with mine each had the same position only with different colors. Also, yes i gave up at around 300.


----------



## Rocky0701 (Sep 26, 2013)

qqwref said:


> http://mzrg.com/rubik/ordercalc.shtml says 1260 times.



Im really bored, so i just tried this and it worked. I did notice a few patterns though. About every 60 rotations, the top layer and sometimes second layers would solve themselves, and the same top layers positions didnt appear to repeat except when a new cycle started. So i have a mini theory that i will test later that this just cycles every OLL. I also messed up a couple times and was able to correct myself because of this pattern. Although the entire time i felt like i would imagine a multiblind solver does, and wondered if i had messed up ever.


----------



## cubeone (Sep 26, 2013)

I prefer R2 x.


----------



## Noahaha (Sep 26, 2013)

Rocky0701 said:


> Im really bored, so i just tried this and it worked. I did notice a few patterns though. About every 60 rotations, the top layer and sometimes second layers would solve themselves, and the same top layers positions didnt appear to repeat except when a new cycle started. So i have a mini theory that i will test later that this just cycles every OLL. I also messed up a couple times and was able to correct myself because of this pattern. Although the entire time i felt like i would imagine a multiblind solver does, and wondered if i had messed up ever.



It definitely does not reach every OLL, given that 57*60 = 3420

If you take any sequence of moves, you can figure out how many times it will take to solve pretty easily by finding two numbers:

c = # of iterations from the solved position before corners are solved.
e = # of iterations from the solved position before edges are solved.

The cube is solved when both the corners and edges are solved, so all you have to do is find the least common multiple of c and e.


----------



## YddEd (Sep 26, 2013)

cubeone said:


> I prefer R2 x.


I prefer R2 x'.


----------



## Ninja Storm (Sep 26, 2013)

I prefer x' x.


----------



## Tim Major (Sep 26, 2013)

Stefan said:


> 4.67 seconds:
> 
> 
> 
> ...



I came in to post this. We used to do this as a challenge at Melbourne meetups years ago, in fact I was talking about this on IRC just a few weeks ago. It's so addicting, I actually found it easier on older cubes though (like type A for example)


----------



## Rocky0701 (Sep 26, 2013)

Noahaha Well at the time 60 was just an estimate, but i just redid it and counted and it actually was 60 which oddly enough 1260/60 is 21 which is the number of PLL's. However this has nothing to do with PLL because none of these positions are PLL's. For that equation how can you figure the number of moves for corners and edges before you multiply the two?


----------



## Noahaha (Sep 26, 2013)

Rocky0701 said:


> Noahaha Well at the time 60 was just an estimate, but i just redid it and counted and it actually was 60 which oddly enough 1260/60 is 21 which is the number of PLL's. However this has nothing to do with PLL because none of these positions are PLL's. For that equation how can you figure the number of moves for corners and edges before you multiply the two?



Test it. 

36 iterations solves the corners. I'm too lazy to find the # for edges. Note that you're not multiplying the two, but finding their least common multiple.


----------



## Rocky0701 (Sep 26, 2013)

Noahaha said:


> Test it.
> 
> 36 iterations solves the corners. I'm too lazy to find the # for edges. Note that you're not multiplying the two, but finding their least common multiple.



I figured it couldn't be too much higher than 36, so i counted and 70 iterations solve the edges. The LCM of 36 and 70 would be 1260.


----------



## Stefan (Sep 26, 2013)

Noahaha said:


> 36 iterations solves the corners. I'm too lazy to find the # for edges. Note that you're not multiplying the two, but finding their least common multiple.



Lazy indeed. From the 36, a multiple of 4, you already know we'll need a multiple of 4 iterations overall. So do four iterations (this gets rid of cube rotations) and simply observe the edges: One 7-cycle and one 5-cycle. Thus you need the least common multiple of 36, 7 and 5.


----------



## Rocky0701 (Sep 26, 2013)

Stefan said:


> Lazy indeed. From the 36, a multiple of 4, you already know we'll need a multiple of 4 iterations overall. So do four iterations (this gets rid of cube rotations) and simply observe the edges: One 7-cycle and one 5-cycle. Thus you need the least common multiple of 36, 7 and 5.


You alop know that the number has to be greater than 36 and so it matches up with 70, but you could also just go straight to 1260.


----------



## Stefan (Sep 26, 2013)

Rocky0701 said:


> You alop know that the number has to be greater than 36 and so it matches up with 70, but you could also just go straight to 1260.



Huh?


----------



## Noahaha (Sep 26, 2013)

Stefan said:


> Huh?



He's saying that it was possible that the edges wouldn't be solved until 1260 iterations.


Also I wasn't being lazy. When I got to 70, the edges weren't solved, so I guess I messed up.


----------



## Stefan (Sep 26, 2013)

Noahaha said:


> He's saying that it was possible that the edges wouldn't be solved until 1260 iterations.



If that's what he meant, NSA should be interested in you and your deciphering skills.



Noahaha said:


> Also I wasn't being lazy. When I got to 70, the edges weren't solved, so I guess I messed up.



My point was that there's a really easy and effortless way to determine the 1260, and to tell (more him than you) that there are other ways than to look at all edges as a whole and do turns and count until all of them are solved again. Four moves and then cycle-counting is enough, and not doing that is lazy, especially for a BLD expert


----------



## Rocky0701 (Sep 26, 2013)

First what is the NSA? Also it wasnt really deciphering, i knew that the edges had to be more than 36 iterations, so the LCM of 5 and 7 which is higher than 36 would stand out to be 70 which the LCM of 70 and 36 is 1260.


----------



## Stefan (Sep 26, 2013)

Rocky0701 said:


> First what is the NSA?



Seriously?
http://en.wikipedia.org/wiki/NSA
https://www.google.com/#q=NSA&tbm=nws

They're climbin’ in your windows (and your linux etc), they're snatchin’ your datas up, tryin’ to analyze ‘em. So y’all need to hide your disks, hide your drive, and hide your stick cause they’re analyzin’ everybody out here.



Rocky0701 said:


> Also it wasnt really deciphering



That's very true. *You* were *ciphering*. Noah was the one who *de*ciphered your gibberish. (Edit: Darn, I thought you had written _"I wasnt really deciphering"_. Meh, close enough)



Rocky0701 said:


> the LCM of 5 and 7 which is higher than 36 would stand out to be 70 which the LCM of 70 and 36 is 1260.



Aaaand you're doing it again.


----------



## Rocky0701 (Sep 26, 2013)

That's very true. *You* were *ciphering*. Noah was the one who *de*ciphered your gibberish.



Aaaand you're doing it again.[/QUOTE]

How was that gibberish?


----------



## Noahaha (Sep 26, 2013)

Stefan, you always put a smile on my face. <3

Don't listen to the haters.


----------



## Stefan (Sep 26, 2013)

Rocky0701 said:


> How was that gibberish?



The first or the second time? (Or this third time, where you broke the quotation?)

I'll include my thoughts about the second time in bold:

_"the LCM of 5 and 7 *(that's 35, but go on)* which is higher than 36 *(no it's not, 35 is lower than 36)* would stand out to be 70 *(what does"stand out to be" mean? This might be my fault for not knowing that expression, but I do claim it's at least unusual)* which the LCM of 70 and 36 is *(70 is the LCM of 70 and 36???)* 1260 *(how does that dangling number fit into the sentence??)*."_

The (correct) lack of a comma before "which is higher than 36" could have given me a hint, but the overall lack of commas and sentence structure didn't make me think about that.

Admittedly this one was rather ok and after some thinking I'm able to understand what you meant (I still think it's not a proper sentence), but the first one I really couldn't.


----------



## Rocky0701 (Sep 27, 2013)

Stefan said:


> The first or the second time? (Or this third time, where you broke the quotation?)
> 
> I'll include my thoughts about the second time in bold:
> 
> ...



Yes, the sentence was very poorly written, and needed more commas. The lack of a comma before "which is higher than 36" was intentional. The reason for this was because, when going through the 36 iterations to get from a solved state to a corners-solved state, i would have noticed if the edges had become solved before this. I realize that the LCM of 7 and 5 is 35, but i knew that the number of iterations to get to an edges-solved state had to be the least common multiple of 7 and 5 which was greater than 36. By saying this would "stand out" i basically meant it would very easily appear that this number would be 70. The LCM of 36 and 70 is 1260. I know that this is definately not the most quick or eifficient way getting to the answer, and that there are many ways to do it, but this is was worked for me when i did it. I hope that how i said it this time was much more clear and i appologize for making less sense to begin with.


----------



## Stefan (Sep 27, 2013)

Rocky0701 said:


> The reason for this was because, when going through the 36 iterations to get from a solved state to a corners-solved state, i would have noticed if the edges had become solved before this.



Yeah, that helps understanding, as I also didn't see a reason for wanting it higher than 36. I still don't get why you want the *least* one above 36, though. I don't see any reason why the edges should be solved after 70 iterations, not just at 140. So that approach of using 36, 7 and 5 to get 70 (and then using 36 and 70 to get 1260) still seems flawed anyway. I maintain that the proper way to do it is the direct LCM(36,7,5).


----------



## Rocky0701 (Sep 27, 2013)

Stefan said:


> Yeah, that helps understanding, as I also didn't see a reason for wanting it higher than 36. I still don't get why you want the *least* one above 36, though. I don't see any reason why the edges should be solved after 70 iterations, not just at 140. So that approach of using 36, 7 and 5 to get 70 (and then using 36 and 70 to get 1260) still seems flawed anyway. I maintain that the proper way to do it is the direct LCM(36,7,5).


Yes, i agree that the most quick and efficient way to do the equation is from the LCM of 36, 7, and 5, but this is just the way that i did it. I don't know why i did it this way, i just did.


----------



## (X) (Sep 27, 2013)

Got a 3.44 for (Rw2' Uw2' Rw2 Uw2')6


----------

