Automatic F2L Pair Analysis for solver solutions

[orcube]

Automatic F2L Pair Analysis for solver solutions

I've just released a new feature for my RubiksSolverDemo: automatic pair analysis for solver solutions.

The solver can now analyze the intermediate state of the F2L slots while generating solutions, and attach labels to solutions based on the pair structures found along the way.

For each F2L slot, the analysis considers the corner together with its three corresponding F2L edges: one E-edge in the middle layer and the two D-layer edges on either side.

There are two basic states:

• Pair Block — the corner and an edge are connected as a 1x1x2 or 2x1x1 block.
• Free Pair Block — the corner and an edge can become a Pair Block with a single move.

The location is completely unrestricted. A Pair Block does not have to be in its intended F2L slot, on the U layer, or in any other particular position. If the corner and edge happen to form the required 1x1x2 or 2x1x1 structure somewhere else in the cube, it is still considered a Pair Block.

Likewise, a Free Pair Block only means that the two pieces can become such a block with one move. It does not mean that the resulting pair is necessarily in a usable F2L position.

The labels also record when a state is established and whether it is subsequently preserved:

• — Pair Block is already present before the solution starts and remains preserved
• M5 — Pair Block is established at move 5 and remains preserved afterward
• End — Pair Block is established at the final move
• — Free Pair Block is already present before the solution starts and remains preserved
• M5 — Free Pair Block is established at move 5 and remains preserved afterward
• End — Free Pair Block is established at the final move

In other words, M5 does not simply mean “a Pair Block happens to appear at move 5”; it identifies the point at which the labeled state is established, with the label representing its subsequent preservation as well.

When a Pair Block or Free Pair Block is already present before the solution starts, no move number is attached. The move number indicates the point at which the state is established during the solution.

The labels can contain the three relevant edges for a slot. For example:

BR[E: M5]

BL[DB: M5, E: M6, DL: End]

BR[DR: M8, DB: End]

FR[E: End]

FL[DL: , E: End, DF: End]

The badge colors provide another level of information. They are not simply "Pair Block found / not found":

• Green — the E-edge forms a Pair Block with the corner. The D-edge states do not change this classification.
• Yellow — the E-edge forms a Free Pair Block, but not a Pair Block. This remains yellow even if the two D-edges form Pair Blocks with the corner, producing a 2x2x1 structure.
• Blue — the E-edge is not even a Free Pair Block, while the two D-edges form Pair Blocks on both sides, producing a 2x2x1 structure.

In other words, the three colors describe different structural relationships among the corner, its E-edge, and its two D-edges, rather than simply indicating whether a pair exists.

The analysis is available for all non-pseudo solvers and trainers in the project, including Cross, XCross, XXCross, XXXCross, and the other corresponding stages.

The same analysis is available in the trainers. The labels are attached to the generated solutions, so the same information can be inspected while working with different training stages.

The trainers intentionally color only the pieces relevant to the corresponding stage. For example, the Cross trainer highlights the Cross pieces and relevant centers rather than the entire cube. This is by design.

If you want to inspect the movement of the other pieces, each solution panel also provides links to external tools such as Twizzle, alg.cubing.net, and cubedb.net, allowing the complete cube state and solution to be viewed there.

The pair-analysis labels are descriptive only. They are generated mechanically from the cube state and solution, and are not used to rank or score the solutions.

The latest version is available here: https://or18.github.io/RubiksSolverDemo/

 

[zauberwuerfelloesen]

The preservation labels raise an interesting implementation question: do you find the establishment point by scanning the state predicates backwards from the final position?

For each tracked corner–edge relation, you could record whether the pair exists after each move, then find the start of the final uninterrupted run of true values. Once the states have been evaluated, that part is linear in the sequence length. It would distinguish an early appearance from a pair that gets broken and rebuilt later.

I drew a small test trace below to illustrate the boundary. Start from a solved cube, apply R, then F F' U, tracking the original FR edge and DFR corner. Pair presence is 1, 0, 1, 1, so the preserved suffix starts at M2. The cancelling moves are intentional here: this is a test fixture, not a proposed efficient solve.

Do you evaluate preservation independently for Pair Blocks and Free Pair Blocks? In particular, how do you handle a Free Pair becoming a Pair Block later in the sequence?

Whole-cube rotations would also make a useful regression test, since they should not change the structural relationship between the tracked pieces.