It looks like Clement has done a very nice job improving my 4x4x4 solver for use with TNoodle. He has apparently updated it to try multiple solutions for a given phase (to get average solution length down), reduced memory usage and still have it produce the solutions quickly.
I do have some concerns, though, about if this solver is really a correct random-state solver. With the 4x4x4, there are a couple of issues you need to watch out for in a random-state solver.
First, the puzzle has indistinguishable pieces. Because of this, puzzle states do not have unique inverse states. Thus, I would expect that the program would pick a puzzle state at random, run the solver, then invert the solver's solution to produce a sequence that generates the chosen state when starting from the solved state. The last step of my solver uses only half-turns. Thus, I would tend to expect the scrambles produced to start with some half-turn moves. It seems that some do, while others seem to end with several half-turn moves instead. I find this puzzling.
Secondly, the solver (at least the one I made) doesn't care what orientation the cube has when solved. (The puzzle doesn't have fixed centers that can serve as a reference for the orientation of the cube.) So when the solver is done, the cube might have "red-yellow" (up-front) orientation instead of "white-green" orientation. Simply inverting the solution would produce a scramble assuming "red-yellow" starting orientation instead of the WCA standard "white-green" orientation. I believe this can result in uneven probability distribution among the elements of a symmetry-equivalence class (with some elements having probability zero). Possibly, Clement is dealing with this issue in some way, but I can't immediately tell.
Thank you, Bruce.
About your first point, I was trying to solve using hex-search (3 orientations + inverse), but I soon realized that because the centers do not form a group, you could not use the inverse position. This has already been fixed in my own repository (https://github.com/clementgallet/FiveStage444) but is not incorporated yet into the main scrambler.
About your second post, you are right. The cube can end up in several orientations, and I didn't take that into account.
Thanks for reviewing.
Great, I just wanted to be sure that the scrambler came up with a correct scramble for any chosen state before this was used for official competitions.
I note that I could have written the solver to force the orientation of the solved cube to be fixed. This would have caused some phases to have slightly more moves in the worst case. My solver was a sort of by-product of some work I did to come up with upper bounds on God's number for the 4x4x4. Because of that, I specifically opted for more flexible goal states so as to minimize the worst case number of moves in each phase.
For random state scrambler purposes, it might (but not necessarily) make sense to change the solver to force the orientation of the solved cube. I think this would especially make sense if the scrambler were intended to produce a particular cube orientation as well as a particular position. However, I am guessing what is being implemented is to simply producing a random position, but not a particular cube orientation for that position.
Clement mentioned using 3 orientations. One might wonder, if my solver is not solving to a particular cube orientation, if this would matter at all. Well, yes, it still matters. I'll give an example below using phase 1.
One of the goals of phase 1 is to orient the corners. To orient corners, my solver always places the white/yellow stickers on two opposite faces. It could be the U/D faces, the L/R faces, or the F/B faces. When Clement talks about using 3 orientations, I assume he means that in one case, it will place the red/orange stickers on opposite faces; and in another case, it will place the green/blue stickers on opposite faces. In all cases, the two faces can be any of the three possibilities.
I noticed this scrambler, and wanted to try, but it didn't work.
When I accessed http://tnoodle.tk/scramble, it displayed just
"Loading scramble interface...", and after that nothing happened anymore.
My laptop is Mac OS X 10.7 (Lion), and I tried several browsers like
Safari, Chrome, Firefox, but all of them are NG.
I also tried to download the jar file from https://github.com/cubing/tnoodle/downloads
and executed "java -jar TNoodle-0.6.9.jar". Then it displayed
and opened a browser, but the same happened as above. The version of java isINFO 10 1346256291178 net.gnehzr.tnoodle.utils.Launcher:wrapMain Re-execing with [java, -Xmx512m, -classpath, /Users/okayama/TNoodle-0.6.9.jar, net.gnehzr.tnoodle.server.TNoodleServer, -noReexec]
TNoodle-0.6.9 started
Opening http://xxx.yyy.zz.ww:8080 in browser. Pass -n to disable this!
If I explicitly accessed http://tnoodle.tk/scramble/Big%20Com...nd%201=333*fmc or$ java -version
java version "1.6.0_33"
Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-11M3720)
Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode)
http://tnoodle.tk/scramble/My%20Comp...ound%202=333*5 ,
appropriate scrambles were given.
Does anyone know why?
Just to let you know there are moves such as 3U 3D' next to each other in the 6x6 scrambler and this is not meant to be allowed, you should probably fix that. I believe 4x4 is fine.
Not sure if this has been mentioned already but at N8W8 this weekend there were 6x6 scrambles with things like 3U 3D'
EDIT: So badly ninja'd there
Thanks, this has actually been fixed already, but we haven't uploaded a new version yet. See https://github.com/cubing/tnoodle/issues/59 for details.
Bookmarks