CFOP and Beginner methods take too many moves

[Cosme1]

Given the input: "oooyybgwbborbbrrbrwryyrywwwooyggyggbgwwboryggbgowwoyrr", I used the CFOP method which took 106 moves to solve.

Here is the Solution:
F2, Y, L, F, U', F', L', U, F2, Y, F, R, U', R', F', U, U, F2, Y, F2, F2, Y, B, U, B', U', R, U, R', U', R, U2, R', Y, U2, B, U, B', U, U, U, U, R, U2, R', U, R, U', R', Y, B, U, B', U, F', U', F, U', F', U', F, Y, U, F', U2, F, U', R, U, R', Y, Y, L', B', L, U', R', U, R, L', B, L, U, Y, Y, Y, Y, U, Y, Y, Y, R2, Y', D', R, U', R, U, R', Y, D, R2, Y, R, U', R'

The Kociemba algorithm for example only took 21 moves and the CFOP is supposed to take around 40 to 60 moves max. I don't really understand the program but I kinda get the concept of CFOP. Could someone explain what's going on? Thanks

[JupiLogy]

Hey Cosme1, I haven't looked at this code too much myself so I'm not sure how the algorithms are implemented. After looking at the solution, all I can say is that it is not a very efficient solution!

I'm not a CFOP solver but I believe I can critique this one, and maybe explain why it takes so long. Skip to the end for the conclusion, or read along my analysis of each step. Although I tried to keep the analysis focused on the unnecessary amount of moves used, towards the end I also consider why the solver was created this way.

Analysis

ALG.CUBING reconstruction with step labels

Cross

After the first move, 2 cross pieces are already solved. An experienced solver wouldn't miss that the red cross piece could be inserted at the same time as the green piece in 3 moves, and would probably find some way to set up the blue piece as well. However, the red cross piece is ignored until after the green piece is in place, indicating that this algorithm is intended to solve one cross piece at a time.

The third cross piece takes 7 moves to be put into place, with L F U' F' L' U F2, whereas L F' L' would have solved it much faster. I believe this is because the algorithm tries to put the cross piece into a specific position on the top layer before inserting it, in a beginner-method type fashion. Even then there are many superfluous moves I can't understand whatsoever, as the second cross piece is inexplicably moved out of position and back with no beneficial effect on the remaining cross pieces.

The final cross piece is left in one of the worst possible positions, but can still be solved in just 4 moves. However this algorithm once again moves it to the top layer before inserting 1) more unnecessary moves and finally 2) the last cross piece.

Also notice that the algorithm performs several U moves in a row near the end of the cross as the final piece is to be inserted. This indicates to me that the algorithm checks if the cross piece is above the correct position after each U turn, instead of moving it directly to the correct spot.

F2L

It would take too long to analyse all of these pairs, but to start with I'll note that the easiest pair I can spot to start with is the blue orange pair, which would take 6 moves. The red green pair can be done in 8 moves (or maybe less; as I said, CFOP is not my main method). However our solver is also not so keen, starting off with a useless F2 F2. I later realised that this double F2 is the algorithm solving the last cross piece which miraculously stayed solved the entire time. I guess our solver didn't notice it sitting there. This in particular suggests to me that the algorithm insists on solving the pieces in a set order; even if other pieces are in a much nicer position.

Ignoring that, the remainder of the first pair solution is 11 moves. A decent, rational solution. In fact most of the F2L pairs are executed fairly well.

The pairs are solved one at a time in a clockwise direction, just like the cross pieces. Somehow the F2L feels more efficient than the cross, with the exception of a sequence of 4 U moves in a row (it happens to the best solvers in speedsolving settings, but surely a computer would be able to erase mistakes like that?).

Overall the F2L is okay, looking more like an actual human solve than the cross at least.

OLL/PLL

Finally, the OLL and PLL are hard to get wrong with an algorithmic solver but this solver still manages to make it weird. Rotations instead of U moves to get a good angle on OLLs do save moves, but a human solver would go for U moves as they're faster to execute. Up until now this solver has not been optimising the number of moves used, so it's odd that it might start at this point. It's perhaps even stranger that before PLL it uses a combination of rotations and U moves.

As for the actual algorithms themselves, I don't honestly know OLL or PLL so I don't know if these are standard algorithms for these cases, but I would say it's unlikely.

1. It's extremely odd for an OLL to include R, U, L and B moves.
2. Rotations are normally avoided in speedsolves, so a PLL algorithm involving 3 y rotations seems crazy to me.
   I can only assume this is the solver trying to be efficient with moves again, by using shorter algorithms with more rotations and difficult to execute moves. As I said before though, this doesn't seem to match with the excessive use of unnecessary moves up until this point.

Perhaps the intuitive parts of the solve are programmed inefficiently, and the algorithmic parts are pulling from a highly optimised FMC algorithm set. This would make sense if the program was designed simply to make a CFOPpy solution that works well in python, rather than using python to make a good CFOP solver.

Conclusion

In conclusion, this solver has produced a very long solution due to the following limitations:

1. Treating multiple moves of the same face as different moves (U U for example could be shortened to U2).
2. Solving the pieces in a set order, ignoring easy cases.
3. Very algorithmic and inefficient cross solutions.
4. Somewhat inefficient F2L solutions.

I also want to add that although this comment is criticising the program, I mean no hate or disrespect towards it or its creator. The time and effort that is required to make even a poor rubik's cube solver is high, and I appreciate this repo which is why I have been watching it for so long.

[Cosme1]

Thank you so much on this detailed description. The analysis explains the problem really well and in my case, limitations such as treating moves such as R2 as two moves can be ignored by counting it as one. However the issue such as not taking an advantage of nicer positions is a deal breaker. I can see that you forked this repo, so have you made improvements to this project that improves the current solver? If not could you recommend me a repo that makes use of the CFOP algorithm efficiently? Thanks again, you have been a big help to me.

[JupiLogy]

I sort of realised after I forked it that it's not quite what I was looking for. I also didn't quite understand what forking was at the time. I think one good addition would be a cross solver.

What were you hoping to use this for? Did you want CFOP solves that you can integrate with another Python program? There may be better tools in other languages, though really I'm not sure. Actually here is another Python project on github, although it currently only has beginners method. It was updated less than a day ago so they might be working on adding full CFOP!