Message #3727

From: Thomas Lehéricy <thomas.lehericy78@orange.fr>
Subject: re: [MC4D] ZZ^4 - ZZ-type method for 3^4 [1 Attachment]
Date: Mon, 19 Jun 2017 11:51:53 +0200

Congratulations for your achievement! I find 3D-ZZ beautiful, it’s great you managed to adapt it. For some time I thought there would be orientation issues which would prevent it; thank you for proving me wrong :)

As for the methods, the most used are CFOP-like methods (possibly with Petrus-like blockbuilding at the beginning), which are move-efficient but require more thinking, and methods using commutators, which are simpler but longer. There has been some tries to develop other methods; here are two of mine:

• One was inspired by Thistlethwaite’s method (http://www.ryanheise.com/cube/human_thistlethwaite_algorithm.html). The goal is to fix more and more invariants without actually placing pieces until the very end of the solve; it relies on the fact that the only configuration with all invariants fixed is the solved state.

I used it once, and beat the previous record on 3^4 by 22 moves (although I cheated at the end by using an optimal solver for 3^3); I found it extremely tedious. You can find a laconic explanation on my userpage on the wiki: http://wiki.superliminal.com/wiki/User:Thomas_Leh%C3%A9ricy#Sketch_of_my_method

• I’ve been working on a Roux adaptation, which I think is now functional. It might prove a bit simpler than CFOP, but I’m not quite sure about the move count. I’ll post a solve that uses it someday.

Thomas

> I finally cracked a ZZ variant for the 3^4, which orients the two-colour centre pieces relative to the front, back, top and kata cells. It also makes full F2L in one step, rather than as the F2L then S2L of the existing CFOP-type method documented on the wiki. I have attached a log file of a full, albeit inefficient solve using this method. (note - I used green as the bottom cell, brown as the top cell, red as the left cell, teal as the right cell, and purple, yellow, cyan and blue cells as the centre four which are oriented to, so when viewing the log use that orientation to perhaps get an understanding of the method.)

>
I will be posting a more concrete analysis and explanation of the method soon, but as of yet I only have the basic steps, which are EOSquare, F2L blocks, OLC (orient last cell) and PLC (permute last cell) (note 2 - I used RKT CFOP for the last cell, but in hindsight I should have used RKT ZZ to lower the move count.) I do not yet have an understandable way to teach the method through text, although I could show it to anyone who has a good understanding of ZZ and would be willing to talk to me for a few hours for a walkthrough solve. (if that’s you, email me at scarecrowfish@gmail.com and we can sort something out)

>
I’m very excited to progress and develop this method, and I hope that others can help and that we can finally find an efficient and quick method, which would bring together move count and speed, and which could also possibly bring in more cubers to higher dimensional puzzles as a gateway method. (I like to dream)

>
Share your thoughts with me.

>
~ Luna=._,___