Reconstruir de forma idéntica los tableros estrictos de 460 de la comunidad y descubrir, de paso, la jugada que los solucionadores corrientes no saben hacer: pagar dos desajustes en una misma celda.
Reproducircon semilla — se reproduce con la semilla indicada·relanza la búsqueda (Ver más abajo)·Presupuesto: not logged (exploratory run, not the standardized single-core bench)
Complejidad
Tiempo
DFS with an exact 14-cell tail; 8 threads, 5 s restart cadence, per-witness budget
Espacio
bounded by the DFS frontier plus the fixed frame and the witness schedule
Backtracking search is exponential in the worst case; the exact tail and the witness schedule tame it to a targeted replay rather than a blind hunt.
Hardware y ejecución
Ejecución nativaSolo CPU
Núcleos
8
RAM
16 GiB
GPU
0
CPU
Apple M1
Máquina
MacBook (Apple M1, 8 cores)
Presupuesto
not logged (exploratory run, not the standardized single-core bench)
REPLAY cierra el estudio con una
forma de aprendizaje distinta. Cada experimento anterior extraía una estadística del
corpus completo; REPLAY aprende de un solo tablero, y aprende justo lo que una
estadística no puede mostrar: la jugada exacta que un récord empleó y que nuestra
búsqueda no sabía hacer. Los tableros públicos totalmente pistados que sirvieron de
patrón a este proyecto llegan a 460 (el récord comunitario ha avanzado desde entonces
hasta 464), pero la propia búsqueda con roturas permitidas de este proyecto se estancaba
en 457 o 458, pasara lo que pasara. REPLAY se propuso reproducir esos tableros de 460 de
forma idéntica, pieza a pieza, para aprender qué hacían que nuestra búsqueda no sabía
hacer. La respuesta resultó ser una única jugada que había pasado inadvertida.
Una búsqueda con roturas permitidas normalmente deja que una celda cargue como mucho un
desajuste al colocarse. REPLAY relaja esa regla para admitir dos en ciertas celdas y
reordena cómo se clasifican los emplazamientos candidatos, de modo que las jugadas que
un buen tablero conocido usó de verdad pasan por delante de las que parecen más baratas.
Con esos dos cambios puede recorrer el mismo camino que tomó el tablero testigo.
Reproducidos de esta manera, los tableros de 460 de la comunidad se reconstruyen de
forma idéntica, cada pieza en su sitio, y la puntuación cuadra. La reproducción es la
prueba de que el ingrediente que faltaba era real.
▶Interactivo: las celdas de doble roturaExplorar →
Cargando…
▶Interactivo: reproducir la programación de roturasExplorar →
Encuentra las celdas de doble defecto en un tablero real
Elige un tablero récord. Lo puntuamos en vivo, localizamos cada arista no coincidente y marcamos las celdas que arrastran dos defectos a la vez. Un solucionador que solo admite un defecto por celda —casi todos— es literalmente incapaz de colocar estas celdas, así que se estanca unos puntos por debajo. Ese es el movimiento que REPLAY tuvo que añadir para reproducir con exactitud los tableros de la comunidad.
463 / 480
24 celdas rotas
9 celdas de doble defecto
celda de doble defecto (dos defectos)el resto del tablero encaja a la perfección
Las celdas de doble defecto se calculan aquí a partir de las propias aristas del tablero (la misma regla de aristas coincidentes que usan el motor y la clasificación de Bucas), no se colocan a mano. Abre el tablero en el visor para inspeccionar cada arista. En los tableros strict-460 de la comunidad hay entre 4 y 5 de estas celdas; el orden prior-over-cost de REPLAY junto con un operador de defecto de coste 2 es lo que las hace alcanzables.
Ambos tableros estrictos de 460 de la comunidad se reproducen exactamente hasta 460. El
hallazgo: cada uno contiene cuatro o cinco celdas que pagan dos desajustes a la vez. Una
búsqueda que solo permite un desajuste por celda literalmente no puede alcanzar esos
tableros, y eso es exactamente por lo que las ejecuciones anteriores del proyecto se
saturaban en 457 a 458. Permitir la doble rotura eleva la escala estricta hasta 460.
Es una explicación nítida de un estancamiento de larga data y una advertencia: una regla
de apariencia razonable (una rotura por celda) vedaba en silencio el acceso a los mismos
tableros que perseguíamos.
La reproducción es una búsqueda en profundidad ejecutada en un modo deliberadamente
restringido.
Ordenación prior-sobre-coste. El DFS corriente tolerante a roturas clasifica los
emplazamientos candidatos por coste de desajuste inmediato, el más barato primero.
REPLAY invierte la prioridad a prior-sobre-coste: los candidatos que el tablero
testigo usó de verdad se clasifican por delante de los que parecen más baratos, de modo
que la búsqueda es atraída por el buen camino conocido en lugar de desviarse de él. Es
el indicador --prior-over-cost gobernado por la propia programación del tablero
testigo.
Cola exacta. Las últimas 14 celdas se resuelven de forma exacta (--exact-tail 14)
en lugar de heurística, de modo que la fase final que las ejecuciones corrientes
chapucean se cierra de forma determinista.
La relajación que importó. El presupuesto de desajustes por celda pasa de uno a dos.
Ese único cambio es lo que admite los tableros testigo en absoluto.
Ejecutados sobre un marco fijo de 460, 8 hilos, una cadencia de reinicio de 5 segundos y
un presupuesto por ejecución, ambos testigos estrictos de 460 de la comunidad se
reconstruyen pieza a pieza y la puntuación cuadra: la reproducción es la prueba de que
el ingrediente que faltaba era la doble rotura.
El hallazgo. Cada testigo contiene cuatro o cinco celdas que pagan dos desajustes a
la vez. Una búsqueda limitada a una rotura por celda no puede representar esos tableros, y
es precisamente por eso que las ejecuciones anteriores del proyecto, tolerantes a roturas,
se saturaban en 457-458. Es un resultado de completitud de búsqueda disfrazado de intento
de récord: el muro estaba en el conjunto de jugadas, no en el cómputo.
Esta está inicializada por semilla y más cerca del determinismo que los constructores
estocásticos: la reproducción DFS a partir de un marco fijo y una programación de testigo
reconstruye los tableros de 460 de forma fiable. Los objetivos que reconstruye son los
récords estrictos de 460 propios de la comunidad, de modo que los
propios tableros figuran en la cronología de récords; lo que este experimento añade es la
reproducción que los reconstruye. La reproducción necesita dos entradas más allá del
puzzle, un marco de borde y el tablero testigo de la comunidad que reconstruye; está
previsto un directorio de apoyo ejecutable que entregue ambos.
¿Permitir dos roturas por celda abre una vía hacia 461 y más allá, o solo hacia los 460
conocidos? ¿Existen tableros que necesiten una triple rotura? ¿Y se pueden predecir las
celdas de doble rotura a partir de un tablero parcial en lugar de descubrirlas por
reproducción?