# UWR - Largest Computer Cube Solve Ever!



## qqwref (May 20, 2013)

I solved the 111x111x111! ​






It took a total of just under 30 hours of work, done over 10 days or so on the newest version of IsoCubeSim. Some more detailed statistics:
- Total solve time: 29:51:02.641, or 107,462.641 seconds.
- Total moves: 201,858*
- Number of pieces: 72,596
- Seconds per piece: 1.480 (!!!)
- Moves per piece: 2.781 (!!!)
- Moves per second: 1.878
- Real time spent: about 10 days 6 hours 48 minutes (from 2:59 PM on the 9th, until 9:47 PM on the 19th).
- Percent of time spent working: 12.1%

*The game says 199430 moves, but it actually forgot to count the moves from my first save due to a programming bug which I fixed as soon as I noticed it.

If you're interested in some more details, check out the gallery of progress screenshots or download all the replay files.

I also want to describe the method I used. I really put a lot of thought into making a method for every part that would scale well - remain easy even with extremely large cubes. It's going to be a bit long, so I'll put it in a spoiler...


Spoiler



First, some basics. I solved most faces in two steps: "cleaning" and finishing up. The idea of cleaning a face is to solve as many pieces as possible as quickly as possible. After that step, which typically solves 50% or more of the face, I can go through the longer step of putting each of the remaining pieces of that color into the center, one at a time or in blocks. As for notation, I'll be using something like SiGN (xR means turn the xth layer on the R face, or the first layer if x is absent), except that I'll also be using lowercase p and q as variables to better describe classes of commutators.

1) Solve the edges. I do edges first for large computer cubes because reduction (centers first) scales badly, and because having solved edges actually lets me use them to keep track what part of the puzzle I'm working on. A lot of the time I do a pR' move or something to start working on a row of one center, and the incorrect edge reminds me which row it is. With so many layers it's impossible to do it by counting or visual inspection alone. Anyway, for the first 9 edges I did basically the same thing as with other cubes. For the last three edges I used moves like pR U2 pR' (for the 10th edge only), pR2 U2 pR U2 pR2, and pR' F U' R F' U pR. Instead of solving one orbit at a time like on my keyboard solves, I went for an edge at a time and solved pieces in the same position in groups. For instance on the last 3 edges there are only 6 possible positions for each piece, so with 109 pieces in each edge there are a lot of pieces in the same position which can be solved in the same way, all at once, by replacing a pR move with a whole bunch of slice moves along the same layer. This took about an hour in total.

2) Clean the first center. I used white. Hold the white face on U, and then for each row (perpendicular to the F face), we do something like this: move white centers out of the way on the corresponding row on F using pU moves, then qR', then solve as many white centers into that layer as possible using only pU-axis moves, then qR. By "solve as many white centers ... as possible" I mean I basically look at that row on R, B, and L, and for every white center I see, move that layer the right amount. Note that these rows are vertical, which is something I did because of the way Iso is set up (when zoomed in, it's easy to scroll through a vertical row on F or R using just the up/down arrow keys). You could do any of this from a different angle if you wanted. A typical layer might be something like (2U 4U 7U ...) 3R' y (3U 6U 8U ...) y (U2 4U2 8U2 ...) y (2U' 3U' 4U' ...) y 3R. Each center on white corresponds to 5 stickers, and a white center on any of those 5 stickers means the center gets solved. I think roughly 60% of the center ends up solved.

3) Finish the first center. Now I can hold the center on F and look at R. If I see a white center anywhere, I can solve it using pF qU' pF' qU. Four-move commutators are fast! However, I can't just do that randomly, but instead, I have to do it so that the center moves into a place on the white center that didn't have a solved center already. To check if there is room I do qU' qU, and if there isn't, I rotate the white center and repeat as necessary. You'll see this type of checking often as I continue. Note that this requires centers to be adjacent, and since we're solving from all five, we have to swap two adjacent centers. On the 5x5x5 the algorithm for this is 2R U2 2R' 2L' U2 2L U 3R U' 3R', which you then have to properly undo later.

