modern FMC approaches

[bcube]

Hi,

as I understand it (as a person who never attempted to solve the cube in the fewest moves possible), the modern FMC approach roughly tries to conceptually mimic the Thistlethwaite's algorithm, namely:

Step 1 - edge orientation
Step 2 - getting into Domino state
Step 3 - getting into half-twists only state
Step 4 - finish

Inspired by this thread, I was wondering whether there has been any development in reducing the number of steps from 4 to 3 or even 2, possibly resulting in fewer moves?

I am asking about combining the earlier steps as opposed the later steps. For example by starting directly with a Domino state instead of edge orientation.

 

[tseitsei]

We have not even perfected the EO -> DR step yet. There is a "half-step" between EO and DR called "rzp" (no idea why it is called that). What you do in that step is you do usually 0-2 moves to solve a specific number of pieces to DR state. That is called DR-XcYe where X is the number of corners NOT in DR and Y is the number of edges NOT in DR.

After that you set the "unsolved" pieces to a known trigger (using <U,D,R2,L2,F2,B2> movegroup for F/B EO and U/D DR) and execute the trigger to get to DR.
Not long ago all people did was DR-4c4e (and then setup so that just R solves DR), DR-4c2e (setup to R U2 R), DR-3c2e (setup to R U R or R U' R).
But we have improved and nowadays top solvers also commonly use DR-7c8e (R U L setup), DR-8c8e (R L setuP). And sometimes even more obscure DR-XcYe cases. But we still can't directly see optimal solutions from EO->DR for all cases.
(This is also the reason why good FMC solvers check tons of different EOs. They try to find as many EOs as possible that give one of the"good" DR-XcYe cases in 5 moves or less.)

So no we are not close to combining the EO+DR steps but we are getting closer and closer to actuallly doing EO->DR in 1 step.

What people are already quite good at is "combining" the last 2 steps. Top solvers can usually find optimal (not always but often) from a given DR state. So that is already pretty optimized.

P.S. I hope this is somewhat understandable for non-FMCer. I have no idea what terms you are already familiar with. Feel free to ask more questions if anything is unclear.

 

[bcube]

I hope this is somewhat understandable for non-FMCer.

Yes.

I have no idea what terms you are already familiar with.

I was familiar with everything you said already, except for "So no we are not close to combining the EO+DR steps".

There is a "half-step" between EO and DR called "rzp" (no idea why it is called that).

Ruchy Zupełnie Przypadkowy (in Polish).

 

[bcube]

Here is a thought: instead of focusing on a 2-step method leading to DR, you can focus on a 2-step method leading to 3-color cube reduction.

Similarly to labelling EOs as good or bad based on their distance being away from a DR trigger, you can label 3-color cube reduction solution as good or bad depending whether it is in an HTR state or not. By a process of gradual elimination you can then pick a good 3-color cube reduction solution with the fewest moves. Or you could pick a longer good 3-color cube reduction solution with a fewer moves in the finishing step.

A 2-step method leading to 3-color cube reduction would require a new solving approach, and that is where you method developers/designers come in.

 

[tseitsei]

What is the advantage of this compared to current method?

We kind of already have a 3 step method: EO, DR, Finish.

And if I understand you correctly you suggest another 3 step method: 2 steps to 3-color reduction and then 3rd step to finish.
Why would this method be better than the current 3 step method?

 

[xyzzy]

Fake HTR is so much worse than real HTR (*) that effectively using 3-colour reduction for FMC just amounts to doing half turn reduction. So instead of doing 3-colour redux and gambling on the 1/6 chance of real HTR, we just try to get HTR "directly".

In practice, this is done with three steps (as in Thistlethwaite).

I've thought about genning an alg set to go from PDR (partial DR) to HTR directly, but I gave up on the idea because the move counts felt like they'd be terrible. (I didn't actually gen the algs so this is purely based on gut feel.) HTR as FMCers do it now has the huge advantage that it's very easy to check many alternative paths quickly, greatly increasing the chance of finding a short finish. This is not an easy advantage to overcome.

(*) There are exceptions (e.g. using 3c or 2c2c insertions to fix even fake HTR, or 2c2e insertions to fix odd fake HTR), but these also apply to DR already.

 

[bcube]

What is the advantage of this compared to current method?

If you haven´t seen it already, check out the second link in my original post.

Why would this method be better than the current 3 step method?

Possibly lower average move count.

Fake HTR is so much worse than real HTR (*) that effectively using 3-colour reduction for FMC just amounts to doing half turn reduction.

That´s why I am suggesting to avoid fake HTR (or rather, to label it as bad, meaning that it is immediately eliminated from further analysis/search).

So instead of doing 3-colour redux and gambling on the 1/6 chance of real HTR, we just try to get HTR "directly".

While I agree that getting to HTR directly would be the best option, I am afraid humans can´t do it with current solving approaches, if ever.

I do however believe that a 2-step method leading to 3-color cube reduction is viable for humans, there just need to be a different intermediate steps than EO/RZP/DR - which would be a subject to development.

 

[tseitsei]

If you haven´t seen it already, check out the second link in my original post.

I dont really understand computer solvers that well, sorry :/

Possibly lower average move count.

A possible problem I see here is the following:

Now we do scrambled -> DR -> solved. Top solvers avg around 22. Typical splits being about 10 move DR and 12 move finish.
Now, solvers can already find optimal from DR->solved most of the time. But they usually can't find optimal from scrambled ->DR.

And what you are suggesting is going from scrambled -> 3-color redux, which is significantly harder/longer than scrambled -> DR. (It is DR+extra reductions on top of that.) If we can't even do scrambled -> DR efficiently yet, we are even further away from being able to do scrambled -> 3-color redux.
If anything we should try to modify the steps in the other direction. Since we already CAN solve DR->solved optimally it could be possible to make that step more complicated and still be able to solve it (near) optimally and that added complication in the last step might help to make first step(s) simpler and easier to solve optimally.
I feel like you are trying to go the wrong way. Making start more complicated and ending simpler. Instead (based on what steps people can solve optimally now I think we should try the opposite. Make start simpler and accept a more difficult ending.

Of course I dont have any proof either way (obviously no one does since it hasnt been done) but I hope my reasoning makes some sense to you too.

But really where I think the potential for improvement in FMC lies in the near and semi-near future is first improving EO->DR step and then later maybe improving scrambled -> DR directly.

 

[bcube]

Now we do scrambled -> DR -> solved.

That´s how Kociemba´s algorithm works, humans are not there yet (as you were saying by "So no we are not close to combining the EO+DR steps").

And what you are suggesting is going from scrambled -> 3-color redux

Again, you seem to be missing 1 step for some reason. What I was talking about is scrambled -> unknown step -> 3-color cube reduction (pick solutions labelled as good) -> finish, while that unknown step is neither EO nor DR. In the example below you can see that the cube goes trough neither EO nor DR to get to (good) 3-color cube reduction solution in 14 moves (it is a computer generated solution but the idea is: how to get to the 14th move in 2 steps).


I hope you understand better now what I am talking about, so that I don´t need to go through the rest of your post. Yes, I understand your reasoning as it is coming from Thistlethwaite´s/Kociemba´s algorithm or their human adaptation. I am talking about a different solving approach.

 

[tseitsei]

That´s how Kociemba´s algorithm works, humans are not there yet (as you were saying by "So no we are not close to combining the EO+DR steps").

Yeah, sorry maybe I was unclear. What I meant with that is we currently do scrambles -> intermediate step (EO/rzp) -> DR. And we even struggle to do that. Now 3-color reduction is more complicated to achieve than DR so it would be even harder to do 2 steps from scramble -> 3color redux than it is to do 2 steps from scrambled -> DR.

What I was talking about is scrambled -> unknown step -> 3-color cube reduction (pick solutions labelled as good) -> finish, while that unknown step is neither EO nor DR.

Yeah I understood that but worded my previous post badly. As I said above that will be harder than scrambled -> some step -> DR since 3-color reduction has more requirements to fulfill than DR. It has to obey all the rules that DR (EO must be solve, CO must be solved and E-layer edges must be in E-layer) and more on top of that. And we are still struggling to do even scrambled -> EO -> DR optimally.

In the example below you can see that the cube goes trough neither EO nor DR to get to (good) 3-color cube reduction solution in 14 moves

It doesn't do that and it can never do that. If you take a cube that is in 3-color reduction it will also always be in DR. Additionally if you do ANY one move on that cube it will also always be in DR. So the cube will always go through DR before entering 3-color reduction. Here it just happens to be 13 move DR to 14 move 3-color reduction.

My point is that if we can't even do scrambled -> DR in 2 steps optimally yet then doing scrambled -> 3c redux in 2 steps is even further away.

 

[bcube]

I've thought about genning an alg set to go from PDR (partial DR) to HTR directly

What tool would you use for that?
Could that tool be helpful in searching for these 17 cases?
What specific cases do you mean by PDR here?
Am I assuming corretly that by HTR you mean any of all 663 552 cases here?

 

[bcube]

Here it just happens to be 13 move DR to 14 move 3-color reduction.

Our definition of DR is different then.

So the cube will always go through DR before entering 3-color reduction

I see what you mean. I meant more than 1 move between those 2 states (as you stated by "Additionally if you do ANY one move on that [solved as 3-color] cube it will also always be in DR"). In this context, the following cube goes through DR (move 14) to get to (good) 3-color cube reduction solution in 16 moves.

 

[UncleFrank]

Ruchy Zupełnie Przypadkowy (in Polish).

google translate - "Completely Random Movements"
Translate

 

[bcube]

What I was talking about is scrambled -> unknown step -> 3-color cube reduction (pick solutions labelled as good) -> finish, while that unknown step is neither EO nor DR.

An obvious time-management improvement for humans would be the following workflow: scrambled -> unknown step (label cases as good/bad) -> HTR -> finish.

 

[bcube]

I searched the forum and haven't seen this basic idea:

1. orient opposite faces
2. get into an HTR state

After step 1, three cases can happen (assuming oriented faces are top and bottom):

1. 0 misoriented edges in E-layer, i.e. a DR state
2. 2 misoriented edges in E-layer
3. 4 misoriented edges in E-layer

Now, case 3 is probably the one you want to avoid. Step 1 can be then modified to: orient opposite faces and 1 edge in E-layer.

I am wondering how good/bad is case 2 in terms of move count?

 

[bcube]

Here is a simple idea to solve the 2x2x2 cube in a few moves: adapt two-phase algorithm from a 3x3x3 cube to it.

Basically, there are 2 choices - Kociemba's and Feather's algorithm:

• Kociemba: Scrambled -> DR -> Solved (DR means getting 2 opposite colors on 2 opposite faces here)
• Feather: Scrambled -> 3-color cube reduction -> finish in at most 4 moves (on a 2x2x2 cube, this essentially means Scrambled -> HTR -> Solved)

It is good to see some development has been made for the latter approach already:

Thoughts by Levi Gibson.

 

[bcube]

Here is a state map for fixed corner at DBL position. Edges represent turns (see legend at top right), hexagons show stuff like (R2 U2)3 = identity. You can see that all 24 configurations need at most 4 half turns by finding the shortest path to the solved state.

And here is Hamiltonian circuit:

 

[bcube]

Fake HTR is so much worse than real HTR (*) that effectively using 3-colour reduction for FMC just amounts to doing half turn reduction. So instead of doing 3-colour redux and gambling on the 1/6 chance of real HTR, we just try to get HTR "directly".

I wanted to quantify a few things, here are the results:

Sadly, optimal average move count for DR to HTR is currently unknown to me.
Optimal average move count for DR to Solved is 13.58 using <U, D, R2, L2, F2, B2> and 13.53 using all 18 moves.
From the same link, optimal average move count for HTR to Solved is 9.54 using all 18 moves.

Feather´s algorithm with unlimited phase 2 length can be divided into HTR (663,552 configs) and Fake HTR. Fake HTR can be further divided into 1 swap of corners (and 1 swap of edges) and a 3-cycle of corners - in accordance with this page I will call them the Waterwheel set and the Parallel set. Optimal average move count for Waterwheel set (1,990,656 configs) is 13.32 and optimal average move count for Parallel set (1,327,104 configs) is 12.66.

Meaning that the optimal average move count of any of 3 sets (HTR set + 2 Fake HTR sets) is less than the optimal average move count for DR to Solved.

 

[Jared Burkhart]

hehehe I use CFOP and got my fewest move count of 38 hehehe