MethodFinder

MethodFinder

Search infrastructure for Rubik's Cube methods.

MethodFinder explores solving methods at scale. Methods are written in a DSL, executed step-by-step through a constrained solver, turned into features, and ranked by a learned oracle so the expensive solver can focus on the most interesting candidates.

See Architecture See Demo
Representation Method DSL

Steps, constraints, groups, orientations, and cacheable phases.

Execution Solver Runner

Orientation search, subprocess orchestration, caching, and solve traces.

Search Method Ranking

Use ML to triage large method sets before full verification.

DSL first methods are structured programs
Classical solver step-level execution creates the labels
ML oracle prediction reduces brute-force pressure

Overview

The core idea is simple: evaluating methods is expensive, so MethodFinder learns to rank them before paying the full solve cost.

Why

There are far more plausible cube methods than anyone can test by hand. Repeated constrained solves quickly become the bottleneck.

Scope

This is not a neural cube solver. It works at the method level: represent, execute, score, and rank structured solving strategies.

Audience

The site is meant to be interesting to both project reviewers and cubers who care whether a generated method might actually be worth looking at.

Architecture

The interesting part is the pipeline around the solver: representation, orchestration, cached execution, dataset generation, and ranking.

Input DSL Methods

Structured step definitions.

→
Runner Method Engine

Groups, constraints, rotations, and backend orchestration.

→
Output Workspace Data

Solves, caches, features, scores.

Core DSL

Methods are files, not hardcoded classes. Steps, groups, removes, rotations, symmetry options, cache flags, and free-layer hints all live in the same representation.

Runner

A Python execution engine decomposes a method into step-level solver calls, tracks accumulated constraints, chooses orientations, and records per-step move sequences.

Scale

Parallel solve generation, memory-aware worker limits, and algorithm caching are built into the same workflow instead of being bolted on after the fact.

Solver

The backend is not one giant solve call. It is a repeated translation from method intent into concrete solver queries.

Execution

The runner builds solver input from the current step, accumulated constraints, and current state, then invokes the external kube_solver binary as a subprocess.

That makes the project feel more like orchestration infrastructure than a single ML demo script.

Details

  • Orientation search evaluates candidate symmetries before committing to a frame.
  • Quick-out checks try to skip trivial steps cheaply.
  • Cacheable phases can reuse saved algorithms before a full solve.
  • Parallel generation uses a process pool with memory-based worker limits.

Pipeline

The full loop starts with method structure, produces solver traces, and ends with a cheap ranking pass over new candidates.

01

Define

Write methods in the DSL.

02

Quantify

Extract structural features.

03

Solve

Run classical constrained evaluation.

04

Score

Turn solve behavior into a target.

05

Train

Fit the oracle on features and scores.

06

Rank

Screen new methods before verification.

DSL

A full method file makes the project easier to understand than a paragraph of abstraction. 

[METHOD: CFOP| rotation=x2]
[STEP: cross]

init_empty_cube
add_edge UF
add_edge UB
add_edge UR
add_edge UL

[GROUP: F2L | order=best_1]
  [STEP: pair_fr]
  add_edge BR
  add_corner UBR

  [STEP: pair_fl]
  add_edge BL
  add_corner UBL

  [STEP: pair_bl]
  add_edge FL
  add_corner UFL

  [STEP: pair_br]
  add_edge FR
  add_corner UFR

[END GROUP]

[STEP: oll | cache_alg=true | free_layer=D]
add_edges_orientation

[STEP: pll | cache_alg=true | free_layer=D]

add_edge FD
add_edge BD
add_edge LD
add_edge RD
add_corner DFR
add_corner DBR
add_corner DBL
add_corner DFL
[END METHOD]

Meaning

The DSL describes what must be solved, not the exact move sequence a human should execute. That lets the rest of the system treat methods as structured programs with directives, groups, and cache hints.

Oracle

The ML layer matters because it lets the system search more broadly, not because it replaces the classical solver.

Models

Linear Regression provides a simple baseline. Random Forest handles the nonlinear structure better and performed more accurately in the presented experiment.

num_steps num_groups avg_constraints_per_step symmetry_depth num_cache_alg_steps constraint_type_diversity

Results

Model MAE MAPE Max Over Max Under
Random Forest 0.000797 9.22% +0.003340 -0.006893
Linear Regression 0.001746 20.62% +0.006084 -0.013534

Demo

Solve comparison between a ML Method, Roux, and CFOP. All solutions generated with the default method solver.

Demo Slot A ML Method
-- moves

ML-selected Roux mutation. Predicted to be a strong candidate, then verified against the solver benchmark.

Raw score: 0.024752.

Demo Slot B Roux
-- moves

Traditional Roux method used as the comparison baseline.


Raw score: 0.023606.

Demo Slot C CFOP
-- moves

CFOP with best_1 F2L pair ordering. It solves more moves in this benchmark and scored lower than Roux.

Raw score: 0.019125.

Limits

The project can find efficient candidates, but that is not the same thing as proving a method is good for human speedsolving.

Humans

Recognition, ergonomics, lookahead, finger tricks, and learning burden are not fully captured by the current score.

Solver

A constrained backend can exploit large phases in ways that do not map cleanly to practical speedsolving.

Target

The oracle learns the score you define. Better targets and better features remain part of the future work.