4) Clean the second center. I used yellow. This is the same idea as the first center - hold yellow on U (so, white on D) and proceed row by row. However, instead of using pR' moves to move a row onto the F face, I used pR U2 pR' moves. This does solve the layers in a different order, but that's okay. For the middle layer I used U pR U' pR'. Each center on yellow again corresponds to 5 stickers (any yellow piece in one of those 5 places means that piece gets solved), and I think roughly 67% of the center ends up solved after this.

5) Finish the second center. Again I swap yellow with another center, so I can hold yellow on F, white on U, and the solved center on R. The commutator this time is pF2 qU' pF2 qU (or pF2 qU pF2 qU' for the mirror). Since I can't just do x rotations and keep going, I have to do some extra center swaps to bring each of the four non-white/yellow centers into the right place. There was also plenty of the qU' qU moves to check if there's room to put a piece.

6) Clean the third center. I used orange (for visibility). Place orange on U and white/yellow on L/R. Now we can do pU2 moves but not pU moves. So I do something like the white center cleaning, where I do pU2 moves to move orange centers out of the way, then a qR' move to bring the row down, then do more pU2 moves to solve as many orange centers as possible, then a qR move. A typical row clean might look something like (2U2 4U2 7U2 ...) 3R' y2 (2U2 3U2 4U2 ...) y2 3R. Each center on orange corresponds to only 3 stickers, solving about 57% of the center.

7) Solve the third center. This is just like what I do on yellow, with the pF2 qU' pF2 qU moves, since they keep U and D solved, and again I use plenty of qU' qU moves. In fact, there are fewer center swaps than last time, since the D center can stay where it is.

8) Clean the fourth center. As a general rule you want this to be adjacent to the third center, so I chose green (since it was brighter). Unfortunately the cleaning setup I use only really lets us clean a center opposite of the third one, so we place orange on D and green on F, then swap F and U, and begin. The cleaning itself is just like the third center except, again, we use pR U2 pR' rather than pR'. Each center on green corresponds to 3 stickers, solving about 70% of the center.

9) Solve the fourth center. Things got pretty messy here and it took a lot longer than I expected; most of that was probably because I can't use 4-move commutators any more and thus had to switch to 8-move ones. I held green on F and orange on D, and then did commutators like [pU2, qR U qR']. In fact I did all of the pU2 moves ahead of time, so that for each row I could immediately do a qR move for each piece I wanted to solve (using pU2 pu2 to check), and then solve many piece in that row at once. The problem, apart from the large number of qR moves, is that I couldn't stray too far from U, because I had to do U turns. So I ended up having to stay on the top half of F, and doing a lot of F and B moves to be able to solve things. Oh yeah, and once I got rid of all the green pieces on B, I had to swap U and B and do it again.

10) Solve the last two centers. No cleaning here - I couldn't see any way to quickly solve most of the center. I held the two centers on F and R, and solved one vertical row of R at a time. The commutator looks something like [pU', R' qU' R]. Basically, I would do a pU' for every center in that row that I could solve, then do the R' qU' R, undo the pU moves, and finish the commutator. Then rotate F and go again - in at most 4 separate block commutators I would solve all pieces in that row. (With one caveat - if the x-center closer to D is unsolved, this commutator won't work on it. When that happened I had to do it individually.) After each finished row I did a qF2 move to get it out of the way and make the next row easy to see; since I had blue on R, I ended up with a whole bunch of green rows on that face. Since I had to be in view of the F-R edge to do R tuns, I only did the first half of the blue face before undoing all those green rows, turning that center by 180 degrees, and doing it again. 

