Tutorial de Kociemba — resolución casi óptima
Qué es esto
Esta página asume que ya puedes resolver con CFOP (o cualquier método de velocidad) — conoces caras / aristas / esquinas / capas y puedes leer notación como R U R′.
Kociemba no es un método humano — es un algoritmo de resolución por computadora: dale cualquier mezcla y encuentra una solución de ~20 movimientos en decenas de milisegundos. Un humano resolviendo el mismo cubo suele tardar 50+ movimientos.
Esta página cubre dos cosas: cómo llega la máquina a ese conteo de movimientos sorprendentemente bajo (reducción en dos fases), y por qué 20 es el techo (número de Dios).
Esto no es un método que puedas «aprender y ejecutar a mano» — no hay conjunto de algoritmos que memorizar, ni reconocimiento de casos. Es una página conceptual para entender cómo una computadora resuelve un cubo de forma casi óptima.
El techo y la brecha
El número de Dios = 20. Es un límite estricto demostrado matemáticamente: cualquier cubo 3×3 mezclado puede resolverse en 20 movimientos o menos — ningún estado necesita 21.
Lo que hace asombroso al 20 es el contraste: tú resuelves ese mismo cubo con CFOP en 50–60 movimientos. Los métodos humanos quedan casi al doble de distancia del óptimo.
¿De dónde viene la brecha? Los humanos reconocemos — detectamos un conjunto finito de casos (los 57 OLL y 21 PLL de CFOP) y aplicamos un algoritmo memorizado; el conteo de movimientos está limitado por «cuántos casos caben en tu memoria». La máquina no está atada a eso: busca en una tabla precalculada que cubre decenas de miles de millones de estados, consultando directamente un camino hacia una solución corta. El reconocimiento tiene techo; la búsqueda (casi) no.
Cómo llega la máquina
La ventaja de la máquina no es «un movimiento más listo en cada paso» — es la reducción del problema. Divide la resolución en dos fases: la Fase 1 (reducción) arroja el cubo a una forma restringida especial — el subgrupo G1; la Fase 2 (resolución) termina dentro de ese espacio mucho más pequeño. Las soluciones son inherentemente más cortas en G1, porque hay menos movimientos disponibles. Cada fase corre su propia búsqueda; juntas promedian unos 22 movimientos, rara vez por encima de 25. La demo de abajo lo pone en escena — observa el divisor Fase 1 / Fase 2 en la tira de movimientos: ahí es exactamente donde la máquina cambia de estrategia.
¿Por qué dos fases, en vez de buscar de punta a punta? Porque encontrar la solución globalmente más corta implica buscar todo el espacio de estados del cubo — un espacio demasiado vasto para buscarlo directamente. Dividir en dos fases encoge cada búsqueda a un tamaño que una tabla precalculada resuelve en milisegundos. La reducción compra computabilidad — esa es la razón de existir del algoritmo.
Detalles formales (para curiosos)
Conjunto de movimientos de G1: dentro del subgrupo G1 solo se necesitan {U, D, R2, L2, F2, B2} — U/D pueden girar libremente, pero R/L/F/B se limitan a medios giros. Esta es la formulación formal de «por qué las soluciones son más cortas en G1»: menos opciones, más soluciones cortas al alcance de la búsqueda.
Qué reduce la Fase 1: la Fase 1 lleva tres coordenadas a cero simultáneamente — orientación de esquinas twist(3⁷ = 2187) × orientación de aristas flip(2¹¹ = 2048) × posición de las aristas de la rebanada E UD-slice(C(12,4) = 495). Su producto ≈ 2.2 mil millones — el espacio de búsqueda de coordenadas de la Fase 1.
|G1| (orden del subgrupo): el subgrupo reducido contiene unos 1.95 × 10¹⁰ (~19 500 millones) de estados — unas nueve órdenes de magnitud menos que el espacio completo (~4.3 × 10¹⁹). Ese es el beneficio cuantificado de la reducción.
Por qué casi óptimo: cada fase usa una tabla de poda precalculada más búsqueda IDA* (A* de profundización iterativa). La tabla guarda «al menos cuántos movimientos hasta la meta», permitiendo que la búsqueda pode agresivamente las ramas malas — la clave para resolver un cubo en decenas de milisegundos. Dos fases no garantizan optimalidad global, pero en la práctica quedan extremadamente cerca.
Número de Dios = 20, en contexto: esto es en la métrica de medio giro (un medio giro cuenta como 1). El límite inferior = 20 se estableció temprano — posiciones como el superflip necesitan exactamente 20; el límite superior = 20 fue confirmado en 2010 por Rokicki et al. mediante enumeración por computadora (cada estado está a ≤20 movimientos del resuelto). Los límites coinciden, así que el número de Dios queda fijado en 20.
Los 15 años de hueco del número de Dios: el límite inferior de 20 quedó fijado temprano por el superflip (~1995), pero el límite superior fue bajando despacio desde Thistlethwaite (1981) hasta que Rokicki et al. finalmente lo apretaron a 20 en 2010 con cómputo masivo. Probar que «ningún estado necesita más de 20 movimientos» fue mucho más difícil de lo esperado — una historia que vale la pena leer completa.
Hacia dónde seguir
Acabas de ver el «techo» teórico — pero la teoría no te hace más rápido. Volver a CFOP, entrenar F2L y afinar el reconocimiento es lo que de verdad baja tu conteo de movimientos.
Para ir más profundo: la historia completa del número de Dios — ese hueco de 15 años, el superflip, el sprint computacional de 2010 — es la siguiente lectura natural; más allá, los solvers óptimos (garantizan ≤20 movimientos) y la teoría de grupos formal del cubo. Cada uno merece su propia inmersión.