And that's it! It might sound kind of complicated, but each step is pretty straightforward once you know what's going on, and I spent the vast majority of my time doing the same kind of thing over and over. The low move/piece count was mostly due to the cleaning stages, where I could solve a ton of pieces in one or two moves each. Those stages would have an absurdly low movecount in axial turn metric / snyder metric, with something like 400 moves solving 5000+ pieces. And in fact, you can do a cleaning stage on the same center more than once - just turn the center to a different orientation and continue. With four of these cleaning stages you should be able to solve every piece on the affected centers. I didn't do this because the returns do diminish, and so I don't think it's worth it to clean more than once for any individual center. Maybe for the fourth center it's worth it though!


----------



## Brest (May 20, 2013)




----------



## That70sShowDude (May 20, 2013)

o____________________________________________________________O


----------



## Andreaillest (May 20, 2013)

¿¿¿wat???


----------



## Blake4512 (May 20, 2013)

oh. my. god.


----------



## Christopher Mowla (May 20, 2013)

No one messes with Mr. Gottlieb! Epic. I nominate qqwref the craziest (in a good way) member of the year.


----------



## uniacto (May 20, 2013)

will you be reconstructing this solve any time soon?


----------



## qqwref (May 20, 2013)

Thanks everyone!

@uniacto: Nope


----------



## Owen (May 20, 2013)

Incredible.
This must be discouraging to that guy in the middle of a 105x105 solve..


----------



## Rubiksfreak (May 20, 2013)

Based on the world record for 3x3, if you were moving at high speeds to complete this cube it would take around 1220 hrs and that's at world record speeds. Are you sure you completed it in only 29 hrs?

Sent from my LG-L38C using Tapatalk 2


----------



## qqwref (May 20, 2013)

A 3x3x3 has 20 pieces, so the WR spent ~0.28 seconds per piece. This one had 1.48. Admittedly, by my standards on other large cubes, that IS pretty darn fast. I think it had to do with lots of block commutators (with low moves per piece, but some overhead per row) as opposed to the large number of 4- and 8-move commutators I normally do.

EDIT: Also I'd like to point out that if this took 1220 hours I couldn't exactly have started on May 9th  Even including non-solving time, I only spent ~247 hours working on this.


----------



## AvGalen (May 20, 2013)

Dedication, brains and years of computersolving experience put together. Interesting read about the cleanup phase.
But I think you avoided doing a 112x112x112 because the secret parity on that is too much for you


----------



## Iggy (May 20, 2013)

Woahh... that's awesome. Great job. :tu


----------



## wrathofgods54 (May 20, 2013)

wow gratz


----------



## Dene (May 20, 2013)

ucrazy >.<


----------



## ben1996123 (May 20, 2013)

yae you finished it sub30 

also, soup has done 20 hours of his 105x105 solve... hes half way through the first centre


----------



## BaconCuber (May 20, 2013)

Um...um...um...*stares at screen with mouth open in shock*


----------



## soup (May 20, 2013)

I hereby quit my 105x105 solve. 120x120 now.


----------



## uniacto (May 20, 2013)

soup said:


> I hereby quit my 105x105 solve. 120x120 now.



but that's 20 hours of your life wasted!


----------



## Owen (May 20, 2013)

Now it's on.


----------



## soup (May 20, 2013)

uniacto said:


> but that's 20 hours of your life wasted!



It's no longer a record, so it's meaningless. I didn't think anyone was going to make a serious attempt, so I was pushing it off. Now that qq did his 111, I'll have to go for either 115 or 120.

Also, grats to qq on this amazing feat.


----------



## etshy (May 20, 2013)

Very very impressive , congrats


----------



## cmhardw (May 20, 2013)

Congratulations Michael, that's very impressive! I find your cleaning then solving approach really creative and fascinating! I also find it neat that you do a cage approach for bigger cubes, and your seconds per piece solved and sustained turns per second rate are very impressive! I dare say you are still the King of computer cubes


----------



## cubernya (May 21, 2013)

Michael, this is insane. I have no idea how you do this, let alone so fast. As Chris said, you are definitely the King of computer cubes


----------



## qqwref (May 21, 2013)

As far as I can tell, here's a history of largest computer cube solves ever:

2x2x2 - January 12, 2000, by David Barr, in 35.600
3x3x3 - January 12, 2000, by David Barr, in 1:23.600
4x4x4 - January 12, 2000, by David Barr, in 5:52.460
5x5x5 - January 12, 2000, by David Barr, in 9:20.180
6x6x6 - January 13, 2000, by David Barr, in 16:42.830
7x7x7 - January 21, 2000, by David Barr, in 23:33.450
11x11x11 - March 12, 2000, by David Barr, in 1:20:15.566
11x11x11 - June 12, 2000, by Chris Hardwick, in 56:32.298
11x11x11 - February 20, 2001, by fl, in 5:24:40.242
11x11x11 - April 11, 2001, by fl, in 6:57:35.728
11x11x11 - May 25, 2001, by fl, in 2:23:04.975
11x11x11 - May 31, 2001, by vfr, in 1:36:03.768
20x20x20 - June 12, 2001, by Chris Hardwick, in 4:24:54 (solving time) or 8:13:56 (total time)
20x20x20 - March 16, 2002, by Richard Carr, in 3:53:39.573
20x20x20 - June 25, 2002, by Richard Carr, in 3:05:27.722
20x20x20 - September 7, 2002, by Richard Carr, in 2:46:48.822
21x21x21 - October 28, 2002, by Grant Tregay, in 72:38:11.378
31x31x31 - January 1, 2003, by Richard Carr, in 7:43:15.493
35x35x35 - October 1, 2003, by Joe Allen, in 103:26:10.140
39x39x39 - October 8, 2003, by Joe Allen, in 113:48:13.052
40x40x40 - February 17, 2004, by Chris Moyer-Grice, in 23:35:xx (solving time)
55x55x55 - March 18, 2004, by Joe Allen, in 23:00:24 (solving time)
100x100x100 - December 20, 2008, by Ravi Fernando and Peter Greenwood, in 820:13:11.220
111x111x111 - May 19, 2013, by Michael Gottlieb, in 29:51:02.641 (solving time) or 246:48:xx (total time)


----------



## ben1996123 (May 21, 2013)

qqwref said:


> As far as I can tell, here's a history of largest computer cube solves ever:
> 
> 100x100x100 - 820:13:11.220
> 111x111x111 - 29:51:02.641



yeah wtf


----------



## Christopher Mowla (May 21, 2013)

qqwref said:


> 100x100x100 - December 20, 2008, by Ravi Fernando and Peter Greenwood, in 820:13:11.220
> 111x111x111 - May 19, 2013, by Michael Gottlieb, in 29:51:02.641 (solving time)


I agree, Ben. Maybe this track is more appropriate. Not only did Michael solve the 111x111x111 amazingly fast, he also programmed a cuboid simulator software that might really be the best virtual cuboid software to solve big cubes the fastest. Unbelievable. I usually don't cry, but listening to this track and thinking of Michael's amazing time for such a large cube just made me look at the human potential in a whole new light and I shed a few tears of excitement.:tu:tu

People have been jealous before. How about now?


----------



## qqwref (May 21, 2013)

ben1996123 said:


> yeah wtf


Well, the 820 hour time is realtime, so really you should be comparing it with my ~247 hours. I'm not sure how much solve time Ravi and Peter's solve took, as their website is down


----------



## soup (May 21, 2013)

cmowla said:


> People have been jealous before. How about now?



*raises hand*


----------



## Adrian0 (Jul 4, 2013)

Do you have those replay files? The link is now broken. Thanks.


----------



## qqwref (Jul 4, 2013)

Try this: http://www.speedyshare.com/ECpD9/111.rar


----------



## Frubix (Jul 4, 2013)

uniacto said:


> will you be reconstructing this solve any time soon?



He can't reconstruct someting that is this big and that took so long?


----------

