() { 201, 206, 211, 216, 221, 225, 229, 233, 237, 239 };
```
Diez breaks en total, el último desbloqueándose en la profundidad 239. Esto es lo
que hace que los [tableros récord](/es/research/records/) sean alcanzables en absoluto:
un 256 perfecto nunca se ha encontrado, pero un tablero que tolera un puñado de
desajustes tardíos es algo que un backtracker puede terminar de verdad.
Dos detalles afinan el cuadro. Primero, el presupuesto viene con una disciplina:
nunca se permite que dos breaks se toquen: cada desajuste debe quedar aislado entre
aristas apareadas. Blackwood deletrea la consecuencia él mismo: cualquier ejecución
que alcance 255 colocaciones se completa automáticamente a 256, y un tablero 469 es
equivalentemente un parcial de 249 piezas con siete huecos
([groups.io message 10051](https://groups.io/g/eternity2/message/10051)). Segundo,
la lista de diez entradas de arriba es en sí misma un reajuste: al planear el
empujón de 469 a 470, Blackwood recortó el presupuesto de breaks de once
profundidades a diez, un cambio que documentó, palanca por palanca, en su propio
plan de ajuste
([groups.io message 10076](https://groups.io/g/eternity2/message/10076)). Los puntos
de desbloqueo desplazados que esbozó en ese plan nunca se adoptaron (el código 470
publicado conserva los puntos de la era 469 y simplemente descarta el undécimo), y
ese calendario más ceñido es el que encontró el 470.
## Reinicios, aleatoriedad, y un tope de 50 000 millones de nodos
Un backtracker por recorrido de filas rara vez vuelve a subir hasta sus primeras
filas, de modo que una mala apertura puede varar una ejecución entera en una región
imposible. La respuesta de Blackwood es barata y eficaz: aleatorizar la apertura
(la primera esquina y las piezas de la fila inferior se barajan en cada intento, de
modo que dos ejecuciones nunca retrazan el mismo prefijo) y topar cada intento en
50 000 millones de nodos explorados. Alcanza el tope, abandona,
[reinicia](/es/research/build/backtracking/restarts/) con una apertura fresca, y sal a
buscar una más fértil.
## Hacerlo caber en la caché
El último ingrediente es la simpatía mecánica. Las piezas candidatas viven en
tablas de consulta por posición, y cada entrada es una estructura compacta (número
de pieza, rotación, los dos lados expuestos, un contador de breaks y un contador
heurístico) dimensionada para que el conjunto de trabajo quepa en la caché de la
CPU:
```csharp
public struct RotatedPiece
{
public ushort PieceNumber { get; set; }
public byte Rotations { get; set; }
public byte TopSide { get; set; }
public byte RightSide { get; set; }
public byte Break_Count { get; set; }
public byte Heuristic_Side_Count { get; set; }
}
```
Esta es la mitad de «rendimiento» de la historia: el mismo diseño que
[Peter McGavin](/es/research/lab/experiments/peter-mcgavin/backtracker/) llevó más tarde
a cientos de millones de colocaciones por segundo.
## De un solo 468 a una ola de récords
La historia del solucionador es tan instructiva como sus entrañas. Blackwood llegó
como un completo desconocido: su 468, el primer avance más allá del
[467 de Louis Verhaard](/es/research/lab/experiments/louis-verhaard/eii/) en doce años,
llegó a la lista de correo de segunda mano, retransmitido desde una publicación de
Reddit
([groups.io message 10032](https://groups.io/g/eternity2/message/10032)). Tres días
después liberó el código del solucionador, con heurísticas que él calculaba lo
hacían «el doble de bueno» que la ejecución del 468
([message 10037](https://groups.io/g/eternity2/message/10037)); Jef Bucas lo tenía
corriendo bajo Mono en Ubuntu casi de inmediato
([message 10038](https://groups.io/g/eternity2/message/10038)). En una semana,
Peter McGavin, ejecutándolo «en unos doscientos núcleos», alcanzó 469
([message 10045](https://groups.io/g/eternity2/message/10045)). Bucas reescribió
entonces el algoritmo en C para aproximadamente el doble de velocidad
([message 10065](https://groups.io/g/eternity2/message/10065)), una ola de nuevos
tableros 469 siguió en cuestión de semanas, y el generador de código detrás de la
reescritura se publicó como [libblackwood](https://github.com/jfbucas/libblackwood)
([message 10078](https://groups.io/g/eternity2/message/10078)). Cuando Blackwood
publicó su 470 en marzo de 2021, provino de ese mismo código público. Sus propias
palabras, al republicar el repositorio después de que hubiera pasado silenciosamente
a privado: «Es el código exacto usado para encontrar un 470»
([message 10161](https://groups.io/g/eternity2/message/10161)). Un récord, liberado
en abierto, se convirtió en una máquina de récords comunitaria.
## El estudio de parámetros de Jef: wrapper_blackwood
Todo lo anterior es *cómo* funciona el solucionador. Jef Bucas construyó
[wrapper_blackwood](https://github.com/jfbucas/wrapper_blackwood) para preguntarse
si sus números son *correctos*. El montaje es un pequeño
[experimento distribuido](/es/research/build/faster/distributed-solving/): un servidor
Python reparte trabajos por HTTP, donde cada trabajo es una variación de los
parámetros del solucionador. Los clientes (un worker por núcleo) recogen un trabajo,
generan la fuente C# a partir de plantillas con esa variación integrada, la compilan
con Mono, la ejecutan, y reportan el resultado de vuelta al servidor para su
análisis.
Dos parámetros recibieron el tratamiento:
- **Los tres colores priorizados.** Muestreando muchos conjuntos distintos de tres
patrones, y registrando hasta qué profundidad llegó el algoritmo con cada uno, su
[página de resultados](https://github.com/jfbucas/wrapper_blackwood/blob/main/doc/batch00_edge_combos_stats.html)
asocia cada combinación de un color de borde y dos colores interiores con la
profundidad que alcanzó, junto con un mapa de calor de dónde, en el tablero, la
búsqueda pasó su tiempo. Las mejores puntuaciones conocidas se concentran en dos
conjuntos de patrones distintos.
- **El calendario de cuotas.** Ejecutando muchas variaciones aleatorias del arreglo
heurístico de 256 entradas y graficando hasta dónde llegó cada una (más verde es
mejor), la curva fabricada a mano por Blackwood cae justo en el medio de la región
verde.
> **[Figure]** interactive figure. Rendered on the canonical page (link above); not shown in this markdown export.
## Lo que el ajuste manual acertó
Ese último resultado merece énfasis. Blackwood rellenó su calendario a mano: cinco
segmentos lineales, coeficientes estimados a ojo. Cuando un barrido aleatorio
exploró el vecindario a su alrededor, la línea ajustada a mano quedó de lleno en la
zona de mejor rendimiento. La conclusión de Jef, y la nuestra: los parámetros
originales eran casi óptimos. El viejo consejo se sostiene. Antes de rediseñar las
heurísticas de un solucionador récord, comprueba si su autor ya encontró el óptimo
local a mano.
> **Los propios resultados negativos de Blackwood**
>
> Blackwood llevó a cabo la misma auditoría sobre sí mismo. Después del 469 catalogó sus callejones sin salida en la lista de correo ([groups.io message 10056](https://groups.io/g/eternity2/message/10056)): eliminar cuatro colores temprano en lugar de tres (ninguna ganancia), reservar colores para el tramo final (peor), solucionadores SAT como kissat, cryptominisat y Google OR-tools (pobre), aceleración por GPU, y cachear todos los bloques 2×2 preresueltos (medido, luego descartado). Lo único que alguna vez rindió fue refinar las heurísticas mismas, con otro factor de ~2. Es la misma conclusión que el barrido de Jef, alcanzada desde el otro extremo: el calendario es la magia, no la tecnología en bruto.
## Replicar el estudio
Una salvedad sobre el estudio de parámetros, y es del propio Jef: los tamaños de
muestra detrás de estos resultados son bajos, y él no está 100% seguro de las
conclusiones. Sus notas lo dicen sin rodeos: sería bueno intentar reproducir estos
resultados, para validarlos o invalidarlos. Él ofrece sus muestras, y el arnés
[wrapper_blackwood](https://github.com/jfbucas/wrapper_blackwood) es público: apunta
unas cuantas máquinas al servidor, vuelve a ejecutar los barridos, y publica lo que
encuentres en la [lista de correo](https://groups.io/g/eternity2). Una replicación
independiente confirmaría o refutaría los hallazgos, y cualquiera de los dos
desenlaces sería una contribución real.
## Ejecutarlo aquí
El estudio de arriba audita los parámetros de Blackwood; esta última sección audita
algo distinto: lo que hace su programa publicado cuando lo construyes tú mismo y lo
sometes al puzzle real, en un solo núcleo, en mi máquina.
### De dónde vino el código
La fuente es su repositorio público,
[github.com/jblackwood345/EternityII_Solver](https://github.com/jblackwood345/EternityII_Solver),
bajo la licencia GPL-3.0. Se construye sin modificaciones en .NET 8. No se copia
aquí: la licencia y los buenos modales dicen ambos que hay que enlazarlo, no
incorporarlo, así que se clonó en un directorio temporal, se ejecutó, y solo se
conservaron los números.
### Qué se cambió para ejecutarlo
Su programa está escrito para correr sobre el total de núcleos de una máquina y para
guardar solo tableros casi completos. Para medirlo en un solo núcleo, y para ver
cualquier cosa por debajo de una resolución completa, se hicieron tres
modificaciones, cada una invitada por su propio README («cambia el número de
núcleos», «cambia la función de guardado»):
- **Un solo hilo de búsqueda.** Su constante `number_virtual_cores` vale 64 por
defecto. Su `Parallel.For(1, N)` lanza `N-1` workers, así que fijarla en 2 da
exactamente un hilo de búsqueda.
- **Una línea de progreso.** Sin modificar, en una ejecución acotada solo imprime
«Solving...». Una sola línea añadida reporta la colocación más profunda alcanzada,
de modo que una ejecución que no termina aún arroja un número.
- **Un umbral de guardado más bajo, y la fijación de pistas** para la ejecución
restringida de abajo.
### Tal como se publicó: rápido, y apuntando a la única pista que vincula
Ejecutado tal como está su código, en un solo núcleo durante 60 segundos, es rápido
y llega lejos:
- **248 / 256 piezas colocadas**, un tablero que se recalifica a **454 / 480**
aristas apareadas.
- **~18,9 millones de nodos por segundo** (un nodo es un intento de colocación).
Su programa publicado no tiene noción alguna de pistas: trata cada pieza, incluidas
las especiales, como ordinaria y maximiza las aristas apareadas en bruto. Esto es
menos un compromiso de lo que parece a primera vista, porque un tablero legal de
Eternity II tiene exactamente **una** restricción vinculante, la pista central
obligatoria (la pieza 139 en su celda central, en su orientación dada); las otras
cuatro «pistas» del puzzle eran pistas extra que soltó el creador, no requisitos. Su
célebre tablero **470** es la prueba: en el [visualizador](/viewer/) se verifica como
pistas respetadas **1 / 5**, siendo la única respetada el centro, y una es todo lo
que un tablero legal necesita. Maximizar aristas sin lógica de pistas no es un atajo
que rodee el puzzle; es una forma legítima de atacar la única que vincula.
Las últimas ocho celdas de ese tablero 454 son un callejón sin salida genuino:
ninguna disposición de las ocho piezas sobrantes las completa con aristas perfectas.
(Por diversión, entregar ese tablero a
[nuestro ALNS](/es/research/build/local-search/local-search-alns/) durante 30 segundos
rellenó las ocho y lo empujó a 462 reordenando la región.)
### Con las pistas fijadas: se atasca
Fijar las piezas de pista en sus celdas obliga al motor a respetarlas en lugar de
colocarlas donde encajen. El mismo código, las cinco pistas oficiales fijadas, 120
segundos, un solo núcleo:
- **Colocación más profunda: alrededor de 45 / 256.**
Su heurística de orden de recorrido no tiene nada a lo que agarrarse una vez que las
piezas especiales quedan fijas a mitad del tablero: se debate cerca de las filas
inferiores y nunca sube. Fijar las cinco es más estricto que lo que el puzzle exige
en rigor (solo la pista central es obligatoria), pero es la misma restricción a la
que se someten los otros motores aquí, y Blackwood aterriza muy por debajo del
[438 de la reimplementación de Verhaard](/es/research/lab/experiments/louis-verhaard/verhaard-reimpl/)
o del [204 de McGavin](/es/research/lab/experiments/peter-mcgavin/backtracker/) bajo la
misma restricción.
> **Una salvedad justa**
>
> Esta fijación de pistas es tosca: prohíbe cualquier otra pieza en las cinco celdas de pista y reserva esas piezas. Un rediseño consciente de las pistas buscaría hacia afuera a partir de las pistas en su lugar, y lo haría mejor. Así que 45 es un piso para «su código publicado con las pistas atornilladas encima», no un veredicto sobre el enfoque. Su récord 470 se encontró con este código más una gran cantidad de cómputo y suerte, no en dos minutos.
## Relacionado
- [El backtracker en C de McGavin: la historia del rendimiento, reconstruida aquí](https://eternity2.dev/es/research/lab/experiments/peter-mcgavin/backtracker/) — El backtracker en C de Peter McGavin, el más rápido de la comunidad: una receta de optimización de 2007 capitalizada durante dos décadas mediante código generado, tablas de búsqueda y trucos de contador, luego compilada en mi M1 y apuntada al puzzle real de 256 piezas, donde en un solo núcleo supera las 200 de 256 piezas a ~109M colocaciones/s.
- [El eii de Verhaard: el solucionador que ganó el único premio](https://eternity2.dev/es/research/lab/experiments/louis-verhaard/eii/) — El motor detrás del 467, la única puntuación de Eternity II jamás premiada, reconstruido a partir de los propios mensajes de Louis Verhaard en la lista de correo: poda prospectiva, órdenes de relleno en peine, deslizamiento de arista condicionado por la profundidad, un calendario de deslizamiento ajustado por cadena de Markov. Y por qué su propio binario Win32, sin código fuente, no puede compilarse ni ejecutarse en esta máquina en absoluto.
- [Benchmark mono-núcleo](https://eternity2.dev/es/research/lab/experiments/single-core-benchmark/) — Quince solucionadores, los nuestros y nuestras implementaciones de los dos backtrackers récord de la comunidad, cada uno ejecutado una vez sobre diez variantes del puzzle oficial con las esquinas fijadas, un solo núcleo, 60 segundos por ejecución. El hallazgo: el número de nodos no es la puntuación.
- [Récords y solucionadores](https://eternity2.dev/es/research/records/) — Eternity II nunca se ha resuelto, pero casi dos décadas de esfuerzo colectivo han llevado el mejor tablero a 470/480. Quién ostenta qué, cómo lo lograron y por qué algunos tableros «480» anunciados no corresponden al puzzle real.
- [Cómo buscan los solucionadores récord](https://eternity2.dev/es/research/build/solvers/) — Cómo buscan en realidad los solucionadores que ostentan los récords. Todos son, en el fondo, backtrackers en profundidad; lo que los distingue es el orden en que prueban las cosas y cómo doblan las reglas al acercarse al final.
---
# El eii de Louis Verhaard
> El eii de Louis Verhaard ganó el único premio que el puzzle llegó a pagar, pero se distribuye como un binario de Windows sin código fuente. En qué consiste su método, por qué el original no se ejecuta aquí, y dónde vive una reimplementación fiel del mismo.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/louis-verhaard/
- Actualizado: 2026-07-15
---
Esta sección trata sobre el eii de [Louis Verhaard](/es/research/people/louis-verhaard/),
el solucionador que encontró el 467 y ganó el único premio del puzzle. A diferencia
de McGavin y Blackwood, nunca publicó el código fuente, de modo que su propio programa
no puede ejecutarse aquí. Esta página deja constancia de su método y de esa carencia;
el motor ejecutable es una
[reimplementación](/es/research/lab/experiments/louis-verhaard/verhaard-reimpl/),
que vive aquí junto al método que reconstruye, atribuida a Raphaël Anjou porque
el código es suyo aunque la idea sea de Verhaard.
## Páginas de esta sección
- [El eii de Verhaard: el solucionador que ganó el único premio](https://eternity2.dev/es/research/lab/experiments/louis-verhaard/eii/) — El motor detrás del 467, la única puntuación de Eternity II jamás premiada, reconstruido a partir de los propios mensajes de Louis Verhaard en la lista de correo: poda prospectiva, órdenes de relleno en peine, deslizamiento de arista condicionado por la profundidad, un calendario de deslizamiento ajustado por cadena de Markov. Y por qué su propio binario Win32, sin código fuente, no puede compilarse ni ejecutarse en esta máquina en absoluto.
- [Reimplementación de Verhaard](https://eternity2.dev/es/research/lab/experiments/louis-verhaard/verhaard-reimpl/) — Una reimplementación desde cero del método eii de Louis Verhaard, ya que su propio binario no incluye código fuente y no se ejecuta aquí. Recocido por intercambio de composición de conjunto bajo la métrica de teselado 2×2; en el puzzle real de cinco pistas alcanza 438 de 480, en un solo núcleo.
---
# El eii de Verhaard: el solucionador que ganó el único premio
> El motor detrás del 467, la única puntuación de Eternity II jamás premiada, reconstruido a partir de los propios mensajes de Louis Verhaard en la lista de correo: poda prospectiva, órdenes de relleno en peine, deslizamiento de arista condicionado por la profundidad, un calendario de deslizamiento ajustado por cadena de Markov. Y por qué su propio binario Win32, sin código fuente, no puede compilarse ni ejecutarse en esta máquina en absoluto.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/louis-verhaard/eii/
- Actualizado: 2026-07-21
- Temas: backtracking, local-search, speed
- Fuente: Detalles del solucionador eii de Louis Verhaard (el original, solo Win32) — https://www.shortestpath.se/eii/eii_details.html
- Fuente: La publicación: «estoy atascado… mi única esperanza es la fuerza bruta» (groups.io message 5940) — https://groups.io/g/eternity2/message/5940
- Fuente: Decodificador y documentación de los entresijos publicados; el 467 hallado más de 40 veces (groups.io message 6275) — https://groups.io/g/eternity2/message/6275
- Fuente: El método revelado: deslizamiento de arista condicionado por la profundidad, puntuación limpia 247 (groups.io message 7321) — https://groups.io/g/eternity2/message/7321
- Fuente: El banco de pruebas independiente de JSA: un 467 en 82 días con el binario público (groups.io message 6687) — https://groups.io/g/eternity2/message/6687
- Fuente: El hogar duradero del solucionador: shortestpath.se/eii (groups.io message 7439) — https://groups.io/g/eternity2/message/7439
- Fuente: Verhaard sobre su método (groups.io msg 6891) — https://groups.io/g/eternity2/message/6891
---
> **De quién es este trabajo**
>
> El solucionador, llamado **eii**, y su documentación son obra de **Louis Verhaard**, alojada en su propio sitio ([shortestpath.se/eii](http://www.shortestpath.se/eii/)). La entrada ganadora se presentó a nombre de su esposa, Anna Karlsson; las propias palabras de Verhaard zanjan la cuestión del crédito: «Mi esposa presentó mi mejor solución el año pasado y ganó 10 000 dólares» ([groups.io message 7451](https://groups.io/g/eternity2/message/7451)). Esta página, redactada por [Raphaël Anjou](/es/research/people/raphael-anjou/), reconstruye la máquina a partir de los mensajes de Verhaard en la lista de correo de 2008 a 2010 y del banco de pruebas público de JSA sobre el binario publicado, y deja constancia de por qué el binario original no puede ejecutarse aquí en absoluto. El motor ejecutable es una [reimplementación](/es/research/lab/experiments/louis-verhaard/verhaard-reimpl/) aparte, archivada aquí en esta sección junto al método, atribuida a Raphaël porque ese código es suyo, no de Verhaard.
El eii de Louis Verhaard es el solucionador detrás del 467/480 que ganó el premio
de finalista de 10 000 dólares en la primera fecha de escrutinio, el único dinero
que el concurso Eternity II llegó a pagar. Esa misma puntuación se mantuvo luego
como récord durante doce años, hasta el 468 de Joshua Blackwood en 2020. Como
[el motor de Blackwood](/es/research/lab/experiments/joshua-blackwood/solver/), es en el
fondo un backtracker en profundidad con heurísticas ajustadas a mano superpuestas.
A diferencia del de Blackwood, sus entresijos nunca se publicaron como código; lo
que tenemos en su lugar es un testimonio de una calidad poco común: Verhaard
documentó él mismo las heurísticas y el orden de búsqueda, discutió el diseño en la
lista de correo en primera persona, y distribuyó un binario público que un usuario
independiente llevó por banco de pruebas hasta la mismísima puntuación del premio.
Esa ausencia de código fuente es la razón por la que, de los tres motores
comunitarios estudiados en este laboratorio, el suyo es el que no puede ejecutarse
en absoluto; la última sección dice exactamente por qué.
## La trayectoria: atascado más allá de 463, así que publícalo
La historia de origen de Verhaard desarma. Su primer programa de puntuación alta
solo colocaba piezas que encajaban a la perfección, y se estancaba en torno a 450:
cientos de parciales limpios de 248 piezas, sin salida. Solo cuando probó el
solucionador de Bob Cousins (originalmente el de Dave Clark), que encontró un 458 en
menos de un minuto, comprendió que el concurso puntuaba las *aristas concordantes*,
de modo que las colocaciones que encajan a medias también cuentan
([groups.io message 5767](https://groups.io/g/eternity2/message/5767)). Según su
propio relato, nunca se había molestado en leer las reglas; Jef Bucas seguía
señalando a los lectores esa confesión en la documentación de Verhaard en 2021
([groups.io message 10582](https://groups.io/g/eternity2/message/10582)).
A lo largo del verano de 2008 el techo públicamente visible de la comunidad era 463
([groups.io message 5688](https://groups.io/g/eternity2/message/5688)), y en un
intercambio notable Verhaard y Max confrontaron sus notas, como los únicos dos que
se sabía que habían superado lo que llamaban el «límite-del-que-no-se-habla»
([messages 5767–5787](https://groups.io/g/eternity2/message/5767)). Luego, el 22 de
septiembre de 2008, a tres meses de la primera fecha de escrutinio, Verhaard
publicó el solucionador para que cualquiera lo ejecutara en fingerboys.se: «Esto
porque estoy atascado y mi única esperanza de mejorar mi mejor puntuación es
mediante la fuerza bruta»
([message 5940](https://groups.io/g/eternity2/message/5940)). Las condiciones
reflejaban las de eternity2.net: necesitabas poseer el puzzle real, y cualquier
premio se repartiría al 50-50 entre el usuario de mayor puntuación y Verhaard. La
comunidad se convirtió en su granja de cómputo.
Funcionó. El 6 de enero de 2009 publicó un decodificador para los archivos de
salida `.eii` del solucionador, documentó los entresijos (heurísticas y orden de
búsqueda), y reveló el número que la granja había alcanzado: 467, hallado más de 40
veces por distintos usuarios
([message 6275](https://groups.io/g/eternity2/message/6275)). Nueve días más tarde
salió a la luz el anuncio de Tomy: ninguna solución completa, y un premio de
finalista de 10 000 dólares para Anna Karlsson, de Lund, por 467 de 480
([message 6337](https://groups.io/g/eternity2/message/6337)). A la lista le llevó
alrededor de una hora decodificar «Lund + 467». El resto de la historia del concurso
corresponde a [la página de historia](/es/research/community/hunt/): el silencio de
Tomy, la cobertura de prensa, las secuelas. Lo que sigue aquí es la máquina.
## Poda prospectiva contra umbrales estáticos
El bucle base es un backtracker en profundidad sobre un
[orden de relleno](/es/research/build/backtracking/fill-order/) fijo, pero que poda por
anticipación: las ramas cuya puntuación heurística cae por debajo de un umbral se
cortan antes de explorarlas. Verhaard describía sus umbrales como estáticos y
ajustados a mano: «basados sobre todo en pura conjetura y solo en una cantidad
limitada de teoría o mediciones», lentos de ajustar pero predecibles en ejecuciones
largas
([groups.io message 5771](https://groups.io/g/eternity2/message/5771), que se le cita
de vuelta en el [message 5772](https://groups.io/g/eternity2/message/5772)).
¿Para qué sirven los umbrales *en realidad*? El diseño sobre el que él y Max
convergieron en ese intercambio es la parte interesante: solo puedes influir en la
selección de piezas temprano en la búsqueda, pero lo que quieres maximizar es la
**pavabilidad de las piezas restantes** en lo profundo del relleno, en torno a las
piezas 160 a 200, donde el factor de ramificación se desploma hacia jugadas
forzadas. Así que los umbrales tempranos se ajustan, de forma semimanual, para
responder: ¿qué puntuación heurística deben alcanzar los parciales tempranos para
que los supervivientes lleven un conjunto de piezas sobrantes que aún pave bien? El
veredicto de Verhaard sobre la descripción de Max: «Creo que, después de todo,
trabajamos de una manera muy parecida»
([message 5780](https://groups.io/g/eternity2/message/5780)).
## El panel de control: dónde culmina la distribución de nodos
¿Cómo sabes que una heurística es fuerte? La medida en la que ambos se detuvieron
(propuesta por Max, adoptada por Verhaard) es dónde se sitúa el pico de la
distribución de nodos por profundidad. Una búsqueda exhaustiva sin heurística sobre
E2 pasa la mayor parte de su tiempo en torno a la profundidad 161, la cifra de
referencia de Brendan Owen
([message 6112](https://groups.io/g/eternity2/message/6112)); ambas búsquedas
heurísticas habían empujado el pico hasta justo por debajo de 170
([message 5780](https://groups.io/g/eternity2/message/5780)). Max aportó la
interpretación: un pico en 170 equivale aproximadamente a eliminar por completo un
color interior del puzzle; una «heurística asesina» que eliminara dos parecía fuera
de alcance ([message 5787](https://groups.io/g/eternity2/message/5787)).
## Búsqueda en peine: un orden de relleno para puntuaciones altas
Una búsqueda de solución completa quiere un recorrido fila por fila; una búsqueda de
puntuación alta vive más adentro del tablero, y quiere una frontera distinta. Cuando
Brendan Owen planteó exactamente esa pregunta, Verhaard reveló la forma de su
respuesta: los mejores órdenes que había encontrado se asemejan a una **búsqueda en
peine** (la mayoría de las filas recorridas horizontalmente, y luego las filas
restantes recorridas verticalmente), con la longitud del diente ligada al objetivo:
«Cuanto más baja es la puntuación a la que aspiras, más largos se vuelven los
dientes del peine»
([groups.io message 6112](https://groups.io/g/eternity2/message/6112)). Max había
convergido de forma independiente en casi la misma geometría (doce filas de
recorrido en línea, luego recorrido por columnas) y reportaba que sus puntuaciones
quedaban alrededor de una arista por debajo de «los resultados que logra el
solucionador de Louis»
([message 6126](https://groups.io/g/eternity2/message/6126)).
## Deslizamiento de arista, condicionado por la profundidad
La palanca que realmente compró el 467 es una imperfección deliberada. Preguntado
directamente al respecto un año más tarde, Verhaard fue preciso: el programa del 467
busca «normalmente», pero a ciertas profundidades permite el **deslizamiento de
arista**: colocar una pieza con una arista discordante contra un vecino ya colocado.
No construye primero un parcial limpio y luego parchea los huecos; las discordancias
están presupuestadas *dentro del descenso*, desbloqueadas a profundidades elegidas.
Y la anatomía del resultado es reveladora: la mayoría de los tableros a 467 que
examinó tenían una puntuación limpia de apenas 247, con trece aristas deslizadas
gastadas allí donde el calendario lo permitía
([groups.io message 7321](https://groups.io/g/eternity2/message/7321)). El 467
tampoco fue casualidad: lo encontró más de 50 veces
([el mismo mensaje](https://groups.io/g/eternity2/message/7321)).
La técnica en sí tiene [su propia página](/es/research/build/reduce/edge-slipping/): por
qué las discordancias programadas alcanzan tableros que una búsqueda limpia nunca
podría, y la teoría del conteo detrás del coste de cada arista concordante
adicional. Lo que corresponde aquí es la maquinaria del lado del solucionador: el
presupuesto de discordancias por profundidad es un **arreglo de deslizamiento**, una
entrada por profundidad, y es un objeto ajustado, no una conjetura.
## El optimizador del arreglo de deslizamiento: una cadena de Markov
En enero de 2009, en el hilo donde Owen extendía la
[teoría del complejo](/es/research/why/complex-theory/) para cubrir los deslizamientos,
Verhaard publicó el esbozo (con fragmentos en Java) del algoritmo que usaba para
optimizar el orden de búsqueda y el arreglo de deslizamiento de eii
([groups.io message 6423](https://groups.io/g/eternity2/message/6423)). La entrada es
un orden de búsqueda candidato más un arreglo de deslizamiento. Para cada profundidad
estima dos números a partir de ejecuciones experimentales (la teoría bastaría para
empezar, señalaba): la probabilidad de que una pieza restante tomada al azar encaje a
la perfección, y la probabilidad de que encaje con una arista deslizada. A partir de
ellos construye una cadena de Markov cuyo estado es *(profundidad, aristas deslizadas
hasta ahora)*, con transiciones para una colocación limpia y, allí donde el arreglo
de deslizamiento lo permite, para una deslizada. Ejecutar la cadena de principio a
fin da la probabilidad de llegar al fondo y el número esperado de nodos: un evaluador
en bucle cerrado, barato, para cualquier par (orden, calendario de deslizamiento),
memoizado por eficiencia. Él mismo señaló su límite: el modelo simple ignora la
paridad de los deslizamientos, de modo que se vuelve poco fiable en puntuaciones
objetivo muy altas.
El aire de familia con lo que llegó una década más tarde es difícil de pasar por
alto: los índices de ruptura de Blackwood son también un presupuesto de discordancias
condicionado por la profundidad, y su calendario de cuotas es también una curva
precomprometida, por profundidad, ajustada a mano en lugar de optimizada por cadena.
El linaje pasa por este solucionador.
## El hermano de puntuación limpia
Las mismas heurísticas impulsaban un segundo programa con una jugada de final de
partida distinta: en lugar de deslizar una arista, puede *saltarse una casilla*, es
decir, dejar una celda vacía y seguir. El nombre es suyo
([message 7321](https://groups.io/g/eternity2/message/7321)). Ese es el cazador de
puntuación limpia (sin discordancias). Con él, Verhaard rellenó 14 filas completas
más dos piezas, un parcial impecable de 226 piezas y el récord que conocía en aquel
momento ([groups.io message 6303](https://groups.io/g/eternity2/message/6303)). En un
regreso de un día en diciembre de 2009, tras estimar unos 2000 parciales de 248 por
cada 249, obtuvo tres 249 seguidos y se detuvo, situando un 250 alrededor de 4000
veces más difícil ([message 7306](https://groups.io/g/eternity2/message/7306)).
Preguntado al respecto una década más tarde, confirmó que el 249 de su sitio es
real: alrededor de una semana de cómputo en una sola máquina
([message 9890](https://groups.io/g/eternity2/message/9890)).
## La reproducción pública: 82 días hasta un 467
Como el binario era público, el 467 es el raro récord de la era del concurso con una
reproducción independiente y cuantificada. JSA ejecutó eii de forma continua en un
solo PC y registró la distribución de puntuaciones a medida que se acumulaba:
- **43 días:** 2 008 484 veces 463 · 109 195 veces 464 · 6048 veces 465 · 250 veces
466 · nada más alto
([groups.io message 6571](https://groups.io/g/eternity2/message/6571))
- **62 días:** 427 veces 466, llegando a razón de unos 5 a 6 por día, y todavía
ningún 467 ([message 6653](https://groups.io/g/eternity2/message/6653))
- **82 días:** dos 467, junto a 4 017 182 veces 463 · 227 245 veces 464 · 13 637
veces 465 · 625 veces 466
([message 6687](https://groups.io/g/eternity2/message/6687))
Ese último registro es la medición pública más nítida de la escalera exponencial de
rareza cerca de la cima: cuatro millones de 463 por cada par de 467, y un peldaño
466→467 que le llevó a una sola máquina casi tres meses. La despedida de JSA,
«Felicidades a Louis por un algoritmo bien pensado», hace también las veces de
veredicto de verificación.
## Lo que le enseñó a la comunidad
Más allá de la puntuación, eii sentó un precedente: cuando estás atascado, publica el
solucionador y deja que las máquinas de la comunidad cacen, con el reparto del premio
como contrato. El 467 lo encontraron *usuarios* de un binario publicado, más de 40
veces, antes de ganar nada. Doce años después
[Joshua Blackwood repitió el patrón](/es/research/lab/experiments/joshua-blackwood/solver/),
publicando un 468 y abriendo el código del motor pocos días después, y obtuvo la
misma recompensa: una oleada de récords comunitarios sobre su propio algoritmo. La
otra lección es metodológica y recorre toda esta página: Verhaard ajustó su
solucionador contra *modelos* en lugar de contra meras intuiciones (el panel de
control del pico de nodos, el evaluador por cadena de Markov), en una época en que
esa disciplina era rara.
## Dónde vive el código, y por qué no se ejecutará aquí
El hogar original, fingerboys.se, era el sitio de su banda; cuando la banda dejó de
mantener el sitio, el solucionador desapareció con él durante meses. En enero de 2010
Verhaard lo volvió a publicar, sin cambios, en
[shortestpath.se/eii](http://www.shortestpath.se/eii/)
([groups.io message 7439](https://groups.io/g/eternity2/message/7439)); esa dirección
sigue siendo su hogar, y la fuente de primera mano detrás de la fila del 467 en
[la tabla de récords](/es/research/records/). Una nota operativa de las preguntas y
respuestas que siguieron: el solucionador no guarda memoria de posiciones pasadas, de
modo que sus miles de tableros a 463–465 no están deduplicados
([message 7451](https://groups.io/g/eternity2/message/7451)).
Lo que «el código vive ahí» oculta es que ningún *código fuente* vive en ninguna
parte. Lo que Verhaard distribuyó es `eii-1.0-win32.zip`: un `eii.exe` de Windows, un
léeme, y algunos archivos `.bat`. Hay **cero archivos fuente**, y es solo Win32. No
se ejecuta en Apple silicon, y no hay en esta máquina ninguna capa de Windows ni de
emulación bajo la cual ejecutarlo. Su artefacto es, aquí, inejecutable, y no hay nada
suyo que recuperar y compilar. Los órdenes de relleno en peine y el calendario de
deslizamiento condicionado por la profundidad descritos más arriba se convirtieron en
canon comunitario precisamente porque se recuperaron de sus mensajes y, cuando eran
numéricos, byte a byte de las cadenas dentro de `eii.exe`, ya que ese binario es el
único registro superviviente de ellos.
Así que «ejecutar a Verhaard» siquiera significa reconstruir su método a partir de
esa documentación. Eso es lo que hace la
[reimplementación de Verhaard](/es/research/lab/experiments/louis-verhaard/verhaard-reimpl/),
y en el puzzle real de cinco pistas alcanza 438 de 480, en un solo núcleo. Ese motor
está archivado aquí junto a esta página, atribuido a Raphaël, porque es una lectura
del método de Verhaard reescrita como código de Raphaël. Nombrar esa distinción forma
parte del hallazgo: de los tres motores comunitarios estudiados aquí, el suyo es el
que no puede ejecutarse en absoluto.
## Relacionado
- [Reimplementación de Verhaard](https://eternity2.dev/es/research/lab/experiments/louis-verhaard/verhaard-reimpl/) — Una reimplementación desde cero del método eii de Louis Verhaard, ya que su propio binario no incluye código fuente y no se ejecuta aquí. Recocido por intercambio de composición de conjunto bajo la métrica de teselado 2×2; en el puzzle real de cinco pistas alcanza 438 de 480, en un solo núcleo.
- [El solucionador de Blackwood, decodificado y ejecutado aquí](https://eternity2.dev/es/research/lab/experiments/joshua-blackwood/solver/) — El backtracker récord de Joshua Blackwood, decodificado gracias a las notas de Jef Bucas (un calendario de cuotas de color y una tolerancia a desajustes en el tramo final, ajustados casi óptimamente), luego construido y ejecutado en mi M1: tal como se publicó, vuela hasta 248 de 256 piezas ignorando las pistas; fija las cinco pistas oficiales y el mismo motor se atasca cerca de 45.
- [El deslizamiento de arista](https://eternity2.dev/es/research/build/reduce/edge-slipping/) — La jugada premiada de Louis Verhaard: dejar que el backtracker coloque una pieza no concordante, pero solo a profundidades escogidas cerca del final del tablero. Cada deslizamiento permitido cuesta un punto de puntuación y multiplica de forma astronómica el número de tableros objetivo. Por eso su 467 se encontró más de cincuenta veces, y el ancestro directo de las rupturas de Blackwood.
- [Récords y solucionadores](https://eternity2.dev/es/research/records/) — Eternity II nunca se ha resuelto, pero casi dos décadas de esfuerzo colectivo han llevado el mejor tablero a 470/480. Quién ostenta qué, cómo lo lograron y por qué algunos tableros «480» anunciados no corresponden al puzzle real.
- [Cómo buscan los solucionadores récord](https://eternity2.dev/es/research/build/solvers/) — Cómo buscan en realidad los solucionadores que ostentan los récords. Todos son, en el fondo, backtrackers en profundidad; lo que los distingue es el orden en que prueban las cosas y cómo doblan las reglas al acercarse al final.
---
# Reimplementación de Verhaard
> Una reimplementación desde cero del método eii de Louis Verhaard, ya que su propio binario no incluye código fuente y no se ejecuta aquí. Recocido por intercambio de composición de conjunto bajo la métrica de teselado 2×2; en el puzzle real de cinco pistas alcanza 438 de 480, en un solo núcleo.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/louis-verhaard/verhaard-reimpl/
- Actualizado: 2026-07-21
- Temas: speed, local-search
- Reproducir: `just experiments single-core-benchmark`
- Fuente: Motor ejecutable + resultados versionados + scripts (directorio de referencia de este experimento) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/single-core-benchmark
- Fuente: Detalles del solucionador eii de Louis Verhaard (el original, solo Win32) — https://www.shortestpath.se/eii/eii_details.html
---
> **De quién es este trabajo**
>
> El **método** es [de Louis Verhaard](/es/research/lab/experiments/louis-verhaard/eii/). El **código** que aquí se presenta es una reimplementación desde cero de [Raphaël Anjou](/es/research/people/raphael-anjou/). Está archivado aquí, en la sección de Verhaard, junto al método que reconstruye, como una reconstrucción: una lectura de su método, no su programa. La firma sigue siendo la de Raphaël, porque el código es suyo; la sección es la de Verhaard, porque la idea lo es.
El eii original de Verhaard es un binario de Windows sin código fuente que
[no se ejecuta aquí](/es/research/lab/experiments/louis-verhaard/eii/). La única manera
de ejecutar su enfoque es reconstruirlo, y esto es precisamente esa reconstrucción:
el mismo motor que aparece como `verhaard` en la
[grilla](/es/research/lab/experiments/single-core-benchmark/).
## Qué reimplementa
El método documentado de Verhaard: el **recocido por intercambio de composición de
conjunto** bajo la métrica de teselado 2×2. Se elige un subconjunto interior de unas
180 piezas, se recuece su composición mediante intercambios hasta maximizar localmente
el número de subteselados 2×2 alcanzables, se colocan primero las piezas más
problemáticas y luego se busca el resto bajo ese armazón. Las constantes numéricas del
motor se recuperaron bit a bit a partir de las cadenas contenidas en `eii.exe`, ya que
ese binario es el único registro que se conserva de ellas.
Decir que se "ejecuta Verhaard" es un atajo que conviene reconocer: es una lectura de
su método, no de su código. Que esta sea la única manera de ejecutar su enfoque forma
parte del hallazgo.
## Qué logra en el puzzle real de cinco pistas
En un solo núcleo, 120 segundos, con las cinco pistas oficiales fijadas:
- **438 / 480** aristas emparejadas, un tablero **completamente colocado** (256 de 256 piezas).
- Las cinco pistas respetadas (una solución estricta de pistas), 42 aristas rotas, a unos
40 millones de nodos por segundo.
La ejecución y el tablero resultante están versionados en el
[directorio de referencia](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/single-core-benchmark)
del motor, y `just experiments single-core-benchmark` la vuelve a ejecutar, de modo que
el 438 es verificable en lugar de afirmado. Se trata de la instancia de cinco pistas, un
puzzle más difícil que las variantes con esquinas fijadas que puntúa la
[clasificación](/es/research/lab/experiments/single-core-benchmark/), donde el mismo motor
alcanza un mejor resultado de 451.
Encontró 438 en unos doce segundos y luego se estancó durante el resto del presupuesto:
un auténtico óptimo local para esa semilla y ese tiempo. Es la única de las tres
reimplementaciones comunitarias presentes aquí que resuelve bien el puzzle real de cinco
pistas, en lugar de una versión más fácil, pero las tres no miden lo mismo, así que la
comparación exige cautela.
[Blackwood](/es/research/lab/experiments/joshua-blackwood/solver/) se mide sobre la misma
base, aristas emparejadas con las pistas fijadas, y se atasca cerca de 45.
[McGavin](/es/research/lab/experiments/peter-mcgavin/backtracker/) no: su cifra es una
*profundidad* de colocación (unas 204 de 256 piezas alcanzadas), no una puntuación de
aristas emparejadas, de modo que no puede leerse en el mismo eje que el 438 de aquí, y
los dos números no son directamente comparables. Lo que las tres comparten es solo el
veredicto de que el puzzle restringido es mucho más difícil que el no restringido; los
números que sustentan ese veredicto están en escalas diferentes.
## Relacionado
- [El eii de Verhaard: el solucionador que ganó el único premio](https://eternity2.dev/es/research/lab/experiments/louis-verhaard/eii/) — El motor detrás del 467, la única puntuación de Eternity II jamás premiada, reconstruido a partir de los propios mensajes de Louis Verhaard en la lista de correo: poda prospectiva, órdenes de relleno en peine, deslizamiento de arista condicionado por la profundidad, un calendario de deslizamiento ajustado por cadena de Markov. Y por qué su propio binario Win32, sin código fuente, no puede compilarse ni ejecutarse en esta máquina en absoluto.
- [Benchmark mono-núcleo](https://eternity2.dev/es/research/lab/experiments/single-core-benchmark/) — Quince solucionadores, los nuestros y nuestras implementaciones de los dos backtrackers récord de la comunidad, cada uno ejecutado una vez sobre diez variantes del puzzle oficial con las esquinas fijadas, un solo núcleo, 60 segundos por ejecución. El hallazgo: el número de nodos no es la puntuación.
- [Búsqueda local y ALNS](https://eternity2.dev/es/research/build/local-search/local-search-alns/) — Destruir una parte del tablero, reconstruirla mejor y dejar que el algoritmo aprenda qué demoliciones rinden. La búsqueda de gran vecindario adaptativa es el pulidor más fiable de este proyecto, y la demostración más nítida del muro donde el pulido se detiene.
---
# Cómo publica el laboratorio
> El estándar editorial de este cuaderno abierto: cómo una investigación sobre Eternity II pasa de ser un trabajo no publicado a una página publicada. De qué tipo de contribución se trata, si se publica, en qué nivel y dónde reside. Un estándar común, concebido para escalar a muchos autores.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/methodology/
- Actualizado: 2026-07-21
---
Esta página es el estándar editorial que sustenta todo lo que contiene el
laboratorio. Existe para que un hallazgo llegue al lector como un objeto
redactado, y no como una nota en bruto, y para que las mismas reglas se apliquen
sin importar quién lo escriba.
## Lo que se publica, y lo que no
La regla de base sobre la que todo se apoya:
- **El trabajo no publicado no aparece aquí.** El lugar donde un investigador
conserva su trabajo en curso solo le concierne a él. Sencillamente no figura en
este repositorio. No hay ningún borrador a medias en el cuaderno publicado.
- **El trabajo publicado reside en el laboratorio.** Público, decantado, escrito
para un lector. Llegó hasta aquí tras una revisión.
La publicación se realiza mediante pull request. Un investigador abre una PR que
añade o promueve una página, y es en la revisión de esa PR donde se decide la
publicación, y en qué nivel. Nada entra en el registro público sin una PR, y es
en la PR donde un segundo lector la coteja con el estándar descrito más abajo.
Esto mantiene la revisión como algo colegiado en lugar de una barrera pesada, y
escala a muchos autores.
## Tres ejes describen cada página
Mantenerlos separados es todo el método. Es fácil difuminar «pulido»,
«reproducible» y «revisado» en una noción vaga de «terminado». No son lo mismo.
1. **Contribución:** ¿de qué tipo de resultado se trata?
2. **Nivel:** ¿hasta dónde ha llegado la revisión?
3. **Rigor y reproducibilidad:** ¿con qué firmeza se sustenta la afirmación?
Más la atribución: quién hizo qué.
## Eje 1: la contribución
No todo resultado es un solucionador, y el cuaderno dejó de fingir lo contrario.
Una página declara su contribución:
- **solucionador:** produce un tablero competitivo mediante búsqueda. Su
puntuación es un verdadero resultado de búsqueda. Solo estos ganan una fila en
la clasificación.
- **análisis:** demuestra o calcula una propiedad de un tablero existente o de la
instancia. No produce un tablero nuevo.
- **reconstrucción:** decodifica o reconstruye el trabajo conocido de la
comunidad para extraer una idea. El número es de ellos, decodificado.
- **teoría:** una propiedad matemática, una ley o una prueba de imposibilidad.
- **método:** una técnica descrita para su reutilización, no una ejecución con
puntuación.
- **medición:** un benchmark o una observación empírica sobre solucionadores o
instancias.
- **negativo:** un callejón sin salida explorado con rigor. De pleno derecho, no
una nota al pie.
- **herramienta** y **exposición:** un artefacto de software, o una explicación.
La distinción que carga el peso opone el solucionador a todo lo demás. Un
solucionador de bandas por encuentro en el medio (meet-in-the-middle) que prueba
que un final de partida es óptimo es un análisis, no un solucionador, y no tiene
cabida en un gráfico de puntuaciones aunque emita un número. Ajustar bien este
eje es lo que hace que la clasificación signifique una sola cosa.
Este eje es además una superficie de navegación: el [índice por
contribución](/es/research/lab/experiments/by-contribution/) reúne las páginas según
la etiqueta que declaran, de modo que los análisis, la teoría, las mediciones, y
los [callejones sin salida guardados como resultados negativos de pleno
derecho](/es/research/lab/experiments/by-contribution/negative/) tienen cada uno su
propio estante.
## Eje 2: el nivel
Una vez publicada, una página lleva un nivel que indica con qué firmeza ha sido
revisada:
- **Informe técnico:** público, pero la revisión solo confirmó que es sólido y
está presentado con honestidad, no que haya sido verificado de forma
independiente. La página lleva una insignia de «informe técnico», del mismo
modo que un preprint se estampa como «aún no revisado». Un estado de reposo
legítimo: no todo necesita ir más lejos.
- **Hallazgo revisado:** un segundo lector, o el mismo autor tras un periodo de
decantación, confirmó que se sostiene. Citado, tratado como casi inmutable; las
correcciones se hacen sobre el terreno, anotadas.
Dos principios se trasladan de cómo funciona la publicación científica en otros
ámbitos. El nivel está estampado en la página, de modo que el lector siempre sabe
qué tiene ante sí. Y la promoción se juega sobre el rigor, no sobre el resultado:
un método sólido que no encontró nada se publica como resultado negativo,
mientras que un resultado llamativo obtenido con un método poco sólido no se
publica.
## Eje 3: rigor y reproducibilidad
Cada página indica con qué firmeza está establecida su afirmación central
(probada, medida o conjeturada) y hasta qué punto es reejecutable. Para todo lo
cuantitativo el criterio es simple: un número solo se publica cuando su
configuración exacta y su semilla están archivadas y puede reejecutarse a partir
de la documentación. Una puntuación de benchmark sin configuración reejecutable
no se publica. Las contribuciones más baratas llevan un listón más ligero: un
resultado negativo o una explicación necesita un razonamiento sólido y límites
claramente enunciados, no un script de reproducción.
## La atribución, concebida para más autores
Las páginas de cada investigador se agrupan automáticamente en su página de
colaborador, derivadas de la firma, nunca listadas a mano. Añadir un autor
consiste en añadir una entrada al registro y escribir páginas a su nombre. Cuando
una página tiene más de una mano, un rol de colaborador ligero (quién la ejecutó,
quién la analizó, quién la validó, quién la redactó) registra el reparto, para
que el crédito se mantenga justo a medida que el laboratorio crece.
## La decisión, en resumen
Cuando un trabajo está terminado:
1. **Nombrar la contribución.** Solucionador, análisis, reconstrucción, teoría,
método, medición, negativo, herramienta o exposición.
2. **Decidir si se publica.** Se publica sobre el rigor, no sobre el
entusiasmo. Un callejón sin salida sólido se publica. Un número sin
configuración reejecutable espera.
3. **Abrir una PR en un nivel.** Informe técnico si está redactado pero aún no
verificado de forma independiente; hallazgo revisado una vez que un segundo
lector lo avala.
4. **Situarlo.** Los solucionadores y sus afines bajo los experimentos; los
resultados estructurales bajo por qué es difícil; las técnicas bajo construir
un solucionador; las mediciones entre solucionadores con los benchmarks.
5. **Llevarlo al gráfico solo si es un solucionador.**
Ese es todo el estándar. Es deliberadamente ligero, porque el propósito es elevar
el suelo de cada página sin frenar el cuaderno.
## Relacionado
- [El laboratorio](https://eternity2.dev/es/research/lab/) — El cuaderno abierto del wiki: hallazgos estructurales y experimentos de búsqueda con nombre propio, cada uno atribuido al investigador que lo llevó a cabo y reproducible desde el código fuente. Un rincón de la investigación más amplia de la comunidad.
- [Experimentos](https://eternity2.dev/es/research/lab/experiments/) — Los experimentos de búsqueda con nombre del laboratorio, una sección por investigador. Cada uno es un run real contra Eternity II con su idea, su mejor tablero y las preguntas que dejó abiertas. El cuaderno de Raphaël Anjou está aquí completo; el cuaderno queda abierto a cualquier otra persona.
- [Contribuye con tus investigaciones](https://eternity2.dev/es/research/contribute/) — Este wiki es el hogar de investigación de la comunidad, y hay sitio en él para tu trabajo. Tres formas de publicarlo, desde un mensaje en la lista de correo hasta una pull request, más el pequeño conjunto de reglas de la casa que mantiene cada página digna de confianza.
---
# El motor de Peter McGavin
> El backtracker en C que el propio Peter McGavin escribió, el solucionador en bruto más rápido que la comunidad ha medido. Obtenido de la lista de correo, compilado en un M1 y ejecutado sobre el verdadero Eternity II. Su código, su algoritmo; ejecutado y documentado aquí.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/peter-mcgavin/
- Actualizado: 2026-07-15
---
Esta sección es el propio solucionador de [Peter McGavin](/es/research/people/peter-mcgavin/):
el backtracker en C que publicó en la lista de correo y que, según las mediciones
de la comunidad, es el motor en bruto más rápido que nadie haya ejecutado. El
algoritmo y el código son suyos. Lo que se añade aquí es la ejecución: obtenido
desde las fuentes, compilado en una sola máquina y apuntado al puzzle real, con
las cifras documentadas.
## Páginas de esta sección
- [El backtracker en C de McGavin: la historia del rendimiento, reconstruida aquí](https://eternity2.dev/es/research/lab/experiments/peter-mcgavin/backtracker/) — El backtracker en C de Peter McGavin, el más rápido de la comunidad: una receta de optimización de 2007 capitalizada durante dos décadas mediante código generado, tablas de búsqueda y trucos de contador, luego compilada en mi M1 y apuntada al puzzle real de 256 piezas, donde en un solo núcleo supera las 200 de 256 piezas a ~109M colocaciones/s.
---
# El backtracker en C de McGavin: la historia del rendimiento, reconstruida aquí
> El backtracker en C de Peter McGavin, el más rápido de la comunidad: una receta de optimización de 2007 capitalizada durante dos décadas mediante código generado, tablas de búsqueda y trucos de contador, luego compilada en mi M1 y apuntada al puzzle real de 256 piezas, donde en un solo núcleo supera las 200 de 256 piezas a ~109M colocaciones/s.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/peter-mcgavin/backtracker/
- Actualizado: 2026-07-21
- Temas: speed, backtracking
- Reproducir: `fetch genbody71.zip from groups.io msg 11749; gcc -Ofast -DG then without -DG`
- Fuente: El genbody71.zip de Peter McGavin (groups.io msg 11749, la fuente original) — https://groups.io/g/eternity2/message/11749
- Fuente: La receta de optimización de Mike Field: «Brute force does not work» (groups.io message 3098, 2007) — https://groups.io/g/eternity2/message/3098
- Fuente: McGavin reencuentra el hilo de Field: «I found the old thread» (groups.io message 11338) — https://groups.io/g/eternity2/message/11338
- Fuente: El método 10×10 y las estadísticas: 180 años-núcleo (groups.io message 9688) — https://groups.io/g/eternity2/message/9688
- Fuente: El anuncio del 469: unos días en un par de centenares de núcleos (groups.io message 10045) — https://groups.io/g/eternity2/message/10045
- Fuente: Tabla de rendimiento multinúcleo, del Raspberry Pi al doble Xeon (groups.io message 11369) — https://groups.io/g/eternity2/message/11369
- Fuente: Velocidades de un solo núcleo en nueve combinaciones CPU/compilador (groups.io message 11643) — https://groups.io/g/eternity2/message/11643
- Fuente: El truco del contador y el manual del compilador (groups.io message 11751) — https://groups.io/g/eternity2/message/11751
- Fuente: 295M colocaciones/s medidas en el código de McGavin (groups.io message 11750) — https://groups.io/g/eternity2/message/11750
---
> **De quién es este trabajo**
>
> El algoritmo y el C son el motor autogenerado de **Peter McGavin** en persona, publicado en la lista de correo. Según su propio testimonio, se apoya en una receta de optimización que Mike Field publicó en 2007 ([message 3098](https://groups.io/g/eternity2/message/3098)), una deuda que reconoció en dos ocasiones ([message 11338](https://groups.io/g/eternity2/message/11338), [message 11780](https://groups.io/g/eternity2/message/11780)). Un récord queda deliberadamente excluido de esa estirpe: su 469 salió de ejecutar el [solucionador de Joshua Blackwood](/es/research/lab/experiments/joshua-blackwood/solver/), no el suyo ([message 10045](https://groups.io/g/eternity2/message/10045)). Esta página es [Raphaël Anjou](/es/research/people/raphael-anjou/) compilando y ejecutando el código de McGavin en una sola máquina y documentando lo que hizo; los únicos cambios a su fuente son los dos pequeños que se describen más abajo.
Desde finales de 2010 hasta hoy, Peter McGavin ha sido la mesa de teoría de la lista
de correo y su cronómetro. Es quien maquetó la
[teoría compleja](/es/research/why/complex-theory/) de Brendan Owen en un artículo LaTeX
([message 9188](https://groups.io/g/eternity2/message/9188)), la reimplementó
como referencia en C en 2024
([message 11197](https://groups.io/g/eternity2/message/11197)), resolvió el
[benchmark](/es/research/build/benchmarks/) abierto más difícil de la comunidad y estableció
el récord de 469 que se mantuvo hasta el 470 de Blackwood. Pero bajo todo eso corre un
proyecto más discreto, de veinte años: un simple backtracker de recorrido por filas en
C, afinado hasta contar colocaciones de piezas por cientos de millones por segundo. Esta
página recorre ese proyecto a través de sus propios números publicados (de dónde vino la
velocidad, qué reportó y qué dijo él mismo que nunca podría lograr), luego lo compila
aquí y lo apunta al puzzle real.
## La receta es de 2007, y él lo dice
En octubre de 2007, respondiendo a la pregunta «¿dónde has oído hablar de 70 millones de
piezas por segundo?», Mike Field publicó un manual completo de optimización bajo el
punzante título «Brute force does not work»
([message 3098](https://groups.io/g/eternity2/message/3098)). Sus ingredientes: una
tabla de búsqueda indexada por los colores norte y oeste de una celda, de modo que
encontrar las piezas candidatas es un único acceso a memoria; un orden de búsqueda
**fijo** explotado sin piedad (colocar una pieza solo actualiza a sus vecinas sur y
este); ningún bucle en absoluto, sino código monolítico *generado* de forma
procedimental, un bloque en línea recta por celda; estado mínimo (reconstruir la bonita
salida después, no almacenarla en la ruta crítica); los lados de una pieza empaquetados
en un solo entero; y la lectura del ensamblador generado a la caza de vaciados de
pipeline y fallos de caché L1. El código de Field se compilaba en unas 33 instrucciones
por celda y corría a 60-80 millones de colocaciones por segundo y por núcleo en un
ordenador de escritorio de 2007, con picos cercanos a los 100 millones cuando el
conjunto de trabajo se mantenía en la caché L1.
Ese mensaje es el genoma del motor de McGavin. Cuando mostró un fragmento de su «horrible
código fuente autogenerado» en 2024, se reconocía el mismo organismo: un bloque
etiquetado por celda (`cell_9_2_next:`), una tabla `LookupNW` indexada por los colores
norte y oeste, un arreglo `tileFree`, indicaciones `register` y un `goto` de vuelta al
bloque de la celda anterior al agotarse
([message 11337](https://groups.io/g/eternity2/message/11337)). Se puso a buscar el
origen minutos después y publicó el enlace: «I found the old thread»
([message 11338](https://groups.io/g/eternity2/message/11338)); en 2026 repitió la
atribución: su código C de backtracker optimizado «is based on» el mensaje de Mike de
2007 ([message 11780](https://groups.io/g/eternity2/message/11780)).
El propio Field aporta la referencia de la época. En 2011 reportó su propio backtracker a
75 millones de piezas colocadas por segundo y por núcleo en un AMD a 2 GHz, unos 26 ciclos
de reloj por pieza, con más de la mitad del tiempo detenido en espera de acceso a memoria
([message 9003](https://groups.io/g/eternity2/message/9003)). Ese número, grosso modo 40 a
80 millones por núcleo, es lo que un motor comunitario serio dio durante la década
siguiente, incluido el de McGavin.
## Lo que él añadió, en sus propias palabras
La receta era pública; la capitalización fue de McGavin. Los refinamientos que ha
descrito en la lista, más o menos en el orden en que van apareciendo:
- **Un generador de código, no un programa.** El C por celda se regenera para cada
puzzle, conjunto de pistas y
[ruta de colocación](/es/research/build/backtracking/fill-order/). Su flujo de trabajo de
2026 es un ciclo de compilar/ejecutar/compilar/ejecutar: la primera pasada reconstruye
`body.c`, el código de celda en línea recta, y la segunda compila el solucionador que
lo incorpora. Sáltese un paso tras cambiar un archivo de entrada y el programa «won't
be doing anything sensible»
([message 11751](https://groups.io/g/eternity2/message/11751),
[message 11782](https://groups.io/g/eternity2/message/11782)). En enero de 2026 publicó
el conjunto en la lista con el nombre `genbody71.zip`: 1455 líneas de `genbody.c` más un
README, compilado con `-DG` para emitir `body.c` y de nuevo sin él para construir el
solucionador que lo incluye. Su propia advertencia encabeza el README: «This is
experimental development code that evolved over several years --- not nice, elegant code
at all» ([message 11749](https://groups.io/g/eternity2/message/11749)).
- **Un contador que casi no cuesta nada.** `ntpll` («number of tile placements per second
long long», según su propia glosa) no se incrementa directamente. Un registro de 16 bits
se aumenta en cada colocación, y se suma `0x10000` al contador de 64 bits cada vez que
desborda: un vestigio de las máquinas de 32 bits, donde un incremento de 64 bits
desperdiciaba registros o tocaba RAM lenta. Cronometró ambos enfoques hace años; el
truco ganó. En las primeras máquinas de 64 bits era incluso más rápido instalar las
bibliotecas de compatibilidad de 32 bits y compilar con `gcc -m32`
([message 11751](https://groups.io/g/eternity2/message/11751)).
- **Arqueología del compilador.** Compilar con clang en lugar de gcc dio «a significant
speed boost» ([message 11330](https://groups.io/g/eternity2/message/11330)); en ARM,
clang-15 le gana a clang-19 y a gcc; añada `-march=native` y `-mtune=native`; pruebe icc
e icx; use optimización guiada por perfil
([message 11751](https://groups.io/g/eternity2/message/11751)). Nada de esto cambia la
búsqueda. Cambia cuántas búsquedas compra un euro de electricidad.
- **La ruta de colocación como una decisión medida.** El recorrido por filas es el mejor
para E2, pero la espiral hacia dentro gana en los puzzles de pistas 1 y 3, el borde
primero en los 2 y 4, y la espiral hacia fuera en las variantes sin marco; él lo
comprueba ejecutando el solucionador o consultando la teoría compleja, tras descubrirse
«poor at judging solving orders» a ojo
([message 9703](https://groups.io/g/eternity2/message/9703),
[message 9713](https://groups.io/g/eternity2/message/9713)).
## Los números, de 2007 a 2026
Cada cifra de abajo proviene del archivo, en las propias unidades de su autor.
| Cuándo | Cifra | Contexto | Fuente |
| --- | --- | --- | --- |
| 2007-10 | 60–80M colocaciones/s/núcleo, ~100M pico | Receta de Mike Field, AMD X2 3800+ | [3098](https://groups.io/g/eternity2/message/3098) |
| 2011-02 | ~38M colocaciones/s/núcleo (2300 × 10⁶/min) | McGavin contando esquinas 5x5 del 10x10 de Brendan, 4 núcleos; 8672 es su propia corrección de las unidades (colocaciones, no soluciones) | [8672](https://groups.io/g/eternity2/message/8672) |
| 2011-06 | ~50M nodos/s, un solo núcleo | AMD Phenom II, recorrido por filas, 8x8 de Brendan | [8863](https://groups.io/g/eternity2/message/8863) |
| 2011-11 | 75M/s/núcleo (~26 ciclos/pieza) | Referencia de Field, AMD a 2 GHz, detenido en memoria | [9003](https://groups.io/g/eternity2/message/9003) |
| 2013-06 | 44.6M nodos/s sostenidos | una prueba de primera fila 10x10 de 683 mil millones de nodos | [9167](https://groups.io/g/eternity2/message/9167) |
| 2014-04 | 67M colocaciones/s, un solo núcleo | Benchmark de Arnaud Carré: las 4 soluciones en menos de un minuto | [9263](https://groups.io/g/eternity2/message/9263) |
| 2024-10 | 60–140M colocaciones/s por backtracker | «depending on CPU type» | [11329](https://groups.io/g/eternity2/message/11329) |
| 2024-11 | 99M → 10,160M nodos/s por máquina | Raspberry Pi 4 (4 procesos) a doble Xeon Gold 6338 (128) | [11369](https://groups.io/g/eternity2/message/11369) |
| 2025-09 | 38–84M colocaciones/s, un solo núcleo | nueve combinaciones OS/compilador/CPU en el 8x8 de Brendan | [11643](https://groups.io/g/eternity2/message/11643) |
| 2026-01 | ~225M colocaciones/s, un solo núcleo | Orange Pi 6 Plus en puzzles pequeños; «halves on 16x16» | [11751](https://groups.io/g/eternity2/message/11751) |
| 2026-01 | 295M colocaciones/s, un solo núcleo | Joe ejecutando el código de McGavin en una CPU más reciente, frente a su propio C# a 27–37M | [11750](https://groups.io/g/eternity2/message/11750) |
| 2026-02 | 44.0M frente a 105.1M piezas/s | árbol idéntico de 2.12 billones de nodos: Phenom II de 2010 frente a Ryzen 5 5600H | [11782](https://groups.io/g/eternity2/message/11782) |
Dos lecturas de esa tabla. Primero, el titular: la cifra de ~295M/s (la que cita nuestra
[página de récords](/es/research/records/)) es real, pero es la medición de Joe, hecha en
enero de 2026 cuando McGavin compartió su fuente y Joe la ejecutó en hardware más reciente
que cualquier cosa que McGavin posea; el propio solucionador C# de Joe alcanzaba 27–37M/s
en la misma máquina, y la mejor velocidad que había visto mencionada en la lista era
70–90M/s ([message 11750](https://groups.io/g/eternity2/message/11750)). La mejor cifra del
propio McGavin son los ~225M/s del Orange Pi en puzzles pequeños
([message 11751](https://groups.io/g/eternity2/message/11751)).
Segundo, la lectura más discreta y más instructiva: la velocidad de un solo núcleo apenas
se movió durante quince años. McGavin lo dijo él mismo al publicar la tabla de 2025: las
velocidades en las CPU más recientes «are only a little faster» que en su Phenom II de
2010 ([message 11643](https://groups.io/g/eternity2/message/11643)). El motor ya estaba
cerca del muro de memoria que Field describió en 2011. Lo que realmente creció fue el
número de núcleos que podía apuntar a un problema.
## Cientos de núcleos con un presupuesto de aficionado
El capítulo de McGavin en la
[historia de la resolución distribuida](/es/research/build/faster/distributed-solving/) de la
comunidad es de un encanto doméstico. Para la campaña 10×10 empezó con una veintena de
núcleos en casa, luego añadió tres Odroid XU4 de ocho núcleos y veinticinco Orange Pi Lite
de cuatro núcleos a 12 dólares cada uno (más de 130 núcleos, cada núcleo ARM valiendo
alrededor de un tercio de la velocidad de un núcleo de PC) y, cuando se le permitía,
servidores multinúcleo en el trabajo, para un total de más de 400
([message 9688](https://groups.io/g/eternity2/message/9688)). Los Orange Pi funcionaban con
cargadores USB de 12 puertos (mató definitivamente un cargador al enchufar doce placas
ejecutando 48 backtrackers, y bajó a ocho por cargador) con red WiFi: un solo cable por
placa, para la alimentación
([message 9690](https://groups.io/g/eternity2/message/9690)). La orquestación son dos
scripts de shell: uno arranca tantos backtrackers como núcleos tenga un nodo, el otro lo
lanza en ~20 nodos por ssh, cada uno con 16 a 48 núcleos, aunque «well, they are
hyperthreads, strictly speaking»
([message 9753](https://groups.io/g/eternity2/message/9753)). En el pico, «more than 400
backtrackers running at once»
([message 9751](https://groups.io/g/eternity2/message/9751)).
## Lo que la velocidad reportó
**Los recuentos verificados, primero.** Las enumeraciones completas rápidas son lo que le
permite a la comunidad confrontar la teoría con la realidad. En 2011, una ejecución
nocturna contó 4,739,821,621,743 bloques de esquina 5×5 del 10×10 de Brendan, frente a una
estimación de la teoría compleja de 5.0077 × 10¹², «pretty close… if I do say so myself»
([message 8672](https://groups.io/g/eternity2/message/8672)). En 2014 su único núcleo
barrió el árbol del benchmark de 256 piezas de Arnaud Carré (3,979,209,754 colocaciones,
las 4 soluciones) en menos de un minuto
([message 9263](https://groups.io/g/eternity2/message/9263)). En 2026, dos máquinas
distintas recorrieron el mismo árbol de 2,120,424,701,160 nodos de un puzzle parecido a E2
y encontraron la misma única solución: el determinismo como característica, el recuento de
nodos como suma de verificación
([message 11782](https://groups.io/g/eternity2/message/11782)).
**El 10×10, por encima de todo.** El 10×10 set_1 de Brendan, un benchmark que llevaba una
década abierto, cayó en septiembre de 2017 bajo exactamente esta maquinaria: enumerar ~20
millones de primeras filas candidatas, clasificarlas por las soluciones por nodo de
búsqueda de la teoría compleja, y dejar que la granja las pruebe una por una, alrededor de
un día-núcleo cada una. La solución llegó en la prueba de fila ~92,907 de una prevista de
una entre 70,000, tras casi 2 × 10¹⁷ nodos, unos **180 años-núcleo**, menos del 0.5 % del
árbol entero
([message 9686](https://groups.io/g/eternity2/message/9686),
[message 9688](https://groups.io/g/eternity2/message/9688)), repartidos a lo largo de unos
cuatro años ([message 9804](https://groups.io/g/eternity2/message/9804)). Su resumen: «no
new methods, just systematic persistence and the law of large numbers.» La
[página de benchmarks](/es/research/build/benchmarks/) cuenta esa historia como la validación
más fuerte de la teoría compleja; aquí se yergue como el punto culminante de la historia
del rendimiento.
**Y un récord, en el motor de otro.** En septiembre de 2020, días después de que Joshua
Blackwood liberara el código de su solucionador, McGavin lo ejecutó «for a few days on
about a couple of hundred cores and hit the jackpot. New record score of 469!»
([message 10045](https://groups.io/g/eternity2/message/10045)), con estadísticas de
ejecución acordes (2832 tableros alcanzando 252 piezas, uno con 255, uno con 256:
[message 10049](https://groups.io/g/eternity2/message/10049)). Note lo que se combinó allí:
las [heurísticas de Blackwood](/es/research/lab/experiments/joshua-blackwood/solver/)
aportaron la forma de la búsqueda; la granja de McGavin aportó las colocaciones. Su propio
motor en C no ostenta ningún récord de puntuación de E2; sus 226 en recorrido por filas de
febrero de 2020 igualaron la vieja marca de colocaciones consecutivas de
[Verhaard](/es/research/lab/experiments/louis-verhaard/eii/), nada más
([message 10523](https://groups.io/g/eternity2/message/10523)).
## Lo que la velocidad no pudo comprar
McGavin es también el testigo más consistente del archivo *en contra* de la velocidad
bruta. Sus propios números arman el caso. Con el orden de recorrido por filas, la teoría
compleja sitúa el árbol de búsqueda completo de E2 en unas 1.6 × 10⁴⁷ colocaciones
([message 9710](https://groups.io/g/eternity2/message/9710)), unas 9.3 × 10⁴² por solución
esperada ([message 9713](https://groups.io/g/eternity2/message/9713)). Incluso en su mejor
ruta de colocación de 5 pistas (un árbol mucho más pequeño, unos 3.1 × 10⁴⁰ nodos) calculó
4.9 × 10³² años a 100 millones de nodos por segundo, y añadir miles de millones de núcleos
sigue dejándote «orders of magnitude longer than the age of the Universe»
([message 11201](https://groups.io/g/eternity2/message/11201)). Había sacado la conclusión
mucho antes, en 2013: «It seems clear to me that E2 will not be solved by brute force. If
it is to be solved at all, it will be by deep analysis and/or clever insight, in my
opinion» ([message 9117](https://groups.io/g/eternity2/message/9117)).
Por eso la mayor aceleración aislada que jamás reportó no fue en absoluto una aceleración.
Para las cacerías de sub-soluciones sin marco, usó la teoría compleja como una anticipación
al estilo del ajedrez: estimar las soluciones por nodo en cada hoja 13 o 14 jugadas por
delante, cachear las estadísticas repetidas y dirigirse hacia la mejor rama. Ganancia
global: un factor de alrededor de 25 a la profundidad 81
([message 9751](https://groups.io/g/eternity2/message/9751)). Ninguna opción de compilador
le dio jamás 25×. Dar forma al árbol le ganó a reducir los nanosegundos. Esa es la
[lección central](/es/research/why/prune-vs-speed/) de este sitio, reportada aquí como el
experimento de veinte años de un profesional: construyó el motor más rápido de la historia
de la comunidad, lo midió todo y concluyó que la brecha hasta 480 nunca se jugó en el
reloj.
## Ejecutándolo aquí
Todo lo anterior está sacado del archivo. El resto de esta página es ese mismo motor,
compilado en mi máquina y apuntado al puzzle real, para que la historia del rendimiento
lleve una medición de primera mano y no solo una retransmitida.
### De dónde vino el código
La fuente es `genbody.c`, adjunta como `genbody71.zip` al
[message 11749 de groups.io](https://groups.io/g/eternity2/message/11749). Son 1455 líneas
de C, con un README, un archivo de piezas y un archivo de pistas. No está copiada en este
repositorio: se queda en la lista, donde su autor la puso.
Es un programa de dos pasadas, y el README es franco sobre el estilo («dreadful C source
code ... it really needs a lot of work to clean it up»). Compilado con `-DG`, genera un
segundo archivo C, `body.c`, especializado para un puzzle. Recompilado sin `-DG`, incluye
ese archivo generado y ejecuta la búsqueda. Ese flujo de dos pasadas es exactamente el
diseño de generador de código descrito más arriba, ahora frente a mí.
### Qué se cambió para ejecutarlo
Dos cosas, ambas pequeñas:
- **Nada, para compilarlo.** Compila limpio en silicio de Apple con `clang` (una
advertencia de variable sin usar). El display de estado POSIX que usa, `setitimer` y
`termios`, funciona en macOS sin ningún adaptador.
- **El puzzle que lee.** Los nombres de archivo estaban codificados en duro hacia el
puzzle de prueba de Joe. Hice que se leyeran desde la línea de comandos para poder
alimentarlo con el Eternity II real, y escribí las piezas y pistas oficiales en su
formato `.puz` / `.hnt` a partir del archivo canónico del puzzle. Su ruta de búsqueda se
construye de forma genérica (celdas de pista primero, luego un recorrido por filas), así
que no hizo falta ningún otro cambio.
### Qué hace en el puzzle de Joe
Configurado tal como se entrega, en el puzzle de prueba 16×16 de 18 pistas de Joe, es muy
rápido y termina:
- **~279 millones de colocaciones de piezas por segundo**, un solo núcleo.
- Resuelve el puzzle hasta el final en unos 13 segundos (3.577 mil millones de colocaciones
hasta la primera solución), de forma idéntica en cada ejecución.
Ese es el número que la comunidad quiere decir con «McGavin es rápido». Es real, y es en
hardware actual, no en una máquina de siete años: justo en línea con los ~295M/s que midió
Joe, y cómodamente por encima de los ~225M/s del propio Orange Pi de McGavin.
### Qué hace en el Eternity II real
Alimentado con el puzzle real de 256 piezas, una vez solo con la pista central obligatoria
y otra vez con las cinco pistas oficiales: su solucionador solo guarda un tablero cuando
encuentra una solución **completa**, y el puzzle real nunca ha sido resuelto, así que no
guarda nada y corre sin detenerse. Lo que sí reporta, en vivo, es lo más profundo que ha
llegado a colocar:
| Puzzle | Colocación más profunda, 30 s | Ritmo | Soluciones |
| --- | --- | --- | --- |
| E2 real, 1 pista | **205 / 256** | ~108 M colocaciones/s | 0 |
| E2 real, 5 pistas | **204 / 256** | ~109 M colocaciones/s | 0 |
Dos cosas conviene decir con claridad. Primero, esto es una **profundidad** (hasta dónde
llegó la búsqueda antes de retroceder), no una puntuación de aristas sobre 480: su programa
no emite un tablero parcial para volver a puntuar. Segundo, el ritmo en el puzzle real es
de unos 109 millones de colocaciones por segundo, aproximadamente el 40 % de su velocidad
en el puzzle de Joe, porque las restricciones del puzzle real podan con más dureza. El
número de pistas apenas lo mueve: 205 con una pista, 204 con cinco. Esta es la misma
lección a la que llegan sus propios mensajes, ahora en mi propio hardware: el motor en
bruto es soberbio recorriendo un árbol y no dice nada, por sí solo, sobre dónde se esconde
un tablero de alta puntuación.
### Un solo núcleo, confirmado
El binario enlaza solo con la biblioteca del sistema, no tiene primitivas de threading en
su fuente y mantiene una CPU al 100 % (no al 800 %) con un único hilo de principio a fin.
La velocidad es la de un núcleo. Esa es la unidad justa para comparar motores, y es la que
usa el
[benchmark de un solo núcleo](/es/research/lab/experiments/single-core-benchmark/) para poner
este motor junto al
[de Blackwood](/es/research/lab/experiments/joshua-blackwood/solver/) y la
[reimplementación de Verhaard](/es/research/lab/experiments/louis-verhaard/verhaard-reimpl/).
Los tres no miden el mismo eje (el número de McGavin es una profundidad de colocación, no
una puntuación de aristas coincidentes), así que lea la comparación con cuidado.
Una posdata de primera mano sobre el propio rendimiento. Reconstruido sin pantalla (su
pantalla de terminal en vivo, resulta, le cuesta ~2,7×) y apuntado a un tablero fácil y a
uno difícil, este motor C fija el listón frente al cual se midió luego un
[backtracker de generación de código en Rust portable](/es/research/lab/experiments/raphael-anjou/jit-backtracker/)
en el mismo M1: el Rust lo iguala en tableros difíciles y profundos como el rompecabezas
real (~105–110 M cada uno) y queda ~2,3× por detrás en los fáciles y poco ramificados
(~287 M frente a ~122 M). Una calibración útil de cuánto de la ventaja de este motor es
oficio portable y cuánto es la forma del tablero sobre el que corre.
## Relacionado
- [El solucionador de Blackwood, decodificado y ejecutado aquí](https://eternity2.dev/es/research/lab/experiments/joshua-blackwood/solver/) — El backtracker récord de Joshua Blackwood, decodificado gracias a las notas de Jef Bucas (un calendario de cuotas de color y una tolerancia a desajustes en el tramo final, ajustados casi óptimamente), luego construido y ejecutado en mi M1: tal como se publicó, vuela hasta 248 de 256 piezas ignorando las pistas; fija las cinco pistas oficiales y el mismo motor se atasca cerca de 45.
- [Benchmark mono-núcleo](https://eternity2.dev/es/research/lab/experiments/single-core-benchmark/) — Quince solucionadores, los nuestros y nuestras implementaciones de los dos backtrackers récord de la comunidad, cada uno ejecutado una vez sobre diez variantes del puzzle oficial con las esquinas fijadas, un solo núcleo, 60 segundos por ejecución. El hallazgo: el número de nodos no es la puntuación.
- [La teoría compleja: contar el árbol de búsqueda antes de recorrerlo](https://eternity2.dev/es/research/why/complex-theory/) — La teoría compleja de Brendan Owen estima la anchura del árbol de búsqueda a cada profundidad, e incluso cuántas soluciones existen en total. Muchos en la comunidad la consideran lo más importante que hay que entender sobre Eternity II.
- [Los benchmarks de la comunidad](https://eternity2.dev/es/research/build/benchmarks/) — Cómo una comunidad a la que se le prohibió compartir las piezas construyó aun así una cultura de pruebas compartida: protocolos de verificación por conteos derivados, las suites Txibilis y para principiantes, duelos al número de nodos, enumeraciones completas y el único benchmark que sigue abierto hoy.
- [Cómo buscan los solucionadores récord](https://eternity2.dev/es/research/build/solvers/) — Cómo buscan en realidad los solucionadores que ostentan los récords. Todos son, en el fondo, backtrackers en profundidad; lo que los distingue es el orden en que prueban las cosas y cómo doblan las reglas al acercarse al final.
---
# Los experimentos de Raphaël Anjou
> Un cuaderno de experimentos de búsqueda sobre Eternity II, organizado en torno a los motores compartidos sobre los que se ejecutan, las pipelines de combinación que persiguen la puntuación, cuatro estudios que desmontan un paradigma de búsqueda una decisión a la vez, y resoluciones exactas de final de partida. Cada uno expone su idea, su mejor tablero y las preguntas que deja abiertas. El mejor alcanza 463 de 480.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/
- Actualizado: 2026-07-22
---
Este es el cuaderno de experimentos de búsqueda sobre Eternity II de [Raphaël
Anjou](/es/research/people/raphael-anjou/). Algunos son ideas originales; otros
reimplementan fielmente una técnica conocida de la comunidad para medir con
exactitud lo que aporta. Cada uno registra su idea, el tablero que alcanzó y las
preguntas que deja abiertas, y cada tablero es real y comprobable en el
[visor](/viewer/). El mejor alcanza **463 de 480** aristas casadas; el mejor de
la comunidad en el mismo puzzle es 470. Los métodos y los tableros están aquí al
completo, sin ocultar nada.
Es un cuaderno, no un resultado único, así que conviene conocer cómo está
organizado antes de adentrarse en él.
> **[Interactive: RecentlyAdded]** Rendered on the canonical page (link above); not shown in this markdown export.
## Qué contiene esta sección
Aquí conviven dos tipos de cosas: el **aparato** sobre el que se ejecutan los
experimentos, y los **experimentos** mismos. Estos últimos vienen en tres
variantes: pipelines que persiguen la puntuación del tablero completo, estudios
que aíslan una decisión de búsqueda a la vez, y resoluciones exactas que
*prueban* una región pequeña en lugar de adivinarla. Empieza allí donde esté la
pregunta que te importa.
- [Los motores](/es/research/lab/experiments/raphael-anjou/engines/) — La maquinaria compartida sobre la que se ejecutan los experimentos: un productor constructivo por haz, una búsqueda local de destrucción y reparación, y una familia de preajustes CSP. Documentada una sola vez aquí para que cada estudio pueda remitirse a ella en lugar de reexplicar la máquina. Empieza aquí si quieres saber cómo funciona una búsqueda antes de leer qué hizo un estudio con ella.
- [Pipelines de combinación](/es/research/lab/experiments/raphael-anjou/pipelines/) — Las ejecuciones con nombre que hacen subir la puntuación. Cada una es una pipeline, no un algoritmo aislado: construir un tablero con un motor y luego elevarlo o rematarlo con otro. El interés reside en el reparto del trabajo entre construcción, reparación y un final de partida exacto. De aquí salen los tableros que se acercan al récord.
- [El estudio DFS](/es/research/lab/experiments/raphael-anjou/dfs-study/) — El backtracking en profundidad, diseccionado. Una familia de backtrackers partiendo de cero, separados cada uno por un solo cambio (orden de relleno, heurística, política de ruptura), ejecutados sobre las mismas diez variantes con un presupuesto fijo, para poner precio a lo que vale cada idea.
- [El estudio de reparación](/es/research/lab/experiments/raphael-anjou/repair-study/) — Su hermano, para la búsqueda local de destrucción y reparación: qué región destruir, cómo reconstruirla, cuándo conservar un movimiento, de qué tablero partir. El bucle con el que los récords alcanzan de verdad la cima, desmontado una decisión a la vez.
- [Aprender de los tableros fuertes](/es/research/lab/experiments/raphael-anjou/learning/) — Un estudio vuelto hacia adentro: en lugar de variar la búsqueda, variar lo que se le permite *saber*. Cinco experimentos minan el corpus de tableros fuertes en busca de estructura y la reinyectan, y los cinco chocan contra el mismo muro.
- [El estudio de las pistas](/es/research/lab/experiments/raphael-anjou/hint-study/) — Dar gratis a un backtracker cinco piezas correctas, en la geometría de pistas del propio puzzle. Medidas contra la ausencia total de pistas, nunca ayudan a un backtracker cronológico en estos tableros; pueden costar de 10 a 20 puntos a un barrido compacto y hundir en unos 345 puntos un orden que corre hacia las pistas, porque una pieza fijada es una restricción dura que un orden de relleno fijo debe satisfacer al llegar.
- [Encuentro en el medio](/es/research/lab/experiments/raphael-anjou/meet-in-the-middle/) — Resoluciones exactas de final de partida: enumerar una región desde dos extremos y unirla en la costura para hallar la verdadera mejor compleción, con una prueba de que ninguna puntúa más alto. Miden con exactitud una región pequeña en lugar de perseguir la puntuación del tablero completo.
- [Ir rápido](/es/research/lab/experiments/raphael-anjou/going-fast/) — La otra palanca: no una búsqueda más astuta, sino más rápida. Un backtracker en Rust portable que genera y compila Rust propio de cada rompecabezas, llevado peldaño a peldaño hasta un rendimiento de la clase de McGavin - a la par del C más afinado a mano de la comunidad en tableros difíciles y realistas, desde un lenguaje seguro. Un resultado de velocidad, en un eje propio, distinto de las puntuaciones de arriba.
Los dos motores constructivos, el productor por haz y la etapa de pulido ALNS,
todavía no tienen su propio exposé; allí donde una pipeline dirige uno, su
propia página indica qué hace ese motor al nivel que el estudio necesita. Los
preajustes CSP son el único motor documentado y medido por completo. Aparte de
este aparato, el pequeño [motor de
referencia](/es/research/lab/experiments/raphael-anjou/engine/) que impulsa las
demos en vivo del sitio y recomprueba cada cifra tiene su propia página.
## Hallazgos e instrumentos
No todo aquí es una pipeline o un estudio. Tres páginas se sostienen solas, una
línea cada una:
- [FROSTLINE](/es/research/lab/experiments/raphael-anjou/frostline/): una energía
libre de propagación de creencias sobre las piezas sobrantes de la última
fila, que predice por rango hasta qué punto la fila puede aún terminarse, y
cuya señal muere más allá de una fila.
- [LEDGER](/es/research/lab/experiments/raphael-anjou/ledger/): una poda correcta,
color a color, de la oferta frente a la demanda para un DFS con presupuesto
de rupturas, cuyos ahorros se componen con la profundidad.
- [La escalera de tamaños](/es/research/lab/experiments/raphael-anjou/scaling-ladder/):
un banco que ejecuta un solver sin cambios sobre tableros plantados,
totalmente resolubles, de N = 8 a 14, para hallar dónde se derrumba el método
antes de dedicar semanas al 16x16 real.
Otros dos hallazgos viven en el estante de las pipelines:
[hacer un productor beam 10x mejor](/es/research/lab/experiments/raphael-anjou/pipelines/beam-width/),
donde la anchura misma resultó ser la respuesta a presupuesto igual, y
[el marco fluido](/es/research/lab/experiments/raphael-anjou/pipelines/fluid-frame/),
donde un borde perfecto resultó no ser un arreglo único sino una variedad
conexa de intercambios gratuitos.
## Dónde está el cuaderno
Leído como una sola investigación, el cuaderno sigue tres líneas. Los
constructores desde cero y las pipelines de combinación se estancan en una
banda de 436 a 460 aristas casadas: la construcción sola se atasca, y lo que
las pipelines ganaron vino del reparto del trabajo entre construcción,
reparación y un final de partida exacto, no de ningún motor en particular. La
[línea de aprendizaje sobre corpus](/es/research/lab/experiments/raphael-anjou/learning/)
alcanza 460 a 463, y sus cinco experimentos se detienen en el mismo [muro de
rigidez](/es/research/why/rigidity-wall/). Las resoluciones exactas de [encuentro
en el medio](/es/research/lab/experiments/raphael-anjou/meet-in-the-middle/) son un
resultado de otra naturaleza: sus tableros de 437 a 448 llegan con una prueba
sobre una región pequeña, no con una persecución de la puntuación del tablero
completo. La pregunta abierta del cuaderno es qué tendría que cambiar un
próximo experimento para pasar de 463; variar la búsqueda y variar lo que sabe
han chocado ambas con muros, así que la palanca probablemente no sea ninguna de
las dos por separado. La brecha que queda es con el 470 de la comunidad, en la
[página de récords](/es/research/records/).
El cuaderno cuenta sus puntuaciones en dos convenciones, que no señalan el
mismo máximo. En aristas emparejadas, el mejor es 463
([PALIMPSEST](/es/research/lab/experiments/raphael-anjou/learning/palimpsest/)).
Bajo la convención estricta de las cinco pistas, donde las cinco pistas
oficiales deben ocupar sus casillas, el mejor es 461: un productor de orden en
peine alcanza 457 y un pulido de destrucción y reparación lo eleva por 459 y
460. Ambos números quedan por debajo de las mejores marcas de la comunidad; la
[página de récords](/es/research/records/) mantiene al día las convenciones y la
clasificación.
## Próximas redacciones
Hay resultados en el laboratorio que aún no tienen su página, en el orden
probable de llegada: el linaje estricto 461 de arriba, el finalizador exacto
que sella las últimas filas de un tablero producido, el haz de doble ruptura
y el productor de cuencas por novedad. Cada uno llegará con su reproducción
ejecutable, como las páginas de arriba.
## Cómo leer las puntuaciones
El gráfico y la tabla de abajo contienen dos tipos de número que nunca deben
confundirse, por lo que se dibujan como grupos separados.
- **Exploración** es el mejor tablero que cada método alcanzó en ejecuciones
exploratorias sobre 8 núcleos, sin registrar el tiempo de reloj. Son los
números destacados que citan los exposés, y culminan en el 463 de PALIMPSEST.
- **Banco** es el banco de pruebas estandarizado de un solo núcleo: un núcleo,
sesenta segundos, cada tablero re-puntuado por el mismo baremo canónico. Más
bajo, y *directamente comparable* entre métodos de una forma que los números
de exploración no permiten.
No todos los experimentos merecen una fila. Los estudios varían una
perilla a lo largo de una rejilla en lugar de producir un solo tablero, de modo
que los estudios [DFS](/es/research/lab/experiments/raphael-anjou/dfs-study/) y de
[reparación](/es/research/lab/experiments/raphael-anjou/repair-study/) llevan sus
propias clasificaciones en vez de una fila en el gráfico; aquí solo aparece su
mejor resultado de banco. [El estudio de las
pistas](/es/research/lab/experiments/raphael-anjou/hint-study/) lleva igualmente
sus propias tablas en sus páginas y no tiene fila en el gráfico. Los cinco experimentos de
[aprendizaje](/es/research/lab/experiments/raphael-anjou/learning/) alcanzan cada uno
un tablero puntuado, así que conservan sus filas además de su hogar de estudio.
Las filas de banco de arriba son resultados de estudio, no páginas autónomas, de
modo que solo aparecen en el gráfico.
> **[Interactive: ExperimentScoreChart]** Rendered on the canonical page (link above); not shown in this markdown export.
Los experimentos con nombre en forma de tabla ordenable (haz clic en una
cabecera de columna para reordenar por puntuación, nombre, método o mes). El
autor, el mes, el rigor y la reproducibilidad se leen de la propia página de
cada experimento, de modo que este resumen se mantiene al día con ellas.
s.group !== "bench")} />
## Páginas de esta sección
- [Los motores compartidos](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/engines/) — Los motores compartidos que sustentan los experimentos de Raphaël Anjou. Los experimentos con nombre son estudios que se ejecutan sobre ellos; este es el aparato que comparten. Los preajustes CSP y la reimplementación de Verhaard están documentados por completo, junto al motor de referencia, el backtracker JIT, una guía de la velocidad y el arnés de la escalera de tamaños; los motores constructivos aún no están publicados.
- [El motor de referencia que impulsa este sitio](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/engine/) — El backtracker de Rust a WebAssembly que anima cada demo en vivo y verifica cada número de este wiki. No una máquina de récords sino un motor de referencia, portado cuatro veces y validado byte a byte, construido para que las afirmaciones de aquí puedan volver a ejecutarse.
- [Pipelines de combinación](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/) — Siete experimentos de búsqueda con nombre propio que persiguen la puntuación, cada uno un pipeline más que un único algoritmo: construye un tablero con un motor y luego lo eleva o lo remata con otro. Junto a ellos, dos hallazgos desmontan la maquinaria en la que los pipelines se apoyan. Cada página deja constancia de su idea, de su tablero y de las preguntas que deja abiertas.
- [El estudio DFS](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/) — Una sola pregunta, planteada con cuidado: entre los backtrackers en profundidad para Eternity II, ¿qué aporta realmente cada orden de relleno, cada heurística y el mecanismo de ruptura? Una familia de backtrackers escritos desde cero, separados cada uno por un único cambio, ejecutados sobre las mismas diez variantes con esquinas fijadas, en un solo núcleo, durante sesenta segundos.
- [El estudio de las pistas](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/hint-study/) — Darle a un backtracker cinco piezas correctas gratis, en la geometría misma de las pistas del puzzle. Resulta que no ayuda, y según el orden de relleno puede dañar gravemente, porque una pieza fijada es una restricción dura que un orden de relleno fijo debe satisfacer al llegar. Una familia de órdenes de relleno, ejecutada sobre los mismos tableros con pistas, un solo núcleo, medida contra la ausencia total de pistas.
- [El estudio de la reparación](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/repair-study/) — La hermana del estudio DFS, para la otra manera en que se ataca Eternity II: destruir parte de un tablero, reconstruirla, conservar el cambio si ayuda. Una pregunta, planteada con cuidado. Qué aporta cada decisión de ese bucle: qué región destruir, cómo reconstruirla, cuándo conservar un movimiento, cuándo reiniciar, y desde qué tablero partir.
- [Aprender a partir de tableros fuertes](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/) — Un estudio en cinco experimentos de una sola idea: en lugar de buscar Eternity II desde cero, extraer estructura del corpus de tableros fuertes ya encontrados y reinyectarla en una búsqueda. Un prior de posición, un voto de jugada aprendido, una brújula de demanda escasa, un minero de antipatrones y un decodificado de récord, ordenados de la señal más simple a la más sutil, y el único muro que los cinco alcanzan.
- [Meet in the middle](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/meet-in-the-middle/) — Experimentos exactos de final de partida que se encuentran en el medio: enumeran una región desde dos extremos y las unen por la costura, para hallar la verdadera mejor terminación con una prueba en lugar de la mejor conjetura de una heurística. Miden con exactitud una región pequeña en vez de perseguir la puntuación del tablero completo.
- [Ir rápido: cuando un solucionador gasta su presupuesto en velocidad](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/going-fast/) — Algunos motores de Eternity II vuelcan su esfuerzo en recorrer el árbol de búsqueda lo más rápido posible; otros lo gastan en el criterio sobre dónde buscar. Este es el alegato a favor de los primeros - qué compra el rendimiento bruto, las tres cosas distintas que la gente llama «rápido» y por qué el motor más rápido jamás construido sigue sin poder resolver el rompecabezas.
- [El backtracker JIT: Rust portable a la par del C afinado a mano en tableros difíciles](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/jit-backtracker/) — Un backtracker Rust en profundidad, seguro y portable, especializado en tiempo de ejecución al emitir y compilar Rust propio de cada rompecabezas, llevado de 43 a 123 millones de nodos de búsqueda por segundo en un núcleo. Medido con justicia frente al C de Peter McGavin en la misma máquina: un empate en tableros difíciles y profundos como el Eternity II real, y alrededor del 44 % de su velocidad en los fáciles. Cada peldaño recorre el árbol idéntico; toda la ganancia es código, no algoritmo.
- [Una poda correcta por conteo de colores para la búsqueda tolerante a rupturas](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/ledger/) — Llevar, color a color, la oferta de semiaristas frente a la demanda del frente en un DFS con presupuesto de rupturas, y podar en cuanto el déficit o su paridad superan las rupturas restantes. Correcto por construcción; la ganancia se compone con la profundidad.
- [Leer el futuro de una fila en sus piezas sobrantes](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/frostline/) — Una energía libre de propagación de creencias, calculada sobre las piezas sobrantes de la última fila, predice el rango del mejor final posible. La señal no es un proxy del puntaje bruto, sobrevive a un cambio de productor y muere más allá de una fila.
- [La escalera de tamaños](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/scaling-ladder/) — Un banco que ejecuta cualquier solucionador, sin cambios, sobre tableros plantados totalmente resolubles con N = 8, 10, 12, 14, cada uno con un techo probado de 2N(N-1): el tamaño de colapso de un método se mide antes de gastar semanas en el 16×16 real.
---
# El estudio DFS
> Una sola pregunta, planteada con cuidado: entre los backtrackers en profundidad para Eternity II, ¿qué aporta realmente cada orden de relleno, cada heurística y el mecanismo de ruptura? Una familia de backtrackers escritos desde cero, separados cada uno por un único cambio, ejecutados sobre las mismas diez variantes con esquinas fijadas, en un solo núcleo, durante sesenta segundos.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/
- Actualizado: 2026-07-16
- Temas: backtracking, search-space, speed
- Reproducir: `just experiments dfs-study`
- Fuente: Motor ejecutable + resultados versionados + scripts (el directorio de respaldo de este estudio) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/dfs-study
---
Todo solucionador de Eternity II poseedor de un récord (Blackwood, Verhaard,
McGavin) es un backtracker en profundidad. Lo que los distingue de un backtracker
del primer trabajo de la semana no es su naturaleza, sino un puñado de decisiones:
el orden en que rellenan las celdas, la anticipación que aplican y el hecho de
dejar o no que una arista *rompa*. Este estudio desmonta esas decisiones.
Construye desde cero una familia de backtrackers en profundidad, cada uno
separado de su vecino por un único cambio, y los ejecuta a todos sobre las mismas
diez variantes con esquinas fijadas del puzzle oficial, en un solo núcleo,
sesenta segundos por ejecución. La puntuación máxima es de 480 aristas casadas.
El objetivo no es ganar. La variante más fuerte que aquí se presenta ronda de
media los 430 justos, muy por debajo de los 464 de la comunidad sobre estas cinco
pistas, porque sesenta segundos en un núcleo son apenas una fracción ínfima del
cómputo que exigieron los récords. El objetivo es aislar *lo que vale cada idea*
cambiando una sola cosa a la vez y midiendo el resultado con el mismo
solucionador canónico de puntuación para cada tablero.
> **[Interactive: StartingPuzzleCarousel]** Rendered on the canonical page (link above); not shown in this markdown export.
## La familia, y el clasificatorio
Cuatro familias, dispuestas de modo que los vecinos difieran en una sola decisión.
**Baseline** es el backtracker más crudo posible, acompañado de un gemelo
especializado a mano que pone precio al coste de la ingeniería de bajo nivel.
**Path order** fija todo salvo la secuencia en que se rellenan las celdas.
**Heuristic** fija el orden y añade un propagador cada vez. **Break** es el eje de
élite: el mecanismo de ruptura de arista con umbral de profundidad sobre el que se
apoyan los récords. Los motores récord de la comunidad, el C de McGavin y el C# de
Blackwood, son ellos mismos backtrackers de ruptura, de modo que ocupan su lugar
en la familia break, y no en una categoría aparte. De quién es el código de un
motor sigue siendo cuestión de etiquetado, no de color. Ambos aparecen en el
clasificatorio con su puntuación de esquinas fijadas, marcados con una insignia
allí donde se derrumban, y de nuevo sobre una rejilla sin fijación más abajo,
donde funcionan tal como fueron diseñados.
> **[Interactive: DfsStudyLeaderboard]** Rendered on the canonical page (link above); not shown in this markdown export.
## Lo que el estudio encontró
- **El orden de recorrido es la mayor palanca gratuita, y el orden equivocado es
catastrófico.** Un simple recorrido fila por fila promedia 377; un relleno
estricto de borde primero o en espiral, sin heurística que lo rescate, se estanca
cerca de 67. Mismo motor, mismo presupuesto, una oscilación de más de 300 puntos
debida al solo orden de relleno.
- **La heurística de la celda más restringida (MRV) es lo que hace viable el borde
primero.** Eleva un borde primero estancado desde los sesenta hasta una media de
324, a un coste de tres órdenes de magnitud en el rendimiento de nodos. El
rendimiento de nodos y la puntuación son dos ejes distintos, una distinción sobre
la que el estudio vuelve de principio a fin.
- **Más propagación no compró más puntuación con este presupuesto.** El
forward-checking, la arco-consistencia y el razonamiento por color aterrizan a un
punto unos de otros (322, 321, 321), una brecha muy dentro de la dispersión de
una ejecución a otra, de modo que una anticipación más pesada ni ayudó ni
perjudicó claramente. Gasta los sesenta segundos en demostrar regiones pequeñas
en lugar de descender más profundo.
- **Las rupturas descienden más profundo que cualquier búsqueda estricta.** Los
backtrackers estrictos se topan con un techo en los 200 justos (el más rápido,
NAIVE-CODEGEN, en 216); un presupuesto de ruptura con umbral de profundidad
supera 245 y promedia los 430 justos, porque puede forzar el paso más allá de una
arista localmente incasable en lugar de retroceder para salir de ella. El factor
decisivo es el *calendario* de las rupturas: desbloquear las rupturas demasiado
pronto (la escalera de Verhaard, media 399) puntúa muy por debajo de la escalera
más tardía de Blackwood (media 431). Elevar el tope por celda de uno a dos no
ayudó con este presupuesto, un resultado nulo reportado como medido.
Cada uno de estos puntos tiene su propia página: cómo se construye el motor y qué
significa cada estadística registrada está en la
[página de método](/es/research/lab/experiments/raphael-anjou/dfs-study/method/), y las
comparaciones de recorrido, heurística y ruptura se desarrollan en la
[página de resultados](/es/research/lab/experiments/raphael-anjou/dfs-study/findings/).
## Cómo leer las cifras
Cada tablero se vuelve a puntuar con un único solucionador canónico de puntuación,
y no se da por buena la puntuación autodeclarada de ningún motor. El rendimiento
se reporta en nodos de búsqueda por segundo y **nunca se compara de una familia a
otra**, porque un nodo que ejecuta una arco-consistencia completa no es la misma
unidad de trabajo que una colocación ingenua. La profundidad es la colocación más
profunda que alcanzó una variante, sobre 256.
El número de rupturas merece una definición precisa, porque es fácil enunciarlo de
forma vaga. La *puntuación* de un tablero es el número de sus aristas interiores
casadas, y la brecha `480 − score` es el déficit total de aristas no casadas del
tablero. Sobre un tablero **completado**, cada arista no casada es una ruptura
genuina, de modo que allí la puntuación vale exactamente `480 − #breaks`. Sesenta
segundos rara vez bastan para rellenar el tablero, sin embargo, de manera que la
mayoría de los tableros de las variantes de ruptura aquí presentados son parciales,
y su déficit está dominado por aristas simplemente aún vacías más que rotas. Este
estudio reporta por tanto el **verdadero número de rupturas**, es decir, los
desapareamientos interiores que la búsqueda comprometió efectivamente bajo su
presupuesto, seguidos por la propia búsqueda en lugar de inferidos de la
puntuación. Ese número se mantiene pequeño incluso cuando el déficit es grande.
Cada tablero lleva una `.url` bucas que se abre en el [visualizador](/viewer/), de
modo que tanto la puntuación como las aristas rotas pueden verificarse
directamente.
Todo el aparato (el espacio de trabajo del motor, las diez variantes, los
resultados por ejecución versionados y los scripts de la rejilla) reside bajo el
[directorio de respaldo](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/dfs-study)
del estudio, y `just experiments dfs-study` reconstruye el motor y relanza toda la
rejilla.
## Páginas de esta sección
- [Cómo está construido el estudio DFS](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/method/) — El motor detrás del estudio DFS: un backtracker componible donde una variante es un cambio declarado sobre un padre, una capa IO compartida que cada algoritmo habla, y las definiciones de cada estadística que el estudio plantea: tasa de nodos, profundidad, rupturas.
- [Qué mostró el estudio DFS](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/findings/) — Las tres comparaciones en el corazón del estudio DFS, llevadas hasta el final: el orden de relleno (el recorrido por filas gana, un mal orden es catastrófico), las heurísticas (MRV rescata el borde primero pero cuesta rendimiento; más propagación no aportó nada) y las rupturas (rompen el muro de profundidad; el calendario de rupturas es la palanca, no el tope por celda).
## Relacionado
- [Los experimentos de Raphaël Anjou](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/) — Un cuaderno de experimentos de búsqueda sobre Eternity II, organizado en torno a los motores compartidos sobre los que se ejecutan, las pipelines de combinación que persiguen la puntuación, cuatro estudios que desmontan un paradigma de búsqueda una decisión a la vez, y resoluciones exactas de final de partida. Cada uno expone su idea, su mejor tablero y las preguntas que deja abiertas. El mejor alcanza 463 de 480.
- [Benchmark mono-núcleo](https://eternity2.dev/es/research/lab/experiments/single-core-benchmark/) — Quince solucionadores, los nuestros y nuestras implementaciones de los dos backtrackers récord de la comunidad, cada uno ejecutado una vez sobre diez variantes del puzzle oficial con las esquinas fijadas, un solo núcleo, 60 segundos por ejecución. El hallazgo: el número de nodos no es la puntuación.
- [Órdenes de relleno](https://eternity2.dev/es/research/build/backtracking/fill-order/) — El orden en que un algoritmo de backtracking visita las 256 celdas es su única libertad: no cuesta nada en tiempo de ejecución y mueve el tamaño del árbol de búsqueda en varios órdenes de magnitud. Veinte años de ciencia comunitaria, desde las guerras entre fijo y dinámico y las carreras de estrategias hasta el cuadrado mágico 10×16 y la búsqueda en peine de Verhaard, responden todos a la misma pregunta: ¿qué camino a través del tablero es el más barato?
---
# Qué mostró el estudio DFS
> Las tres comparaciones en el corazón del estudio DFS, llevadas hasta el final: el orden de relleno (el recorrido por filas gana, un mal orden es catastrófico), las heurísticas (MRV rescata el borde primero pero cuesta rendimiento; más propagación no aportó nada) y las rupturas (rompen el muro de profundidad; el calendario de rupturas es la palanca, no el tope por celda).
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/findings/
- Actualizado: 2026-07-16
- Temas: backtracking, search-space, speed
- Fuente: Resultados por ejecución versionados (results.jsonl) e informe por familia (report.md) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/dfs-study/results
---
Tres comparaciones sostienen el [estudio DFS](/es/research/lab/experiments/raphael-anjou/dfs-study/).
Cada una aísla una decisión manteniendo todo lo demás fijo. Todas las puntuaciones son el
número medio de aristas apareadas sobre las diez variantes con esquinas fijadas, un solo núcleo,
sesenta segundos. El rendimiento se mide en nodos de búsqueda por segundo y nunca se compara
entre familias.
## Qué aporta la especialización de bajo nivel: rendimiento, y solo eso
Las dos referencias ejecutan el *mismo* algoritmo estricto de recorrido por filas: `NAIVE-CLEAN`
como motor general legible, `NAIVE-CODEGEN` como bucle caliente 16×16 especializado a mano,
reservado al recorrido por filas. La especialización entrega lo que debe en el eje que persigue.
`NAIVE-CODEGEN` es notablemente más rápido por nodo, hasta un tercio más en algunas instancias.
En cuanto a la *puntuación*, las dos empatan, a un punto o dos de distancia a sesenta segundos y
bien dentro de la dispersión entre ejecuciones, que es la lectura rigurosa más que una afirmación
de que la especialización *perjudique*. A tiempo de reloj fijo, un motor más rápido alcanza un
punto distinto del mismo árbol, y la mejor solución parcial de un backtracker no varía de forma
monótona con la velocidad a la que llegó allí. Las referencias son, por tanto, una comparación
limpia de *velocidad* y deliberadamente no se presentan como una comparación de *puntuación*. Los
efectos sobre la puntuación que merece la pena estudiar están todos en los ejes de abajo, donde la
búsqueda misma cambia.
## Orden de relleno: el recorrido por filas gana, y el orden equivocado es catastrófico
Fijemos el motor (estricto, sin heurísticas) y cambiemos solo el orden en que se rellenan las
celdas. Los seis órdenes solo se diferencian en el lugar donde la búsqueda envía su frente, que se
muestra abajo.
> **[Figure]** Los seis órdenes de relleno, trazados como el camino que recorre la búsqueda — interactive: PathOrderDiagram. Rendered on the canonical page (link above); not shown in this markdown export.
- **El recorrido por filas** es la referencia fuerte, con una media de 377. Su zona de daño se
mantiene constante, ya que cada celda nueva tiene las dos mismas celdas vecinas ya colocadas, de
modo que alcanza gran profundidad antes del muro estricto.
- **Un relleno estricto de borde primero o en espiral se colapsa.** Rellenar primero el anillo del
borde, sin anticipación, conduce directo a las restricciones de esquina y de borde más duras y se
atasca casi de inmediato, cerca de una media de 67 a una profundidad de 66 aproximadamente. La
espiral paga el mismo impuesto de cierre.
- **El recorrido por filas de abajo hacia arriba va aún peor en esta geometría de pistas**
(media 226, pero tan bajo como 18 en algunas variantes), porque las pistas fijadas se sitúan en
filas que el relleno de abajo hacia arriba alcanza pronto y no puede satisfacer.
Mismo motor, mismos sesenta segundos, una oscilación de más de 300 puntos debida únicamente al
orden de relleno. Esta es la forma medida de un saber de la comunidad: el borde primero solo es
bueno *con* una heurística para elegir las celdas dentro del anillo. Por sí solo es uno de los
peores órdenes disponibles.
Prueba la palanca tú mismo: elige uno de los nueve órdenes de recorrido del motor abajo y observa cómo el mismo backtracker real alcanza una profundidad distinta en el mismo puzzle.
> **[Interactive: DfsScanOrderLab]** Rendered on the canonical page (link above); not shown in this markdown export.
## Heurísticas: MRV rescata el borde primero, pero el rendimiento se desploma
Fijemos ahora el camino cerca del marco y añadamos una cosa cada vez. La mayor palanca es
**MRV**, que rellena a continuación la celda vacía más restringida, elegida dinámicamente.
Convierte el borde primero atascado (media 67) en una búsqueda cuya media es 324 (mejor 341) a una
profundidad de 190 aproximadamente. También recalcula la celda más restringida sobre todo el frente
en cada paso, de modo que el rendimiento en nodos cae tres órdenes de magnitud, de decenas de
millones de nodos por segundo a unos pocos miles. Cada nodo vale mucho más, y se visitan muchos
menos. El ritmo de nodos y la puntuación son ejes distintos.
Añadir una anticipación más pesada por encima **no** aportó más puntuación con este presupuesto.
- **La verificación hacia delante** (rechazar una colocación que vacíe el dominio de una vecina)
obtuvo una media de 322.
- **La consistencia de arco** y la **verificación de suministro por color** obtuvieron cada una una
media de 321. Con una dispersión de puntuación por variante de unos 11 puntos sobre las diez
instancias, esa diferencia de un punto está bien dentro del ruido: los tres propagadores son aquí
estadísticamente indistinguibles, de modo que la lectura rigurosa es que una anticipación más
pesada ni ayudó ni perjudicó claramente, más que la verificación hacia delante hubiera ganado.
- Una ordenación de valores de **colores raros primero** fue inerte, no mejor que el simple orden de
inserción, haciendo eco al resultado negativo repetido de la comunidad sobre los órdenes de
valores dentro de un mismo cubo.
La lección no es que la propagación sea inútil. Es que con un presupuesto pequeño y fijo, sobre esta
instancia, la poda útil más barata (la verificación hacia delante) ya capta cualquier beneficio
disponible, y un razonamiento más caro no recupera su coste adicional por nodo en sesenta segundos.
## Rupturas: más allá del muro, y el calendario es la palanca
El backtracking estricto, sea cual sea su orden o su heurística, choca contra un muro muy antes de
un tablero completo: el recorrido por filas se estanca en torno a la profundidad 208 de 256, e
incluso la variante estricta más rápida (NAIVE-CODEGEN) solo alcanza 216. Los motores recordistas
lo superan *rompiendo*: permiten un número acotado de incompatibilidades de aristas interiores,
liberadas según un calendario de profundidad, con una regla que impide que una celda cargue con
demasiadas aristas rotas. La puntuación de un tablero completo es entonces `480 − #rupturas`.
- **Las rupturas superan el muro.** Un presupuesto de rupturas condicionado por la profundidad
alcanza más allá de la profundidad 245 y ronda los 430 bajos (ruptura-1 da 431 de 480, mejor 435),
una gran ganancia sobre los 370 altos del estricto, sobre las mismas instancias y presupuesto.
Este es el mecanismo tras los backtrackers recordistas de la comunidad, no un paradigma distinto
sino una relajación de la regla de apareamiento condicionada por la profundidad.
- **Permitir una segunda ruptura por celda no ayudó aquí.** Una ruptura y dos rupturas alcanzan el
mismo mejor tablero (435), y sus medias (431,3 frente a 428,5) se sitúan dentro de la dispersión
propia de la variante de dos rupturas, de modo que ninguna domina en media. Lo que sí las separa
es la regularidad: la variante de una ruptura está estrechamente agrupada (nunca por debajo de
427), mientras que la variante de dos rupturas desciende hasta 402. La geometría de doble ruptura
que emplean los tableros 460 de la comunidad parece necesitar más de sesenta segundos para dar
fruto; con este presupuesto, la libertad adicional sobre todo ensancha el ramaje sin alcanzar
mejores tableros. Es un resultado nulo, reportado tal como se midió y no como cabría esperar.
- **El calendario es la palanca decisiva.** La escalera de deslizamiento de Verhaard desbloquea las
rupturas mucho antes que la de Blackwood (profundidad 193 frente a 201) y aquí puntúa
notablemente peor (media 399 frente a 431), porque desbloquear pronto gasta el presupuesto en
rupturas superficiales. Cuándo y con qué rapidez se abren las rupturas es una decisión de ajuste
más que un detalle.
Estas cifras de rupturas conviven con las de las reimplementaciones al estilo Blackwood y al estilo
Verhaard, rehechas desde cero, del benchmark hermano, que alcanzan los 430 altos sobre las mismas
cinco pistas. La concordancia de un motor independiente valida de forma cruzada la maquinaria de
rupturas aquí.
## Dónde se sitúan los motores de la comunidad: dos rejillas
Blackwood y McGavin son la gama alta de esta misma familia, y ambos se compilan y ejecutan en esta
máquina, de modo que este estudio los hizo correr tanto en una rejilla fijada como en una no
fijada, con cada puntuación recalculada canónicamente a partir del tablero propio del motor. El
resultado es un hallazgo por derecho propio, y tiene dos mitades.
**En la rejilla fijada, se colapsan.** El C de McGavin, compilado con las propias opciones ARM de
su autor (ajuste nativo más optimización en tiempo de enlace), alcanza la profundidad 211 en el
puzzle de pista central simple a unos 85 millones de piezas por segundo, muy por delante de nuestro
motor estricto más rápido, y sin embargo fijar tres esquinas lo colapsa a la profundidad 21, una
puntuación canónica de 13. Su camino de recorrido generado nunca visita las esquinas pronto, de modo
que una esquina fijada restringe su vecindad de inmediato y bloquea el camino fijo casi al instante.
El C# de Blackwood codifica en duro su conjunto de piezas y su recorrido, de modo que ni siquiera
puede expresar una fijación de esquina arbitraria; sobre la restricción de cinco pistas
correspondiente, su heurística de rupturas se agita hasta la profundidad 47, una puntuación canónica
de 75, porque está ajustada para la instancia de una pista, casi sin restricciones, donde se
estableció su récord de 470.
> **[Figure]** El colapso al fijar las esquinas: celdas colocadas de 256 — interactive: PinCollapseDiagram. Rendered on the canonical page (link above); not shown in this markdown export.
Ese colapso es justamente el punto. Un motor recordista construido en torno a una configuración de
pistas no se transfiere a otra, y un camino de recorrido fijo no puede absorber una fijación
arbitraria. Nuestros motores rehechos desde cero tratan una fijación como una celda pre-colocada que
el recorrido simplemente salta, razón por la cual son ellos, y no los binarios de la comunidad, los
sustitutos en la rejilla fijada.
**En una rejilla no fijada equitativa, corren como se diseñaron.** Dad a cada motor las piezas
oficiales con la única pista central obligatoria, y nada se bloquea en una esquina. En sesenta
segundos sobre un núcleo, McGavin alcanza 392, nuestro motor de rupturas más fuerte 344, la
reimplementación de Verhaard 286, y Blackwood 214. Leed esas cifras como lo que un solo núcleo
compra en un minuto desde arranque en frío, no como el techo de ningún motor: el 470 de Blackwood y
las ejecuciones profundas de McGavin vinieron de días sobre cientos de núcleos, que este presupuesto
no puede mostrar. Lo que la rejilla sí muestra es que los cuatro corren correctamente una vez
desaparecidas las fijaciones que rompen un camino de recorrido fijo, que es exactamente lo que la
rejilla fijada les negaba a los dos motores ajenos. Ambas rejillas figuran en la clasificación del
estudio de arriba.
## El hilo conductor
Un tema atraviesa las tres comparaciones: **el número de nodos no es la puntuación.** Las variantes
más rápidas por nodo (la referencia en codegen y el motor estricto de recorrido por filas) no
alcanzan los mejores tableros; la más lenta por nodo (MRV con propagación) alcanza otros mucho
mejores; y las rupturas que ganan lo hacen cambiando *qué* rama es legal, no visitando ramas más
rápido. La velocidad bruta es un factor constante, mientras que dónde y si a la búsqueda se le
permite ir es el factor exponencial.
## Relacionado
- [El estudio DFS](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/) — Una sola pregunta, planteada con cuidado: entre los backtrackers en profundidad para Eternity II, ¿qué aporta realmente cada orden de relleno, cada heurística y el mecanismo de ruptura? Una familia de backtrackers escritos desde cero, separados cada uno por un único cambio, ejecutados sobre las mismas diez variantes con esquinas fijadas, en un solo núcleo, durante sesenta segundos.
- [Cómo está construido el estudio DFS](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/method/) — El motor detrás del estudio DFS: un backtracker componible donde una variante es un cambio declarado sobre un padre, una capa IO compartida que cada algoritmo habla, y las definiciones de cada estadística que el estudio plantea: tasa de nodos, profundidad, rupturas.
- [Órdenes de relleno](https://eternity2.dev/es/research/build/backtracking/fill-order/) — El orden en que un algoritmo de backtracking visita las 256 celdas es su única libertad: no cuesta nada en tiempo de ejecución y mueve el tamaño del árbol de búsqueda en varios órdenes de magnitud. Veinte años de ciencia comunitaria, desde las guerras entre fijo y dinámico y las carreras de estrategias hasta el cuadrado mágico 10×16 y la búsqueda en peine de Verhaard, responden todos a la misma pregunta: ¿qué camino a través del tablero es el más barato?
- [Una poda correcta por conteo de colores para la búsqueda tolerante a rupturas](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/ledger/) — Llevar, color a color, la oferta de semiaristas frente a la demanda del frente en un DFS con presupuesto de rupturas, y podar en cuanto el déficit o su paridad superan las rupturas restantes. Correcto por construcción; la ganancia se compone con la profundidad.
---
# Cómo está construido el estudio DFS
> El motor detrás del estudio DFS: un backtracker componible donde una variante es un cambio declarado sobre un padre, una capa IO compartida que cada algoritmo habla, y las definiciones de cada estadística que el estudio plantea: tasa de nodos, profundidad, rupturas.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/method/
- Actualizado: 2026-07-16
- Temas: backtracking, speed
- Fuente: El espacio de trabajo del motor (dfs-engine, dfs-run) sobre la biblioteca compartida e2-core / e2-io — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/dfs-study/engine
---
Esta página es el aparato detrás del [estudio DFS](/es/research/lab/experiments/raphael-anjou/dfs-study/):
cómo está construido el motor, por qué una nueva variante cuesta poco añadir, y qué
significa cada número entre los resultados. Nada de esto depende del motor del
[benchmark de un solo núcleo](/es/research/lab/experiments/single-core-benchmark/)
vecino. Todo el objetivo era reimplementar la familia desde cero, manteniendo la
ingeniería de software limpia y el relato del «qué se apila sobre qué» explícito.
## Una variante es un cambio declarado sobre un padre
Cada algoritmo del estudio es el *mismo* backtracker recursivo en profundidad,
parametrizado por cuatro elecciones independientes:
- **orden de recorrido**: la secuencia en que se rellenan las celdas (por filas,
en espiral, borde primero, el peine de Verhaard, o dinámico por celda más
restringida);
- **orden de valores**: el orden en que se prueban las piezas candidatas de una
celda;
- **propagador**: la anticipación ejecutada tras cada colocación (ninguna,
verificación hacia adelante, arco-consistencia, razonamiento por color);
- **política de ruptura**: si una arista puede ser discordante, y bajo qué
presupuesto condicionado por la profundidad.
Una variante es un pequeño registro que nombra esas cuatro elecciones, junto con
**el padre del que deriva y una descripción de una línea del cambio único que
añade**. Añadir una variante equivale a añadir un registro al registro, sin nuevo
código de búsqueda a menos que la idea sea una estrategia genuinamente nueva. La
matriz del «qué se apila sobre qué» de la página de resultados se genera a partir
de esas descripciones, de modo que no puede divergir del código que se ejecutó.
Eso es lo que mantiene un estudio extenso, con decenas de variantes a un solo
cambio de distancia, mantenible en lugar de un montón de solucionadores copiados y
pegados.
## Una capa IO, y conversiones entre motores
Cada algoritmo del estudio consume un único tipo de instancia y emite una única
salida: el mejor tablero, su puntuación canónica, y una URL bucas. Alrededor de
eso se articula una capa IO compartida con convertidores sin pérdida entre los
formatos que hablan los demás motores del sitio: el JSON con el esquema del sitio
del benchmark, el CSV de los motores comunitarios autónomos, las URL bucas, y los
archivos de pistas. El estudio lee las *mismas* diez variantes con esquinas
fijadas que usa el benchmark de un solo núcleo, a través de esta capa, de modo que
los dos experimentos son directamente comparables. Una pequeña utilidad
`dfs-convert` expone las conversiones desde el shell, de modo que la salida de
cualquier motor del blog puede alimentar a cualquier otro.
## El scorer es la única fuente de verdad
Ningún score auto-reportado por un motor es digno de confianza. Cada tablero,
estricto o roto, es re-puntuado por un único scorer canónico: las adyacencias
interiores, no de borde, concordantes, contadas a la derecha y hacia abajo por
cada celda. Es, byte por byte, la misma fórmula que la del scorer del sitio y la
del benchmark, verificada por un test que re-puntúa un tablero de 469 conocido y
exige 469. Esto es lo que permite que puntuaciones de variantes distintas, y las
del benchmark vecino, se asienten sobre un solo eje.
## Las estadísticas que el estudio plantea
Para cada ejecución, el motor registra, y los resultados los llevan hasta la
página:
- **puntuación**: aristas concordantes canónicas (de 480). Para un tablero
completo con rupturas, esto equivale a `480 − #breaks`.
- **rendimiento de nodos**: nodos de búsqueda por segundo, un nodo por colocación
intentada. Reportado por variante y **nunca comparado entre familias**, porque un
nodo que ejecuta arco-consistencia completa no es la misma unidad de trabajo que
una colocación ingenua. Una propagación pesada intercambia rendimiento por calidad
de nodo, y el estudio mide ambos ejes en lugar de fundirlos en uno solo. Las
variantes más lentas llevan una salvedad que vale la pena enunciar con
franqueza: el motor MRV elige la celda más restringida recorriendo la lista de
candidatos de cada celda vacía en cada nodo, lo cual es intrínsecamente más pesado
que un orden de relleno fijo. Dos optimizaciones que preservan el comportamiento lo
acercan a unas pocas veces el coste de los motores rápidos, en lugar de los miles de
veces que valía antes: la búsqueda de la celda más restringida deja de contar los
candidatos de una celda en cuanto superan la mejor celda encontrada hasta ahora
(una búsqueda de mínimo nunca necesita el recuento exacto de una celda que no puede
ganar), y evita reverificar las aristas sobre las que la lista de candidatos ya está
indexada. Lo que aún no hace es mantener el recuento de candidatos de cada celda de
forma plenamente incremental de una colocación a otra, cosa que sí haría un
solucionador CSP de producción; ese último paso tendría que rastrear cómo una pieza
recién usada afecta al recuento de cada celda, y se deja de lado aquí para mantener
el motor legible. La clasificación por puntuación no depende de nada de esto, puesto
que el rendimiento es un eje aparte, pero la tasa de nodos MRV debe leerse como la de
este motor limpio y no como la mejor posible de MRV.
- **profundidad máxima alcanzada**: la colocación más profunda que hizo la
búsqueda, de 256, la medida del estudio de cuánto avanzó una variante. El
backtracking estricto choca contra un muro en los 200 bajos (por filas 208, la
variante estricta más rápida 216); las rupturas lo empujan mucho más allá, hasta
243 a 245.
- **profundidad a la expiración**: dónde se hallaba el frente de búsqueda cuando el
reloj dio la hora, de modo que una variante que nunca termina registra igualmente
dónde estaba trabajando.
- **número de rupturas**: las aristas interiores en las que la búsqueda realmente
*rompió* en el mejor tablero. Es cero para una variante estricta, y para una
variante con rupturas es el recuento que su propia contabilidad de presupuesto
comprometió, en lugar del déficit de puntuación. En un tablero completado equivale a
`480 − score`; en un parcial expirado el déficit cuenta además las aristas todavía
vacías, así que el estudio reporta en su lugar el verdadero número de rupturas. La
URL bucas de cada tablero hace ambos verificables en el [visualizador](/viewer/).
- **retrocesos**: repliegues fuera de una celda tras agotarse sus candidatos.
## Las dos referencias, y lo que cuesta la especialización
La variante más cruda, `NAIVE-CLEAN`, es un motor general legible: listas de
candidatos por celda sin centinela, indexadas por los dos vecinos ya colocados, una
caché de aristas resueltas para que ninguna rotación se recompute en el camino
caliente, y ninguna asignación dentro de la búsqueda. Su gemela, `NAIVE-CODEGEN`, es
el *mismo algoritmo* reexpresado como un bucle caliente especializado a mano, solo
16×16, por filas, mantenido como programa separado para que el motor general se
conserve limpio. Ponerlos a competir cara a cara pone precio a la ingeniería de bajo
nivel: en este puzzle compra una ganancia de rendimiento modesta y dependiente de la
instancia y, notablemente, ninguna mejor puntuación. Los números están en la
[página de hallazgos](/es/research/lab/experiments/raphael-anjou/dfs-study/findings/).
## Corrección de los propagadores
La verificación hacia adelante, la arco-consistencia y el control de suministro por
color son correctos *por construcción*. Cada uno solo rechaza un estado en el que
alguna celda ya tiene un dominio vacío, una celda que ninguna pieza no usada puede
rellenar, de modo que ninguno de ellos puede eliminar una rama que lleve a una
finalización real. La revisión de arco-consistencia es deliberadamente prudente allí
donde es imprecisa: dondequiera que pudiera estar insegura, poda *menos* en lugar de
más, quedándose del lado seguro. Los propagadores son correctos solo bajo colocación
estricta, porque bajo un presupuesto de rupturas una anticipación local puede podar
una rama que el presupuesto global aún podría rescatar, así que las variantes con
rupturas deliberadamente no ejecutan ningún propagador. El registro lo impone: una
variante que empareja rupturas con un propagador reservado al modo estricto falla al
compilar. Los tests del motor comprueban esa restricción así como la contabilidad de
la puntuación y de las rupturas, aunque la corrección de la poda en sí descansa sobre
el argumento anterior y no sobre un test.
## Reproducibilidad
El espacio de trabajo del motor, las diez variantes, los resultados por ejecución
commiteados y los scripts de la grilla viven todos bajo el
[directorio de soporte](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/dfs-study)
del estudio. `just experiments dfs-study` reconstruye el motor y reejecuta toda la
grilla; la ejecución es determinista con semilla fija, y la disposición de las
esquinas es el único eje de diversidad.
## Relacionado
- [El estudio DFS](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/) — Una sola pregunta, planteada con cuidado: entre los backtrackers en profundidad para Eternity II, ¿qué aporta realmente cada orden de relleno, cada heurística y el mecanismo de ruptura? Una familia de backtrackers escritos desde cero, separados cada uno por un único cambio, ejecutados sobre las mismas diez variantes con esquinas fijadas, en un solo núcleo, durante sesenta segundos.
- [Qué mostró el estudio DFS](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/findings/) — Las tres comparaciones en el corazón del estudio DFS, llevadas hasta el final: el orden de relleno (el recorrido por filas gana, un mal orden es catastrófico), las heurísticas (MRV rescata el borde primero pero cuesta rendimiento; más propagación no aportó nada) y las rupturas (rompen el muro de profundidad; el calendario de rupturas es la palanca, no el tope por celda).
- [Órdenes de relleno](https://eternity2.dev/es/research/build/backtracking/fill-order/) — El orden en que un algoritmo de backtracking visita las 256 celdas es su única libertad: no cuesta nada en tiempo de ejecución y mueve el tamaño del árbol de búsqueda en varios órdenes de magnitud. Veinte años de ciencia comunitaria, desde las guerras entre fijo y dinámico y las carreras de estrategias hasta el cuadrado mágico 10×16 y la búsqueda en peine de Verhaard, responden todos a la misma pregunta: ¿qué camino a través del tablero es el más barato?
---
# El motor de referencia que impulsa este sitio
> El backtracker de Rust a WebAssembly que anima cada demo en vivo y verifica cada número de este wiki. No una máquina de récords sino un motor de referencia, portado cuatro veces y validado byte a byte, construido para que las afirmaciones de aquí puedan volver a ejecutarse.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/engine/
- Actualizado: 2026-07-17
- Temas: backtracking, speed
- Fuente: El repositorio eternity2 en GitHub — https://github.com/raphael-anjou/eternity2
---
> **De quién es este trabajo**
>
> Esta página trata del motor detrás del sitio que estás leyendo, escrita por la persona que lo escribió, [Raphaël Anjou](/es/research/people/raphael-anjou/). No es un solucionador de récords de la comunidad: esos se estudian en otro lugar de este laboratorio ([Blackwood](/es/research/lab/experiments/joshua-blackwood/solver/), [McGavin](/es/research/lab/experiments/peter-mcgavin/backtracker/), [Verhaard](/es/research/lab/experiments/louis-verhaard/eii/)). Este se sitúa entre ellos como un par, y un par modesto: los solucionadores de récords tienen los récords; este tiene los comprobantes.
Donde los [experimentos con nombre](/es/research/lab/experiments/raphael-anjou/)
plantean cada uno una pregunta y los [motores compartidos](/es/research/lab/experiments/raphael-anjou/engines/)
son el aparato sobre el que corren esos estudios, esta página es una tercera
cosa: el pequeño motor de referencia que impulsa el sitio mismo, verifica las
cifras que citan las otras páginas y anima cada demo en vivo. No marca ningún
récord. Su misión es la verificabilidad y la enseñanza.
## Qué es
Un pequeño crate de Rust compilado a WebAssembly, corriendo en vivo en tu
navegador en cada página interactiva de este wiki. Implementa los clásicos, sin
rodeos: el conjunto oficial de piezas 16×16, un generador que construye puzzles
resolubles de cualquier tamaño (con un modo opcional al estilo del E2 real que
restringe los colores de borde a la banda del marco), nueve órdenes de visita de
celdas, un backtracker en profundidad estricto, un puntuador y una variante
tolerante a rupturas de la búsqueda, una reimplementación de la idea del índice
de ruptura del [solucionador de Blackwood](/es/research/lab/experiments/joshua-blackwood/solver/),
construida para que los laboratorios de aquí puedan demostrarla.
Una decisión de diseño importa más que los algoritmos: el solucionador es una
máquina que avanza por pasos, no una función recursiva. Quienes lo invocan lo
hacen avanzar un paso acotado a la vez, una colocación o un retroceso, y leen el
tablero entre pasos. Eso es lo que permite que una página web anime una búsqueda
real en lugar de una grabación enlatada:
[la página de observación](/playground/watch/) hace avanzar exactamente este
motor, y no un vídeo de él.
## Un motor, muchos portes
El sitio ejecuta un solo motor: el crate Rust/WASM, la referencia canónica. Pero
el repositorio conserva toda una colección de reimplementaciones fieles de ese
motor en otros lenguajes: un porte en TypeScript puro (cero WASM), un porte en C,
un porte en C++, y estudios más pequeños en Python, Lua, COBOL, e incluso
Brainfuck. Cada uno se valida byte a byte contra los datos de referencia que
produce el crate de Rust: puzzles generados hasta la salida del RNG, los nueve
caminos de relleno en varios tamaños y ejecuciones completas del solucionador con
los conteos exactos de nodos, intentos y retrocesos.
Esa disciplina existe por una sola razón: una demo interactiva que no puedes
contrastar no es más que una animación. Dos implementaciones independientes que
concuerdan hasta el último retroceso son mucho más difíciles de equivocar de la
misma manera dos veces, y ocho lo son aún más. Los portes son una pieza de
exposición, no opciones de build (el sitio siempre ejecuta Rust), y viven juntos
en la colección `engine-ports/` del repositorio. Algunos (el backtracker en
Brainfuck sobre todo) están ahí por gusto.
## Lo que no reclama
Esto no es una máquina de récords, y sería engañoso presentarlo como tal. El
solucionador estricto no lleva ninguno de los calendarios de cuotas ajustados a
mano ni las estrategias de reinicio que hacen del
[solucionador de Blackwood](/es/research/lab/experiments/joshua-blackwood/solver/) el
motor detrás de los mejores tableros de la comunidad. La mejor puntuación producida
por [los experimentos de aquí](/es/research/lab/experiments/) es 463 de 480; la mejor de
la comunidad sobre el mismo puzzle es 470. Los solucionadores de récords estudiados
en este laboratorio son sencillamente mejores encontrando tableros.
El rendimiento es un eje aparte, uno que este motor de referencia deliberadamente no
persigue - pero un experimento hermano sí. El
[backtracker JIT](/es/research/lab/experiments/raphael-anjou/jit-backtracker/) pregunta
cuán rápido puede ir una búsqueda Rust *portable*, y alcanza un
[rendimiento de la clase de McGavin](/es/research/lab/experiments/peter-mcgavin/backtracker/)
en los tableros difíciles y profundos que se parecen al rompecabezas real - a la par de
su C afinado a mano en la misma máquina (su C sigue siendo ~2,3× más rápido en los
tableros fáciles). Es un resultado de velocidad, no de resolución: se estanca donde se
estanca todo backtracker estricto. Velocidad y puntuación son
[ejes distintos](/es/research/lab/experiments/raphael-anjou/going-fast/), y el motor de esta
página no optimiza ninguno - solo el ser verificable.
La misión de este motor es otra: la verificabilidad y la enseñanza. Cuando este
wiki enuncia un conteo de nodos, una cifra de factibilidad o una puntuación, la
afirmación la verifica este motor, y como corre en tu navegador y su código
fuente es público, tú también puedes verificarla.
## Cómo impulsa el wiki
Cada elemento interactivo de esta sección de investigación es este motor: las
demos de DFS en vivo, las carreras de orden de relleno en
[la página de caminos](/playground/paths/), el laboratorio del índice de ruptura
en [el centro de solucionadores](/es/research/build/solvers/), la puntuación y la
verificación del visor de tableros, y los conteos de referencia versionados que
citan las páginas de investigación. La propia suite de pruebas del motor
contrasta contra tableros reales de la comunidad, de modo que un cambio que
rompiera la puntuación o las convenciones de rotación fallaría ruidosamente en
lugar de corromper en silencio las cifras del sitio.
## Dónde conseguirlo
Todo está en un solo repositorio,
[github.com/raphael-anjou/eternity2](https://github.com/raphael-anjou/eternity2),
y [ejecútalo tú mismo](/es/research/build/run-it-yourself/) recorre la construcción
del motor, la ejecución de sus pruebas y la reproducción de los resultados
publicados, comando por comando. Una salvedad sobre el estado actual: las
ejecuciones de experimentos citadas en este laboratorio fueron exploratorias,
sus tableros, cuando están enlazados, son verificables en el visor, y todavía no
se distribuye una reproducción empaquetada de un solo comando de esas
ejecuciones.
## Qué lo impulsa
El motor no crece según su propio calendario; crece cuando
[un experimento](/es/research/lab/experiments/) necesita algo. El solucionador
tolerante a rupturas existe porque demostrar los índices de ruptura requería uno;
el generador restringido al marco existe porque un laboratorio necesitaba puzzles
que se comportaran como el borde real del E2. Eso mantiene el motor pequeño, y
mantiene cada funcionalidad ligada a una pregunta que alguien realmente hizo.
## Relacionado
- [Los motores compartidos](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/engines/) — Los motores compartidos que sustentan los experimentos de Raphaël Anjou. Los experimentos con nombre son estudios que se ejecutan sobre ellos; este es el aparato que comparten. Los preajustes CSP y la reimplementación de Verhaard están documentados por completo, junto al motor de referencia, el backtracker JIT, una guía de la velocidad y el arnés de la escalera de tamaños; los motores constructivos aún no están publicados.
- [Ejecútalo tú mismo](https://eternity2.dev/es/research/build/run-it-yourself/) — Todo el sitio, el motor y cada resultado de esta sección se ejecutan desde un único repositorio. Aquí tienes cómo ponerlo en marcha, recompilar el motor WebAssembly y reproducir las cifras.
- [El solucionador de Blackwood, decodificado y ejecutado aquí](https://eternity2.dev/es/research/lab/experiments/joshua-blackwood/solver/) — El backtracker récord de Joshua Blackwood, decodificado gracias a las notas de Jef Bucas (un calendario de cuotas de color y una tolerancia a desajustes en el tramo final, ajustados casi óptimamente), luego construido y ejecutado en mi M1: tal como se publicó, vuela hasta 248 de 256 piezas ignorando las pistas; fija las cinco pistas oficiales y el mismo motor se atasca cerca de 45.
---
# Los motores compartidos
> Los motores compartidos que sustentan los experimentos de Raphaël Anjou. Los experimentos con nombre son estudios que se ejecutan sobre ellos; este es el aparato que comparten. Los preajustes CSP y la reimplementación de Verhaard están documentados por completo, junto al motor de referencia, el backtracker JIT, una guía de la velocidad y el arnés de la escalera de tamaños; los motores constructivos aún no están publicados.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/engines/
- Actualizado: 2026-07-22
---
Los [experimentos](/es/research/lab/experiments/raphael-anjou/) son estudios: cada
uno plantea una pregunta y da cuenta del tablero que alcanzó. Pero la mayoría no
se construyen desde cero. Se ejecutan sobre un pequeño conjunto de motores
compartidos, y el mismo motor reaparece experimento tras experimento. Esta
página documenta ese aparato una sola vez, para que los estudios puedan apuntar
aquí en lugar de reexplicar la máquina cada vez. El motor de referencia que
impulsa las demostraciones en vivo del sitio es una máquina distinta y tiene
[su propia página](/es/research/lab/experiments/raphael-anjou/engine/); aparece
abajo en su papel de aparato.
- [Los preajustes CSP, medidos](/es/research/lab/experiments/single-core-benchmark/csp-presets/) — Un único motor de propagación de restricciones con ordenamientos y propagadores intercambiables: consistencia de arco, emparejamiento por grafo de colores, varios órdenes de relleno. Reimplementaciones fieles de técnicas conocidas de la comunidad, ejecutadas bajo una docena de preajustes sobre las diez variantes, de modo que el coste exacto de cada parámetro figure en la tabla de clasificación en lugar de discutirse.
- [La reimplementación de Verhaard](/es/research/lab/experiments/louis-verhaard/verhaard-reimpl/) — Una reimplementación desde cero del método eii de Louis Verhaard, ya que su propio binario no incluye código fuente y no se ejecuta aquí. Recocido por intercambio sobre composición de conjuntos bajo la métrica de teselado 2×2; sobre el verdadero puzzle de cinco pistas alcanza 438 de 480, en un solo núcleo.
- [El motor de referencia que impulsa este sitio](/es/research/lab/experiments/raphael-anjou/engine/) — La máquina de verificación y demostración del wiki, distinta de los motores de búsqueda compartidos: el backtracker de Rust a WebAssembly que ejecuta cada demostración en vivo y comprueba cada número citado en estas páginas, portado cuatro veces y contrastado byte a byte.
- [El backtracker JIT](/es/research/lab/experiments/raphael-anjou/jit-backtracker/) — Un backtracker Rust en profundidad, seguro y portable, especializado en tiempo de ejecución emitiendo y compilando Rust propio de cada puzzle, llevado de 43 a 123 millones de nodos de búsqueda por segundo en un núcleo y medido frente al C afinado a mano de Peter McGavin en la misma máquina.
- [Ir rápido](/es/research/lab/experiments/raphael-anjou/going-fast/) — Una guía de campo de los solucionadores centrados en velocidad: qué compra el rendimiento bruto, las tres cosas distintas que la gente entiende por "rápido", y por qué el motor más rápido jamás construido sigue sin poder resolver el puzzle.
- [La escalera de tamaños](/es/research/lab/experiments/raphael-anjou/scaling-ladder/) — El arnés que ejecuta cualquier solucionador, sin cambios, sobre tableros plantados totalmente resolubles con N = 8, 10, 12, 14, de modo que el tamaño de colapso de un método se mida antes de gastar semanas en el 16×16 real.
Los dos motores constructivos en los que estos estudios también se apoyan, el
productor por haz y la etapa de pulido ALNS, aún no tienen su propia
presentación aquí; esas páginas están retenidas por ahora, y ninguno de los dos
figura en la tabla de clasificación del benchmark. Allí donde un experimento
dirige a uno de ellos, su propia página dice qué hace ese motor al nivel que el
estudio necesita, de modo que nada de lo que sigue depende de leer una página
que aún no está aquí. Los dos motores documentados y medidos por completo son
los preajustes CSP y la reimplementación de Verhaard.
## Por qué documentar los motores aparte de los experimentos
Un estudio y su motor responden a preguntas distintas. El motor responde a *cómo
funciona la búsqueda*: las estructuras de datos, el orden de relleno, los
propagadores, y se reutiliza sin cambios en muchos estudios. El estudio responde
a *qué ocurre cuando se apunta ese motor a una idea concreta*: un prior
aprendido, un borde fijo, una máscara de ruptura. Mantenerlos aparte significa
que un lector que quiera entender el prior de PRIOR no tenga que releer cómo
funciona un haz, y que un lector que quiera el motor lo obtenga en un solo lugar,
actualizado y completo.
Allí donde estos motores compiten cara a cara bajo un presupuesto fijo, aparecen
en el [benchmark de un solo núcleo](/es/research/lab/experiments/single-core-benchmark/).
La teoría general que hay detrás de cada método vive en la sección
[construir-un-solucionador](/es/research/build/); estas páginas son los motores
específicos tal como se construyeron y midieron aquí.
---
# Leer el futuro de una fila en sus piezas sobrantes
> Una energía libre de propagación de creencias, calculada sobre las piezas sobrantes de la última fila, predice el rango del mejor final posible. La señal no es un proxy del puntaje bruto, sobrevive a un cambio de productor y muere más allá de una fila.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/frostline/
- Actualizado: 2026-07-22
- Temas: construction, structure, search-space
- Reproducir: `just research-frostline`
- Fuente: Yedidia, Freeman, Weiss: Understanding Belief Propagation and its Generalizations (MERL TR2001-22) — https://www.merl.com/publications/docs/TR2001-22.pdf
- Fuente: Reproducción versionada: plan, script y resultados (este proyecto) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/tail-finishability-frostline
---
Un constructor ordena sus tableros parciales por aristas emparejadas. Ese
número no dice nada sobre si las piezas sobrantes todavía pueden terminar bien
las celdas restantes. FROSTLINE pregunta si una cantidad barata tomada de la
física estadística, la energía libre de Bethe de un modelo de propagación de
creencias sobre las piezas sobrantes de la última fila, predice el mejor
puntaje que esa fila aún puede alcanzar. En una fila, sí: rho de Spearman
cerca de -0,75, con validación cruzada, y la señal sobrevive a un cambio de
productor.
## Cómo funciona
Se congelan las primeras quince filas de un tablero completo y se toma como
reserva las dieciséis piezas que el propio tablero había colocado en la fila
15, lo que garantiza que la última fila sigue siendo completable. Después se
calculan dos números por tablero:
- **La etiqueta.** Un solver exacto (una programación dinámica con máscaras de
bits sobre subconjuntos de piezas y colores de costura, exacta en
milisegundos con 16 celdas) da el mejor puntaje de cola alcanzable: las 15
aristas internas de la última fila más las 16 aristas de costura contra la
fila 14, sobre 31.
- **El predictor.** Un grafo de factores sobre las dieciséis celdas vacías,
con estados tomados de la reserva y factores de pareja que premian el
acuerdo de color a temperatura inversa beta. Sobre él corre propagación de
creencias suma-producto y se lee la energía libre de Bethe. Menor energía
libre debería significar una cola más terminable.
Dos decisiones de modelado importan. La cola es un problema de emparejamiento
máximo, no de restricciones duras: un desacuerdo de color cuesta un punto en
vez de estar prohibido, así que el grafo es un modelo blando a beta finito y
no una instancia de satisfacibilidad. Y la costura contra las filas congeladas
debe ser un factor blando; el estudio fuente midió que un filtro de costura
duro se contradice en 5 de 16 celdas de cimas reales casi óptimas. En una
fila, el grafo residual es una cadena: allí la propagación de creencias es
exacta y la energía libre es el verdadero logaritmo de la función de
partición.
## El resultado
El estudio fuente encontró el efecto en 103 cimas distintas de un
haz de anchura 2048, puntajes brutos de 446 a 452. La reproducción versionada
lo regenera todo en otro régimen: 120 cimas voraces con semilla, puntajes
brutos de 361 a 396, etiquetas de cola de 16 a 22. La columna esperada cita el
estudio fuente; la columna medida es esta ejecución.
> **[Figure]** Esperado vs medido, última fila (16 celdas) — interactive figure. Rendered on the canonical page (link above); not shown in this markdown export.
El umbral prerregistrado (|rho| de al menos 0,4, o AUC por encima de 0,75 o
por debajo de 0,25) se supera con cada beta probado, con el signo de la
fuente. Dos lecturas de la tabla:
- **No es un proxy del puntaje bruto.** Controlando el conteo de aristas del
propio tablero, la correlación parcial se queda en -0,74. En el régimen
voraz el puntaje bruto casi no informa sobre la cola (+0,08 frente al +0,605
de la fuente), lo que hace este control más estricto aquí, no más débil.
- **Mide el tablero, no el productor.** La señal se encontró en cimas de haz y
se reproduce en cimas voraces, un productor distinto con una distribución de
calidad más baja y más ancha. Una estadística que sobrevive a ese intercambio
está leyendo las piezas sobrantes, no un artefacto de cómo se construyó el
tablero.
Tableros sueltos hacen concreto el punto: la
[peor cima de cola](/viewer/?puzzle_size=16&board_edges=abeaachbadpcadidaftdabjfaeibaeteafoeaemfaeueabveacsbadtcadhdaacdencahhunptwhhjnttrujjkgrillkthjlourhmhjuuqlhvntqspwnpskphvjscafvcidaujsiwgsjnnpgujuogisjliwijurirsmtjprsllkptjoqwwvgksmwjuhsfadudweasoqwsujopmmuulwmslrlwvwlrnkvmpjnrilpkkgiokvkvulkmhgihrphdabmepcaqgmpjiggmrwmwvlrrtkvwvwtkvwvjgwvlorggllovmqllljmghhlpnqrbacrcocamjvogtgiwushlplukrwpwhtrwkuhwhqkruhhlgvvqmqgjovmpproqrqpcabhckfasiukgqiivprqlmtpwuhmtmsuujvmqovjhmkqvwppquiwvgourtrgqvgtbacvfjbaunrqigpnringtvvihnlvsvpnvlwvhwqlkrvwphkriqphoqnqrtrqgwstdafwbtearkgtpgnkntovvphtlsnppgmswqngqwtqjhhwkprhppjpnvokrkhvsntkfacnendarkmnnhskomnihmrmnwlmmsownhlsttkmhustsrtujminorrmhmortlgmcafhdofamnlosnnnnvjnriliwtgiopstloupklwosuhltnpgiiwgrluqqttlgkogfacrfubalrqwnpmojijpjjmiqphjsuvpkjhuttpjjistqwoiwolluisogmkiokqmcacpbtfaqikljvvijklquwokpmiwrgtmhsspqugssgruoslgkqjsssskkrvmqhwmcadgfufakounvuwolijjowuiinqwtkknsoiigtnqrvmtusuvgvgshunvvtkuwuwsdadsfgfauqnontmqjkqtugolqooiriqoommisommlnkojronijjrnvijktnlqosneabobdaagdadteadqbaegbabjbabqeacseaepbaepcablfaeqfafqeafpdaehbafcaad) de la reproducción puntúa 375 en bruto con
un mejor final de 16, mientras que la [mejor](/viewer/?puzzle_size=16&board_edges=adcaadhdadsdadidacidabhcacsbadpcadgdaendabveabgbabjbacvbadtcaacdcqeahwmqsoqwiqwoiklqhvrkmqlvphjqgimhngrivvlggsgvjprsvwpptwvwcafvepdammupqgqmwwvglwvwtqqwlhuqjlthmnwlrqunlhwqgwqnrjkgpppjvulkfafudofauploqgmpvomjvuwoqnoukolnttkmwhptunvhsnnnqoqnkuwojvmulwvvfacrfhcalghhmkigmnrknpgnoqtjjklqkgikpnigvoknnjroqovjwmsomsomvpnscaepchbahruhijurrijjgqiittlqlgmtiiwgisoikqjsrtrqvvitssphouisnhhueafqbjfaumhjulwmjmllinjmlktnrwpkwgsjouvgjtrurgrtisjgpgmsigtghmkqfaemfqfahnlvhsknlgosjigguksipgnksqugvgtqrusgrhoujnthmpjnpskpkssseaesfgfallogkillommiiwpmstgwnqgtuiwqliwistjiopsttnpgjnnvkvrnswuweadwfjbaovmjlrwvmorrpprogwvjksmwutmsrsmtjuhssthuplmtrqwlrqpqooiqdafwboeamniopmonrgtmolugsnhltkknqtjkmqnthmrmhiqpmorhwuiooujuinqwfacneqbailprorgltkvruvtkmkrvuhwkjnvilomnriqolirirqvpvntqjmijqkwhcacobpcajttpgiwtvwvkollwrlslwoklvntomokqqrlukgtrgkogtvphijvvjlijcadgcrbatusrhmwuvwkrlsuhuvuskokvtrwhpnqrplsnulpllkplprhkvmtrmrwmdaftbmdasiujjpjikrphunkoushwhvjswjhhhukjsntkpwnspsuvnqosujoshhrpfadubdaaueaencaepcackfachbaftfabubafteabteaelfaeoeafibaeteadpbaeeaab) puntúa 372 en
bruto con un final de 22. El tablero con menos puntaje bruto tiene el mejor
final.
## Lo que no se sigue
- **La señal muere más allá de una fila.** Con la misma etiqueta y el corte
más arriba, la correlación de la fuente se degrada de -0,74 con 16 celdas
residuales a -0,19 con 32 y -0,12 con 48, mientras el dominio medio por
celda crece de 12,5 a 32,6 y 72,2. FROSTLINE es un oráculo de final de
última fila, no una señal de dirección a mitad de construcción.
- **No compra (todavía) mejores tableros.** En el estudio fuente, usarlo para
elegir qué parciales reciben cómputo exacto no supera la elección por
puntaje bruto: el puntaje final realizado lo domina la dispersión del
puntaje bruto, mientras la energía libre solo predice un pequeño delta de
cola. El discriminador es real; el valor de selección, en esta forma, no.
- **Las cantidades secundarias dependen del régimen.** La correlación de la
entropía de Bethe cambia de signo entre regímenes, y dos cantidades nulas en
cimas de haz llevan señal débil en cimas voraces. Nada de esto toca el
resultado principal, pero todo queda anotado como salvedad en el plan
versionado.
- Nada de esto mueve un puntaje de tablero completo; para el estado real de la
frontera, ver la [página de récords](/es/research/records/).
## Reproducir
La ejecución lleva semilla y es determinista: `just research-frostline`
regenera las 120 cimas, las etiquetas exactas y la tabla completa de
correlaciones en unos dos minutos con un núcleo, y reproduce el
`frostline_r15.json` versionado. Es una reproducción de nivel cualitativo: se
regeneran el signo y la banda de fuerza del efecto; el conjunto de cimas de
haz del estudio fuente, no. La lista completa de números esperados y el
argumento de fidelidad de escala viven en el plan enlazado arriba.
## Relacionado
- [Búsqueda en haz](https://eternity2.dev/es/research/build/construct/beam-search/) — Mantener con vida los K tableros parciales más prometedores a la vez y hacerlos crecer celda a celda. La búsqueda en haz es el motor de los constructores desde cero de este proyecto, y una ilustración nítida de por qué la anchura por sí sola se estanca en las profundidades del interior.
- [La entropía y la ley de área](https://eternity2.dev/es/research/why/entropy-area-law/) — Eternity II tiene dos reglas: los bordes deben coincidir y cada pieza se usa una sola vez. La primera es generosa. Toda la dificultad reside en la segunda.
- [Calibrado en el pico de dificultad](https://eternity2.dev/es/research/why/phase-transition/) — Eternity II utiliza 22 colores, repartidos entre 17 colores interiores y 5 reservados al marco, y ese número de alrededor de 17 se sitúa cerca del punto donde este tipo de puzzle es más difícil de resolver (la transición es una banda, no un entero único).
---
# Ir rápido: cuando un solucionador gasta su presupuesto en velocidad
> Algunos motores de Eternity II vuelcan su esfuerzo en recorrer el árbol de búsqueda lo más rápido posible; otros lo gastan en el criterio sobre dónde buscar. Este es el alegato a favor de los primeros - qué compra el rendimiento bruto, las tres cosas distintas que la gente llama «rápido» y por qué el motor más rápido jamás construido sigue sin poder resolver el rompecabezas.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/going-fast/
- Actualizado: 2026-07-20
- Temas: speed, backtracking
- Fuente: McGavin: even at 100M nodes/s, the 5-hint tree is 4.9×10³² years (groups.io msg 11201) — https://groups.io/g/eternity2/message/11201
- Fuente: Razvan's epitaph for the 2025 speed thread: 'we will not make a dent' (groups.io msg 11657) — https://groups.io/g/eternity2/message/11657
---
Todo solucionador de Eternity II tiene un presupuesto fijo de esfuerzo humano y tiempo
de máquina, y gasta ese presupuesto en uno de dos lugares. Puede gastarlo en
**velocidad** - recorrer el árbol de búsqueda tan rápido como permita el hardware,
probar miles de millones de colocaciones por segundo - o en **criterio** - ser más
astuto sobre *qué* colocaciones probar, para recorrer un árbol más pequeño y mejor.
Esta página es el alegato a favor de los primeros: qué compra de veras ir rápido, qué no
compra, y cómo hablar de ello sin engañarse.
Es también el hogar conceptual de un resultado concreto: un
[backtracker de Rust portable que iguala el C afinado a mano de McGavin en tableros difíciles](/es/research/lab/experiments/raphael-anjou/jit-backtracker/)
- el motor más rápido de la historia de la comunidad - y corre a alrededor del 44 % de su
velocidad en los fáciles. Aquella página es el diario de ingeniería; esta es lo que el
diario *significa*.
## Tres cosas que la gente llama «rápido»
La mayor fuente de confusión en veinte años de discurso sobre la velocidad es que
«rápido» nombra tres cantidades sin relación. Mantenerlas separadas es ganar casi toda
la batalla.
> **Los tres ejes, y por qué no se convierten**
>
> **1 · Colocaciones por segundo (alias piezas/s, nodos/s).** Cuán rápido *avanza* la búsqueda. Es un número de motor-*y-tablero*: el C de McGavin hace ~287 M en un tablero fácil pero ~105 M en uno difícil; el [motor JIT presentado aquí](/es/research/lab/experiments/raphael-anjou/jit-backtracker/) hace ~122 M en el fácil y ~110 M en el difícil - igualando al C justo donde el rompecabezas es difícil. Mayor significa más rápido, pero siempre *en el mismo tablero*. **2 · Aristas casadas sobre 480.** Cuán *bueno* es un tablero. Ahí viven los [récords](/es/research/records/) - el techo es 470. No tiene nada que ver con el eje 1: un motor lento puede encontrar un tablero mejor que uno rápido, y lo hace a menudo. **3 · Colocaciones agregadas por segundo.** Un número de *flota* - muchas máquinas sumadas. El famoso «~300 M/s» de la comunidad que a veces se atribuye a un solo motor es en realidad el [enjambre del Eternity 2 Syndicate](/es/research/build/faster/distributed-solving/): ~20 máquinas sumadas, no un núcleo. Un número alto en el eje 1 no dice nada del eje 2, y el eje 3 no es en absoluto una velocidad de motor. Toda afirmación rigurosa de velocidad dice sobre qué eje va.
Para la historia precisa y documentada de cómo la comunidad fijó su definición de
«nodo» - piezas *colocadas*, al estilo del ajedrez, y por qué incluso eso favorece los
órdenes de llenado por fila - véase la sección sobre disciplina de medición del
[registro de ingeniería de solucionadores](/es/research/build/faster/solver-engineering/).
Esta página da ese vocabulario por sentado y pregunta para qué sirve la velocidad.
## Qué compra la velocidad
Cosas reales, y vale la pena ser concreto, porque el alegato *en contra* de la velocidad
solo cala una vez que se respeta el alegato *a favor*.
- **La enumeración verificada.** Un motor rápido y determinista puede recorrer un árbol
de referencia hasta el último nodo y *contarlo*, convirtiendo la teoría en hecho
comprobado. Los [benchmarks](/es/research/build/benchmarks/) de la comunidad - protocolos
de censo, el 10×10 que por fin cayó tras ~180 años-núcleo - son victorias de
rendimiento. No se verifica lo que no se puede terminar.
- **El determinismo como suma de comprobación.** Dos motores rápidos que recorren el
mismo árbol deben reportar el mismo número de nodos. Esa igualdad es como los
portados, las reescrituras y el hardware nuevo demuestran que recorren el mismo árbol
antes de que su velocidad signifique algo - es la columna vertebral de la
[escalera de optimización del motor JIT](/es/research/lab/experiments/raphael-anjou/jit-backtracker/),
donde cada peldaño se detiene en el número de nodos idéntico.
- **Más intentos por segundo bajo una heurística.** La velocidad es un multiplicador
del criterio: un buen bucle de reparación que corre el doble de rápido tiene el doble
de oportunidades de un tablero mejor en el mismo tiempo de reloj. La velocidad no
*reemplaza* al criterio, pero amplifica el que ya se tiene.
## Qué no puede comprar la velocidad
El muro. Y nadie ha sido más claro al respecto que quien construyó el motor más rápido.
En su mejor camino de colocación de cinco pistas - ya un árbol mucho más pequeño que el
rompecabezas en bruto - McGavin calculó que incluso a cien millones de nodos por
segundo la búsqueda tardaría unos **4,9 × 10³² años**, y que echarle miles de millones
de núcleos aún deja «órdenes de magnitud más allá de la edad del Universo»
([msg 11201](https://groups.io/g/eternity2/message/11201)). Cuando el hilo sobre
velocidad de 2025 se apagó, Razvan escribió su epitafio: por rápido que podamos
verificar, «no le haremos mella» al espacio
([msg 11657](https://groups.io/g/eternity2/message/11657)).
La aritmética es implacable y es la [lección central](/es/research/why/prune-vs-speed/) del
sitio: una aceleración de factor constante, por muy trabajada que sea, se *multiplica
contra* un número tan grande que ningún factor constante importa. Duplicar la velocidad
de recorrido de una búsqueda que tardaría 10³² años da una búsqueda que tarda 5 × 10³¹
años. Encoger el *árbol* es la única palanca con exponentes.
## El experimento controlado
Por eso justamente el [resultado del backtracker JIT](/es/research/lab/experiments/raphael-anjou/jit-backtracker/)
se plantea como un experimento de velocidad y nada más. Responde una pregunta nítida y
acotada - *¿puede el Rust portable y seguro alcanzar el rendimiento del C afinado a
mano?* - y la respuesta depende del tablero: en los tableros difíciles y profundos como
el rompecabezas real lo **iguala**, recorriendo el árbol idéntico; en los fáciles y poco
ramificados el C es unas 2,3× más rápido. Zanja una pregunta abierta menor que la
comunidad había dejado en pie: si la famosa ventaja de ~4× del motor de McGavin sobre los
solucionadores «típicos» era **oficio de generación de código** o simplemente **hardware
más nuevo**. Manteniendo el hardware fijo y alcanzando su velocidad *en tableros
difíciles* desde código portable, se demuestra que era oficio - el mismo oficio,
reproducible en un lenguaje seguro, consignado peldaño a peldaño. (También muestra dónde
rinde más el oficio: en los tableros fáciles, donde el trabajo por nodo es casi gratis,
su generación de código más ajustada sigue ganando.)
Y luego se detiene, con honestidad, donde se detiene todo motor rápido: apuntado al
rompecabezas real, se estanca en los 300 altos sobre 480, porque un backtracker
estricto es un magnífico recorredor de árboles y un pobre solucionador. Los récords
pertenecen a los motores que gastan su presupuesto del *otro* modo - en el
[criterio de destrucción-reparación](/es/research/lab/experiments/raphael-anjou/repair-study/)
y en [lo que a una búsqueda se le permite aprender](/es/research/lab/experiments/raphael-anjou/learning/) -
y llegan allí a una fracción de la velocidad.
Ese es todo el trato. La velocidad es real, aprendible y merece dominarse; el motor JIT
prueba que se puede dominar en un lenguaje seguro. Pero en Eternity II, el carril rápido
y el carril ganador no son el mismo carril. Por eso la pregunta de ingeniería
interesante nunca es solo «cuán rápido» - es «rápido *¿en qué?*, y ¿es eso el
obstáculo?»
Una nota sobre lo que se distribuye hoy: las ejecuciones detrás de estas cifras
fueron exploratorias, cualquier tablero enlazado desde estas páginas es
verificable en el visor, y todavía no existe una reproducción empaquetada de un
solo comando.
## Relacionado
- [El backtracker JIT: Rust portable a la par del C afinado a mano en tableros difíciles](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/jit-backtracker/) — Un backtracker Rust en profundidad, seguro y portable, especializado en tiempo de ejecución al emitir y compilar Rust propio de cada rompecabezas, llevado de 43 a 123 millones de nodos de búsqueda por segundo en un núcleo. Medido con justicia frente al C de Peter McGavin en la misma máquina: un empate en tableros difíciles y profundos como el Eternity II real, y alrededor del 44 % de su velocidad en los fáciles. Cada peldaño recorre el árbol idéntico; toda la ganancia es código, no algoritmo.
- [El backtracker en C de McGavin: la historia del rendimiento, reconstruida aquí](https://eternity2.dev/es/research/lab/experiments/peter-mcgavin/backtracker/) — El backtracker en C de Peter McGavin, el más rápido de la comunidad: una receta de optimización de 2007 capitalizada durante dos décadas mediante código generado, tablas de búsqueda y trucos de contador, luego compilada en mi M1 y apuntada al puzzle real de 256 piezas, donde en un solo núcleo supera las 200 de 256 piezas a ~109M colocaciones/s.
- [Ingeniería de solucionadores: el oficio bajo el algoritmo](https://eternity2.dev/es/research/build/faster/solver-engineering/) — Todos los solucionadores récord ejecutan el mismo backtracking en profundidad. Lo que los distingue es la capa de debajo: tablas de consulta, hashes perfectos, structs a medida del caché, código generado, arqueología del compilador. Ese oficio decide si un nodo cuesta 26 ciclos o 2.600. Veinte años del registro de ingeniería de la comunidad, técnica por técnica, y lo que todo ello rindió.
- [Por qué un ordenador más rápido no ayuda](https://eternity2.dev/es/research/why/prune-vs-speed/) — La idea más importante de la búsqueda combinatoria difícil: reducir el espacio que se explora vence, por un margen exponencial, a explorarlo más rápido. Eternity II está diseñado para que apenas puedas reducirlo.
---
# El estudio de las pistas
> Darle a un backtracker cinco piezas correctas gratis, en la geometría misma de las pistas del puzzle. Resulta que no ayuda, y según el orden de relleno puede dañar gravemente, porque una pieza fijada es una restricción dura que un orden de relleno fijo debe satisfacer al llegar. Una familia de órdenes de relleno, ejecutada sobre los mismos tableros con pistas, un solo núcleo, medida contra la ausencia total de pistas.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/hint-study/
- Actualizado: 2026-07-21
- Temas: backtracking, search-space, structure
- Reproducir: `just experiments hint-study`
- Fuente: Generador ejecutable + resultados versionados + scripts (el directorio de respaldo de este estudio) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/hint-study
---
Hay una respuesta popular a cómo hacer Eternity II más fácil: darle al solucionador
algunas piezas correctas. La siguiente pregunta natural es *cuántas*, y la propia
[discusión comunitaria sobre la geometría de las pistas](/es/research/why/hint-geometry/)
ya la afinó en *dónde*. Este estudio plantea algo más básico, que ambas preguntas
pasan por alto: en nuestros propios tableros generados, ¿ayudan las pistas *en
absoluto*?
Para un backtracker cronológico, la respuesta es **no**. Sémbrelo con las cinco
piezas de las pistas oficiales en sus posiciones reales del tablero, mídalo luego
contra exactamente el mismo tablero sin pistas, y rinde peor en cada orden de
relleno probado, sin excepción. En un barrido compacto fila por fila, las cinco
piezas correctas cuestan solo de diez a veinte aristas casadas; en el orden que un
recién llegado escogería primero, "llegar a las pistas y conectarlas entre sí",
cuestan alrededor de trescientos cuarenta y cinco, convirtiendo uno de los mejores
órdenes sin pistas en el peor. La razón es simple una vez vista: para un
solucionador que rellena las celdas en un orden fijo, una pieza fijada no es
información gratuita sino una **restricción dura que debe satisfacer en el momento
en que llega a ella**, y a veces no puede.
## Verlo: cinco pistas, cuatro órdenes
Cada tablero de abajo se rellena siguiendo un orden distinto, en bucle. Nada se
está *resolviendo*; esto es solo el orden en que la búsqueda visitaría las celdas,
hecho visible. La celda brillante es la recién colocada, y la estela tras ella es
el **frente de onda** reciente, de modo que puede verse cuánto borde abierto
mantiene cada orden mientras avanza. Ese borde abierto, la frontera, es lo que un
backtracker paga: su ramificación crece con la frontera, y una frontera pequeña es
también lo que deja a la búsqueda margen para rodear un fijado hostil.
> **[Interactive: HintPathFill]** Rendered on the canonical page (link above); not shown in this markdown export.
Un barrido fila por fila mantiene una sola frontera delgada y la hace rodar por el
tablero, de modo que cuando encuentra una pieza fijada puede ajustar la única fila
que está construyendo. Los órdenes que buscan las pistas hacen lo contrario.
Espiralar hacia dentro o hacia fuera arrastra un anillo entero como frontera, y
trazar las pistas dispersa su frente de onda por el tablero desde el primer
movimiento, comprometiéndose en todas partes antes de poder saber si los
compromisos son consistentes. El barrido compacto sobrevive a las cinco pistas;
los órdenes que las buscan quedan deshechos por ellas.
## Qué mide el estudio
Dos comparaciones emparejadas, ejecutadas sobre los mismos tableros generados:
- **¿Ayudan las pistas, y qué orden les sobrevive?** Fijar las pistas (cinco, en la
forma de las cinco pistas del propio Eternity II) y variar solo el orden de
relleno, medido contra el tablero idéntico sin pistas. Esta es la columna
vertebral del estudio: muestra que las pistas nunca ayudan, y que cuánto dañan lo
determina el orden de relleno y su frontera abierta.
- **El número.** ¿Ayuda añadir *más* pistas? Algo, pero la forma ingenua de medirlo
está *confundida*. Un bloque de pistas agrupadas acumula gratis un montón de
aristas correctas por el mero hecho de estar fijado; ese "suelo" gratuito halaga
a las disposiciones agrupadas en puntuación bruta sin decir nada sobre si el
tablero se volvió más fácil de *terminar*. La
[página de método](/es/research/lab/experiments/raphael-anjou/hint-study/method/)
define el suelo y las métricas inmunes a él (tasa de resolución y puntuación
ganada) que ven a través de él.
Todo aquí está construido y medido desde cero: nuestro propio generador
paramétrico de tableros, nuestra propia familia de backtrackers, nuestro propio
puntuador canónico, y un solucionador de haz como contraste no backtracker. No se
usa ningún tablero, puzzle ni motor comunitario; solo la *forma* de la disposición
de cinco pistas se toma prestada de la discusión de la lista, como geometría a
probar.
## Cómo leer las cifras
Cada tablero se vuelve a puntuar con un único puntuador canónico de aristas
casadas que nunca cuenta una costura orientada al borde (gris), la misma
convención que el [benchmark](/es/research/lab/experiments/single-core-benchmark/) y el
[estudio DFS](/es/research/lab/experiments/raphael-anjou/dfs-study/). El máximo es 480.
Cada una de las quince semillas es una instancia generada genuinamente distinta,
no meramente una semilla de solucionador diferente, de modo que la dispersión entre
semillas es varianza real de instancia a instancia y se reporta como tal. No se da
por buena ninguna puntuación autodeclarada.
Las comparaciones se desarrollan en la
[página de resultados](/es/research/lab/experiments/raphael-anjou/hint-study/findings/);
cómo se generan los tableros, por qué la receta de colores se mantiene fiel a
todos los tamaños, y qué significa cada métrica están en la
[página de método](/es/research/lab/experiments/raphael-anjou/hint-study/method/).
## Páginas de esta sección
- [Cómo se construye el estudio de las pistas](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/hint-study/method/) — El aparato detrás del estudio de las pistas: un generador paramétrico de tableros fiel a la receta de colores de Eternity II en todos los tamaños, la familia de backtrackers por orden de relleno, el único puntuador canónico, y la pieza de aritmética que mantiene significativo el eje del número, el suelo de costuras fijadas.
- [Qué mostró el estudio de las pistas](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/hint-study/findings/) — Los resultados, desarrollados: en estos tableros las cinco pistas con forma de pistas oficiales nunca ayudan a un backtracker, van de un coste moderado a una catástrofe, y el orden de relleno decide cuánto daño hacen; las puntuaciones son bimodales, no un gradiente suave; y la pregunta por el número de pistas está confundida por un suelo gratuito de costuras fijadas.
## Relacionado
- [Los experimentos de Raphaël Anjou](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/) — Un cuaderno de experimentos de búsqueda sobre Eternity II, organizado en torno a los motores compartidos sobre los que se ejecutan, las pipelines de combinación que persiguen la puntuación, cuatro estudios que desmontan un paradigma de búsqueda una decisión a la vez, y resoluciones exactas de final de partida. Cada uno expone su idea, su mejor tablero y las preguntas que deja abiertas. El mejor alcanza 463 de 480.
- [El estudio DFS](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/) — Una sola pregunta, planteada con cuidado: entre los backtrackers en profundidad para Eternity II, ¿qué aporta realmente cada orden de relleno, cada heurística y el mecanismo de ruptura? Una familia de backtrackers escritos desde cero, separados cada uno por un único cambio, ejecutados sobre las mismas diez variantes con esquinas fijadas, en un solo núcleo, durante sesenta segundos.
- [Dónde colocas las pistas importa más que cuántas](https://eternity2.dev/es/research/why/hint-geometry/) — En un puzzle de 16×16 construido como Eternity II, dieciocho pistas repartidas por el tablero lo resuelven en minutos, mientras que amontonarlas en filas contiguas necesita un centenar solo para bajar la búsqueda a decenas de miles de millones de colocaciones. La posición, no la cantidad, es la palanca, y apunta directamente a la fase final.
---
# Qué mostró el estudio de las pistas
> Los resultados, desarrollados: en estos tableros las cinco pistas con forma de pistas oficiales nunca ayudan a un backtracker, van de un coste moderado a una catástrofe, y el orden de relleno decide cuánto daño hacen; las puntuaciones son bimodales, no un gradiente suave; y la pregunta por el número de pistas está confundida por un suelo gratuito de costuras fijadas.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/hint-study/findings/
- Actualizado: 2026-07-21
- Temas: backtracking, structure, search-space
- Fuente: Resultados por ejecución versionados (results.jsonl) y el script de análisis — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/hint-study
---
El estudio fija cinco pistas en la forma de las cinco pistas del propio Eternity
II, ejecuta ocho órdenes de relleno sobre los tableros idénticos, y hace una
pregunta simple: ¿qué valen esas cinco pistas? Cada número de abajo es sobre
quince instancias generadas distintas, un solo núcleo, ocho segundos por
ejecución, re-puntuado sobre 480 por un único puntuador canónico. La comparación
es emparejada, cada orden de relleno ve los mismos tableros, y la dispersión por
instancia se muestra en lugar de promediarse, porque resulta que importa más que
cualquier mediana.
## Las pistas no ayudan, y el orden de relleno decide cuánto dañan
Empecemos por la distribución. Cada punto es un tablero; la marca es la mediana.
> **[Interactive: HintStudyCharts]** Rendered on the canonical page (link above); not shown in this markdown export.
Dos cosas se ven de inmediato. Primero, las puntuaciones son **bimodales**: en la
mayoría de los órdenes, un tablero o trepa a los 360 o se atasca en los dos
dígitos, con poco término medio. Una mediana trazada a través de eso resume una
brecha, no un centro, que es exactamente por lo que se muestran los puntos.
Segundo, los órdenes se separan con fuerza: los tres barridos compactos (fila por
fila, su espejo de abajo arriba, el peine de Verhaard) quedan altos en la mayoría
de los tableros; los órdenes fragmentadores quedan bajos de principio a fin.
Pero la separación compacto-contra-fragmentador no es el verdadero hallazgo,
porque invita a la pregunta equivocada, "¿qué orden *usa* mejor las pistas?". La
pregunta que importa es si las pistas ayudan *en absoluto*. El segundo gráfico la
responde, y la respuesta es no. Muestra el **cambio emparejado** de añadir las
cinco pistas: la puntuación de cada orden en un tablero menos su puntuación en el
*mismo tablero sin pistas*.
Cada barra está en cero o por debajo. Las cinco pistas con forma de pistas
oficiales no ayudan a un solo orden de relleno. En los barridos compactos cuestan
solo de diez a veinte puntos. En la espiral hacia fuera cuestan unos noventa. Y en
los dos órdenes que buscan las pistas son ruinosas: el orden `trace-hints`, que
dibuja un esqueleto entre las pistas antes de rellenar, pierde unos trescientos
veinticinco, y la inundación `connect-hints-first` pierde aproximadamente
**trescientos cuarenta y cinco**, llevando un orden que puntúa entre los
*mejores* de los ocho sin pistas al *peor* con ellas. Cuanto más deliberadamente
un orden persigue las pistas, más le cuestan. Entregar al solucionador cinco
piezas correctas, en la geometría misma de las pistas del puzzle, hizo peor cada
versión de él.
## Por qué una pista correcta hace daño
Una pieza fijada no es información gratuita para un backtracker cronológico; es
una **restricción dura que el orden de relleno fijo debe satisfacer al llegar**.
Cuando un barrido compacto baja rodando hasta una celda interior fijada, la pieza
ya está allí, y la fila que acaba de construir tiene que casar con las caras de
esa pieza. La mayor parte del tiempo puede, a un coste pequeño: el barrido
esquiva la restricción y pierde unas decenas de puntos. Pero en algunos tableros
la pieza fijada contradice aquello a lo que la frontera ya se comprometió, y no
hay reparación local: la búsqueda choca contra un muro que no puede cruzar y se
revuelve por debajo de él. Ese es el modo atascado, y son las pistas las que lo
crean. En fila por fila, los tableros que se hunden a los dos dígitos son
precisamente aquellos donde un fijado con forma de pista cae donde el barrido no
puede honrarlo; el mismo tablero sin fijados trepa a los 360 y 370.
Esto reencuadra el resultado sobre el orden de relleno. El orden sigue importando
(un barrido compacto sobrevive a las restricciones de las pistas con una cicatriz
de diez a veinte puntos mientras `connect-hints-first` queda destruido por
ellas), pero lo que el orden compra no es "usar bien las pistas". Es
**sobrevivirlas**. La frontera es el porqué: un orden que mantiene una única
frontera prieta tiene margen para rodear un fijado adverso; un orden que ya se ha
fragmentado en cinco manchas abiertas se ha comprometido en todas partes a la vez
y no puede.
Esa relación con la frontera, a través de los ocho órdenes, es llamativamente
limpia, y merece mostrarse precisamente porque la frontera puede computarse desde
la geometría de un orden sin ningún solucionador, y confrontarse luego con las
puntuaciones medidas:
> **[Interactive: FrontierPhaseChart]** Rendered on the canonical page (link above); not shown in this markdown export.
La frontera abierta media que un orden mantiene predice de cerca su puntuación
mediana a través de estos ocho órdenes. Es una relación descriptiva fuerte, no una
ley probada sobre ocho puntos, y deja de zanjar el orden de llegada entre los
órdenes fragmentadores de la derecha (la espiral hacia dentro mantiene una
frontera mayor que la espiral hacia fuera y sin embargo puntúa más alto). Pero la
dirección es exactamente la que el mecanismo predice: el coste de ramificación es
multiplicativo en la frontera, así que un orden que mantiene la frontera pequeña
conserva el margen para absorber un fijado hostil.
Como contraste, el solucionador de haz, que no es un backtracker cronológico y no
paga el coste de la frontera de la misma manera, alcanza una mediana en los 450
sobre estos mismos tableros con pistas. Las pistas y los tableros no están ni
cerca de ser irresolubles. Es específicamente el backtracker *cronológico de
orden fijo* el que no puede convertir cinco piezas correctas en progreso.
## El número: un umbral, no un gradiente, y un suelo que lo esconde
La misma pregunta un nivel más allá: ¿ayuda añadir *más* pistas? La respuesta no
es un suave "cuantas más, mejor", y el número bruto esconde qué parte es real.
El gráfico inferior de arriba divide la puntuación de cada disposición en dos
partes. El **suelo** son las costuras que los fijados completan gratis, porque
sus dos extremos están fijados a la solución verdadera; la parte **ganada** es lo
que la búsqueda encontró de verdad. Un bloque agrupado macizo acumula un suelo
alto (cinco bloques de 4×4 fijan un cuarto de las costuras de todo el tablero
antes de que la búsqueda dé un solo paso), mientras que una retícula dispersa,
cuyas pistas nunca se tocan, no acumula nada. Así que una comparación de
puntuación bruta regala a las disposiciones agrupadas una ventaja de cien puntos
que no dice nada sobre si la búsqueda avanzó.
Lea la columna ganada a través de las retículas dispersas, cuyo suelo es cero de
modo que lo ganado *es* la puntuación, y aparece un umbral. Una dispersión
escasa, de cuatro a dieciséis pistas, no gana casi nada (en los veintitantos):
los fijados son solo restricciones dispersas con las que el barrido tropieza una
y otra vez, exactamente el efecto de las cinco pistas. Pero siga añadiendo y el
cuadro se invierte. Veinticinco pistas dispersas ganan 127, y treinta y seis, una
retícula de seis por línea, **resuelven el tablero por completo en la mayoría de
las instancias**. Por debajo del umbral las pistas dispersas solo estorban; por
encima, por fin hay suficientes para trocear el tablero en piezas lo bastante
pequeñas como para que el barrido las termine. No es un gradiente de ayuda, sino
un muro que el número tiene que superar.
Los bloques agrupados muestran la imagen especular. Su puntuación bruta es sobre
todo *suelo*: cinco bloques de 4×4 (ochenta pistas, un cuarto del tablero) sí
resuelven cada instancia, pero han fijado tanto tablero que lo han medio resuelto
a mano. Quite el suelo y las disposiciones agrupadas por debajo de ese extremo
ganan solo dos dígitos, viviendo de las costuras gratuitas. Así que la verdadera
historia del número no es "más pistas ayudan" ni "más pistas dañan", sino: hace
falta *un montón* de pistas correctas, dispersas o agrupadas, para mover a un
backtracker cronológico, y hasta alcanzar esa cantidad los fijados extra tienen
tantas probabilidades de hacer tropezar la búsqueda como de acelerarla.
La [página de método](/es/research/lab/experiments/raphael-anjou/hint-study/method/)
desarrolla al completo la aritmética del suelo.
## Disperso contra contiguo: obtenemos lo contrario
La [redacción comunitaria sobre la geometría de las pistas](/es/research/why/hint-geometry/)
formula una versión más afilada de la afirmación sobre la colocación: dieciocho
pistas *dispersas* en una retícula resuelven en minutos un puzzle 16×16 de tipo
E2, mientras que dieciocho apiladas en filas superiores *contiguas* apenas
ayudan, y hacen falta ochenta o más pistas contiguas para igualar a las dieciocho
dispersas. Ese resultado se midió en un puzzle concreto con un motor concreto.
Pusimos sus dos disposiciones exactas, la retícula dispersa de las filas {1,3,5}
y el bloque superior de dieciocho celdas, sobre nuestros propios tableros
generados y solucionadores para ver si la dirección se sostiene.
> **[Interactive: HintGeoComparison]** Rendered on the canonical page (link above); not shown in this markdown export.
No se sostiene. En nuestros tableros, las dieciocho **contiguas** puntúan *más
alto* que las dieciocho dispersas en siete de los ocho órdenes de relleno, y por
un margen amplio: un barrido fila por fila alcanza una mediana de 377 con el
bloque contiguo y solo 138 con la retícula dispersa. Esto parece una
contradicción frontal, y merece la pena ser preciso sobre por qué no lo es del
todo.
Los dos estudios miden cosas distintas. El resultado comunitario trata del
*tiempo hasta una solución completa*: las pistas dispersas alcanzan el final de
partida profundo donde un backtracker gasta casi todo su tiempo, así que podan la
parte cara, mientras que un bloque contiguo superior poda solo la apertura
barata. Nuestro número es *puntuación de aristas casadas a presupuesto corto*, y
a ocho segundos ninguno de estos backtrackers estrictos llega al final de
partida. Lo que un bloque contiguo anclado arriba sí compra, de inmediato, es una
gran región correcta contra la que el barrido fila por fila puede construir, así
que la puntuación sube rápido aunque la parte difícil del tablero quede intacta.
Las pistas dispersas, en cambio, fragmentan el relleno temprano exactamente como
lo hacía la forma de cinco pistas. Así que los dos resultados son consistentes en
cuanto se separa "resuelve todo el tablero con el tiempo" de "puntúa bien en los
primeros ocho segundos": la colocación dispersa ayuda a lo primero y perjudica a
lo segundo. La sección siguiente hace visible esa separación.
## Resolverlo: donde lo disperso por fin gana
A 16×16 nada se resuelve en ocho segundos, así que la puntuación es siempre una
instantánea de una búsqueda todavía en su apertura. Para ver el efecto de *final
de partida* que la comunidad reportó, necesitamos un tablero que se resuelva por
completo. Un 8×8 construido con la misma receta de colores lo hace, en bastante
menos de un segundo, así que sobre él podemos medir la cantidad que de verdad
importa: el número de nodos de búsqueda que un backtracker fila por fila necesita
para alcanzar una solución completa. Menos nodos significa que las pistas
hicieron trabajo real de poda. Abajo, una retícula dispersa y un bloque contiguo
emparejado, a números de pistas crecientes.
> **[Interactive: SolveSpeedChart]** Rendered on the canonical page (link above); not shown in this markdown export.
Esta es toda la historia en un gráfico, y por fin encaja con la afirmación
comunitaria. Con cuatro pistas la retícula dispersa es *peor* que inútil,
resolviendo solo dos de treinta tableros, el mismo efecto de
pistas-escasas-que-hacen-tropezar de cada uno de los otros ejes, mientras que el
bloque contiguo emparejado los resuelve casi todos. Pero cruce un umbral en torno
a dieciséis pistas y las líneas se intercambian con fuerza: una retícula dispersa
de dieciséis pistas se resuelve en unos cuatro mil nodos, mientras que el bloque
contiguo emparejado todavía muele casi dos millones, una diferencia de quinientas
veces al mismo número de pistas. Empuje más lejos y ambas disposiciones se
vuelven fáciles (con treinta y seis pistas un cuarto del tablero está fijado y
cualquiera de las dos se resuelve en unos cientos de nodos), así que la ventaja
dispersa es una ventana, la más ancha donde el número basta para alcanzar la
búsqueda profunda pero no es tan grande que el tablero esté medio resuelto a
mano. En esa ventana, las pistas dispersas alcanzan la parte de la búsqueda con
la que un backtracker de verdad batalla y la cortan de raíz, exactamente como
Joe y Peter McGavin lo describieron; un bloque contiguo solo poda la apertura
fácil. La comparación de puntuaciones a 16×16 solo pareció contradecirlos porque
a presupuesto corto la búsqueda nunca vive lo suficiente para llegar a la región
donde la colocación dispersa rinde.
## Lo que dice y lo que no dice
Este es un resultado sobre **backtrackers estrictos, cronológicos, en
profundidad**, sobre tableros 16×16 generados con la receta de colores de
Eternity II, a presupuesto corto (ocho segundos). Cada una de esas palabras de
acotación se gana su lugar. *Cronológico*: el resultado es específico de los
solucionadores que rellenan celdas en un orden fijo y deben satisfacer una pieza
fijada cuando la alcanzan, un solucionador de haz, que no lo hace, llega a los
450 en los mismos tableros. *Generado*: los tableros comparten la receta de
colores de E2 y la *forma* de sus cinco pistas, pero no son el puzzle oficial, y
el estudio no le transfiere ningún número. *Presupuesto corto*: ninguno de estos
backtrackers estrictos resuelve en ocho segundos, así que esto mide hasta dónde
llega cada uno, no una carrera hacia 480; si el efecto "las pistas dañan"
sobrevive a presupuestos mucho más largos queda sin probar aquí.
Dentro de ese ámbito la lección es sólida y, creemos, contraintuitiva: para un
backtracker cronológico, cinco piezas correctas colocadas en la geometría misma
de las pistas del puzzle no son un regalo sino una restricción, y pueden costar
mucho más de lo que dan. Lo que decide el daño no son las pistas sino el orden de
relleno que tiene que vivir con ellas, y el orden paga una pista como paga todo
lo demás, en el tamaño de la frontera que mantiene abierta. Es una lectura más de
[por qué el puzzle se resiste](/es/research/why/hint-geometry/): incluso la
información correcta solo ayuda a un solucionador construido para recibirla.
## Relacionado
- [El estudio de las pistas](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/hint-study/) — Darle a un backtracker cinco piezas correctas gratis, en la geometría misma de las pistas del puzzle. Resulta que no ayuda, y según el orden de relleno puede dañar gravemente, porque una pieza fijada es una restricción dura que un orden de relleno fijo debe satisfacer al llegar. Una familia de órdenes de relleno, ejecutada sobre los mismos tableros con pistas, un solo núcleo, medida contra la ausencia total de pistas.
- [Cómo se construye el estudio de las pistas](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/hint-study/method/) — El aparato detrás del estudio de las pistas: un generador paramétrico de tableros fiel a la receta de colores de Eternity II en todos los tamaños, la familia de backtrackers por orden de relleno, el único puntuador canónico, y la pieza de aritmética que mantiene significativo el eje del número, el suelo de costuras fijadas.
- [Dónde colocas las pistas importa más que cuántas](https://eternity2.dev/es/research/why/hint-geometry/) — En un puzzle de 16×16 construido como Eternity II, dieciocho pistas repartidas por el tablero lo resuelven en minutos, mientras que amontonarlas en filas contiguas necesita un centenar solo para bajar la búsqueda a decenas de miles de millones de colocaciones. La posición, no la cantidad, es la palanca, y apunta directamente a la fase final.
- [El estudio DFS](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/) — Una sola pregunta, planteada con cuidado: entre los backtrackers en profundidad para Eternity II, ¿qué aporta realmente cada orden de relleno, cada heurística y el mecanismo de ruptura? Una familia de backtrackers escritos desde cero, separados cada uno por un único cambio, ejecutados sobre las mismas diez variantes con esquinas fijadas, en un solo núcleo, durante sesenta segundos.
---
# Cómo se construye el estudio de las pistas
> El aparato detrás del estudio de las pistas: un generador paramétrico de tableros fiel a la receta de colores de Eternity II en todos los tamaños, la familia de backtrackers por orden de relleno, el único puntuador canónico, y la pieza de aritmética que mantiene significativo el eje del número, el suelo de costuras fijadas.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/hint-study/method/
- Actualizado: 2026-07-21
- Temas: backtracking, structure, search-space
- Fuente: El generador paramétrico y el motor de órdenes de relleno (el directorio de respaldo de este estudio) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/hint-study
---
Esta página es el aparato detrás del
[estudio de las pistas](/es/research/lab/experiments/raphael-anjou/hint-study/):
cómo se generan los tableros, por qué se mantienen fieles a Eternity II en todos
los tamaños, la familia de órdenes de relleno, y la pieza que más importa para
leer correctamente los resultados, la aritmética del *suelo de costuras fijadas*,
que es lo que separa un efecto real de un artefacto de medición en el eje del
número.
## Los tableros: un generador fiel, paramétrico en tamaño
Cada instancia se genera desde cero, con semilla y determinista: el mismo triplete
`(size, colours, seed)` produce el mismo tablero en cualquier máquina. Un tablero
generado es un tablero *resuelto*, la pieza $i$ ocupa la celda $i$ con rotación
cero, cuyos identificadores de pieza se reetiquetan después mediante una
permutación con semilla, de modo que una pista para la celda `pos` fija la pieza
verdadera (reetiquetada), y un solucionador no puede simplemente recorrer la
colocación identidad.
La receta de colores refleja exactamente la estructura del puzzle oficial. En un
tablero $n\times n$ hay
$$
E(n) \;=\; 2\,n\,(n-1)
$$
costuras interiores (las aristas casadas; $E(16) = 480$). Estas se dividen en una
**banda de marco**, las costuras que unen dos piezas de borde a lo largo del
perímetro, y el interior profundo. Los cinco *colores de borde* están confinados a
la banda de marco y nunca aparecen en el interior; los *colores interiores*
aparecen tanto en el interior profundo como en la cara orientada hacia dentro de
las piezas de borde. Este es el hecho estructural definitorio de un tablero
Eternity II real, y el generador lo reproduce y se testea contra él.
### Por qué el censo está automáticamente equilibrado (una afirmación que conviene enunciar con cuidado)
Es tentador, y las primeras redacciones lo hicieron, presentar el censo de colores
*par* de Eternity II como un regalo especialmente afinado: cada color aparece un
número par de veces, de modo que los emparejamientos $\sum_c N_c / 2$ de una
solución perfecta encajan con holgura cero. La paridad par es real, pero **no** es
un logro de afinado. Está forzada.
Un color pintado sobre $k$ costuras interiores aparece en exactamente $2k$ caras
de pieza, una a cada lado de cada costura. Así que para todo color $c$,
$$
N_c \;=\; 2\,k_c \quad\text{es par, para cualquier coloreado de costuras.}
$$
La paridad de holgura cero es por tanto automática para *cualquier* tablero
construido coloreando costuras; no dice nada especial sobre Eternity II. Las
propiedades que de verdad soportan carga, y que el generador debe conseguir, son
tres: los colores de borde confinados a la banda de marco, los recuentos por color
mantenidos **equilibrados** (para que ningún color sea tan escaso que
sobre-restrinja), y cada pieza **distinta salvo rotación** (para que una pista
fijada nombre una pieza única). La redacción del estudio es precisa en esto donde
el encuadre anterior no lo era.
### Escalar la receta sin cambiar la dificultad
El generador y el solucionador son ambos paramétricos en tamaño, el tablero puede
ser $8\times8$ o $12\times12$ con la misma facilidad que $16\times16$, lo que abre
una continuación natural: ¿se *refuerza* el efecto de la colocación conforme el
tablero crece? Responder eso limpiamente necesita una receta de colores que no
cambie la *dificultad* del puzzle cuando cambia el tamaño. Mantener simplemente
fijos los *recuentos* de colores mientras crece $n$ haría el puzzle
estructuralmente *más fácil* a $n$ grande: con más costuras y la misma paleta,
cada color se repite más a menudo, la celda media acepta más vecinos y la
restricción se afloja. Eso confundiría tamaño con dificultad.
En su lugar, la receta mantiene la **multiplicidad por color** aproximadamente
constante. Escribiendo $F(n)$ para el número de costuras de la banda de marco y
$E(n) - F(n)$ para el interior, el número de colores de borde e interiores se
elige como
$$
b(n) \;=\; \operatorname{round}\!\Big(\tfrac{F(n)}{12}\Big), \qquad
i(n) \;=\; \operatorname{round}\!\Big(\tfrac{E(n) - F(n)}{24}\Big),
$$
apuntando a las multiplicidades que el propio Eternity II usa en $n=16$ (borde
$\approx 12$, interior $\approx 24$). En $n=16$ esto devuelve exactamente la
receta oficial, cinco colores de borde y diecisiete interiores.
Conseguir esto en tableros pequeños exigió una corrección del generador. La paleta
de Eternity II es *de dominante interior*, cinco colores de borde frente a
diecisiete interiores, pero el generador por defecto limita el número de colores
de borde a cinco y toma todo lo demás como interior, lo que en un tablero pequeño
invierte la proporción: en $8\times8$ la receta quiere ocho colores, y el tope los
repartiría en cinco de borde y uno interior, un mar interior casi uniforme que no
se comporta en nada como E2. El generador acepta ahora un número explícito de
colores de borde, y la receta mantiene el interior en aproximadamente el triple
del borde en cada tamaño ($8\times8 \to$ dos de borde, seis interiores;
$16\times16 \to$ cinco y diecisiete, sin cambio). Con eso, los tableros pequeños
son fieles *y* plenamente resolubles, que es de lo que depende la comparación de
velocidad de resolución de la
[página de resultados](/es/research/lab/experiments/raphael-anjou/hint-study/findings/).
Los resultados principales de órdenes y número están todos a $16\times16$; el
tablero $8\times8$ se usa solo donde hace falta una resolución completa.
## Las geometrías de pistas
Cada disposición es una función pura del tamaño del tablero, de modo que la misma
geometría puede dibujarse, medirse y escalarse de forma consistente. La galería de
abajo las renderiza todas desde la única primitiva de tablero compartida.
> **[Interactive: HintLayoutGallery]** Rendered on the canonical page (link above); not shown in this markdown export.
## El suelo de costuras fijadas: mantener significativo el eje del número
Aquí está la sutileza que remodeló el estudio. Pregunte "¿ayudan más pistas?" y el
movimiento obvio es comparar puntuaciones finales con distintos números de pistas.
Pero una pista hace dos cosas distintas a la vez, y la puntuación las confunde:
1. **retira una pieza** de la búsqueda (la parte útil, poda el árbol);
2. **puede completar una costura gratis**, si una celda vecina también está
fijada.
El segundo efecto es un puro regalo contable. Definamos el **suelo de costuras
fijadas** de una disposición como el número de costuras interiores con *ambos*
extremos fijados:
$$
\text{suelo} \;=\; \#\{\, \text{costuras interiores } (u,v) : u \text{ y } v \text{ ambas con pista} \,\}.
$$
Como los fijados son piezas de la solución verdadera, cada una de esas costuras
está garantizada correcta antes de que el solucionador arranque. Un bloque
agrupado macizo de $k\times k$ aporta $2k(k-1)$ de ellas; cinco bloques de $k{=}4$
acumulan $5 \cdot 24 = 120$ costuras correctas, un **cuarto de las 480 totales**,
gratis. Una retícula dispersa, cuyas pistas nunca se tocan, tiene un suelo de
**cero**.
Así que una comparación de puntuación bruta **halaga** sistemáticamente a las
disposiciones agrupadas: parten con más de cien puntos de ventaja por pura
contabilidad, con independencia de si el tablero se volvió más fácil de
*terminar*. Es la misma familia de error que contar las costuras del perímetro en
un tablero parcial, un suelo que infla el número sin reflejar progreso. El
conmutador de la galería de arriba dibuja esas costuras acumuladas para que la
puntuación gratuita sea visible.
El estudio, por tanto, no clasifica las disposiciones por puntuación bruta en el
eje del número. Usa dos métricas inmunes al suelo:
- la **tasa de resolución**, la fracción de instancias que un orden completa de
verdad hasta 480;
- la **profundidad alcanzada**, cuánto avanzó la búsqueda más allá de las celdas
fijadas, sobre 256.
Ambas miden si la búsqueda hizo *un progreso que los fijados no le regalaron*. En
el eje de los órdenes, donde cada disposición comparada comparte las *mismas*
pistas y por tanto el mismo suelo, la puntuación bruta es directamente comparable
y se usa.
## Medir contra la ausencia de pistas, emparejado por instancia
La pregunta "¿qué valen las pistas?" solo tiene respuesta relativa a *no*
tenerlas. Así que el eje de los órdenes se ejecuta dos veces en cada tablero: una
con las cinco pistas en forma de pistas oficiales, otra sin ninguna
(`baseline_00`), y el efecto reportado es la **diferencia emparejada**, la
puntuación con pistas menos la puntuación sin pistas sobre el *mismo* tablero
generado. Emparejar por instancia elimina la varianza de dificultad de tablero a
tablero, que en estos tableros bimodales es lo bastante grande como para ahogar el
efecto si las dos condiciones se compararan sobre semillas distintas. Una
diferencia emparejada negativa significa que las pistas hicieron ese orden de
relleno peor de lo que era con un interior en blanco, que es lo que reportan los
resultados. Todas las comparaciones usan el conjunto común de semillas que
llegaron a término, de modo que cada orden y cada disposición se agregan sobre
las instancias idénticas.
## Los órdenes de relleno, y por qué la frontera es la palanca
El motor es el [backtracker DFS](/es/research/lab/experiments/raphael-anjou/dfs-study/)
hermano de este estudio, ejecutado en estricto (sin rupturas, sin propagación) de
modo que **el orden de relleno sea lo único que cambia**. Los órdenes probados son
fila por fila, su espejo de abajo arriba, la espiral hacia dentro, la espiral
hacia fuera, borde primero, el peine de Verhaard, un control de
filas-de-pistas-primero, y el orden propio del estudio que busca las pistas,
`connect-hints-first`.
¿Por qué importa tanto el orden? El coste de un backtracker lo gobierna la
**frontera abierta**: el conjunto de celdas ya rellenas todavía adyacentes a una
vacía. Cuando la siguiente celda se coloca contra una frontera de tamaño $f$, el
número de tableros parciales que la búsqueda puede tener que considerar crece
multiplicativamente en $f$, la ramificación es exponencial en la frontera, no en
el tablero. Un único barrido compacto mantiene $f$ en torno a una fila
($\approx n$); un orden que abre manchas alrededor de $k$ pistas dispersas lleva
$k$ fronteras a la vez, y
$$
\text{trabajo} \;\sim\; \prod_{j} b^{\,f_j} \;=\; b^{\sum_j f_j},
$$
de modo que fragmentar el relleno en regiones desconectadas multiplica el coste,
no lo suma. Esto es exactamente por lo que `connect-hints-first`, el orden que
*busca* las pistas, es el peor: alcanzar las pistas pronto vale mucho menos que
mantener la frontera pequeña, y conectar anclas dispersas hace justo lo contrario
de mantenerla pequeña.
## Cómo leer las cifras
Cada tablero se vuelve a puntuar con un único puntuador canónico de aristas
casadas que nunca cuenta una costura orientada al borde (gris). El máximo es
$E(n)$ ($480$ en $16\times16$). Cada una de las quince semillas es una instancia
generada distinta, así que la dispersión entre semillas es varianza genuina de
instancia. El rendimiento, donde se reporta, es en nodos de búsqueda por segundo y
nunca se compara entre órdenes distintos, porque un nodo bajo un orden no es la
misma unidad de trabajo que bajo otro. Todo el aparato, generador, disposiciones,
resultados por ejecución y el script de rejilla, vive en el
[directorio de respaldo](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/hint-study)
del estudio, y `just experiments hint-study` lo relanza todo.
## Relacionado
- [El estudio de las pistas](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/hint-study/) — Darle a un backtracker cinco piezas correctas gratis, en la geometría misma de las pistas del puzzle. Resulta que no ayuda, y según el orden de relleno puede dañar gravemente, porque una pieza fijada es una restricción dura que un orden de relleno fijo debe satisfacer al llegar. Una familia de órdenes de relleno, ejecutada sobre los mismos tableros con pistas, un solo núcleo, medida contra la ausencia total de pistas.
- [Qué mostró el estudio de las pistas](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/hint-study/findings/) — Los resultados, desarrollados: en estos tableros las cinco pistas con forma de pistas oficiales nunca ayudan a un backtracker, van de un coste moderado a una catástrofe, y el orden de relleno decide cuánto daño hacen; las puntuaciones son bimodales, no un gradiente suave; y la pregunta por el número de pistas está confundida por un suelo gratuito de costuras fijadas.
- [Dónde colocas las pistas importa más que cuántas](https://eternity2.dev/es/research/why/hint-geometry/) — En un puzzle de 16×16 construido como Eternity II, dieciocho pistas repartidas por el tablero lo resuelven en minutos, mientras que amontonarlas en filas contiguas necesita un centenar solo para bajar la búsqueda a decenas de miles de millones de colocaciones. La posición, no la cantidad, es la palanca, y apunta directamente a la fase final.
---
# El backtracker JIT: Rust portable a la par del C afinado a mano en tableros difíciles
> Un backtracker Rust en profundidad, seguro y portable, especializado en tiempo de ejecución al emitir y compilar Rust propio de cada rompecabezas, llevado de 43 a 123 millones de nodos de búsqueda por segundo en un núcleo. Medido con justicia frente al C de Peter McGavin en la misma máquina: un empate en tableros difíciles y profundos como el Eternity II real, y alrededor del 44 % de su velocidad en los fáciles. Cada peldaño recorre el árbol idéntico; toda la ganancia es código, no algoritmo.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/jit-backtracker/
- Actualizado: 2026-07-20
- Temas: speed, backtracking
- Reproducir: `cargo run --release -p dfs-codegen --bin run_dfs_codegen_jit -- --puzzle P.json --chain2 --opt native`
- Fuente: Peter McGavin's genbody71.zip — the C reference this engine chases (groups.io msg 11749) — https://groups.io/g/eternity2/message/11749
- Fuente: rust-lang/rust#80630 — LLVM cannot lower loop+match to a computed goto (why the function-chain design exists) — https://github.com/rust-lang/rust/issues/80630
- Fuente: The eternity2 repository on GitHub — https://github.com/raphael-anjou/eternity2
---
> **Qué es este experimento, y qué no es**
>
> Es un experimento de **velocidad**, no de resolución. Plantea una sola pregunta: ¿puede un backtracker de Rust *seguro y portable* alcanzar el rendimiento del motor más rápido de la comunidad - el [C afinado a mano de Peter McGavin](/es/research/lab/experiments/peter-mcgavin/backtracker/) - sin salir de Rust ni bajar a ensamblador? La respuesta depende del tablero: en los tableros **difíciles y profundos como el Eternity II real, iguala a su C**; en los fáciles y poco ramificados, su C es unas **2,3× más rápido**. No dice nada de los *puntajes*: recorrer el árbol rápido y encontrar un tablero de alto puntaje son [ejes completamente distintos](/es/research/lab/experiments/raphael-anjou/going-fast/). Lo mejor que este motor alcanza en el rompecabezas real está en los 300 altos sobre 480, justo donde un backtracker estricto debe detenerse - los tableros récord vienen de metaheurísticas, no de recorrer más rápido.
Todo motor rápido de Eternity II es, por debajo, el mismo backtracker en profundidad:
llenar celdas en un orden fijo, probar cada pieza que encaja, descender, retroceder al
primer callejón sin salida. La
[página de McGavin](/es/research/lab/experiments/peter-mcgavin/backtracker/) cuenta la
historia del rendimiento del motor C que lleva años ostentando la corona de velocidad
mononúcleo de la comunidad. Esta página es la otra cara: cuánto puede acercarse el
*Rust portable*, y dónde cae la línea rigurosa.
El resultado depende del tablero, y ahí está lo interesante. Medido en mi Apple M1, en
un núcleo, ambos motores compilados sin pantalla con generación de código nativa y
ejecutados uno tras otro:
| Tablero | C de McGavin (sin pantalla) | Este motor | Resultado |
| --- | --- | --- | --- |
| Fácil (71.puz de Joe, 18 pistas) | ~287 M/s | ~122 M/s | McGavin **~2,3×** |
| **Difícil (16×16 profundo, como el E2 real)** | **~102–105 M/s** | **~104–111 M/s** | **~empate** |
En los tableros que de veras se parecen a Eternity II - profundos, densamente
restringidos, donde la búsqueda pasa el tiempo retrocediendo - un motor Rust seguro y
portable **iguala al C afinado a mano**. En los tableros fáciles y poco ramificados,
donde casi no hay nada que hacer por nodo, el C en línea recta de McGavin es más del
doble de rápido. Ambos números son reales; la ingeniería de abajo es lo que llevó a
Rust al empate en tableros difíciles.
Todo lo que sigue es **generación de código y disposición de datos**, no una búsqueda
más astuta: cada peldaño recorre el árbol *idéntico* y, en un tablero de prueba soluble,
se detiene en el *mismo número de nodos*. Ese invariante es la columna vertebral de todo
el experimento, así que conviene enunciarlo primero.
> **Mide la referencia a plena velocidad, o te engañarás a ti mismo**
>
> Una versión anterior de este trabajo informó que *superábamos* a McGavin sin más. Era falso, y la razón es instructiva. El motor de McGavin trae una pantalla de terminal en vivo (`#define INTERACTIVE`): un estado que redibuja sin cesar. Esa pantalla le cuesta cerca del **2,7× de su rendimiento** - su velocidad sin pantalla es ~287M en el tablero fácil, pero con la pantalla lee ~106M. La primera comparación enfrentó nuestro motor sin pantalla con su binario *frenado* y produjo una victoria fantasma. Reconstruido sin pantalla (`-mcpu=native`), el cuadro real es el de arriba: gana el tablero fácil con holgura, y empatamos en los difíciles. La lección es general: construye siempre la referencia tal como corre a plena velocidad antes de fiarte de un cociente.
## La regla del juego: el mismo árbol, en cada peldaño
Un backtracker en profundidad es determinista. Dado un tablero y un orden de llenado
fijo, visita exactamente una secuencia de nodos, en cualquier máquina, en cualquier
lenguaje. Existe pues una prueba implacable para saber si una «optimización» es de
veras solo una aceleración y no un cambio silencioso de la búsqueda: **el número de
nodos no debe moverse.**
A lo largo de este trabajo, el oráculo fue un 16×16 soluble con 60 pistas. Cada versión
del motor lo resuelve a 480 y reporta **251 815 nodos** - el mismo número, hasta el
dígito, desde la referencia más lenta hasta el build fusionado más rápido. Todo cambio
que moviera ese número era un fallo disfrazado y se revirtió. Esa sola disciplina es lo
que permite leer la escalera de velocidad de abajo como una comparación en igualdad de
condiciones, y no como una colección de programas de comportamiento distinto.
> **Aquí la corrección es un invariante de base, no un hito**
>
> El motor verifica las cuatro aristas de cada colocación contra cada vecino ya fijado (pieza colocada o el borde del marco), y prohíbe que una arista de borde/gris mire hacia el interior. No son optimizaciones «añadidas después» - son la definición de una colocación legal de Eternity II, presente en cada versión de esta página. La escalera solo varía la velocidad de una búsqueda fija y correcta.
## La idea central: generar el programa, no interpretar el rompecabezas
Un backtracker genérico paga, en cada nodo, preguntas cuya respuesta nunca cambia
durante una ejecución: *¿en qué celda estoy? ¿dónde están sus vecinos? ¿qué reserva de
candidatos leo?* Un bucle guiado por tablas las busca en arreglos, por nodo, sin fin.
El C de McGavin las responde **una vez, al compilar**, generando un programa
especializado para un rompecabezas: `genbody -DG` escribe un segundo archivo C con un
bloque en línea recta por celda, las direcciones de los vecinos grabadas como
constantes, y cadenas de `goto` enlazando los bloques. Esa especialización es la fuente
de su velocidad - mismo algoritmo, ejecutado a ras del metal.
Este motor hace lo mismo en Rust, en tiempo de ejecución:
1. `emit_program(&instance)` escribe un **programa Rust autónomo y especializado para
el rompecabezas** - piezas, reservas de candidatos, pistas y orden de llenado todo
grabado como datos `const`, sin crates externas.
2. La envoltura lo compila con `rustc -O` (unos 0,15 s para el build simple, ~1,7 s
para el fusionado).
3. El binario generado ejecuta la búsqueda e imprime su resultado.
Es el flujo `genbody -DG → compila → ejecuta` de McGavin, en Rust, invocado como una
biblioteca. Nada exótico - solo sacar los hechos fijos del rompecabezas del bucle
caliente y ponerlos en manos del compilador. Todo lo que sigue es exprimir factores
constantes del código generado, y cada exprimido es un cambio pequeño y autónomo que un
diff ilustra mejor.
## La escalera, un cambio a la vez
Los diffs de abajo están **simplificados para leer**: el motor real emite su bucle
interno como Rust generado (constantes como la posición de una celda y sus vecinos van
grabadas por celda, y la fuente son unos cientos de líneas por rompecabezas). Cada diff
muestra la idea del cambio, no el texto generado literal - ejecuta el motor con
`--emit-src out.rs` para ver el código real de un tablero dado.
### 1 · Empaquetar cada candidato en una palabra
El primer bucle generado aún perseguía un puntero: leer un índice `u32`, seguirlo hasta
un arreglo `oriented[]` por el `(id, rotación, aristas)` de la pieza, *y luego* probar
si la pieza ya estaba usada. Tres cargas dependientes para considerar un candidato.
```diff
- let idx = pool[i]; // load an index …
- let (pid, rot, edges) = oriented[idx as usize]; // … chase it into a second array …
- if !used[pid] { /* consider */ } // … then test usage
+ let cand = pool[i]; // one contiguous load: pid<<48 | rot<<40 | edges<<8
+ let pid = (cand >> 48) as usize;
+ if free[pid] != 0 { let edges = (cand >> 8) as u32; /* consider */ }
```
Cada candidato pasa a ser un único `u64` empaquetado, guardado directamente en su
reserva `(up, left)`. El bucle caliente hace **una** carga, extrae el id de la pieza y
prueba el uso *antes* de desempaquetar las aristas - el patrón «verificar `tileFree`
primero» de McGavin. **+12 %**, y sienta la representación empaquetada de la que depende
todo el resto del trabajo.
### 2 · Guardar las celdas del tablero en un `u32`, no cuatro bytes
El tablero guardaba las cuatro aristas de cada celda como `[u8; 4]`. Leer la arista de
un vecino para compararla exigía cuatro cargas de byte separadas. McGavin guarda las
aristas de cada ficha colocada como **un solo `u32`** y las empuja a los vecinos con
desplazamientos.
```diff
- let cell: [[u8; 4]; N]; // four byte loads to read one neighbour
- let up_edge = cell[up_pos][2]; // …and index arithmetic each time
+ let cell: [u32; N]; // one u32 per cell, URDL packed, empty = 0xFFFF_FFFF
+ let up_edge = (cell[up_pos] >> 8) as u8; // one load + one shift
```
Fue la mayor palanca de disposición de datos: **34 → 57 M nodos/s, +67 %**. Número de
nodos sin cambios. Representar bien la estructura de datos más caliente (el tablero)
importó más que cualquier micro-optimización posterior.
### 3 · Emitir una función por celda - el punto de inflexión
Este es el gesto que hizo «igualar a McGavin» plausible. El impuesto restante era el
propio bucle guiado por tablas: `free_order[level]`, `cursor[level]`, `score_at[level]`
- cargas de arreglos indexados en *cada nodo*, para valores que McGavin tiene como
constantes de compilación. La forma obvia de grabarlos - un único `loop { match level {
…256 ramas… } }` enorme - no funciona: `rustc` tarda más de un minuto en compilar una
sola función gigante, y
[LLVM no sabe rebajar un `loop`/`match` a un goto calculado](https://github.com/rust-lang/rust/issues/80630)
de todos modos, así que ni reproduciría la estructura de `goto` de McGavin.
La forma que *sí* funciona es emitir **una pequeña función `#[inline(never)]` por
celda**:
```diff
- // one generic loop, indexing arrays by depth on every node
- loop {
- let pos = free_order[level];
- let (up_pos, left_pos) = neigh[level];
- // …scan, place, advance level, or back out…
- }
+ // one function per cell; its position and neighbours are baked constants
+ fn cell_37(st: &mut St, left_arg: u8) -> bool {
+ const POS: usize = 138; const UP: usize = 122; // this cell's facts, as constants
+ for cand in POOL_UL[/* up*COLORS+left */] { // its exact candidate pool
+ // place …
+ if cell_38(st, right_edge) { return true; } // advance = call the next cell
+ // unplace …
+ }
+ false // exhausted = plain return (backtrack)
+ }
```
Avanzar es una llamada a la función de la celda siguiente; retroceder es un simple
`return`. Unas 256 funciones *pequeñas* compilan en unos dos segundos (una cadena de
200 funciones compila en ~1 s; la función gigante única tardaba >60 s). Es el código en
línea recta por celda de McGavin, expresado como una cadena de funciones diminutas que
Rust sí compilará. **58 → 92 M nodos/s, +56 %** - la mayor palanca de la escalera.
Número de nodos sin cambios.
### 4 · Dejar de recalcular lo que ya se cargó
Dos cambios menores, mismo tema: nunca releer de memoria algo que ya se tiene en un
registro.
El **vecino de la izquierda** de una celda es, el 94 % del tiempo (240 de las 256
celdas, todas salvo los inicios de fila), exactamente la pieza que la celda *llamadora*
acaba de colocar. La llamadora pasa entonces su propia arista derecha como argumento, y
la celda deriva su restricción izquierda sin ninguna lectura del tablero:
```diff
- let left_edge = (cell[LEFT] >> 24) as u8; // re-read the neighbour we just placed
+ fn cell_38(st: &mut St, left_arg: u8) -> bool { // caller handed us its right edge
+ let left = left_arg; // …no board read
```
Y la **ganancia de coincidencia** - cuántas aristas recién casadas añade una colocación
- releía los cuatro vecinos. Pero las aristas de arriba y de la izquierda *ya estaban
cargadas* para elegir la reserva de candidatos, y en el orden por fila esos vecinos
siempre están colocados (o una arista de marco, sin ganancia). Así que la ganancia
arriba/izquierda pasa a ser dos sumas `bool → u32` sin ramas sobre valores ya en mano;
solo vecinos abajo/derecha realmente fijados cuestan una lectura:
```diff
- let gain = matched(up) + matched(left) + matched(down) + matched(right); // 4 reads
+ let gain = u32::from(e_up == up) + u32::from(e_left == left) // 0 reads: cached
+ + need_down_read + need_right_read; // only if pinned
```
Juntos: **92 → 106 M nodos/s** - en el tablero difícil, esto empareja con el C sin
pantalla de McGavin (~102–105 M allí). Número de nodos sin cambios.
### 5 · Un arreglo de bytes para el conjunto de piezas usadas
El motor rastreaba las piezas colocadas con un mapa de bits `u64`: desplazar,
enmascarar, y, probar. McGavin usa un `unsigned char tileFree[256]` plano; su prueba es
una carga de byte y una comparación con cero.
```diff
- if used[pid >> 6] & (1u64 << (pid & 63)) == 0 { /* free */ } // shift, mask, and, test
+ if free_pc[pid] != 0 { /* free */ } // one byte load + compare
```
**106 → 108 M.** Número de nodos sin cambios.
### 6 · Fusionar celdas para amortizar la llamada - la jugada ganadora
Lo último entre la cadena de funciones y el `goto` de McGavin era la propia llamada: un
`goto` a la celda anterior es un salto desnudo; un `return` de función restaura primero
los registros guardados por el llamado. Así que **fusionemos varias celdas en una
función** - anidemos el barrido de la segunda celda *dentro* del bucle de colocación de
la primera, la tercera dentro de la segunda, y así, para tener una `call` por *grupo* de
celdas colocadas en vez de una por celda:
```diff
- fn cell_37(st){ for c in pool { place; if cell_38(st, r) {return true} unplace } }
- fn cell_38(st){ for c in pool { place; if cell_39(st, r) {return true} unplace } }
+ fn cells_37_38_39(st){ // three cells, one function, one call in/out
+ for c37 in pool37 { place37;
+ for c38 in pool38 { place38;
+ for c39 in pool39 { place39;
+ if next_group(st, r) {return true}
+ unplace39 }
+ unplace38 }
+ unplace37 }
```
La fusión cambia menos llamadas por más presión sobre los registros, de modo que hay un
óptimo, y es poco marcado. Barriendo el tamaño del grupo en `bench-hard`, tres pruebas
cada uno, uno tras otro:
| grupo | 1 | 2 | 4 | 6 | 8 |
| --- | --- | --- | --- | --- | --- |
| nodos/s | ~102 M | ~107 M | **~110 M** | ~108 M | ~108 M |
La fusión bate claramente a la ausencia de fusión (grupo 1), pero más allá del grupo 2
las diferencias caen dentro del ruido de una ejecución a otra: el pico vaga entre los
grupos 4 y 6 según el tablero y el humor del asignador de registros de LLVM, y nunca
supera un par de por ciento. El valor por defecto de `--chain2` es el grupo 6; el grupo 4
se adelantó en este tablero concreto. Lo que importa es el salto desde el grupo 1, no el
ganador exacto. El número de nodos se preserva a través del anidamiento en cualquier caso.
## La escalera de un vistazo
Tres puntos de anclaje se revierifican hoy sobre los tableros `bench-*.json` commitidos;
los pasos entre ellos son los deltas tomados durante el desarrollo (cada uno un commit
autónomo), que derivan un par de por ciento según el estado de la máquina - así que lee
las filas del medio como la *forma* de la subida, no como constantes de laboratorio.
| Peldaño | Motor | Cambio | estado |
| --- | --- | --- | --- |
| **naive-clean** | recursivo | DFS Rust portable simple, la referencia rigurosa | **~44 M, verificado** |
| **JIT guiado por tablas** | codegen | programa generado, bucle interno por tablas | **~61 M, verificado** |
| celdas del tablero en u32 | codegen | una carga + desplazamiento por vecino | +~65 % (diario) |
| cadena de funciones | codegen | una función por celda | +~55 % (diario) ★ |
| arriba/izquierda en caché + bytes | codegen | dejar de releer los vecinos colocados | +~15 % (diario) |
| **fusión (grupo 4–6)** | codegen | **una llamada por varias celdas** | **~108–110 M difícil / ~122 M fácil, verificado** |
| *C de McGavin (sin pantalla)* | C | *misma máquina, como referencia* | *~102 M difícil / ~287 M fácil* |
Dos motores comparten esta tabla: `naive-clean` es un backtracker recursivo aparte
(ejecutable con `run_dfs --algo naive-clean`), y todo desde «JIT guiado por tablas» es el
camino codegen del que trata esta página (`run_dfs_codegen_jit`). El resumen honesto es
una **mejora de ~2,5× de la referencia naive-clean al campeón fusionado en el tablero
difícil** (~44 M → ~110 M) y **~2,8× en el fácil** (~44 M → ~122 M) - aterrizando, en el
difícil, a la par del C sin pantalla de McGavin. De ello salen tres meta-lecciones, la
parte transferible:
1. **La representación pesa más que las micro-operaciones.** Las dos mayores ganancias
aisladas - celdas u32 (+67 %) y cadena de funciones (+56 %) - trataban ambas de la
*forma* de los datos y del código, no de recortar instrucciones. Ningún ajuste de
ramas se le acercó.
2. **Reutilizar lo que ya se calculó.** La ganancia en caché y la
izquierda-como-argumento fueron puras ganancias de «deja de recargarlo».
3. **La estructura pesa más que los ciclos.** La fusión atacó la *estructura de
llamada*, no un ciclo aislado - y eso fue lo que llevó a Rust a la par del C afinado
a mano en tableros difíciles.
## Reprodúcelo
El motor y dos tableros de referencia commitidos viven en el repositorio público bajo
`research/experiments/dfs-study/engine/crates/dfs-codegen` (`bench/bench-easy.json`,
`bench/bench-hard.json`, y un `bench/README.md` con la receta completa). Los tres puntos
de anclaje de la escalera - la referencia naive-clean, el piso codegen y el campeón
fusionado - son ejecutables directamente, para que cualquiera pueda rejugarlos en su
propia máquina, uno tras otro. Desde `research/experiments/dfs-study/engine`:
```bash
# naive-clean: la referencia rigurosa (backtracker recursivo simple aparte) ~44 M
cargo run --release -p dfs-run --bin run_dfs -- \
--puzzle crates/dfs-codegen/bench/bench-hard.json --algo naive-clean --seed 1 --budget-s 10
# piso JIT guiado por tablas: el camino codegen sin cadena/fusión ~61 M
cargo run --release -p dfs-codegen --bin run_dfs_codegen_jit -- \
--puzzle crates/dfs-codegen/bench/bench-hard.json --budget-s 15 --opt native
# campeón fusionado (grupo = 6): el motor del que trata esta página ~108–110 M difícil, ~122 M fácil
cargo run --release -p dfs-codegen --bin run_dfs_codegen_jit -- \
--puzzle crates/dfs-codegen/bench/bench-hard.json --budget-s 15 --chain2 --opt native
# cualquier ancho de fusión, para barrer los grupos tú mismo
cargo run --release -p dfs-codegen --bin run_dfs_codegen_jit -- \
--puzzle crates/dfs-codegen/bench/bench-hard.json --budget-s 15 --group 4 --opt native
```
Apunta `--puzzle` a `bench-easy.json` y cada configuración imprime `score=480` con el
**mismo número de nodos** (3 577 121 570) - la igualdad que prueba que la escalera es una
escalera de velocidad y nada más. En el `bench-hard.json` no terminante, imprimen el mismo
puntaje parcial a `nps` distintos. (Dale un presupuesto real: uno muy corto mide el
calentamiento del compilador, no el rendimiento. El tablero fácil pide ≥30 s para
resolverse.) Los tres micro-pasos intermedios de la tabla de arriba - candidatos
empaquetados, ganancia en caché, conjunto usado en bytes - no son banderas separadas; son
la secuencia de commits en `bench/README.md`, reproducible con `git checkout`.
Para reproducir con justicia la comparación con McGavin, construye **su** motor sin
pantalla - comenta `#define INTERACTIVE` cerca del inicio de `genbody.c` para que la
pantalla en vivo no lo frene - y luego lee el rendimiento real:
```bash
# McGavin, sin pantalla + nativo: emitir el C especializado, luego enlazar y ejecutar
gcc -o genbody genbody.c -lm -Ofast -mcpu=native -DG # emite body.c para este puzzle
./genbody PUZZLE.puz HINTS.hnt
gcc -o solve genbody.c -lm -Ofast -mcpu=native # enlaza body.c, corre la búsqueda
./solve PUZZLE.puz HINTS.hnt
# lee la línea «Rate:» (= colocaciones / tiempo) en un tablero difícil, o el resumen
# final «tiles/second» en uno soluble — esa es su velocidad real
```
Con la pantalla activa, el mismo binario lee alrededor de un tercio de eso - que es
exactamente la trampa que produjo el falso «lo superamos».
> **Primero: ¿acaso contamos lo mismo?**
>
> Una comparación de velocidad no tiene sentido si ambos motores no cuentan los mismos eventos, así que antes de confiar en cualquier razón leímos la fuente de McGavin. Su contador (`ntp`, el famoso truco de desbordamiento de 16 bits) se incrementa **una vez por pieza colocada en el tablero** - después de que el candidato ha pasado la tabla de coincidencia de colores y el control de uso, en el instante en que se coloca (`genbody.c`, el `ntp++` justo tras `square[x][y].tile = t`). Nuestro `st.nodes` hace exactamente lo mismo: se incrementa después de que un candidato pasa los controles de aristas y de uso, al colocar la pieza. Ninguno cuenta los candidatos que fallan esos controles; ambos cuentan las colocaciones que luego se deshacen. Así que las «fichas colocadas por segundo» de McGavin y nuestros «nodos de búsqueda por segundo» son **la misma medida** - colocaciones efectivas, no intentos. (La única asimetría: él cuenta el puñado de colocaciones de pistas forzadas y nosotros las extraemos - ≤18 sobre un recuento de miles de millones, es decir, nada.) El número del que hay que desconfiar es el «M/s» de un *tercer* motor: ahí «colocaciones intentadas» y «colocaciones efectuadas» pueden diferir en un orden de magnitud, que es la vieja advertencia de la comunidad sobre [qué es un «nodo»](/es/research/build/faster/solver-engineering/).
> **Medir con honestidad, o no medir**
>
> El rendimiento absoluto en nodos/s deriva con la carga y la temperatura de la máquina y - como muestra la corrección de arriba - con cómo se construye el motor de *referencia*. **Solo los cocientes tomados en el mismo estado, uno tras otro, sin pantalla, con la máquina por lo demás en reposo, son fiables.** Cada comparación de esta página se tomó sin nada más en marcha, ambos motores compilados sin pantalla con generación de código nativa y ejecutados con segundos de diferencia. El viejo folclore «McGavin es 5× más rápido» también era un espejismo, en el otro sentido: comparaba su ejecución en un rompecabezas fácil con la nuestra en uno difícil. Iguala el tablero, iguala el build, mide uno tras otro - o el número no significa nada.
## La brecha del tablero fácil es una palanca real y abierta
¿Por qué el C de McGavin gana el tablero fácil por 2,3× pero solo empata en los
difíciles? Porque en un tablero poco ramificado casi no hay nada que hacer por nodo
- elegir el candidato o dos, colocar, avanzar - y su código en línea recta, con la lista
de candidatos de cada celda reducida a una consulta por hash perfecto mínimo, lo hace
con el menor número de instrucciones posible. Nuestro trabajo por nodo (indexar la
reserva, calcular la ganancia, verificar el borde) es barato pero no *nulo*, y cuando el
árbol es poco profundo y ancho ese sobrecosto se nota. En un tablero difícil, los mismos
nodos están dominados por el retroceso y los fallos de caché, donde ambos motores
convergen. Cerrar la brecha del tablero fácil significaría adoptar su generación de lista
de candidatos más ajustada - un paso siguiente concreto, no un muro. Queda consignado
aquí como abierto en vez de disimulado.
## Qué vale la velocidad
Apuntado al Eternity II real de 256 piezas - seis núcleos, quince minutos, la pista
central obligatoria fijada - este motor recorre el árbol a decenas de millones de nodos
por segundo por núcleo y se estanca, de una semilla a otra, en los 300 altos sobre 480.
No es una decepción; es
[todo el sentido de la lección central del sitio](/es/research/why/prune-vs-speed/). Un
backtracker estricto es un magnífico recorredor de árboles y un pobre solucionador: el
espacio de búsqueda es tan vasto que ninguna velocidad alcanzable le hace mella, que es
justo por lo que los récords vienen de las
[heurísticas y la reparación](/es/research/lab/experiments/raphael-anjou/repair-study/), no
del rendimiento bruto.
Por eso el resultado aquí es deliberadamente estrecho y, creo, merece decirse con
franqueza: un motor Rust *seguro y portable* puede **igualar al C afinado a mano en los
tableros difíciles y profundos que se parecen al rompecabezas real**, recorriendo el
mismo árbol en el mismo hardware - mientras que el C aún gana por ~2,3× en los fáciles. Y
aun a la par, no sabe resolver Eternity II, porque la velocidad nunca fue el obstáculo.
El argumento más largo sobre esa disyuntiva - por qué unos algoritmos gastan su
presupuesto en velocidad y otros en criterio - tiene su propia página:
[ir rápido](/es/research/lab/experiments/raphael-anjou/going-fast/).
## Relacionado
- [El backtracker en C de McGavin: la historia del rendimiento, reconstruida aquí](https://eternity2.dev/es/research/lab/experiments/peter-mcgavin/backtracker/) — El backtracker en C de Peter McGavin, el más rápido de la comunidad: una receta de optimización de 2007 capitalizada durante dos décadas mediante código generado, tablas de búsqueda y trucos de contador, luego compilada en mi M1 y apuntada al puzzle real de 256 piezas, donde en un solo núcleo supera las 200 de 256 piezas a ~109M colocaciones/s.
- [Ir rápido: cuando un solucionador gasta su presupuesto en velocidad](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/going-fast/) — Algunos motores de Eternity II vuelcan su esfuerzo en recorrer el árbol de búsqueda lo más rápido posible; otros lo gastan en el criterio sobre dónde buscar. Este es el alegato a favor de los primeros - qué compra el rendimiento bruto, las tres cosas distintas que la gente llama «rápido» y por qué el motor más rápido jamás construido sigue sin poder resolver el rompecabezas.
- [Ingeniería de solucionadores: el oficio bajo el algoritmo](https://eternity2.dev/es/research/build/faster/solver-engineering/) — Todos los solucionadores récord ejecutan el mismo backtracking en profundidad. Lo que los distingue es la capa de debajo: tablas de consulta, hashes perfectos, structs a medida del caché, código generado, arqueología del compilador. Ese oficio decide si un nodo cuesta 26 ciclos o 2.600. Veinte años del registro de ingeniería de la comunidad, técnica por técnica, y lo que todo ello rindió.
- [Por qué un ordenador más rápido no ayuda](https://eternity2.dev/es/research/why/prune-vs-speed/) — La idea más importante de la búsqueda combinatoria difícil: reducir el espacio que se explora vence, por un margen exponencial, a explorarlo más rápido. Eternity II está diseñado para que apenas puedas reducirlo.
---
# Aprender a partir de tableros fuertes
> Un estudio en cinco experimentos de una sola idea: en lugar de buscar Eternity II desde cero, extraer estructura del corpus de tableros fuertes ya encontrados y reinyectarla en una búsqueda. Un prior de posición, un voto de jugada aprendido, una brújula de demanda escasa, un minero de antipatrones y un decodificado de récord, ordenados de la señal más simple a la más sutil, y el único muro que los cinco alcanzan.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/
- Actualizado: 2026-07-16
- Temas: learning, construction
---
La mayor parte de este cuaderno busca Eternity II desde cero: un beam construye un
tablero a partir de una rejilla vacía, un backtracker excava y retrocede, un bucle
de reparación pule un tablero completo mediante jugadas. Cada uno razona solo a
partir de las reglas del puzzle y del tablero que tiene delante. Este estudio es la
excepción, y es un estudio y no un conjunto suelto de runs porque sus cinco
experimentos plantean una misma pregunta desde ángulos distintos: **¿qué puede
aprender una búsqueda de los tableros que la gente ya ha encontrado, y hasta dónde
la lleva eso?**
La materia prima es un corpus de tableros fuertes, todo arreglo que la comunidad y
este proyecto han empujado por encima de 400 de 480. El gesto, en cada experimento
aquí, consiste en leer ese corpus en busca de estructura (dónde se sitúan las
piezas, qué piezas se tocan, qué patrones locales se repiten, qué acuerdos son
trampas) y reinyectar la estructura en una búsqueda como un sesgo. Está más cerca
del aprendizaje por imitación que del diseño de búsqueda, y merece su propio hogar
porque el mismo puñado de ideas sigue regresando, cada una un poco más afilada que
la anterior.
El corpus en sí está [publicado](/es/research/build/dataset/): 7658 tableros distintos
que puntúan de 400 a 469, publicados bajo CC0, con el control de diversidad que
impide que una señal aprendida se limite a recodificar un solo tablero. La
exposición agnóstica al método de cada técnica vive en la sección teórica sobre
[aprender a partir de tableros fuertes](/es/research/build/learning/); las páginas aquí
son su vertiente de laboratorio, los runs que ponen cada técnica sobre el tablero
real de 16×16, con sus puntuaciones y las preguntas que dejaron abiertas.
## Los cinco experimentos, de la señal más simple a la más sutil
El estudio se lee como una secuencia. Cada experimento aprieta una vuelta de tuerca
más que el anterior, y las páginas están ordenadas para leerse en ese orden.
| # | Experimento | La señal aprendida | Alcanzado (de 480) |
|---|---|---|---|
| 1 | [PRIOR](/es/research/lab/experiments/raphael-anjou/learning/prior/) | dónde tiende a situarse cada pieza, un simple recuento de posiciones | 460 |
| 2 | [KEYRING](/es/research/lab/experiments/raphael-anjou/learning/keyring/) | tres señales (posición, adyacencia, parche 2×2) votando juntas | 460 |
| 3 | [LODESTONE](/es/research/lab/experiments/raphael-anjou/learning/lodestone/) | qué piezas sirven a una demanda de color escasa, una brújula tenue | 451 |
| 4 | [PALIMPSEST](/es/research/lab/experiments/raphael-anjou/learning/palimpsest/) | los malos hábitos compartidos que limitan los tableros, minando la trampa y no la estructura | 463 |
| 5 | [REPLAY](/es/research/lab/experiments/raphael-anjou/learning/replay/) | la única jugada que un tablero récord empleó y que nuestra búsqueda no sabía hacer | 460 |
**[PRIOR](/es/research/lab/experiments/raphael-anjou/learning/prior/)** es la forma más
simple que la idea puede adoptar, un recuento: sobre los tableros fuertes, ¿con qué
frecuencia se sitúa cada pieza en cada celda? Usado como desempate de construcción,
levanta un tablero competitivo desde la nada y alcanza 460.
**[KEYRING](/es/research/lab/experiments/raphael-anjou/learning/keyring/)** suma señales
en lugar de fiarse de una sola, dejando que un recuento de posición, un recuento de
adyacencia y una calidad de parche 2×2 aprendida voten sobre cada colocación, lo
que lleva una construcción hasta una familia de esquinas que ninguna búsqueda
anterior había forzado.
**[LODESTONE](/es/research/lab/experiments/raphael-anjou/learning/lodestone/)** toma el
camino inverso, hacia una única señal deliberadamente tenue (un peso de demanda
escasa por pieza) y, al hacerlo, encuentra el filo de la navaja que atraviesa todo
el estudio: en cuanto una señal aprendida deja de ser un desempate y pasa a ser el
objetivo, la búsqueda se derrumba.
**[PALIMPSEST](/es/research/lab/experiments/raphael-anjou/learning/palimpsest/)** es el
giro sutil. Todos los experimentos que la preceden confían en el acuerdo entre
tableros fuertes; este pregunta qué acuerdos son *trampas*, colocaciones que todo
tablero adopta pero que ningún tablero de cabeza conserva, y orienta una búsqueda de
reparación para atacarlas. Produjo el mejor tablero de este proyecto, 463.
**[REPLAY](/es/research/lab/experiments/raphael-anjou/learning/replay/)** aprende de un
solo tablero y no de una estadística: reconstruir exactamente un récord de la
comunidad, y todo lo que tengas que añadir a tu búsqueda para que recorra ese camino
es precisamente el ingrediente que le faltaba. Aquí fue el double break, la jugada
que hizo pasar la escala estricta de 458 a 460.
## El único muro que los cinco alcanzan
El hilo conductor es lo que hace de esto un estudio y no un saco de trucos, y da que
pensar. Cada señal aquí es segura solo como un sesgo suave: confía demasiado en ella
y la búsqueda se descompone (LODESTONE cae de 451 a 380 a medida que sube su peso;
la lista de trampas de PALIMPSEST ayuda como guía y perjudica como prohibición). E
incluso usada a la perfección, ninguna de estas señales eleva el techo. Alcanzan la
cima del alcance propio de una búsqueda, rápido y de forma fiable, y se detienen,
porque el corpus del que aprenden está hecho de tableros que topan todos con el
mismo [muro de rigidez](/es/research/why/rigidity-wall/). Aprender a partir de tableros
fuertes es el camino más rápido *hacia* la meseta y, por sí solo, ningún camino *más
allá* de ella. Ese modo de fallo es el tema de la
[síntesis sobre el colapso](/es/research/build/learning/when-learning-collapses/) de la
sección teórica, y es la nota sobre la que se resuelve todo el estudio.
Este es uno de los tres estudios del
[cuaderno de experimentos](/es/research/lab/experiments/raphael-anjou/). Sus hermanos, el
[estudio DFS](/es/research/lab/experiments/raphael-anjou/dfs-study/) y el [estudio de
reparación](/es/research/lab/experiments/raphael-anjou/repair-study/), desmontan un único
paradigma de búsqueda decisión por decisión; este mantiene el paradigma suelto y
hace variar lo que a la búsqueda se le permite *saber*.
## Páginas de esta sección
- [PRIOR](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/prior/) — Construir un tablero desde cero, resolviendo los empates según la posición habitual de las piezas en los buenos tableros ya conocidos. Alcanza una puntuación alta sin ningún tablero de partida que copiar.
- [KEYRING](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/keyring/) — Construir un tablero desde cero, clasificando cada pieza siguiente según tres señales aprendidas de tableros fuertes anteriores. Alcanzó 460 en una familia de tableros que ninguna búsqueda previa había resuelto.
- [LODESTONE](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/lodestone/) — Una brújula tenue para una búsqueda partida de cero: incitarla a comprometer las piezas raras pronto, allí donde se necesitan. No eleva el techo; hace que la búsqueda alcance de forma fiable la cima de su propio rango.
- [PALIMPSEST](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/palimpsest/) — Leer cada tablero fuerte para detectar los hábitos que, en silencio, limitan un tablero, y luego romperlos. Este experimento produjo el mejor tablero del proyecto: 463 de 480.
- [REPLAY](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/replay/) — 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.
## Relacionado
- [Aprender de los tableros fuertes](https://eternity2.dev/es/research/build/learning/) — La mayoría de los ataques a Eternity II buscan partiendo de cero. Una familia distinta hace lo contrario: explora el corpus de tableros que la gente ya ha encontrado en busca de estructura, y luego reinyecta esa estructura en la búsqueda. Priors de posición, ordenación aprendida de jugadas, minería de antipatrones, decodificación de récords y el modo de fallo en el que una señal aprendida se derrumba.
- [El conjunto de datos](https://eternity2.dev/es/research/build/dataset/) — Un conjunto de datos público bajo licencia CC0 para Eternity II, en dos partes: catorce instancias de referencia para resolver, y un corpus de 7658 tableros fuertes distintos de los que aprender. Cada puntuación se recalcula a partir del propio tablero, y se verifica que el corpus sea realmente variado, en lugar de mil copias de un mismo tablero.
- [Los experimentos de Raphaël Anjou](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/) — Un cuaderno de experimentos de búsqueda sobre Eternity II, organizado en torno a los motores compartidos sobre los que se ejecutan, las pipelines de combinación que persiguen la puntuación, cuatro estudios que desmontan un paradigma de búsqueda una decisión a la vez, y resoluciones exactas de final de partida. Cada uno expone su idea, su mejor tablero y las preguntas que deja abiertas. El mejor alcanza 463 de 480.
- [El estudio DFS](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/) — Una sola pregunta, planteada con cuidado: entre los backtrackers en profundidad para Eternity II, ¿qué aporta realmente cada orden de relleno, cada heurística y el mecanismo de ruptura? Una familia de backtrackers escritos desde cero, separados cada uno por un único cambio, ejecutados sobre las mismas diez variantes con esquinas fijadas, en un solo núcleo, durante sesenta segundos.
- [El estudio de la reparación](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/repair-study/) — La hermana del estudio DFS, para la otra manera en que se ataca Eternity II: destruir parte de un tablero, reconstruirla, conservar el cambio si ayuda. Una pregunta, planteada con cuidado. Qué aporta cada decisión de ese bucle: qué región destruir, cómo reconstruirla, cuándo conservar un movimiento, cuándo reiniciar, y desde qué tablero partir.
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
---
# KEYRING
> Construir un tablero desde cero, clasificando cada pieza siguiente según tres señales aprendidas de tableros fuertes anteriores. Alcanzó 460 en una familia de tableros que ninguna búsqueda previa había resuelto.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/keyring/
- Actualizado: 2026-07-21
- Temas: construction, learning
- Reproducir: `just research-record-boards`
- Fuente: La búsqueda en haz como construcción best-first de ancho acotado (página conceptual de este proyecto) — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/build/construct/beam-search.mdx
---
[PRIOR](/es/research/lab/experiments/raphael-anjou/learning/prior/) confiaba en una
sola señal aprendida, un conteo de posiciones, para deshacer sus empates. KEYRING
es el siguiente paso del [estudio](/es/research/lab/experiments/raphael-anjou/learning/):
¿y si una sola señal no basta? Al construir un tablero pieza a pieza, la parte
difícil consiste en decidir qué pieza colocar a continuación cuando varias
encajarían, y una única regla empírica, aun aprendida, tiende a llevar la búsqueda
a los mismos callejones sin salida una y otra vez. KEYRING lleva tres corazonadas
aprendidas distintas a la vez, un llavero de ellas, y las deja votar, lo que evita
que la búsqueda confíe en exceso en una sola señal.
## Cómo funciona
A partir de la biblioteca de tableros fuertes, KEYRING aprende tres cosas.
Primero, dónde le gusta situarse a cada pieza: con qué frecuencia una pieza
aparece en cada posición a lo largo de los buenos tableros. Segundo, qué piezas
tienden a ser vecinas: con qué frecuencia dos piezas acaban en contacto. Tercero,
qué pequeños parches 2×2 aparecen en los buenos tableros frente a los malos.
Luego rellena el tablero con una búsqueda en haz, manteniendo muchos tableros
parciales vivos a la vez. Cuando tiene que elegir la pieza siguiente, puntúa cada
opción según cuántas aristas empareja, ajustada por las tres señales aprendidas en
conjunto. Una pequeña dosis de aleatoriedad evita que los muchos intentos
paralelos se desplomen sobre un mismo camino.
> **[Figure]** Interactivo: el voto de colocación de tres señales — interactive: KeyringDiagram. Rendered on the canonical page (link above); not shown in this markdown export.
## El tablero
> **[Interactive: RecordBoard]** Rendered on the canonical page (link above); not shown in this markdown export.
## El resultado
KEYRING alcanzó 460 de 480, y lo hizo en una disposición de esquinas donde ningún
tablero había llegado a ese nivel antes, así que no es simplemente otra ruta hacia
un tablero conocido, sino una región genuinamente nueva. A lo largo de ejecuciones
repetidas logró un tablero fuerte mucho más a menudo que la versión más simple de
señal única de la que surgió.
No es la mejor puntuación del proyecto (esa es 463), pero encontrar un tablero
alto en una familia nueva importa: se sabe que los tableros fuertes están aislados
unos de otros, de modo que cada familia nueva es su propio punto de apoyo.
## Método
Las tres señales, precisadas, y luego cómo orientan el haz.
La más fuerte de las tres es el **prior de parches 2×2**. Sobre el corpus, se
separan los tableros en *altos* (puntuación ≥ 460) y *bajos* (< 460), y para cada
parche 2×2 $q$ (cuatro piezas con sus rotaciones) se puntúa mediante un cociente
de log-odds suavizado a la Laplace:
$$
\text{score}(q) = \log\big(\text{count}_\text{high}(q) + \alpha\big) - \log\big(\text{count}_\text{low}(q) + \alpha\big), \quad \alpha = 0.5
$$
Un parche que aparece en los tableros fuertes y no en los débiles obtiene una
puntuación positiva; un parche trampa de consenso obtiene una puntuación negativa.
(En la ejecución que encontró el 460, el corpus se repartía en 23 tableros altos
frente a 1255 bajos.) Las otras dos señales son conteos más simples: una
frecuencia de **pieza-en-posición** y una frecuencia de **adyacencia de pares de
piezas**, cada una contabilizada sobre el mismo conjunto de tableros fuertes.
La construcción es una **búsqueda en haz**: se mantienen $W$ tableros parciales
vivos, y en cada paso se extiende cada haz puntuando cada colocación candidata
como su ganancia en aristas emparejadas más una suma ponderada de los tres priors,
y luego se conservan los $W$ mejores. Un poco de aleatoriedad inyectada impide que
los $W$ haces se desplomen sobre un solo camino, que es lo que permitió a KEYRING
alcanzar una familia de esquinas *nueva* en lugar de rederivar un tablero conocido.
Los parches se compactan en una clave `u64` (pieza ≤ 8 bits, rotación 2 bits, ×4
celdas = 40 bits), de modo que la consulta del prior es un acierto de hash.
Como con [PRIOR](/es/research/lab/experiments/raphael-anjou/learning/prior/), la
construcción en haz alcanza por sí sola los 450 altos; el tablero 460 confirmado
toma esa construcción y le añade encima una cola de refinamiento local, la misma
separación construir-luego-refinar que emplean los pipelines de récord. Las tres
señales son lo que lleva la *construcción* a una familia nueva; las últimas aristas
son del refinamiento.
Un límite que vale la pena enunciar: los priors se aprenden de un corpus que es él
mismo subóptimo, de modo que codifican tanto el techo de la comunidad como su
sabiduría: esa misma doble arista que [PALIMPSEST](/es/research/lab/experiments/raphael-anjou/learning/palimpsest/)
convierte en una ventaja al separar el buen consenso de las trampas.
## Reproducir
`just research-record-boards` verifica byte a byte la puntuación del tablero 460
confirmado a partir de su cadena Bucas almacenada. La búsqueda es estocástica
(búsqueda en haz con aleatoriedad inyectada), de modo que una nueva ejecución no
reproducirá el mismo tablero; el tablero es el artefacto de referencia. El motor es
el productor en haz compartido; el cambio que describe esta página son las tres
señales de clasificación aprendidas. Esas señales se extraen de un corpus de
tableros fuertes, así que la ejecución no se reproduce desde cero aquí.
## Preguntas abiertas
¿Graduar la señal de parches por grado, en lugar de tratar los parches como
simplemente buenos o malos, ayudaría aún más? ¿Podrían los pesos de las tres
señales desplazarse a medida que el tablero se llena, confiando más en la
estructura al final de la construcción? ¿Y puede empujarse esta nueva familia más
allá de 460 con un refinamiento más largo?
## Relacionado
- [Ordenación de jugadas aprendida](https://eternity2.dev/es/research/build/learning/learned-value-ordering/) — Cuando varias piezas encajan, ¿cuál colocas a continuación? En lugar de una sola regla empírica, transporta varias señales aprendidas de los buenos tableros y deja que voten. El voto evita que la búsqueda confíe en exceso en una única corazonada y avance hacia el mismo callejón sin salida.
- [Aprender a partir de tableros fuertes](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/) — Un estudio en cinco experimentos de una sola idea: en lugar de buscar Eternity II desde cero, extraer estructura del corpus de tableros fuertes ya encontrados y reinyectarla en una búsqueda. Un prior de posición, un voto de jugada aprendido, una brújula de demanda escasa, un minero de antipatrones y un decodificado de récord, ordenados de la señal más simple a la más sutil, y el único muro que los cinco alcanzan.
- [PRIOR](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/prior/) — Construir un tablero desde cero, resolviendo los empates según la posición habitual de las piezas en los buenos tableros ya conocidos. Alcanza una puntuación alta sin ningún tablero de partida que copiar.
- [Por qué el basin-hopping parece imposible](https://eternity2.dev/es/research/why/sigma-cycles/) — Si no puedes mejorar un tablero excelente puliéndolo, quizá puedas saltar a otro tablero excelente. En cada par de récords probado, no puedes, y vale la pena ver la razón estructural que lo explica.
- [Patrones prohibidos](https://eternity2.dev/es/research/why/forbidden-patterns/) — Casi todo pequeño conjunto de piezas que podrías construir es imposible. Para un cuadrado 2×2, el 99,72 % de las formas de colocar cuatro piezas nunca podrá encajar.
- [Búsqueda en haz](https://eternity2.dev/es/research/build/construct/beam-search/) — Mantener con vida los K tableros parciales más prometedores a la vez y hacerlos crecer celda a celda. La búsqueda en haz es el motor de los constructores desde cero de este proyecto, y una ilustración nítida de por qué la anchura por sí sola se estanca en las profundidades del interior.
---
# LODESTONE
> Una brújula tenue para una búsqueda partida de cero: incitarla a comprometer las piezas raras pronto, allí donde se necesitan. No eleva el techo; hace que la búsqueda alcance de forma fiable la cima de su propio rango.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/lodestone/
- Actualizado: 2026-07-21
- Temas: construction, search-space, learning
- Reproducir: `just research-record-boards`
- Fuente: Geografía de los colores raros (este proyecto): dónde viven las demandas (N,O) escasas — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/why/rare-color-geography.mdx
---
[KEYRING](/es/research/lab/experiments/raphael-anjou/learning/keyring/) añadía
señales; LODESTONE, el tercer experimento del
[estudio](/es/research/lab/experiments/raphael-anjou/learning/), se reduce a una única
señal deliberadamente tenue, y al hacerlo deja al descubierto el filo de navaja
sobre el que cada señal aprendida aquí se sostiene en equilibrio. Los tableros
fuertes coinciden discretamente en algo: a medida que la puntuación sube,
satisfacen cada vez más un conjunto particular de demandas escasas, lugares donde
solo una o dos piezas de todo el juego pueden servir los colores norte y oeste de
una celda. LODESTONE se pregunta si informar a una búsqueda partida de cero acerca
de esas demandas la ayuda a comprometer las piezas raras correctas antes de que se
las roben.
## Cómo funciona
A partir del corpus de tableros fuertes, LODESTONE construye un prior: para cada
pieza, cuántas veces acaba sirviendo una de esas demandas escasas noroeste en un
buen tablero, ponderada fuertemente al alza para las más raras, de modo que una
pieza que es el único servidor posible recibe el mayor impulso. La búsqueda por
haz clasifica entonces sus colocaciones candidatas según la puntuación habitual de
aristas apareadas más un pequeño múltiplo de este prior, de modo que, entre
jugadas por lo demás equivalentes, prefiere colocar las piezas que los buenos
tableros aprendieron a gastar pronto.
El detalle crucial es el tamaño de ese múltiplo. El prior tiene que ser un puro
desempate, no una parte del objetivo: desempata entre jugadas que aparean por
igual y nada más.
> **[Figure]** Interactivo: mapa de atracción de colores raros — interactive: LodestoneRarityLab. Rendered on the canonical page (link above); not shown in this markdown export.
## El resultado
Con un peso ínfimo, el prior aporta una ganancia pequeña pero constante: a lo
largo de cinco semillas, la puntuación mediana partida de cero sube de 449 a 451
y, más útil aún, la dispersión se estrecha, de un esparcimiento 446-451 a un rango
fiable 450-451. Hace que el constructor aterrice en la cima de su rango en lugar
de tropezar a veces.
Sube el peso aunque sea un poco y todo se derrumba (422, luego 380), porque
perseguir las demandas escasas del corpus se paga entonces directamente a costa de
aparear la arista que tienes delante. Ese fracaso es en sí mismo el hallazgo: la
escasez es una señal real para saber *qué* pieza preferir, pero una señal débil, y
segura solo como desempate. LODESTONE es modesto sobre su magnitud: mejora la
calidad y la regularidad de la construcción en un par de aristas, y no toca el
techo de cuenca que detiene a todo método cerca de la cima.
## Método
Primero la señal, luego la forma deliberadamente diminuta en que se emplea.
**La medición.** Una *demanda escasa* es una celda cuyos colores norte y oeste
solo pueden ser servidos por una o dos piezas de todo el juego. Sobre el conjunto
del corpus, el número de demandas escasas satisfechas en al menos la mitad de los
tableros crece *de forma monótona* con la puntuación, aproximadamente 1 → 2 → 3 →
10 a medida que los tableros trepan hacia 458+. Los tableros fuertes no colocan
bien las piezas raras solo por casualidad; satisfacen cada vez más las *mismas*
demandas escasas. Es una estructura real, correlacionada con la puntuación, que
ningún constructor anterior había integrado.
**El prior.** Para cada pieza, se pondera cuántas veces sirve una de esas demandas
escasas noroeste en un buen tablero, con un fuerte refuerzo para las más raras
(una pieza que es el *único* servidor posible recibe el mayor peso). El haz
clasifica los candidatos según la ganancia habitual de aristas apareadas más un
pequeño múltiplo de este peso.
**El ajuste es toda la historia.** El múltiplo debe ser un puro *desempate*:
decide entre jugadas que aparean por igual y nada más. Con un peso ínfimo:
puntuación mediana partida de cero 449 → 451 a lo largo de cinco semillas, y la
dispersión se estrecha de 446-451 a un rango fiable 450-451. Sube el peso y todo
se derrumba (422, luego 380), porque perseguir las demandas escasas se paga
entonces directamente a costa de aparear la arista que tienes delante. El derrumbe
*es* el resultado: la escasez dice *qué* pieza preferir, pero débilmente, segura
solo como desempate.
## Reproducir
Con semilla fijada; el artefacto reproducible aquí es el *efecto* del desempate
(una dispersión más estrecha y una mediana +2 a lo largo de cinco semillas), no un
tablero único. El motor es el productor por haz compartido; el cambio que describe
esta página es un tenue desempate pieza-rara-pronto. Ese peso de desempate se
deriva del juego de piezas y de un corpus, de modo que la ejecución no se reproduce
aquí desde cero.
## Preguntas abiertas
¿Podría hacerse el prior consciente de la posición sin que se convierta en parte
del objetivo, fuerte solo en las regiones donde las demandas escasas realmente se
concentran? Combinarlo con las tres señales de KEYRING, ¿añade un cuarto voto útil
o solo más ruido? Y la ganancia de regularidad, ¿vale más que la ganancia de
mediana, dado que una búsqueda más estrecha es más fácil de escalonar en escalera?
## Relacionado
- [Priors de corpus](https://eternity2.dev/es/research/build/learning/corpus-priors/) — La forma más simple de aprender de los tableros fuertes: contar dónde tiende a situarse cada pieza, o con qué frecuencia satisface una demanda escasa, y usar ese recuento como un suave desempate en la construcción. Debe seguir siendo un desempate; en cuanto pasa a formar parte del objetivo, hace colapsar la búsqueda.
- [Cuando el aprendizaje se desmorona](https://eternity2.dev/es/research/build/learning/when-learning-collapses/) — La mitad desencantada de aprender a partir de tableros fuertes. Una señal aprendida alcanza de forma fiable el tope del rango propio de una búsqueda, y ahí se detiene. Confía demasiado en ella y la búsqueda se desmorona; incluso usada a la perfección no eleva el techo, porque el techo no es algo que el corpus conozca.
- [Aprender a partir de tableros fuertes](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/) — Un estudio en cinco experimentos de una sola idea: en lugar de buscar Eternity II desde cero, extraer estructura del corpus de tableros fuertes ya encontrados y reinyectarla en una búsqueda. Un prior de posición, un voto de jugada aprendido, una brújula de demanda escasa, un minero de antipatrones y un decodificado de récord, ordenados de la señal más simple a la más sutil, y el único muro que los cinco alcanzan.
- [El robo de piezas, donde mueren los solucionadores](https://eternity2.dev/es/research/why/piece-theft/) — Un solucionador rellena unas pocas filas sin esfuerzo y luego choca contra un muro en mitad del tablero. He aquí el mecanismo: una pieza escasa gastada en el lugar equivocado, varias filas atrás.
- [KEYRING](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/keyring/) — Construir un tablero desde cero, clasificando cada pieza siguiente según tres señales aprendidas de tableros fuertes anteriores. Alcanzó 460 en una familia de tableros que ninguna búsqueda previa había resuelto.
- [PRIOR](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/prior/) — Construir un tablero desde cero, resolviendo los empates según la posición habitual de las piezas en los buenos tableros ya conocidos. Alcanza una puntuación alta sin ningún tablero de partida que copiar.
- [Los colores raros viven en el marco](https://eternity2.dev/es/research/why/rare-color-geography/) — Cinco de los 22 colores de Eternity II aparecen solo a lo largo del anillo de borde, cada uno en exactamente 24 aristas, nunca una sola vez en el interior. Una separación estructural que moldea la forma en que cada solucionador trata el marco.
---
# PALIMPSEST
> Leer cada tablero fuerte para detectar los hábitos que, en silencio, limitan un tablero, y luego romperlos. Este experimento produjo el mejor tablero del proyecto: 463 de 480.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/palimpsest/
- Actualizado: 2026-07-21
- Temas: local-search, learning
- Reproducir: `just research-record-boards`
- Fuente: Ropke & Pisinger 2006, búsqueda adaptativa de gran vecindario (el marco de destrucción-reparación que esto orienta) — https://doi.org/10.1287/trsc.1050.0135
---
Hasta ahora, cada experimento del [estudio](/es/research/lab/experiments/raphael-anjou/learning/)
ha confiado en el acuerdo entre tableros fuertes: allí donde los buenos tableros
concuerdan, se los sigue. PALIMPSEST es el momento en que esa confianza se examina,
y produjo el mejor tablero del proyecto. Cuando muchas búsquedas independientes
alcanzan todas un tablero alto pero imperfecto, tienden a coincidir en muchas
colocaciones. Parte de ese acuerdo es estructura auténtica, y otra parte es un mal
hábito compartido: una elección local que parece buena y mantiene cada búsqueda
atascada justo por debajo de la cima. La idea de este experimento es leer todo el
corpus de tableros fuertes, separar el acuerdo útil de la trampa, y atacar las
trampas.
## Cómo funciona
Se toma cada tablero que alguien haya encontrado y que puntúe razonablemente bien,
y para cada par de posiciones vecinas se cuenta cuántas veces se sitúa allí un par
de piezas dado, ponderado por lo bueno que era el tablero. Emergen dos patrones.
Algunas adyacencias aparecen una y otra vez en los mejores tableros: son estructura
segura, real. Otras aparecen casi en todas partes pero nunca en los tableros de
cabeza: esas son las trampas, las elecciones que parecen acertadas y limitan la
puntuación.
Las trampas se agrupan en regiones concretas del tablero en lugar de repartirse de
forma uniforme. Saber dónde están convierte el corpus en un mapa: qué colocaciones
seguir, y cuáles desmontar y reconstruir. Agrupar los tableros según cómo están
dispuestas sus esquinas orienta entonces la búsqueda hacia la familia más
prometedora a atacar.
> **[Figure]** Interactivo: el mapa de trampas, familia de esquinas por familia de esquinas — interactive: PalimpsestDiagram. Rendered on the canonical page (link above); not shown in this markdown export.
## El tablero
> **[Interactive: RecordBoard]** Rendered on the canonical page (link above); not shown in this markdown export.
## El resultado
Utilizada como un mapa para orientar la búsqueda, esta aproximación alcanzó 463 de
las 480 aristas emparejadas, el mejor tablero que este proyecto ha producido. A
título de comparación, el mejor tablero de la comunidad en este puzzle es 470, y
una solución completa cuenta 480.
Una salvedad que merece señalarse: intentar usar directamente la lista de trampas,
forzando la búsqueda a evitar las colocaciones atrapadas, no funcionó por sí solo y
tendía a empeorar los tableros. El valor estaba en leer el corpus para elegir dónde
concentrar el esfuerzo, no en codificar en duro sus conclusiones dentro de la
búsqueda.
## Método
Para el lector que quiere el procedimiento exacto. Se ejecuta en dos pasadas.
**1. Minería de consenso ponderada por la puntuación y separada por cuenca.** Sobre
un corpus de tableros cuya puntuación va de 400 a 480, para cada par de celdas
adyacentes $(i, j, \text{dir})$ y cada par de piezas que alguna vez se sitúa allí,
se calculan dos frecuencias en lugar de una:
$$
\begin{aligned}
p_\text{high}(\text{pair}) &= \frac{\#\{\text{boards with the pair, score} \ge 460\}}{\#\{\text{boards with score} \ge 460\}} \\[4pt]
p_\text{all}(\text{pair}) &= \frac{\#\{\text{boards with the pair}\}}{\#\{\text{all boards}\}}
\end{aligned}
$$
junto con un *techo*: la puntuación máxima de cualquier tablero que contenga ese
par. Es el techo, y no $p_\text{high}$, lo que separa las dos categorías. El **buen
consenso** es un $p_\text{all}$ alto con un techo que alcanza la familia de cabeza,
tableros al nivel del mejor del proyecto (463) o a un punto de él: patrones que los
tableros más fuertes conservan, así que estructura fiable. Las **trampas de
consenso** son un $p_\text{all}$ alto con un techo que se cala un par de puntos más
abajo, sin que ningún tablero portador del par supere los 460-y-pico: la elección
errónea consensuada que bloquea a toda una familia por debajo del récord. El corte
se sitúa entre «alcanza la cima» y «se cala justo por debajo»; en este corpus
pequeño (un techo de 463, tableros agrupados desde los 450 altos hasta los 460
bajos) se fija a mano en lugar de barrerse, y $p_\text{high}$ (puntuación $\ge$ 460)
se reporta al lado pero no es el discriminante. La vista de frecuencia única (la
persistencia sola) no puede distinguirlos; separar por techo es todo el truco.
**2. ALNS de destrucción de trampas.** Se toma un tablero de 461 (se sitúa *dentro*
de la cuenca de trampas por construcción), se localizan los ~50 pares-trampa mejor
clasificados que contiene, y se encuentra la cuña: la posición cuya eliminación
rompe la mayor cantidad de pares-trampa mientras preserva los de buen consenso.
Luego se perturban esas celdas trampa, se cambian por piezas no atrapadas,
introduciendo de 4 a 8 discordancias deliberadas, y se devuelve el tablero a la
[búsqueda adaptativa de gran vecindario](/es/research/build/local-search/local-search-alns/).
El operador de destrucción de la peor banda de ALNS rasga preferentemente
exactamente esas regiones rotas intencionadamente y las reconstruye. Ejecución: 30
minutos × 6 semillas.
La complejidad es poco notable: la pasada de minería es lineal en el tamaño del
corpus, y el coste real es la búsqueda ALNS que orienta. La contribución reside en
el *dónde* dirige esa búsqueda, no en una nueva búsqueda.
## Reproducir
El verificador `just research-record-boards` recalcula la puntuación en aristas
emparejadas del tablero de 463 versionado a partir de sus aristas Bucas en bruto y
comprueba que iguala lo anunciado, de modo que el tablero es reproducible y
verificable byte a byte en el visor. La búsqueda que lo *encontró* es una ejecución
estocástica del motor ALNS compartido (30 min × 6 semillas), orientada por el mapa
de trampas descrito arriba. No reproducirá el mismo tablero, razón por la cual el
artefacto de referencia es el tablero, no una nueva ejecución. La orientación se lee
de un corpus de tableros fuertes, de modo que la ejecución no se reproduce aquí
desde cero.
## Preguntas abiertas
¿Por qué la reconstrucción de las regiones atrapadas tiende a recaer sobre el mismo
tablero de cabeza ya conocido en lugar de sobre uno realmente nuevo? ¿Revelaría un
mapa distinto por familia de esquinas una estructura que el mapa combinado oculta?
¿Y ayudaría una penalización suave para las colocaciones atrapadas allí donde una
prohibición estricta perjudicó?
## Relacionado
- [Minería de anti-patrones](https://eternity2.dev/es/research/build/learning/anti-pattern-mining/) — La idea sutil detrás de aprender de los tableros fuertes: no todo acuerdo entre ellos es bueno. Algunos emplazamientos compartidos son estructura real; otros son una trampa común que limita cada búsqueda justo por debajo de la cima. Distinguir ambos y atacar la trampa.
- [Aprender a partir de tableros fuertes](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/) — Un estudio en cinco experimentos de una sola idea: en lugar de buscar Eternity II desde cero, extraer estructura del corpus de tableros fuertes ya encontrados y reinyectarla en una búsqueda. Un prior de posición, un voto de jugada aprendido, una brújula de demanda escasa, un minero de antipatrones y un decodificado de récord, ordenados de la señal más simple a la más sutil, y el único muro que los cinco alcanzan.
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [KEYRING](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/keyring/) — Construir un tablero desde cero, clasificando cada pieza siguiente según tres señales aprendidas de tableros fuertes anteriores. Alcanzó 460 en una familia de tableros que ninguna búsqueda previa había resuelto.
- [Búsqueda local y ALNS](https://eternity2.dev/es/research/build/local-search/local-search-alns/) — Destruir una parte del tablero, reconstruirla mejor y dejar que el algoritmo aprenda qué demoliciones rinden. La búsqueda de gran vecindario adaptativa es el pulidor más fiable de este proyecto, y la demostración más nítida del muro donde el pulido se detiene.
---
# PRIOR
> Construir un tablero desde cero, resolviendo los empates según la posición habitual de las piezas en los buenos tableros ya conocidos. Alcanza una puntuación alta sin ningún tablero de partida que copiar.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/prior/
- Actualizado: 2026-07-21
- Temas: construction, learning
- Reproducir: `just research-record-boards`
- Fuente: Búsqueda beam (página de concepto de este proyecto): construcción primero-el-mejor de ancho acotado — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/build/construct/beam-search.mdx
---
PRIOR abre el [estudio del aprendizaje a partir de los tableros fuertes](/es/research/lab/experiments/raphael-anjou/learning/)
con la forma más simple que la idea puede tomar: un conteo. La mayoría de los
tableros fuertes de este sitio se encuentran partiendo de un buen tablero
existente y mejorándolo. PRIOR plantea una pregunta más difícil: ¿se puede
construir un tablero competitivo desde una cuadrícula vacía, sin ningún tablero
al que anclarse? El truco consiste en dejar que la multitud de buenos tableros
pasados guíe discretamente la construcción sin copiar ninguno en particular, y
esa guía no es más que un recuento de dónde tienden a situarse las piezas.
## Cómo funciona
A partir de la biblioteca de tableros con buena puntuación, PRIOR aprende una
sola cosa muy simple: para cada posición del tablero, con qué frecuencia aparece
cada pieza allí. Eso da una preferencia suave, un prior, sobre lo que tiende a
ir dónde.
Luego construye mediante una búsqueda beam, manteniendo vivos muchos tableros
parciales a la vez y extendiéndolos celda a celda. Cuando dos opciones encajan
el mismo número de aristas, el prior resuelve el empate a favor de la pieza más
típica de los tableros fuertes en ese lugar. Una regla de diversidad evita que
los muchos intentos paralelos colapsen sobre el mismo camino. No se copia ningún
tablero individual; la guía es estadística.
> **[Figure]** Interactivo: el mapa de calor del prior posicional — interactive: PriorDiagram. Rendered on the canonical page (link above); not shown in this markdown export.
## El tablero
> **[Interactive: RecordBoard]** Rendered on the canonical page (link above); not shown in this markdown export.
## El resultado
Desde cero, PRIOR alcanza mediados de los 450, y con un prior más afilado
construido solo a partir de los mejores tableros sube más alto. Seguido de un
refinamiento local, alcanza 460, el tablero mostrado aquí. Que una construcción
desde la nada quede tan cerca de los récords es justamente el punto: la
estructura de los buenos tableros es en parte aprendible, y no hace falta partir
de uno para llegar hasta ahí.
No es la puntuación máxima del proyecto (463), y el impulso final aquí se apoya
en un paso de refinamiento, lo que la etiqueta del tablero señala. Pero como
resultado desde una hoja en blanco es el más fuerte que tiene el proyecto, y es
el cimiento del que crecieron los constructores multi-señal posteriores.
## Método
El prior es deliberadamente la cosa más simple que podría funcionar: un conteo.
Sobre cada tablero del corpus cuya puntuación supera un umbral (440 para el prior
base), se acumula una matriz $256 \times 256$ $M[p][c]$, cuántos tableros fuertes
colocan la pieza $p$ en la celda $c$. Normalizada por celda, esa es la
preferencia usada para resolver los empates.
Tres afinamientos, cada uno una variante del mismo conteo:
- **Sensible a la rotación.** Se divide cada pieza según sus cuatro rotaciones:
un tensor $1024 \times 256$ ($256 \times 4$ filas). El prior ahora prefiere no
solo la pieza correcta sino la orientación correcta, 262.144 entradas frente a
las 65.536 de base.
- **Por familia de esquinas.** Los tableros fuertes se agrupan en familias según
sus cuatro piezas de esquina. Construir un prior *separado* a partir de los
tableros de una sola familia da una señal que la matriz agrupada difumina por
promediado; esto es lo que permitió que la construcción desde cero alcanzara un
460 inédito en lugar del abarrotado cuenco común.
- **Umbral más afilado.** Reconstruir el prior solo a partir de los mejores
tableros (un corte más alto) eleva el techo de la construcción, a costa de una
señal más fina y más ruidosa.
La construcción es una [búsqueda beam](/es/research/build/construct/beam-search/):
se mantienen $W$ tableros parciales, se extienden celda a celda, y cuando los
candidatos empatan en aristas encajadas se deja que $M$ resuelva el empate; una
regla de diversidad mantiene los $W$ beams separados entre sí. El 460 obtenido
aquí lleva una construcción beam desde cero hasta mediados de los 450, y luego
una breve cola de refinamiento local hasta 460.
**La novedad se verificó, no se supuso.** El tablero resultante se compara con
cada tablero del nivel 460 ya conocido, por permutación de esquinas y distancia
de Hamming sobre (pieza, posición); una coincidencia solo cuenta como un nuevo
cuenco cuando la familia de esquinas difiere o la distancia de Hamming es grande.
El tablero de PRIOR pasó esa prueba: es un cuenco genuinamente distinto, no un
redescubrimiento.
## Reproducir
`just research-record-boards` verifica exactamente la puntuación del tablero 460
comprometido, arista a arista, a partir de su cadena Bucas almacenada, de modo
que el resultado es comprobable aunque la búsqueda que lo encontró no sea
determinista (su impulso final usa una cola de refinamiento estocástica). El
tablero es el artefacto de referencia. La búsqueda que lo produjo es el productor
beam compartido, con el único cambio que describe esta página: el prior
posicional aprendido que resuelve sus empates. Ese prior es una matriz extraída
de un amplio corpus de tableros fuertes, razón por la cual la ejecución no se
reproduce aquí desde cero.
## Preguntas abiertas
¿Hasta dónde puede afilarse el prior antes de sobreajustar? Construido a partir
de solo un puñado de tableros de cabeza, la señal es fuerte pero fina. ¿Podría un
prior separado por familia de tableros capturar una estructura que el prior
combinado difumina por promediado? ¿Y qué parte de la brecha final se debe a la
construcción frente al refinamiento que la sigue?
## Relacionado
- [Priors de corpus](https://eternity2.dev/es/research/build/learning/corpus-priors/) — La forma más simple de aprender de los tableros fuertes: contar dónde tiende a situarse cada pieza, o con qué frecuencia satisface una demanda escasa, y usar ese recuento como un suave desempate en la construcción. Debe seguir siendo un desempate; en cuanto pasa a formar parte del objetivo, hace colapsar la búsqueda.
- [Aprender a partir de tableros fuertes](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/) — Un estudio en cinco experimentos de una sola idea: en lugar de buscar Eternity II desde cero, extraer estructura del corpus de tableros fuertes ya encontrados y reinyectarla en una búsqueda. Un prior de posición, un voto de jugada aprendido, una brújula de demanda escasa, un minero de antipatrones y un decodificado de récord, ordenados de la señal más simple a la más sutil, y el único muro que los cinco alcanzan.
- [KEYRING](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/keyring/) — Construir un tablero desde cero, clasificando cada pieza siguiente según tres señales aprendidas de tableros fuertes anteriores. Alcanzó 460 en una familia de tableros que ninguna búsqueda previa había resuelto.
- [GAUNTLET](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/gauntlet/) — Ejecutar la misma búsqueda en haz según nueve órdenes de recorrido distintos, para que aterrice en regiones diferentes en lugar de converger siempre a la misma. El orden en zigzag encontró un tablero 458 inédito.
- [El robo de piezas, donde mueren los solucionadores](https://eternity2.dev/es/research/why/piece-theft/) — Un solucionador rellena unas pocas filas sin esfuerzo y luego choca contra un muro en mitad del tablero. He aquí el mecanismo: una pieza escasa gastada en el lugar equivocado, varias filas atrás.
- [Búsqueda en haz](https://eternity2.dev/es/research/build/construct/beam-search/) — Mantener con vida los K tableros parciales más prometedores a la vez y hacerlos crecer celda a celda. La búsqueda en haz es el motor de los constructores desde cero de este proyecto, y una ilustración nítida de por qué la anchura por sí sola se estanca en las profundidades del interior.
- [PALIMPSEST](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/palimpsest/) — Leer cada tablero fuerte para detectar los hábitos que, en silencio, limitan un tablero, y luego romperlos. Este experimento produjo el mejor tablero del proyecto: 463 de 480.
---
# REPLAY
> 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.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/replay/
- Actualizado: 2026-07-21
- Temas: backtracking, learning
- Fuente: Tableros estrictos de 460 de la comunidad (cronología de récords): los testigos que REPLAY reconstruye — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/records.mdx
---
REPLAY cierra el [estudio](/es/research/lab/experiments/raphael-anjou/learning/) 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.
## Cómo funciona
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.
> **[Figure]** Interactivo: las celdas de doble rotura — interactive: DoubleBreakDiagram. Rendered on the canonical page (link above); not shown in this markdown export.
> **[Figure]** Interactivo: reproducir la programación de roturas — interactive: DoubleBreakLab. Rendered on the canonical page (link above); not shown in this markdown export.
## El resultado
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.
## Método
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.
## Reproducir
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](/es/research/records/) 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.
## Preguntas abiertas
¿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?
## Relacionado
- [Decodificar récords](https://eternity2.dev/es/research/build/learning/decoding-records/) — La forma más literal de aprender de un tablero fuerte: reconstruirlo con exactitud, pieza por pieza, hasta que tu búsqueda sepa reproducirlo. Lo que la reconstrucción te obliga a añadir es el ingrediente que le faltaba a tu búsqueda, y la reproducción es la prueba.
- [Aprender a partir de tableros fuertes](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/) — Un estudio en cinco experimentos de una sola idea: en lugar de buscar Eternity II desde cero, extraer estructura del corpus de tableros fuertes ya encontrados y reinyectarla en una búsqueda. Un prior de posición, un voto de jugada aprendido, una brújula de demanda escasa, un minero de antipatrones y un decodificado de récord, ordenados de la señal más simple a la más sutil, y el único muro que los cinco alcanzan.
- [LADDER](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/ladder/) — Lanzar cientos de búsquedas cortas y baratas sobre el tablero, conservar solo los arranques más profundos y hacer ascender a los supervivientes a través de rondas cada vez más largas.
- [Récords y solucionadores](https://eternity2.dev/es/research/records/) — Eternity II nunca se ha resuelto, pero casi dos décadas de esfuerzo colectivo han llevado el mejor tablero a 470/480. Quién ostenta qué, cómo lo lograron y por qué algunos tableros «480» anunciados no corresponden al puzzle real.
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [Aprendizaje de no-goods: recordar por qué fallaste](https://eternity2.dev/es/research/build/reduce/nogood-learning/) — Un subárbol fallido es un teorema: este estado parcial nunca podrá extenderse. Memorízalo y no vuelvas a entrar en él. La comunidad probó ambas variantes: tablas de transposición al estilo del ajedrez sobre la frontera de búsqueda, y restricciones extraídas del propio puzzle. El balance completo de lo que la memoria compra a la escala de E2, y los tableros pequeños donde realmente rinde.
- [PALIMPSEST](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/palimpsest/) — Leer cada tablero fuerte para detectar los hábitos que, en silencio, limitan un tablero, y luego romperlos. Este experimento produjo el mejor tablero del proyecto: 463 de 480.
---
# Una poda correcta por conteo de colores para la búsqueda tolerante a rupturas
> Llevar, color a color, la oferta de semiaristas frente a la demanda del frente en un DFS con presupuesto de rupturas, y podar en cuanto el déficit o su paridad superan las rupturas restantes. Correcto por construcción; la ganancia se compone con la profundidad.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/ledger/
- Actualizado: 2026-07-22
- Temas: backtracking, search-space, structure
- Reproducir: `just research-ledger-prune`
- Fuente: El topic de reproducción ledger-prune: código, plan y resultados en el repositorio — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/ledger-prune
---
La búsqueda de puntuaciones altas en Eternity II corre con una tolerancia a
rupturas: el DFS puede colocar una pieza discordante mientras el total de
rupturas cobradas quepa en un presupuesto. En ese marco casi ninguna poda
clásica es correcta, porque el presupuesto es un recurso global; una rama que
parece localmente muerta puede salvarse gastando una ruptura en un lugar
completamente distinto. Me pregunté si una prueba de conteo puramente global
podía podar de todos modos, sin cortar jamás una compleción que quepa en el
presupuesto. Se puede: cero disparos erróneos en todas las repeticiones, y
reducciones de nodos que se componen con la profundidad, aunque su magnitud
depende del motor.
## Cómo funciona
En cada nodo la búsqueda lleva un libro de cuentas, color a color: la oferta de
semiaristas que aún ofrecen las piezas sin usar (los cuatro lados de cada una)
y la demanda del frente (lados expuestos de las celdas colocadas que miran a
celdas vacías, más el borde gris que el marco todavía debe). De ahí salen dos
condiciones necesarias para toda compleción que respete el presupuesto de
rupturas restante r:
- **Déficit.** La carencia total, sumada sobre los colores como max(0, demanda
menos oferta), nunca puede superar r. Es la forma consciente del presupuesto
del fallo "se acabó el color c" que un DFS desnudo solo descubre celda a
celda.
- **Paridad.** El número de colores cuya diferencia oferta menos demanda es
impar nunca puede superar 2r, más un hueco por cada unión de pista no
cobrada. Una colocación perfectamente apareada mueve cada balance de color en
una cantidad par; la paridad solo cambia en una ruptura cobrada (que voltea
exactamente dos colores) o en una unión de pista no cobrada (a lo sumo uno).
Si cualquiera de las dos falla, no existe compleción dentro del presupuesto
bajo ese nodo y el subárbol entero se salta. Ambas se demuestran con el mismo
argumento de invariancia, que es lo que hace la poda correcta y no heurística:
nunca necesita adivinar dónde se gastarán las rupturas.
## Qué se midió
Tres sondas, todas confirmadas en el topic de reproducción.
**La puerta de corrección.** Repetir la cola perfecta conocida de un tablero
con holgura cero; como la cola verdadera no necesita rupturas, cualquier
disparo es un bug. Ocho tableros generados, 257 profundidades cada uno: cero
disparos. La versión original de este estudio, dentro de mi motor de caza de
récords, pasó la misma puerta sobre cuatro tableros de alta puntuación (251
celdas juzgadas cada uno), también con cero disparos.
**La malla A/B.** Agotar dos veces un sufijo fijado de un tablero generado
resuelto, poda apagada y poda encendida, contando todas las compleciones dentro
del presupuesto. Los dos brazos deben hallar las mismas compleciones; así fue
en los 144 pares sin censura. Las 96 celdas de la malla (sufijos de 20 a 32
celdas, presupuestos 1 a 3, 8 semillas) muestran una razón de nodos por encima
de 1: mínimo 1,48x, medianas de 1,8x a 4,1x. La paridad es el disparador
dominante en todas partes.
**Las filas de certificado.** Los tres tableros 464 comunitarios (recuperados
de las URL del [estudio design-recipe](/es/research/why/design-recipe/); el cuadro
comunitario vive en la [página de récords](/es/research/records/)) se giraron 180
grados y sus colas se agotaron con presupuestos sin holgura, el protocolo del
estudio original. Los tableros se identifican por su huella de rupturas de
sufijo; uno lee (2, 5, 6, 7) frente al (2, 5, 6, 8) original, tres
profundidades exactas y una desplazada en una sola ruptura por una diferencia
de convención de cobro. Ese tablero es el tablero 1 del estudio original.
## El resultado
| Afirmación (medida original) | Medido aquí | Estado |
|---|---|---|
| Cero disparos erróneos repitiendo colas reales con holgura cero | 0 disparos en 8 tableros x 257 profundidades | reproducido |
| La poda nunca cambia la respuesta | compleciones idénticas en los 144 pares A/B sin censura | reproducido |
| Razón de nodos por encima de 1 con presupuestos pequeños | los 96 pares de la malla por encima de 1 (mín 1,48x) | reproducido |
| La razón se compone con la profundidad (1,5x, 140x, 995x, 4.330x) | 1,7x, 19,4x, 45,3x; la fila más profunda censurada | forma reproducida, magnitud ligada al motor |
| Nulo con presupuesto grande (~0,1 por ciento de disparos) | la sonda quedó en el régimen activo (76 a 82 por ciento) | no probado aquí |
En el tablero 464 identificado, con presupuestos idénticos a los originales
(r = 5 y r = 6 en las filas profundas), el agotamiento halló exactamente una
compleción en cada profundidad sin censura, la forma de certificado que el
original reporta, y la razón se compone:
> **[Figure]** Filas de certificado en el tablero 464 (girado 180°, presupuestos sin holgura) — interactive figure. Rendered on the canonical page (link above); not shown in this markdown export.
Un multiplicador que crece con la profundidad es la firma de una reducción del
factor de ramificación, la única clase de aceleración que sobrevive al cambio
de escala (el argumento está desarrollado en
[la poda vence a la velocidad](/es/research/why/prune-vs-speed/)).
## Alcance y límites
La corrección es el titular, y es independiente del motor; las magnitudes no lo
son. El motor original juzgaba el libro de cuentas por candidato, sobre una
actualización incremental, dentro de una búsqueda por cubetas limitada a una
discordancia por celda, y midió de 140x a 4.330x en las mismas filas. Este
porte juzga una vez por nodo sobre un libro recalculado desde cero, cobra las
rupturas por arista sin tope por celda, y alcanza 45,3x antes de que el tope de
300 segundos censure la fila más profunda. Portar el libro incremental por
candidato es el siguiente paso declarado; hasta entonces, la cifra de 4.330x se
atribuye al motor original, no la confirma este.
Dos cosas más no se siguen. Esto no es una afirmación de puntuación: LEDGER
poda un DFS con presupuesto de rupturas ya existente (la familia de motores
detrás de búsquedas como
[la de Joshua Blackwood](/es/research/lab/experiments/joshua-blackwood/solver/));
por sí solo no encuentra nada. Y solo compensa en el régimen de presupuesto
pequeño y sufijo profundo: el original midió alrededor de 0,1 por ciento de
disparos bajo un presupuesto generoso a escala del tablero, donde la
contabilidad es pérdida pura. Mi sonda fuera de régimen ni siquiera pudo
alcanzar ese régimen silencioso sobre un sufijo corto (un presupuesto agotable
se seca cerca de las hojas, donde vive la mayoría de los nodos); ese nulo queda
por tanto sin probar aquí.
## Relacionado
- [Por qué un ordenador más rápido no ayuda](https://eternity2.dev/es/research/why/prune-vs-speed/) — La idea más importante de la búsqueda combinatoria difícil: reducir el espacio que se explora vence, por un margen exponencial, a explorarlo más rápido. Eternity II está diseñado para que apenas puedas reducirlo.
- [Argumentos de paridad](https://eternity2.dev/es/research/build/analysis/parity-arguments/) — Cuente cualquier cosa en un tablero de emparejamiento de aristas dos veces, una desde cada lado, y los totales deben coincidir, entregando pruebas de imposibilidad al precio de una sola pasada. La historia del 479 muestra tanto su poder como su trampa: un argumento de paridad limpio, cierto para todo movimiento interior, derrotado por las sesenta aristas de borde que nadie puntúa.
- [Diseñado para ser irresoluble: la receta](https://eternity2.dev/es/research/why/design-recipe/) — Eternity II sigue una receta para lograr el puzzle de emparejamiento de aristas más difícil posible: forma compacta, sin piezas simétricas ni duplicadas, paletas separadas, frecuencias planas, una sola solución esperada. La comunidad aplicó ingeniería inversa a cada ingrediente en el año del lanzamiento.
- [El solucionador de Blackwood, decodificado y ejecutado aquí](https://eternity2.dev/es/research/lab/experiments/joshua-blackwood/solver/) — El backtracker récord de Joshua Blackwood, decodificado gracias a las notas de Jef Bucas (un calendario de cuotas de color y una tolerancia a desajustes en el tramo final, ajustados casi óptimamente), luego construido y ejecutado en mi M1: tal como se publicó, vuela hasta 248 de 256 piezas ignorando las pistas; fija las cinco pistas oficiales y el mismo motor se atasca cerca de 45.
---
# Meet in the middle
> Experimentos exactos de final de partida que se encuentran en el medio: enumeran una región desde dos extremos y las unen por la costura, para hallar la verdadera mejor terminación con una prueba en lugar de la mejor conjetura de una heurística. Miden con exactitud una región pequeña en vez de perseguir la puntuación del tablero completo.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/meet-in-the-middle/
- Actualizado: 2026-07-22
---
La búsqueda heurística conjetura; nunca sabe si tiene la mejor terminación
posible. Los experimentos que se recogen aquí adoptan la postura contraria para
una región pequeña: la enumeran desde dos extremos, unen las mitades allí donde
los colores de su costura coinciden y sus conjuntos de piezas no se solapan, y
obtienen la mejor terminación *exacta* junto con una prueba de que nada puntúa
más alto. Es el clásico intercambio
[meet-in-the-middle](/es/research/build/exact/meet-in-the-middle/) de tiempo por
espacio, apuntado al final de partida del puzzle.
Estos no son intentos de superar la puntuación. Responden a una pregunta
distinta de la de las
[combination pipelines](/es/research/lab/experiments/raphael-anjou/pipelines/) y de
los [estudios](/es/research/lab/experiments/raphael-anjou/) de búsqueda: no
*hasta qué altura puede trepar una heurística*, sino *cuál es la verdadera mejor
terminación de esta región y en qué punto los métodos exactos dejan de ser
asequibles*. Una respuesta exacta sobre una región pequeña vale aquí más que otro
casi acierto sobre el tablero completo.
El primer y por ahora único experimento de esa clase es
[BANDSAW](/es/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/).
Resolvió con exactitud una banda de filas en un banco de pruebas de 10×10,
demostró en qué punto el presupuesto de desajustes deja de ser asequible, y
dejó como subproducto un tablero de 437 sin marco (contado en aristas
emparejadas), la única página de este cuaderno con rigor demostrado. La sección
lleva el nombre de la técnica en lugar del de la única página, porque más ideas
exactas de final de partida deberían acompañarla a medida que vayan llegando.
## Páginas de esta sección
- [BANDSAW](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/) — Resolver exactamente una banda de filas encontrándose en el medio, para hallar el verdadero mejor final y medir hasta qué punto puede decidirse por anticipado una fin de partida.
## Relacionado
- [BANDSAW](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/) — Resolver exactamente una banda de filas encontrándose en el medio, para hallar el verdadero mejor final y medir hasta qué punto puede decidirse por anticipado una fin de partida.
---
# BANDSAW
> Resolver exactamente una banda de filas encontrándose en el medio, para hallar el verdadero mejor final y medir hasta qué punto puede decidirse por anticipado una fin de partida.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/
- Actualizado: 2026-07-21
- Temas: exact-methods
- Fuente: Encuentro en el medio (la página conceptual de este proyecto): la técnica de las dos mitades y la unión — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/build/exact/meet-in-the-middle.mdx
---
La búsqueda heurística adivina; nunca sabe si tiene el mejor final posible.
BANDSAW es el experimento opuesto: para una banda de filas cerca del fondo,
calcula la mejor completación exacta, con una prueba de que nada puntúa más
alto. El objetivo no es la velocidad, sino la certeza, y esa certeza sirve
además de regla para medir lo difícil que es realmente la fin de partida.
## Cómo funciona
Se corta la banda en una mitad superior y una mitad inferior. Se enumera cada
forma de rellenar la mitad superior hasta un pequeño presupuesto de
desajustes, indexada por dos cosas: qué piezas empleó y la fila de colores que
deja colgando en la costura. Se enumera la mitad inferior de la misma manera,
pero solo a partir de las piezas que la mitad superior no usó. Luego se unen
las dos mitades allí donde sus colores de costura concuerdan y sus conjuntos de
piezas no se solapan. Esa unión de encuentro en el medio halla la mejor
completación exacta sin recorrer todo el árbol.
Unas tablas de cotas inferiores exactas, calculadas trabajando hacia atrás
columna por columna, le permiten podar las ramas que ya no pueden superar el
presupuesto, y eleva el presupuesto paso a paso hasta que una ronda no
encuentra nada nuevo, lo que prueba la mejor puntuación para esa banda.
> **[Figure]** Interactivo: el árbol de fin de partida por encuentro en el medio — interactive: MeetInMiddleDiagram. Rendered on the canonical page (link above); not shown in this markdown export.
## El resultado
En un banco de pruebas 10×10, BANDSAW resuelve la fin de partida de forma
exacta y fija el presupuesto justo donde la exactitud deja de ser asumible: el
árbol de búsqueda crece unas veinte veces por cada desajuste adicional, en
ambos lados, de modo que encontrarse en el medio deja de compensar al tamaño
completo del tablero. Ese resultado negativo es la parte útil: te dice
exactamente dónde se agotan los métodos exactos y dónde las heurísticas deben
tomar el relevo. Las piezas exactas que sobrevivieron, las tablas de cotas
inferiores de sufijo y el branch-and-bound podado, se convirtieron en
instrumentos reutilizables. Un tablero sin marco que puntúa 437 salió de la
misma maquinaria.
## Método
La unión es la idea; la poda es lo que la hace asumible.
- **Encuentro en el medio.** Se corta la banda en una mitad superior y una
inferior. Se enumera cada relleno de la mitad superior hasta un presupuesto de
desajustes, indexado por (conjunto de piezas usado, fila de colores de
costura). Se enumera la mitad inferior de la misma forma, tomando solo de las
piezas que dejó la mitad superior. Se unen las dos mitades allí donde sus
colores de costura concuerdan *y* sus conjuntos de piezas son disjuntos. Esa
unión halla la mejor completación exacta sin recorrer nunca el árbol entero:
el clásico compromiso tiempo-por-espacio del
[encuentro en el medio](/es/research/build/exact/meet-in-the-middle/).
- **Cotas inferiores de sufijo.** Trabajar hacia atrás columna por columna
construye tablas de cotas inferiores exactas, de modo que un parcial que ya no
puede superar el presupuesto actual se poda antes de extenderse.
- **Trinquete de presupuesto.** Se eleva el presupuesto de desajustes un escalón
a la vez y se vuelve a resolver; cuando una ronda no encuentra nada mejor, el
mejor anterior queda *probado* como óptimo para esa banda. Esa prueba es la
razón por la que esta página está etiquetada como **proven**, y no medida: el
resultado es un certificado, no una muestra.
El techo medido: cada mitad crece ~20× por unidad adicional de presupuesto, de
modo que al tamaño completo de tablero 16×16 la tabla de la mitad superior ya no
cabe; es la memoria, no el tiempo, la que es el muro. Ese resultado negativo es
el entregable: fija con precisión dónde se agotan los métodos exactos y dónde
las heurísticas deben tomar el relevo. El tablero 437 sin marco cayó de la misma
maquinaria.
## Reproducir
Determinista (`kind: exact`): la resolución por encuentro en el medio y su
prueba de optimalidad se reproducen byte a byte para una banda dada, y el
tablero 437 es verificable en el visor. El enumerador MITM y las tablas de cotas
de sufijo están versionados con el código de investigación.
## Preguntas abiertas
¿Pueden las tablas de cotas inferiores escalar a la fin de partida 16×16
completa, o el espacio de estados de la costura crece demasiado? ¿A qué tamaño
de banda pasa a ser la memoria, y no el tiempo, el límite? Y los raros casos en
que la unión del medio sí se dispara, ¿pueden detectarse por anticipado y
terminarse de forma exacta?
## Relacionado
- [STAGED](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/staged/) — Construir todo el tablero desde cero, sin marco prefijado, por etapas, dejando que el borde emerja al final a partir de las piezas restantes.
- [La entropía y la ley de área](https://eternity2.dev/es/research/why/entropy-area-law/) — Eternity II tiene dos reglas: los bordes deben coincidir y cada pieza se usa una sola vez. La primera es generosa. Toda la dificultad reside en la segunda.
- [Encuentro en el medio](https://eternity2.dev/es/research/build/exact/meet-in-the-middle/) — Enumerar dos mitades de un problema y unirlas en una interfaz compartida, intercambiando memoria por un exponente reducido a la mitad. El truco clásico de Horowitz–Sahni, qué aspecto tiene sobre bandas del tablero, y qué midió el experimento BANDSAW de este proyecto, incluido el método unilateral que lo superó.
---
# Pipelines de combinación
> Siete experimentos de búsqueda con nombre propio que persiguen la puntuación, cada uno un pipeline más que un único algoritmo: construye un tablero con un motor y luego lo eleva o lo remata con otro. Junto a ellos, dos hallazgos desmontan la maquinaria en la que los pipelines se apoyan. Cada página deja constancia de su idea, de su tablero y de las preguntas que deja abiertas.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/
- Actualizado: 2026-07-22
---
Este grupo reúne siete experimentos de pipeline con puntuación y dos hallazgos.
Un *pipeline* construye un tablero con un motor y luego lo eleva o lo remata
con otro; el interés reside tanto en la *combinación*, en el reparto del
trabajo entre construcción, reparación y un remate exacto, como en cualquiera
de las etapas por separado. Los dos hallazgos, el estudio de anchura de haz y
el marco fluido, no tienen puntuación propia: desmontan la maquinaria en la que
esta familia se apoya, el productor por haz en un caso y el borde congelado de
CLOISTER en el otro. Las tarjetas de abajo distinguen los dos tipos. Ese
encadenado de motores es también lo que separa a este grupo de los cuatro
estudios que desmontan cada uno un único paradigma: el
[estudio DFS](/es/research/lab/experiments/raphael-anjou/dfs-study/), el
[estudio de reparación](/es/research/lab/experiments/raphael-anjou/repair-study/),
[aprender de tableros fuertes](/es/research/lab/experiments/raphael-anjou/learning/)
y el [estudio de pistas](/es/research/lab/experiments/raphael-anjou/hint-study/).
Comparten los [motores](/es/research/lab/experiments/raphael-anjou/engines/); lo que
difiere es cómo cada uno los compone y los gobierna: qué siembra, qué prohíbe,
qué demuele y reconstruye. La sección de método de cada página recorre sus etapas
en orden. Varios de los constructores que parten de cero se apoyan en el productor
en haz, y dos en el bucle de reparación ALNS, motores que todavía no tienen su
propia ficha aquí (véase la
[página de motores](/es/research/lab/experiments/raphael-anjou/engines/)); cuando un
pipeline sí la tiene, su página lo dice con claridad en lugar de remitir a una
página que aún no existe.
Están ordenados por lo que enseñaron, no por su puntuación. Un pipeline que
terminó más abajo pero explicó por qué vale más aquí que uno que arañó un punto
sin saber decir cómo.
## Páginas de esta sección
- [GAUNTLET](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/gauntlet/) — Ejecutar la misma búsqueda en haz según nueve órdenes de recorrido distintos, para que aterrice en regiones diferentes en lugar de converger siempre a la misma. El orden en zigzag encontró un tablero 458 inédito.
- [CLOISTER](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/cloister/) — Fijar un borde perfecto y luego explorar el interior tratando las aristas del borde como restricciones duras desde la primera celda.
- [CAS](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/cas/) — Colocar primero un borde perfecto y resolver el tablero hacia adentro, anillo por anillo, cada anillo como un problema de asignación sobre las piezas restantes.
- [MIDDEN](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/midden/) — Decidir de antemano no cuándo puede romperse un tablero, sino dónde: confinar cada desajuste a una forma de celdas elegida, y buscar la mejor forma.
- [El marco fluido](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/fluid-frame/) — Un borde perfecto de 60 piezas no es un objeto rígido. Cada marco completamente apareado admite exactamente 45 intercambios libres a coste de borde cero; un tercio de los marcos perfectos ni siquiera pueden arrancar el interior, y un solo intercambio libre revive cada uno de ellos.
- [LADDER](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/ladder/) — Lanzar cientos de búsquedas cortas y baratas sobre el tablero, conservar solo los arranques más profundos y hacer ascender a los supervivientes a través de rondas cada vez más largas.
- [Hacer un productor beam 10x mejor: la respuesta es la anchura](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/beam-width/) — Un repaso verificado más mediciones apareadas: ninguna astucia por nodo supera la anchura bruta del haz a igual tiempo de reloj. Los dos únicos aditivos que sobreviven son aleatorizar las claves de truncado empatadas exactamente (gratis) y el remuestreo SMC de los supervivientes (pequeño pero significativo).
- [MOSAIC](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/mosaic/) — Dividir el tablero en pequeños bloques, resolver cada uno hasta el óptimo demostrado y volver a pegarlos, pagando las costuras en lugar de prohibirlas. Partiendo de cero, sin ningún récord que copiar, el método alcanza 448.
- [STAGED](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/staged/) — Construir todo el tablero desde cero, sin marco prefijado, por etapas, dejando que el borde emerja al final a partir de las piezas restantes.
---
# Hacer un productor beam 10x mejor: la respuesta es la anchura
> Un repaso verificado más mediciones apareadas: ninguna astucia por nodo supera la anchura bruta del haz a igual tiempo de reloj. Los dos únicos aditivos que sobreviven son aleatorizar las claves de truncado empatadas exactamente (gratis) y el remuestreo SMC de los supervivientes (pequeño pero significativo).
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/beam-width/
- Actualizado: 2026-07-22
- Temas: construction, speed, search-space
- Reproducir: `just research-beam-width-smc`
- Fuente: Zhang, Complete Anytime Beam Search (AAAI-98) — https://cdn.aaai.org/AAAI/1998/AAAI98-060.pdf
- Fuente: Escalado de inferencia con filtros de partículas (2025) — https://arxiv.org/html/2502.01618v3
- Fuente: Dirección por Monte Carlo secuencial — https://arxiv.org/pdf/2306.03081
---
Buscaba la palanca que hiciera a un constructor de haz ancho diez veces mejor
por unidad de cómputo: una puntuación por nodo más lista, un oráculo de
completabilidad, una regla de dominancia, lo que fuera. Tras un repaso de la
literatura y una campaña de mediciones A/B apareadas, la respuesta es
decepcionante y útil a la vez: la palanca es la anchura bruta. Todo lo
ingenioso pierde frente a un haz simplemente más ancho a igual tiempo de
reloj, con exactamente dos excepciones baratas, ambas cambios en la regla de
supervivencia, no en cómo se puntúan los nodos.
## Qué se midió
El banco de pruebas es una escalera de instancias N×N plantadas y resolubles,
construidas con el generador del kit del proyecto: tableros con marco, el
balance de colores real, un óptimo conocido de 2N(N−1) aristas interiores
casadas y 5 celdas de la solución fijadas como pistas, a imagen de las pistas
oficiales. Un beam por capas rellena el tablero en orden de filas, y tres
reglas de supervivencia compiten a anchura y tiempo fijos: truncado top-k
determinista (plain), top-k con desempate aleatorio entre claves empatadas
exactamente, y remuestreo SMC, donde los supervivientes se sortean en
proporción a un softmax de su puntuación, al estilo de un filtro de
partículas. Cada tablero terminado se vuelve a puntuar con el marcador
canónico que excluye el borde; no se cree ningún autoinforme del solver.
Aquí importan dos disciplinas. Primero, todas las comparaciones son
apareadas: ambos brazos ven la misma instancia y la misma semilla, y las
estadísticas son una t apareada y un Wilcoxon sobre los deltas por semilla.
Segundo, el tamaño de peldaño se limita a N=12, porque en N=14 la
distribución de puntuaciones es fuertemente bimodal y la varianza de semilla
aplasta la varianza de mecanismo; una comparación con pocas semillas ahí es
ruido. Cuánto mueve la dureza de la instancia a las puntuaciones medidas es un
tema propio; véase
[cómo de difícil es esta instancia](/es/research/why/how-hard-is-this-instance/).
## El resultado
La anchura es la palanca dominante, y no por poco. En el banco más duro del
estudio original, la puntuación media sobre el óptimo sube de forma monótona
de 0,210 a anchura 32 hasta 0,346 (anchura 128), 0,527 (anchura 512) y 0,743
(anchura 2048) con un presupuesto fijo de 3 segundos. Las alternativas caras
pierden a igual tiempo en ese mismo estudio: un oráculo de completabilidad por
emparejamiento de Hall llega a 0,441 con anchura 64 donde un haz plain, con
los mismos 10 segundos, alcanza 0,815 con anchura 8192, y una fusión por
dominancia al estilo de diagramas de decisión baja la puntuación de 0,679 a
0,657. Su coste por nodo crece con el tamaño del tablero justo donde la
profundidad más escasea: el tiempo que queman compra menos que la anchura que
podría haber pagado.
La reproducción versionada confirma cada signo en el banco del kit:
> **[Figure]** Esperado (banco fuente) vs medido (banco del kit) — interactive figure. Rendered on the canonical page (link above); not shown in this markdown export.
Los dos aditivos de la regla de supervivencia son significativos por
separado. Aleatorizar las claves de truncado empatadas exactamente no cuesta
nada y gana +2,06 aristas a anchura 128. El remuestreo SMC gana +1,75 aristas
en N=10 (t = 3,30) y +1,92 en N=12 (t = 5,41), con recuentos de nodos
idénticos en ambos brazos: la ganancia no es más cómputo, sino otra elección
de parciales supervivientes. Un frente remuestreado se mantiene diverso y vive
más profundo antes de morir, donde un frente top-k determinista puede
ahogarse pronto con supervivientes casi duplicados. La temperatura hubo que
barrerla: T = 1,0 es catastrófica (de 17 a 29 aristas perdidas, pierde cada
semilla), y la ganancia vive en una meseta en torno a T en [0,1, 0,2]. El
mejor tablero de la campaña, un tablero SMC a N=12 que puntúa
[237 de 264](https://eternity2.dev/viewer?puzzle=smc_n12_c22_s34&puzzle_size=12&board_edges=adcaacpdafjcacofafqcadmfaeldabmeaetbacpeabmcaadbcmeaplimjunloswuquismgtulmngmmmmtqhmpwwqmjrwdabjejbaipwjnqopwjsqiiojtskinqusmsoqhmgswukmrtuubadtblbawkolomjksplmolipknulunwnoopngrgokhvrughhdaegbpdaorlpjtwrltntisutukjswstkpvisgltvvtklhwsteafwdlbaltqlwvjhnivouspijumstrnuiwigtwvikkwwsjvkfaejbsbaqjgsjrqjvltrpgqlmmignthmitvtvpntwrhqvkhreabkbgcagpogqhpptvshqwjviwvwhuiovgrunnnghhjnhrohbafrcheajrqhpqkrshiqupnhvkopirhkrklrnutijoouovrofaevekcaqvnkkniviggnnuopqjuuhgqjvlggtsrloqhsrvpmeafvcmfanujqklquglkloitlgvkinsnvgqjsrlpkhomsprqofabrfeaakdaewdadifadgdafweadscaehcacpfacmdafrcadbaac&hints=67.0-62.1-7.2-19.0-112.0),
se puede comprobar arista a arista en el visor.
## Qué no se sigue de esto
Este es un resultado sobre instancias de escalera, no sobre el 16×16
canónico. Que la ganancia SMC se transfiera a un productor 16×16 real, y a la
calidad del vivero que alimenta aguas abajo, sigue explícitamente abierto;
ninguna de estas cifras es una reivindicación de récord de ningún tipo (el
estado de los tableros que cuentan vive en la
[página de récords](/es/research/records/)).
Tres salvedades medidas acotan aún más el resultado. Las instancias del kit
son bastante más fáciles que el banco fuente (ratios de 0,82 a 0,88 frente a
0,21 a 0,74), lo que comprime el margen por encima del beam plain: la ganancia
SMC aterriza aquí en torno a +1 % relativo frente a +6 % allí, mismo signo,
significación más fuerte. El coste por nodo de este porte es mayor que el del
motor fuente, así que la ley de anchura se reporta a saturación (tope de 12
segundos, cada pasada termina) en lugar del marco a igual tiempo de la fuente;
los A/B de la regla de supervivencia no se ven afectados, porque ambos brazos
expanden por construcción los mismos nodos a anchura fija. Y el resultado de
los desempates autoriza una sola cosa: aleatorizar las claves empatadas
*exactamente*. Ensanchar la ventana de tolerancia de la puntuación es otro
movimiento, y desastroso sobre el productor 16×16 real en el estudio fuente
(450 cae a 290 con tolerancia 2). Aleatoriza los empates; nunca ensanches la
ventana.
## Relacionado
- [Búsqueda en haz](https://eternity2.dev/es/research/build/construct/beam-search/) — Mantener con vida los K tableros parciales más prometedores a la vez y hacerlos crecer celda a celda. La búsqueda en haz es el motor de los constructores desde cero de este proyecto, y una ilustración nítida de por qué la anchura por sí sola se estanca en las profundidades del interior.
- [Benchmark mono-núcleo](https://eternity2.dev/es/research/lab/experiments/single-core-benchmark/) — Quince solucionadores, los nuestros y nuestras implementaciones de los dos backtrackers récord de la comunidad, cada uno ejecutado una vez sobre diez variantes del puzzle oficial con las esquinas fijadas, un solo núcleo, 60 segundos por ejecución. El hallazgo: el número de nodos no es la puntuación.
- [¿Es NP-completa esta instancia y cómo la codifico?](https://eternity2.dev/es/research/why/how-hard-is-this-instance/) — El emparejamiento de aristas es NP-completo como familia, pero eso no dice nada de un tablero 16×16 fijo: una instancia aislada es una constante, no un problema. Lo que sí es cierto es la dureza en el peor caso de la familia y la dureza empírica de esta instancia, y cómo escribir el puzzle para un solucionador SAT, de cobertura exacta o de PLE, con pequeños esbozos detallados. Una medición con tableros plantados pone cifras a la elección de la formulación: un acantilado de resolubilidad que un paradigma de búsqueda golpea y otro cruza, y que se mueve con el número de colores.
- [LADDER](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/ladder/) — Lanzar cientos de búsquedas cortas y baratas sobre el tablero, conservar solo los arranques más profundos y hacer ascender a los supervivientes a través de rondas cada vez más largas.
---
# CAS
> Colocar primero un borde perfecto y resolver el tablero hacia adentro, anillo por anillo, cada anillo como un problema de asignación sobre las piezas restantes.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/cas/
- Actualizado: 2026-07-22
- Temas: construction, local-search
- Reproducir: `just research-cas-annular`
- Fuente: Tema de reproducción (este proyecto): plan publicado, crate de cómputo y resultados por marco detrás de cada número de esta página — https://github.com/raphael-anjou/eternity2/blob/main/research/topics/cas-annular/article.md
---
CAS (concentric annular solving, resolución anular concéntrica) construye el
tablero como crece una cebolla: se coloca un borde perfecto y se resuelve
hacia adentro, anillo por anillo, hasta que las cuatro casillas centrales
cierran el tablero. La pregunta era si ese orden de fuera hacia dentro podía
ser un camino hacia los récords. La respuesta fue un no rotundo junto a un
sí útil: desde cualquier marco perfecto el pipeline se estanca en una banda
estrecha de 429 a 437, y desde ese mismo estado inicial vence a una
continuación de destrucción y reparación en todos y cada uno de los marcos.
## Cómo funciona
El tablero 16×16 son 8 anillos concéntricos de 60, 52, 44, 36, 28, 20, 12 y
4 casillas. CAS fija primero el anillo más externo como marco perfecto
60/60: las 60 casillas de borde llenas con piezas de borde, cada arista del
perímetro gris, y las 60 adyacencias internas del anillo emparejadas.
Después resuelve cada anillo interior por turno como un problema de
asignación sobre las piezas aún libres, maximizando las aristas emparejadas
contra el anillo que lo rodea más las internas del propio anillo. Una vez
colocado, un anillo queda congelado; la búsqueda nunca vuelve a él.
Las ejecuciones originales (volúmenes de investigación 74 a 79) resolvían
cada anillo con un MIP, de 25 a 45 segundos por marco. La reproducción
publicada lo sustituye por un beam determinista de anchura 1024 por anillo,
que cae en la misma banda, y añade un brazo de comparación: fijar el mismo
marco, dejar el interior vacío y entregar ese estado a una
[búsqueda local de destrucción y reparación](/es/research/build/local-search/local-search-alns/).
## El resultado
Veinte marcos perfectos enumerados, veinte puntuaciones entre 429 y 437
aristas emparejadas de 480 (media 432,8). La auditoría fuente, sobre sus
propios 20 marcos, quedó entre 430 y 436 con media 432,4. La banda y la
media se reproducen con un punto de margen en cada extremo, y el marco no
importa: todo marco 60/60 lleva a la misma meseta. El mejor tablero de la
reproducción puntúa 437; puede comprobarse
[arista por arista en el visor](/viewer/?puzzle=official_eternity2&puzzle_size=16&board_edges=abdaabjbaeqbadteaftdafgfacrfabpcafubabjfafhbafqfadofadhdaendaabedgdajiggqphitwhptgiwgkogrphkpjppumhjjvomhnlvqgtnouvghmwuniombafjdpcagnnpwlmnhuqlisouoqwshwmqppvwhjqpoqtjlvmqtkuvvulkwswuommsfaemcpcansvpiujsqrluonjrkpgnmonpvmjoqgqmtrkgmhmrunhhlktnwhqkmorheabocnfavhunjlthljmlhukjgsquntksjkqtqmokkigmmhgihruhtrgrqpqrrhkpbachfoeaurhotusrgolukuwopmmukrvmqrtropprgmspgsjwuvusgtqvqvntkokvcacoeteahustsgrulorgwuiogvvlvitvtvphpsuvskpphvrkuwovqlhwnkolkgikcadgencaspwnrilpriliiklqvwvkuiwqooiqijjrprsjrmorinjmhsknoiisiwgidafwcqeawinqliwillkilwolvwlwwmulijjmqwlrtqqwosnqjtrukmttiommgllofaelepbanqrpwoiqklwooupllsnhuhwklsuhhwusqngwnnsnrqunttlqmrgtlslreaesbgbaringigqiwwvgpmiwnnvjvijnuksivrtknkvrssskujoslijjgpnilulpeaeubteanpgtqgmpvgsgisjgvntorkmnsmwktrsmvmtrtplmoslgjuhsnkoulqjkeafqeibagtgimsutsphsjnmptmqnmrwmwpkrstoptpjtlsnptgwshhlgouqnjuoufafubmdagmtlujvmqovjmnloqoqnwmsokqhmoriqjkgrntkkwvwtlrwvqvproknvfackdsdatjisvvijvlwvlkplqjskshvjhrphijurgwvjkrvwwhtrwjhhpjijnthjcadtdcaaidacidadweadpcaesbacveabpdaeufadvcafvbactfabhcafrbachcabdaac&hints=135.0-210.1-34.1-221.2-45.1).
> **[Figure]** Esperado frente a medido (20 marcos CAS, 8 marcos de referencia) — interactive figure. Rendered on the canonical page (link above); not shown in this markdown export.
La segunda mitad es el duelo directo. Partiendo del mismo marco fijado con
el interior vacío, la continuación por búsqueda local pierde todas las
veces. En la medición fuente (alns_only completo, 60 segundos por marco)
alcanzó de 385 a 398 y perdió las 8 comparaciones disponibles por 34 a 49
puntos. El proxy más ligero de la reproducción lo hace mejor en términos
absolutos (411 a 419) y aun así pierde cada marco, por 13 a 23 puntos. La
magnitud de la diferencia no es comparable entre los dos montajes; su
dirección y su consistencia en cada marco sí lo son.
## Por qué se detiene
La meseta no es un problema de ajuste, ni un hueco en el objetivo: las 480
aristas están todas en el objetivo de CAS. El mecanismo es escasez de
piezas. Los anillos exteriores, resueltos con avidez, fijan las piezas según
lo bien que encajan hacia fuera, y en los anillos 5 a 7 el conjunto restante
sencillamente ya no contiene piezas cuyos perfiles de color encajen con las
restricciones orientadas hacia dentro. Es la versión a escala de anillos del
[robo de piezas](/es/research/why/piece-theft/): una pieza escasa gastada
pronto, anillos antes de la casilla que la necesitaba.
Los volúmenes fuente probaron los rescates obvios, y ambos confirman el
diagnóstico. Un híbrido CAS-ALNS puntuó 418, peor que CAS solo; una pasada
de refinamiento ALNS sobre un tablero CAS terminado llegó a 437-439, una
mejora de unos pocos puntos que queda muy por debajo de lo que otros
pipelines de este cuaderno alcanzan desde cero en el mismo hardware. Para
situar el listón de la comunidad, véase la
[página de récords](/es/research/records/).
## Qué se sigue de esto, y qué no
CAS es dos cosas a la vez, y ambas mitades son el hallazgo. Como camino
hacia los récords queda refutado en cuanto orden voraz: el orden de fuera
hacia dentro deja sin piezas a su propio final de partida, desde cualquier
marco. Como herramienta de subproblema es la mejor opción que he medido para
un estado concreto, un marco perfecto más un interior vacío. Los operadores
de destrucción y reparación esperan un tablero completo que mutar; ante un
interior vacío primero tienen que construir uno, y lo hacen mal, mientras
que CAS es exactamente la herramienta constructiva de ese estado. Qué
algoritmo conviene depende del estado de partida; la composición del
pipeline importa tanto como sus componentes.
[CLOISTER](/es/research/lab/experiments/raphael-anjou/pipelines/cloister/) es el
experimento hermano que conserva el marco fijado pero abandona el orden
anillo por anillo.
Tres salvedades acotan la conclusión. La reproducción fija las cinco piezas
pista oficiales; las páginas fuente no registran si las ejecuciones
originales lo hacían. Las cinco pistas están en el interior, así que el
brazo del marco no se ve afectado, y fijarlas solo puede hacer la
reproducción ligeramente conservadora, la dirección segura para una
afirmación de meseta. El brazo de referencia es un proxy ligero: solo la
dirección de la diferencia y su consistencia en cada marco se trasladan, no
su tamaño. Y los números son propiedades del juego de piezas oficial 16×16:
el mecanismo vive en los anillos 5 a 7, que un tablero 8×8 (4 anillos) nunca
alcanza, de modo que una prueba en tablero pequeño no puede confirmar ni
refutar la conclusión.
## Reproducir
`just research-cas-annular` vuelve a ejecutarlo todo desde cero: enumera los
marcos con un DFS de borde con semilla, corre el brazo CAS de 20 marcos y el
brazo de referencia de 8 marcos, y regenera el archivo de resultados
publicado con puntuaciones por marco, diferencias y una URL del visor para
cada tablero.
## Relacionado
- [CLOISTER](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/cloister/) — Fijar un borde perfecto y luego explorar el interior tratando las aristas del borde como restricciones duras desde la primera celda.
- [El robo de piezas, donde mueren los solucionadores](https://eternity2.dev/es/research/why/piece-theft/) — Un solucionador rellena unas pocas filas sin esfuerzo y luego choca contra un muro en mitad del tablero. He aquí el mecanismo: una pieza escasa gastada en el lugar equivocado, varias filas atrás.
- [Búsqueda local y ALNS](https://eternity2.dev/es/research/build/local-search/local-search-alns/) — Destruir una parte del tablero, reconstruirla mejor y dejar que el algoritmo aprenda qué demoliciones rinden. La búsqueda de gran vecindario adaptativa es el pulidor más fiable de este proyecto, y la demostración más nítida del muro donde el pulido se detiene.
- [Callejones sin salida](https://eternity2.dev/es/research/build/dead-ends/) — Enfoques que probamos que parecen prometedores y no mueven la aguja en Eternity II, documentados con lo que encontramos para que inviertas tu tiempo en otra parte.
---
# CLOISTER
> Fijar un borde perfecto y luego explorar el interior tratando las aristas del borde como restricciones duras desde la primera celda.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/cloister/
- Actualizado: 2026-07-21
- Temas: local-search, backtracking
- Fuente: Geografía del borde de colores raros (este proyecto): por qué el marco es el corte natural — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/why/rare-color-geography.mdx
---
El borde y el interior suelen resolverse juntos, lo que desperdicia esfuerzo:
el interior no deja de proponer piezas que jamás podrán encajar con el borde
más adelante. CLOISTER fija primero un marco perfecto de 60 piezas y luego
explora el interior 14×14 tomando las aristas del marco orientadas hacia dentro
como restricciones reales desde la primera celda, de modo que un interior
condenado se rechaza de inmediato en lugar de al final.
## Cómo funciona
Se parte de un borde completo y perfectamente apareado. La búsqueda interior es
un relleno en profundidad tolerante a rupturas, pero las celdas que bordean la
arista interna del marco deben coincidir con el marco, y esa exigencia está
activa desde la primera colocación, no verificada solo cuando el interior está
terminado. Fases finales exactas evalúan la última región, incluido lo bien que
se sella contra el borde.
Como el borde queda fijo, la búsqueda recoge algo que un interior reconstruido a
posteriori no puede obtener: el puñado de aristas adicionales que surge de que
el interior encaja realmente con el borde contra el que se construyó, en vez de
injertarse sobre un borde después.
> **[Figure]** Interactivo: cómo el marco ancla el interior — interactive: BorderAnchorDiagram. Rendered on the canonical page (link above); not shown in this markdown export.
Pruébalo en directo: fija un marco y observa cómo la búsqueda interior se
ejecuta frente a él en tu navegador.
> **[Figure]** Interactivo: resuelve el interior autónomo en directo — interactive: CloisterLiveLab. Rendered on the canonical page (link above); not shown in this markdown export.
## El resultado
Como solucionador de interiores autónomo, CLOISTER alcanza una puntuación
interior de 453 sin pistas, en minutos, y confirma un efecto real: un interior
construido contra su propio borde se adhiere a él con unas pocas aristas
apareadas más que el mismo interior, de igual calidad, adherido después. Con las
cinco pistas oficiales forzadas se estabiliza entre el tramo alto de los 440 y
el bajo de los 450.
No bate los mejores récords y satura como todo lo demás al acercarse al muro.
Pero aísla y mide con limpieza el acoplamiento borde-interior que la búsqueda
sobre el tablero completo difumina.
## Método
La búsqueda es un DFS tolerante a rupturas sobre el interior, pero la palanca
está en el encuadre y en una campaña de dos fases llevada sobre *muchos* marcos.
- **El marco como restricción dura.** Un borde completo de 60 piezas se fija, y
los colores del marco orientados hacia dentro se convierten en restricciones
duras sobre las celdas del borde desde la primerísima colocación interior, y
no en un control diferido al final. Un interior condenado se poda de inmediato.
- **Fase final exacta.** La región de la fase final se resuelve exactamente (una
cola exacta de 14 celdas), incluida su unión con el borde, de modo que las
últimas celdas se cierran de forma determinista en lugar de por heurística.
- **Campaña en amplitud sobre los marcos.** En vez de un solo borde, se recorre
un directorio de marcos candidatos en dos fases: una sonda de compatibilidad
con las pistas, poco costosa (~6 segundos), descarta los marcos incapaces de
alojar las pistas, y luego una receta de cola de 30 segundos se ejecuta sobre
cada marco superviviente con 8 semillas. Gana el mejor interior.
El efecto medido es pequeño pero real, y proviene de una sola cosa: el
acoplamiento borde-interior que la búsqueda sobre el tablero completo promedia y
borra, pero que una construcción borde-primero puede explotar mientras aún
puede. 453 sin pistas; del tramo alto de los 440 al bajo de los 450 con las
cinco pistas forzadas.
## Reproducir
Con semilla fija y casi determinista dado un marco: la resolución DFS del
interior a partir de un marco fijo reproduce su puntuación de forma fiable, y el
tablero registrado es verificable arista por arista en el visor. La resolución
necesita una entrada más allá del puzzle, un marco de borde perfecto
pre-resuelto; se prevé un directorio de soporte ejecutable que entregue ese
marco junto al motor. Por ahora la ejecución sigue siendo exploratoria: el
tablero 453 es verificable en el visor, pero todavía no se distribuye una
reproducción empaquetada de un solo comando.
## Preguntas abiertas
¿Qué parte del bono de compatibilidad con el borde puede recogerse sin fijar
primero el borde? ¿Recorrer muchos bordes, en vez de uno solo, encuentra un
interior que se adhiera aún mejor? ¿Y de dónde procede exactamente el techo de
la versión de pistas estrictas?
## Relacionado
- [STAGED](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/staged/) — Construir todo el tablero desde cero, sin marco prefijado, por etapas, dejando que el borde emerja al final a partir de las piezas restantes.
- [Los colores raros viven en el marco](https://eternity2.dev/es/research/why/rare-color-geography/) — Cinco de los 22 colores de Eternity II aparecen solo a lo largo del anillo de borde, cada uno en exactamente 24 aristas, nunca una sola vez en el interior. Una separación estructural que moldea la forma en que cada solucionador trata el marco.
- [MIDDEN](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/midden/) — Decidir de antemano no cuándo puede romperse un tablero, sino dónde: confinar cada desajuste a una forma de celdas elegida, y buscar la mejor forma.
- [Encuentro en el medio](https://eternity2.dev/es/research/build/exact/meet-in-the-middle/) — Enumerar dos mitades de un problema y unirlas en una interfaz compartida, intercambiando memoria por un exponente reducido a la mitad. El truco clásico de Horowitz–Sahni, qué aspecto tiene sobre bandas del tablero, y qué midió el experimento BANDSAW de este proyecto, incluido el método unilateral que lo superó.
- [El marco fluido](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/fluid-frame/) — Un borde perfecto de 60 piezas no es un objeto rígido. Cada marco completamente apareado admite exactamente 45 intercambios libres a coste de borde cero; un tercio de los marcos perfectos ni siquiera pueden arrancar el interior, y un solo intercambio libre revive cada uno de ellos.
---
# El marco fluido
> Un borde perfecto de 60 piezas no es un objeto rígido. Cada marco completamente apareado admite exactamente 45 intercambios libres a coste de borde cero; un tercio de los marcos perfectos ni siquiera pueden arrancar el interior, y un solo intercambio libre revive cada uno de ellos.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/fluid-frame/
- Actualizado: 2026-07-22
- Temas: structure, local-search
- Reproducir: `just research-frame-manifold`
- Fuente: Tema de reproducción (este proyecto): plan, código de cómputo y resultados detrás de cada número de esta página — https://github.com/raphael-anjou/eternity2/blob/main/research/topics/frame-manifold/article.md
---
Los pipelines de «borde primero» como
[CLOISTER](/es/research/lab/experiments/raphael-anjou/pipelines/cloister/)
construyen un borde de 60 piezas completamente apareado, lo congelan y
entregan sus 56 colores orientados hacia dentro como restricciones duras a la
búsqueda interior. Quería saber si ese objeto congelado es de verdad un solo
objeto, partiendo de un reflejo simple: cuando el interior se atasca contra
el borde, ¿por qué retroceder sobre el borde pudiendo intercambiar una sola
pieza del reborde? Medida sobre 500 marcos perfectos frescos, la respuesta es
más nítida que la pregunta. Un borde perfecto es una variedad conexa con
exactamente 45 salidas libres; un tercio de los bordes perfectos ni siquiera
pueden arrancar el interior; y un intercambio libre repara cada marco muerto
muestreado, a coste de borde cero.
## Qué se midió
Primero las definiciones. Un marco coloca las 4 esquinas y las 56 piezas de
borde en las 60 celdas del borde del tablero oficial 16×16, con el gris
exactamente hacia fuera. BB cuenta las adyacencias borde-con-borde apareadas
a lo largo del anillo, máximo 60; BB = 60 es un marco perfecto. Un
intercambio legal permuta dos piezas colocadas de la misma clase (esquina con
esquina, pieza de borde con pieza de borde); las rotaciones vienen forzadas
por la regla del gris hacia fuera, así que un intercambio queda determinado
por el par de celdas. Un intercambio es libre cuando deja BB en 60.
El crate de cómputo genera sus propios marcos BB = 60 del juego oficial de
256 piezas (una colocación en profundidad aleatorizada sobre las 60 celdas
del borde) y luego mide cada afirmación directamente:
1. cada intercambio legal de la misma clase y su coste en BB, agregado sobre
todos los marcos;
2. cadenas de intercambios libres, recalculando el conjunto libre sobre el
anillo actual en cada paso, siguiendo BB, el número de movimientos libres
y cuánto han derivado el anillo y el vector de colores interiores;
3. la rellenabilidad de cada celda interior que toca el marco: un marco está
muerto cuando alguna de esas celdas no puede rellenarse con ninguna de
las 196 piezas interiores;
4. una reparación voraz de cada marco muerto usando solo intercambios
libres.
Pasada principal: 500 marcos generados de forma independiente, paseo de
longitud 100, reanimación intentada sobre los primeros 60 marcos muertos. La
pasada es determinista; relanzar el comando archivado reproduce el fichero de
resultados byte a byte. El primer marco generado puede verse en el
[visor](/viewer/?puzzle=official_eternity2&puzzle_size=16&board_edges=abdaaepbacqeadpcabmdacrbacpcafvcafufabtfachbabhcacsbaepcadteaacddtcaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaencnfaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaeabofhcaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaababgcidaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabafhdofaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaafaelfoeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaeaeseqbaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaeabvbpcaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabafuckfaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaafadufqfaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadadgfjbaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadaepbjfaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaeaetftdaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaeadwdhdaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadaendcaaocacrfacgfafqeafmfaewdafsdadidadgcadvbacjbabteabueaeibaeeaab).
## El resultado
**Exactamente 45 movimientos libres, en cada marco.** Los 500 marcos
perfectos admiten exactamente 45 intercambios libres, nunca 44, nunca 46.
Ningún intercambio sube BB jamás (60 es el máximo), y los movimientos libres
componen: tras 100 intercambios libres encadenados, BB sigue en 60 y siguen
disponibles 45 movimientos libres. El recuento nunca se agota.
**Ninguno es cosmético.** Cero de los 45 intercambios libres preserva el
color interior de las piezas que toca: cada movimiento libre cambia el vector
de restricciones que el borde presenta al interior. Un paseo libre de 100
pasos visitó 99 vectores de objetivos de reborde distintos de 101 posibles
sin salir nunca de BB = 60.
**Perfecto no es utilizable.** 180 de los 500 marcos perfectos (36 por
ciento) tenían al menos una celda interior que ninguna de las 196 piezas
interiores podía rellenar, y 46 (9,2 por ciento) estaban muertos en la
primera celda que visita un solucionador en orden de barrido: la búsqueda
interior muere a profundidad 0 pese a un borde con puntuación perfecta. La
reparación voraz solo con intercambios libres revivió 60 de 60 marcos
muertos muestreados hasta cero celdas muertas, sin que BB saliera nunca de
60. En el ejemplo trabajado del estudio fuente, un solo intercambio libre
llevó un DFS con marco de la profundidad 0 a la profundidad 153 de 196.
> **[Figure]** Esperado frente a medido (pasada principal, 500 marcos) — interactive figure. Rendered on the canonical page (link above); not shown in this markdown export.
Una pasada de robustez con semilla independiente (100 marcos frescos, base de
semilla 7001) concuerda: 45 intercambios libres en cada marco, ningún
aumento, 45 marcos muertos de 100 (histograma 38 / 7), los 45 revividos, y el
paseo vuelve a mantener BB = 60 con 45 movimientos libres de principio a fin.
La conclusión se sostiene, pues, a través de generadores y semillas: un borde
perfecto y un borde utilizable son propiedades distintas, y el marco puede
permanecer móvil durante la búsqueda en lugar de deshacerse por retroceso.
## Qué no se sigue de esto
- No se afirma que caminar por la variedad o revivir marcos muertos mejore
las puntuaciones de tableros completos. El propio A/B del estudio fuente
no produjo ningún tablero completo con marco; cualquier efecto sobre la
puntuación es una cuestión abierta, y un productor que mantenga el marco
fluido durante la búsqueda interior es trabajo futuro. Esta página publica
solo el mecanismo.
- El 45 se reivindica como propiedad del juego de piezas oficial y se
replica aquí sobre marcos de un generador distinto. La tasa de marcos
muertos es una propiedad del muestreo del generador: 36,0 por ciento en la
pasada principal, 45 por ciento en la de semilla independiente; el
enunciado defendible es una tasa entre mediados de los 30 y mediados de
los 40 por ciento, no un 36 universal.
- El recuento bruto de pares de la misma clase es de 1546 por marco aquí
frente a unos 1458 en la fuente, que evidentemente excluía alguna clase de
pares sin efecto. Las cuotas y las dos filas que soportan la carga (45
libres, 0 ganancias) concuerdan de todos modos.
- Los marcos van aquí sin pistas, como en la medición fuente; la
compatibilidad de los marcos con las pistas es un asunto aparte y no forma
parte de esta afirmación.
## Relacionado
- [CLOISTER](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/cloister/) — Fijar un borde perfecto y luego explorar el interior tratando las aristas del borde como restricciones duras desde la primera celda.
- [STAGED](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/staged/) — Construir todo el tablero desde cero, sin marco prefijado, por etapas, dejando que el borde emerja al final a partir de las piezas restantes.
- [El equilibrio del borde](https://eternity2.dev/es/research/why/border-balance/) — Un tablero resuelto esconde una sencilla ley contable: cada color que el borde entrega al interior, el interior se lo devuelve al instante. Rómpela y sabrás de inmediato que el tablero es incorrecto; respetarla, en cambio, no garantiza nada.
- [Los colores raros viven en el marco](https://eternity2.dev/es/research/why/rare-color-geography/) — Cinco de los 22 colores de Eternity II aparecen solo a lo largo del anillo de borde, cada uno en exactamente 24 aristas, nunca una sola vez en el interior. Una separación estructural que moldea la forma en que cada solucionador trata el marco.
---
# GAUNTLET
> Ejecutar la misma búsqueda en haz según nueve órdenes de recorrido distintos, para que aterrice en regiones diferentes en lugar de converger siempre a la misma. El orden en zigzag encontró un tablero 458 inédito.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/gauntlet/
- Actualizado: 2026-07-21
- Temas: construction
- Reproducir: `just research-record-boards`
- Fuente: Búsqueda en haz (la página de concepto de este proyecto): la construcción cuyo orden de recorrido se hace variar — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/build/construct/beam-search.mdx
---
Una búsqueda en haz que rellena siempre el tablero en el mismo orden tiende a
descubrir el mismo tipo de tablero, sea cual sea la semilla aleatoria. El orden
en que se visitan las celdas decide en silencio en qué región se acaba, y a lo
largo de dieciséis semillas, un mismo orden de recorrido produjo una sola
familia de disposición de las esquinas. GAUNTLET lo convierte en una
herramienta: ejecutar la búsqueda según nueve órdenes de recorrido
genuinamente distintos, y así muestrear regiones genuinamente distintas.
## Cómo funciona
GAUNTLET deriva el haz constructivo de PRIOR y le confía un orden de recorrido
intercambiable: fila, fila invertida, columna, columna invertida, zigzag,
zigzag invertido, espiral entrante, espiral saliente y diagonal, nueve en
total. Como el orden de las celdas modifica qué tableros parciales sobreviven
en cada paso, cada orden explora una trayectoria diferente en lugar de
apiñarse en una sola. Un barrido de 9 recorridos × 4 semillas produjo **18
firmas de disposición de esquinas distintas**, frente a una sola a lo largo de
dieciséis semillas del haz de recorrido único del que surgió.
Cada ejecución completa produce un tablero entero; los más sólidos se pulen
luego con un realce ALNS de 30 minutos. La constatación es nítida: *el orden de
recorrido es un eje de diversidad más potente que la semilla aleatoria.* Ese es
el resorte, y es sobre él que se apoyan KEYRING y PRIOR más adelante.
> **[Figure]** Interactivo: el calendario del orden de construcción — interactive: GauntletDiagram. Rendered on the canonical page (link above); not shown in this markdown export.
Recorra un orden paso a paso para ver cómo el orden de visita dirige el haz.
> **[Figure]** Interactivo: recorrer el orden de construcción — interactive: GauntletStepThrough. Rendered on the canonical page (link above); not shown in this markdown export.
O haga competir los nueve órdenes entre sí, en directo, en su navegador.
> **[Figure]** Interactivo: competir las estrategias de construcción — interactive: GauntletLiveRace. Rendered on the canonical page (link above); not shown in this markdown export.
## El tablero
La búsqueda es estocástica, así que no reproducirá este tablero exacto, pero el
tablero que encontró está fijado, incluido aquí y verificable arista por
arista.
> **[Interactive: RecordBoard]** Rendered on the canonical page (link above); not shown in this markdown export.
## El resultado
El orden en zigzag con la semilla 99, realzado, alcanzó 458 de 480 en la
disposición de esquinas cp=(3,0,1,2), el primer tablero igual o superior a 458
jamás encontrado en esa disposición dentro de nuestra base de datos. Se sitúa a
al menos 246 celdas de 256 de todo lo que teníamos a ese nivel: una cuenca
genuinamente nueva, no otra ruta hacia una conocida.
Así que la contribución de GAUNTLET es alcance más que un récord: abrió una
nueva región de tableros sólidos. Una segunda ronda (32 realces más) topó en
457 sin ningún 461, lo que indica que la nueva familia se satura como las
demás, pero la familia en sí era el premio.
## Método
El pipeline consta de tres etapas, y los parámetros son lo esencial.
**Etapa 1: construcción diversa.** Se deriva el haz de PRIOR y se le confía un
orden de recorrido intercambiable sobre las 256 celdas: `row`, `row_rev`,
`col`, `col_rev`, `zigzag`, `zigzag_rev`, `spiral_in`, `spiral_out`,
`diagonal`, nueve órdenes, cruzados con las semillas `{1, 7, 42, 99}`. Todos
comparten un mismo a priori (la matriz `high459`) a baja temperatura de softmax
(0,05), de modo que el haz está guiado por el a priori sin ser determinista. El
orden modifica qué tableros parciales sobreviven en cada paso, de manera que
cada par (recorrido, semilla) recorre una trayectoria diferente.
**Etapa 2: realce.** Cada construcción sólida recibe un realce ALNS (operadores
de escape del a priori + destrucción/reparación `basic_lkh`), 5 minutos por
construcción durante el barrido, más tiempo para los finalistas.
**Etapa 3: agrupamiento.** Se agrupan todas las salidas por permutación de las
esquinas y se señalan las firmas ausentes de la base de datos existente. Así es
como el barrido 9×4 hizo emerger **18 familias de esquinas distintas** allí
donde dieciséis semillas de un recorrido único habían hecho emerger una sola, la
afirmación medida de que *el orden de recorrido es un eje de diversidad más
potente que la semilla.*
El tablero ganador, zigzag, semilla 99, realzado, se sitúa en cp = (3, 0, 1, 2),
a una distancia de Hamming ≥ 246/256 de todo lo que estaba previamente a ese
nivel: una nueva cuenca según el mismo test de permutación de esquinas más
Hamming que emplea [PRIOR](/es/research/lab/experiments/raphael-anjou/learning/prior/).
## Reproducir
`just research-record-boards` verifica la puntuación del tablero 458 retenido,
exactamente, a partir de su cadena Bucas almacenada. El barrido es estocástico
(nueve recorridos × cuatro semillas, luego una pasada de pulido), así que no
reproducirá el mismo tablero; el tablero es el artefacto de referencia. El motor
es el productor en haz compartido, ejecutado según nueve órdenes de relleno;
usa el mismo a priori extraído del corpus que
[PRIOR](/es/research/lab/experiments/raphael-anjou/learning/prior/), de modo que la
ejecución no se reproduce aquí desde cero.
## Preguntas abiertas
¿Presenta esta nueva familia la misma estructura local rígida que las demás, o
una forma diferente? ¿Y puede un refinamiento más largo elevarla por encima de
458, como una familia fresca a veces tiene más margen que una bien rodada?
## Relacionado
- [PRIOR](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/prior/) — Construir un tablero desde cero, resolviendo los empates según la posición habitual de las piezas en los buenos tableros ya conocidos. Alcanza una puntuación alta sin ningún tablero de partida que copiar.
- [KEYRING](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/keyring/) — Construir un tablero desde cero, clasificando cada pieza siguiente según tres señales aprendidas de tableros fuertes anteriores. Alcanzó 460 en una familia de tableros que ninguna búsqueda previa había resuelto.
- [Búsqueda en haz](https://eternity2.dev/es/research/build/construct/beam-search/) — Mantener con vida los K tableros parciales más prometedores a la vez y hacerlos crecer celda a celda. La búsqueda en haz es el motor de los constructores desde cero de este proyecto, y una ilustración nítida de por qué la anchura por sí sola se estanca en las profundidades del interior.
- [Hacer un productor beam 10x mejor: la respuesta es la anchura](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/beam-width/) — Un repaso verificado más mediciones apareadas: ninguna astucia por nodo supera la anchura bruta del haz a igual tiempo de reloj. Los dos únicos aditivos que sobreviven son aleatorizar las claves de truncado empatadas exactamente (gratis) y el remuestreo SMC de los supervivientes (pequeño pero significativo).
---
# LADDER
> Lanzar cientos de búsquedas cortas y baratas sobre el tablero, conservar solo los arranques más profundos y hacer ascender a los supervivientes a través de rondas cada vez más largas.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/ladder/
- Actualizado: 2026-07-21
- Temas: local-search
- Fuente: Halving sucesivo / estrategias de reinicio (la página conceptual sobre reinicios de este proyecto) — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/build/backtracking/restarts.mdx
---
La mayor parte de una búsqueda larga se malgasta en arranques que estaban
condenados desde el principio. LADDER gasta casi nada para averiguar qué
comienzos vale la pena perseguir. Lanza una avalancha de sondeos muy cortos,
conserva los pocos que llegaron más lejos y solo entonces paga por ejecuciones
más largas, únicamente sobre esos. Es selección por torneo aplicada a los
arranques de búsqueda.
## Cómo funciona
La primera ronda son cientos de sondeos de cinco segundos que parten de
semillas aleatorias distintas, cada uno intentando trazar una larga tirada de
celdas perfectamente encajadas. Conserva los prefijos más profundos y descarta
los que son casi duplicados entre sí para que los supervivientes sigan siendo
diversos.
Promueve esos a una ronda más larga con controles de calidad más estrictos, y
luego promueve los mejores de entre ellos a una ejecución de longitud completa.
Cada peldaño dedica más tiempo a candidatos menos numerosos y mejores, del
mismo modo que los torneos por halving sucesivo asignan el esfuerzo a los
contendientes que siguen ganando.
> **[Figure]** Interactivo: la progresión peldaño a peldaño — interactive: LadderDiagram. Rendered on the canonical page (link above); not shown in this markdown export.
> **[Figure]** Interactivo: ejecutar la búsqueda en escalera en directo — interactive: LadderLiveLab. Rendered on the canonical page (link above); not shown in this markdown export.
## El resultado
LADDER produjo un tablero de 451 que respeta las cinco pistas oficiales, sin
ninguna guía de ningún récord conocido, la primera vez que el proyecto escapó
de la banda de 444 a 450 en la que la búsqueda no guiada no dejaba de caer. Los
finales quedan determinados por su prefijo: una vez que se guarda una apertura
lo bastante fuerte, el resto se sigue. Una ejecución más larga tocó después el
452, una arista más, aunque el 451 es el tablero fijado y reproducible aquí.
También cartografió los límites: la reserva de aperturas perfectas se agota, y
más allá de cierto punto los peldaños convergen todos hacia el mismo techo. Así
que LADDER es una buena manera de encontrar el mejor arranque, no una manera de
franquear los muros estructurales que detienen a todo método cerca de la cima.
## Método
La escalera es un torneo recursivo por halving sucesivo sobre los *arranques*
de búsqueda, puntuados por la profundidad del prefijo.
- **Primera ronda: avalancha.** Cientos de sondeos de 5 segundos que parten de
semillas distintas, cada uno trazando una tirada tan larga como sea posible
de celdas perfectamente encajadas. Se ordena por la profundidad de ese
prefijo perfecto; se conservan los más profundos y se descartan los casi
duplicados (prefijos demasiado parecidos a un superviviente) para que el
conjunto conservado siga siendo diverso.
- **Trinquete.** Cada ronda posterior fija el prefijo más profundo guardado en
la ronda anterior (una fijación a profundidad 15 en la ejecución registrada) y
sondea *más allá* de él, empujando la frontera del prefijo perfecto un paso
más. La recursión se detiene cuando una ronda gana menos de cuatro celdas de
profundidad: la reserva de aperturas más profundas se ha secado.
- **Final.** A partir de los tres prefijos distintos más profundos, se lanzan
peldaños largos exact-tail-14 (300 s × 8 semillas cada uno) para convertir la
apertura guardada en un tablero completo.
El hallazgo es que *el final queda determinado por el prefijo*: una vez que se
guarda una apertura perfecta lo bastante profunda, el juego final se sigue. Por
eso concentrar el cómputo en encontrar el mejor arranque, en lugar de
repartirlo entre ejecuciones completas, permitió escapar de la banda 444-450 en
la que la búsqueda no guiada no dejaba de caer. Una ronda de final más larga
tocó después el 452; el tablero fijado y reproducible aquí es el 451.
## Reproducir
Con semilla fijada; la estructura de sondeo-y-promoción reproduce el
*comportamiento* de forma fiable, aunque el tablero exacto depende de las
semillas. El tablero 451 fijado es verificable en el visor. La subida no
necesita ningún corpus, marco ni testigo: parte del puzzle solo, de modo que
está previsto un directorio de acompañamiento ejecutable para ella junto a los
demás experimentos partidos de cero. Por ahora la ejecución sigue siendo
exploratoria: el tablero 451 es verificable en el visor, pero todavía no se
distribuye una reproducción empaquetada de un solo comando.
## Preguntas abiertas
¿Cuál es el verdadero techo de la selección por prefijo primero si se da más
cómputo a los primeros peldaños? ¿Podría la regla de diversidad ser más fina
sobre qué casi duplicados conservar? ¿Y combinar los prefijos más profundos de
familias distintas supera a promover dentro de una sola?
## Relacionado
- [REPLAY](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/replay/) — 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.
- [PRIOR](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/prior/) — Construir un tablero desde cero, resolviendo los empates según la posición habitual de las piezas en los buenos tableros ya conocidos. Alcanza una puntuación alta sin ningún tablero de partida que copiar.
- [Reinicios y colas pesadas](https://eternity2.dev/es/research/build/backtracking/restarts/) — Ejecute el mismo backtracker sobre el mismo puzzle dos veces y los tiempos de ejecución diferirán por potencias de diez. La comunidad lo midió en 2007; la literatura CSP ya lo había bautizado. La cura (cortar, rebarajar, reiniciar) es la razón por la que todo solucionador récord desde entonces es un portafolio de reinicios.
- [Hacer un productor beam 10x mejor: la respuesta es la anchura](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/beam-width/) — Un repaso verificado más mediciones apareadas: ninguna astucia por nodo supera la anchura bruta del haz a igual tiempo de reloj. Los dos únicos aditivos que sobreviven son aleatorizar las claves de truncado empatadas exactamente (gratis) y el remuestreo SMC de los supervivientes (pequeño pero significativo).
- [La escalera de tamaños](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/scaling-ladder/) — Un banco que ejecuta cualquier solucionador, sin cambios, sobre tableros plantados totalmente resolubles con N = 8, 10, 12, 14, cada uno con un techo probado de 2N(N-1): el tamaño de colapso de un método se mide antes de gastar semanas en el 16×16 real.
---
# MIDDEN
> Decidir de antemano no cuándo puede romperse un tablero, sino dónde: confinar cada desajuste a una forma de celdas elegida, y buscar la mejor forma.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/midden/
- Actualizado: 2026-07-21
- Temas: local-search
- Fuente: Robo de piezas (este proyecto): la vista espacial de dónde fallan los tableros, aquello que MIDDEN controla de antemano — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/why/piece-theft.mdx
---
La mayoría de los solucionadores que permiten roturas controlan cuándo se
permite un desajuste: a ciertas profundidades, más allá de cierto relleno.
MIDDEN controla dónde, en cambio. Fija una máscara, un conjunto de celdas
elegido, e impone que los desajustes solo puedan pagarse dentro de ella; en
todos los demás sitios la coincidencia debe ser perfecta. Después busca sobre
la forma de esa máscara. Los métodos existentes dicen cuándo encajar los daños;
este experimento pregunta dónde deben alojarse los daños.
## Cómo funciona
Elige una máscara: un par de filas, un par de columnas, un enrejado disperso de
celdas, o un conjunto elegido por color. Ejecuta la búsqueda forzando
coincidencias perfectas fuera de la máscara y permitiendo desajustes solo dentro
de ella. Formas de máscara distintas conducen la búsqueda a partes distintas del
espacio, de modo que la máscara se convierte en una perilla de ajuste en lugar
de una regla fija.
Comparar formas revela qué geometría de daño permitido deja que un tablero haga
crecer una serie perfecta larga antes de tener que gastar un desajuste.
> **[Figure]** Interactivo: las máscaras de rotura por geometría del daño — interactive: MaskShapeDiagram. Rendered on the canonical page (link above); not shown in this markdown export.
## El resultado
Un enrejado disperso de celdas de daño permitido alarga notablemente más la
serie perfecta más larga que concentrar el daño en una fila o dos, empujando el
muro perfecto desde alrededor de 150 celdas hasta los 170. El mecanismo es
claro; lo que queda abierto es la economía del asunto: convertir una serie
perfecta más larga en una puntuación final más alta una vez que el final de
partida tiene que absorber el daño diferido.
Así que la máscara es una palanca real, el complemento espacial de los controles
de tiempo habituales, con un efecto medido sobre hasta dónde permanece perfecto
un tablero, pero todavía no una vía acabada hacia un récord.
## Método
Cualquier otra búsqueda tolerante a roturas regula el daño por *cuándo*: una
profundidad, una fracción de relleno. MIDDEN regula por *dónde*. Es el primer
control de daño por conjunto de celdas (DÓNDE) frente a las regulaciones por
profundidad (CUÁNDO) de todos los demás.
- **La máscara.** Un conjunto de celdas elegido (una máscara de 256 bits) se
pasa mediante `--break-cells`. Dentro de la máscara, los desajustes están
permitidos; en todos los demás sitios la coincidencia debe ser perfecta. Por
lo demás, la búsqueda es un DFS tolerante a roturas estándar, a partir de un
marco fijo.
- **El barrido.** La *forma* de la máscara se convierte en la variable de
diseño: un par de filas, un par de columnas, un enrejado disperso, o un
conjunto elegido por color, barridos sobre formas y densidades, cada uno a
300 s × 8 semillas.
El resultado medido es una regla de diseño de densidad graduada: un **enrejado
disperso** de celdas de daño permitido alarga la serie perfecta más larga de
~153 celdas a 167-174 (**+21**), mucho más que concentrar el daño en una fila o
dos. El mecanismo es claro; la economía que queda abierta es el final de
partida: una serie perfecta más larga solo ayuda si la cola puede absorber el
daño diferido, y la máscara dispersa que maximiza el muro no sella por sí sola
el final. El paso siguiente natural (componer una máscara de cuerpo dispersa con
una cola abierta) es exactamente lo que el barrido MIDDEN-v2 se propuso probar.
## Reproducir
Sembrado a partir de un marco fijo; el efecto de alargamiento del muro se
reproduce de una máscara a otra, aunque el tablero exacto depende de las
semillas, y el tablero 452 confirmado es verificable en el visor. Como
[CLOISTER](/es/research/lab/experiments/raphael-anjou/pipelines/cloister/), necesita
un marco de borde ya resuelto (más la máscara de celdas de rotura, que es una
entrada literal); se prevé un directorio de respaldo ejecutable que incluya el
marco. Por ahora la ejecución sigue siendo exploratoria: el tablero 452 es
verificable en el visor, pero todavía no se distribuye una reproducción
empaquetada de un solo comando.
## Preguntas abiertas
¿Qué formas de máscara convierten una serie perfecta más larga en aristas
realmente coincidentes al final, en lugar de solo diferir el daño? ¿Se pueden
combinar máscaras espaciales con controles de tiempo, de modo que un tablero
quede regulado tanto en dónde como en cuándo puede romperse? ¿Y existe una
máscara que refleje el lugar donde los mejores tableros conocidos portan
realmente sus desajustes?
## Relacionado
- [LADDER](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/ladder/) — Lanzar cientos de búsquedas cortas y baratas sobre el tablero, conservar solo los arranques más profundos y hacer ascender a los supervivientes a través de rondas cada vez más largas.
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [CLOISTER](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/cloister/) — Fijar un borde perfecto y luego explorar el interior tratando las aristas del borde como restricciones duras desde la primera celda.
- [El robo de piezas, donde mueren los solucionadores](https://eternity2.dev/es/research/why/piece-theft/) — Un solucionador rellena unas pocas filas sin esfuerzo y luego choca contra un muro en mitad del tablero. He aquí el mecanismo: una pieza escasa gastada en el lugar equivocado, varias filas atrás.
---
# MOSAIC
> Dividir el tablero en pequeños bloques, resolver cada uno hasta el óptimo demostrado y volver a pegarlos, pagando las costuras en lugar de prohibirlas. Partiendo de cero, sin ningún récord que copiar, el método alcanza 448.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/mosaic/
- Actualizado: 2026-07-21
- Temas: exact-methods
- Fuente: RC2 MaxSAT (el solucionador de bloques exacto): un algoritmo MaxSAT ponderado guiado por núcleos — https://doi.org/10.3233/SAT190116
---
Eternity II no posee ninguna estructura local que se pueda explotar a escala
global, pero una pequeña ventana de ella, un bloque 4×4, se resuelve hasta la
optimalidad perfecta en segundos. MOSAIC es un experimento construido sobre ese
único hecho: si sabes resolver un bloque exactamente, ¿puedes componer dieciséis
bloques exactos en un tablero entero?
## Cómo funciona
El tablero 16×16 se recorta en dieciséis bloques 4×4, que se rellenan uno a uno.
Cada bloque se entrega a un solucionador MaxSAT exacto, que encuentra la mejor
colocación posible de las piezas que contiene. El truco está en cómo un bloque
se encuentra con sus vecinos ya colocados: esas aristas compartidas no son
requisitos estrictos, sino objetivos *suaves* que el bloque es recompensado por
igualar. Así un bloque nunca puede volverse imposible; simplemente paga por
cualquier costura que no pueda igualar, y siempre se completa.
La segunda idea combate directamente el robo de piezas. Antes de rellenar un
bloque, MOSAIC retiene las piezas globalmente más escasas, de modo que a los
últimos bloques no les falten las piezas raras que sus costuras exigirán. Ajustar
cuánto reservar es la única perilla real; demasiado poco y la esquina se queda
sin recursos, demasiado y los primeros bloques lo sufren.
> **[Figure]** Interactivo: la búsqueda de ensamblaje de bloques — interactive: MosaicBlockLab. Rendered on the canonical page (link above); not shown in this markdown export.
## El resultado
La primitiva de ventana cumple su promesa: un bloque 4×4 se resuelve hasta su
óptimo de 24 aristas en unos treinta segundos, un 3×3 en once, confirmando que
el puzzle es efectivamente tratable a pequeña escala. Compuesto sobre todo el
tablero, desde cero y sin arranque en caliente, MOSAIC alcanza 448 de 480. El
punto óptimo de reserva se sitúa en torno al ocho por ciento del reservorio.
El déficit es informativo: casi todo él está en los tres últimos bloques de la
esquina inferior derecha, donde el reservorio finalmente se agota: el robo de
piezas de nuevo, ahora visible como un único punto brillante en el tablero. La
exactitud a pequeña escala sí compone, pero el orden de composición gasta su
libertad temprano y la paga al final, la misma forma con la que se topa cada
método aquí.
## Método
La exactitud es genuina, y también lo es el backtracking que la cose.
- **Bloques exactos.** Cada bloque 4×4 se codifica como un problema *MaxSAT
ponderado* y se resuelve con RC2, un solucionador guiado por núcleos, hasta un
relleno demostrablemente óptimo. Las aristas compartidas con los vecinos ya
colocados son cláusulas *suaves* (recompensadas, no exigidas), de modo que un
bloque nunca puede ser inviable: paga por cualquier costura que no pueda
igualar y siempre se completa.
- **Backtracking sobre las soluciones.** MOSAIC no es un pegado de un solo tiro.
Cada nivel de bloque mantiene un *enumerador* de soluciones MaxSAT, las mejores
primero, mediante RC2 más cláusulas de bloqueo que descartan los rellenos ya
vistos. Cuando un bloque posterior se queda sin recursos o un nivel se agota,
la búsqueda retrocede y extrae la *siguiente* solución del bloque anterior
(liberando un conjunto de piezas distinto). Es una búsqueda por backtracking
gruesa sobre 16 niveles, donde cada nodo es un bloque entero óptimo.
- **Reserva por escasez.** Antes de rellenar, MOSAIC retiene las piezas
globalmente más escasas, de modo que a los bloques finales no les falten las
piezas raras que sus costuras exigen. Esa fracción de reserva es la única
perilla real; el punto óptimo medido es ~8% del reservorio.
La primitiva de ventana es real: un bloque 4×4 alcanza su óptimo de 24 aristas
en ~30 s, un 3×3 en ~11 s, el puzzle *es* tratable a pequeña escala. Compuesto
desde cero alcanza 448, con el déficit residual concentrado en los tres últimos
bloques de la esquina inferior derecha: el [robo de piezas](/es/research/why/piece-theft/)
hecho visible como un único punto brillante.
## Reproducir
Determinista: las resoluciones de bloque MaxSAT y la composición por backtracking
son exactas, de ahí `kind: exact`; el tablero de 448 se reproduce y se verifica
arista por arista en el visor. El motor de bloque funciona a partir del puzzle
solo, sin corpus ni tablero de partida, siendo su única dependencia externa un
solucionador MaxSAT, por lo que se prevé un directorio ejecutable de respaldo
para él junto a los demás experimentos exactos. Por ahora la ejecución sigue
siendo exploratoria: el tablero 448 es verificable en el visor, pero todavía no
se distribuye una reproducción empaquetada de un solo comando.
## Preguntas abiertas
¿Un orden de bloques no por filas, en espiral hacia el interior o resolviendo
primero la esquina más restringida, desplazaría el agotamiento fuera del bloque
más difícil? ¿Podrían solaparse los bloques, de modo que las costuras se
resuelvan dos veces y se reconcilien? ¿Y haría una primitiva más rápida (en Rust)
asequible un tamaño de bloque mayor, con su garantía de exactitud más fuerte?
## Relacionado
- [BANDSAW](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/) — Resolver exactamente una banda de filas encontrándose en el medio, para hallar el verdadero mejor final y medir hasta qué punto puede decidirse por anticipado una fin de partida.
- [El robo de piezas, donde mueren los solucionadores](https://eternity2.dev/es/research/why/piece-theft/) — Un solucionador rellena unas pocas filas sin esfuerzo y luego choca contra un muro en mitad del tablero. He aquí el mecanismo: una pieza escasa gastada en el lugar equivocado, varias filas atrás.
- [Qué muro detiene a qué método](https://eternity2.dev/es/research/why/walls-and-methods/) — La sección de investigación tiene dos vertientes: los muros estructurales que hacen difícil a Eternity II, y los algoritmos concebidos para franquearlos. Esta página es el puente: cada método enfrentado al muro que realmente ataca, y la puntuación en la que ese muro lo detuvo.
- [Codificaciones SAT y CSP](https://eternity2.dev/es/research/build/exact/sat-csp-encodings/) — Escribir el puzzle como cláusulas y entregárselo a un solucionador industrial: el movimiento evidente, intentado desde 2008. Por qué los solucionadores completos se atascan en el tablero completo, y dónde sus veredictos siguen ganándose el sustento como pruebas de imposibilidad.
---
# STAGED
> Construir todo el tablero desde cero, sin marco prefijado, por etapas, dejando que el borde emerja al final a partir de las piezas restantes.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/staged/
- Actualizado: 2026-07-21
- Temas: construction
- Reproducir: `just research-record-boards`
- Fuente: Búsqueda por haz (la página-concepto de este proyecto): la primitiva de construcción por etapas — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/build/construct/beam-search.mdx
---
Casi todos los solucionadores empiezan por bloquear el borde, porque el borde
es la parte más restringida y fijarlo reduce la búsqueda. STAGED es un
experimento que rechaza esa muleta. Construye el tablero por etapas, de arriba
hacia abajo, con las 256 piezas libres, y nunca se compromete con un borde
hasta el final, cuando el borde simplemente cae de lo que queda. La pregunta
que responde: ¿se puede alcanzar un tablero sólido sin anclarse nunca a un
marco?
## Cómo funciona
La construcción se desarrolla en cuatro etapas. Las dos primeras llenan la
mitad superior del tablero con una búsqueda simple y rápida, guardando los
tableros parciales que sobreviven. En el relevo, una estimación admisible de
bajo coste descarta cualquier parcial que claramente no puede terminarse bien,
de modo que las etapas posteriores solo trabajan sobre arranques prometedores.
La tercera etapa hace crecer la siguiente banda de filas a partir de esos
supervivientes. La cuarta es un finalizador exacto sobre las filas de abajo que
minimiza las discrepancias, y elige el borde inferior al final, contra las
piezas que aún quedan sin usar. Así, el marco no se diseña de antemano; emerge
como consecuencia de todo lo que está por encima.
> **[Figure]** Interactivo: la construcción etapa por etapa — interactive: StageBuildDiagram. Rendered on the canonical page (link above); not shown in this markdown export.
## El resultado
STAGED alcanza 436 de 480 desde cero, con un borde emergente y las cinco pistas
oficiales respetadas, construido de principio a fin sin ningún marco en el que
apoyarse. Eso queda muy por debajo de los récords, y esa brecha es el hallazgo:
mide cuánto vale el anclaje habitual del marco-primero, y demostró que la
maquinaria sin marco funciona a plena escala.
Por el camino fijó la anatomía de los mejores tableros: son un bloque perfecto
que cubre casi todo el tablero más una fina banda de discrepancias concentrada
en unas pocas filas superiores. Esa forma es la que los constructores
posteriores buscan reproducir a propósito.
## Método
Cuatro etapas, cada una entregando sus supervivientes a la siguiente a través
de un filtro admisible.
1. **Beams de la mitad superior (etapas 1–2).** Llenar la mitad superior con una
búsqueda simple y rápida, guardando los tableros parciales que sobreviven.
Las 256 piezas están libres, ningún marco está fijado.
2. **Relevo admisible.** En cada frontera de etapa, una estimación *admisible*
de bajo coste (una cota superior optimista sobre el mejor final posible)
descarta cualquier parcial que, de forma demostrable, no puede completarse
bien. Como la estimación nunca subestima la puntuación alcanzable, la
eliminación es segura: solo retira los parciales que no pueden ganar.
3. **Crecimiento de banda (etapa 3).** Prolongar los parciales supervivientes
hacia abajo, sobre la siguiente banda de filas.
4. **Finalizador exacto (etapa 4).** Resolver exactamente las filas de abajo,
minimizando las discrepancias, y *elegir el borde al final* entre las piezas
restantes. El marco no se diseña de antemano; cae de todo lo que está por
encima.
El resultado es 436 desde cero con un borde emergente, las cinco pistas
respetadas, muy por debajo de los récords, y esa brecha es la medida: cuantifica
cuánto vale el anclaje habitual del marco-primero. El subproducto importó más
que la puntuación: STAGED fijó la anatomía de los mejores tableros, un gran
bloque perfecto más una fina banda de discrepancias en unas pocas filas
superiores, la forma objetivo a la que los constructores posteriores apuntan
deliberadamente.
## Reproducir
Estocástico (los beams de la mitad superior deshacen los empates de forma
aleatoria), por lo que una nueva ejecución no reproducirá el tablero exacto; el
tablero 436 versionado es el artefacto de referencia y puede verificarse en el
visor. El motor es el productor por haz compartido, ejecutado por etapas para
que el borde emerja al final en lugar de fijarse primero. No necesita corpus ni
tablero de partida, así que se prevé un directorio de soporte ejecutable para
todo el pipeline por etapas junto a los demás constructores desde cero.
## Preguntas abiertas
¿Puede un generador que gaste deliberadamente sus discrepancias en las filas
superiores, para mantener el resto perfecto, alcanzar los 450 sin marco? ¿Qué
parte de la brecha de 436 a los récords se debe al anclaje de marco ausente,
frente al final de partida más difícil? ¿Y una estimación aprendida de la
calidad del final selecciona mejores supervivientes que la estimación admisible
de bajo coste?
## Relacionado
- [CLOISTER](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/cloister/) — Fijar un borde perfecto y luego explorar el interior tratando las aristas del borde como restricciones duras desde la primera celda.
- [BANDSAW](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/) — Resolver exactamente una banda de filas encontrándose en el medio, para hallar el verdadero mejor final y medir hasta qué punto puede decidirse por anticipado una fin de partida.
- [Búsqueda en haz](https://eternity2.dev/es/research/build/construct/beam-search/) — Mantener con vida los K tableros parciales más prometedores a la vez y hacerlos crecer celda a celda. La búsqueda en haz es el motor de los constructores desde cero de este proyecto, y una ilustración nítida de por qué la anchura por sí sola se estanca en las profundidades del interior.
- [El marco fluido](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/fluid-frame/) — Un borde perfecto de 60 piezas no es un objeto rígido. Cada marco completamente apareado admite exactamente 45 intercambios libres a coste de borde cero; un tercio de los marcos perfectos ni siquiera pueden arrancar el interior, y un solo intercambio libre revive cada uno de ellos.
---
# El estudio de la reparación
> La hermana del estudio DFS, para la otra manera en que se ataca Eternity II: destruir parte de un tablero, reconstruirla, conservar el cambio si ayuda. Una pregunta, planteada con cuidado. Qué aporta cada decisión de ese bucle: qué región destruir, cómo reconstruirla, cuándo conservar un movimiento, cuándo reiniciar, y desde qué tablero partir.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/repair-study/
- Actualizado: 2026-07-16
- Temas: local-search, search-space, speed
- Reproducir: `just experiments repair-study`
- Fuente: Motor ejecutable + resultados commiteados + scripts (el directorio de referencia de este estudio) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/repair-study
---
Hay dos maneras concretas en que se ataca Eternity II. La primera consiste en
construir un tablero celda a celda y retroceder cuando falla; el [estudio
DFS](/es/research/lab/experiments/raphael-anjou/dfs-study/) lo disecciona. La segunda
consiste en sostener un tablero entero y *repararlo*: arrancar una región,
reconstruirla, conservar el cambio si ayudó, y repetir. La reparación es la
última etapa de las cadenas construir-y-luego-refinar que hay detrás de los
tableros casi récord de este proyecto, y es el método al que recurre la
literatura en cuanto un tablero es demasiado bueno para que el desplazamiento de
una sola pieza lo mejore. Este estudio disecciona el bucle de reparación de la
misma manera en que su hermana diseccionó el backtracking: una decisión a la vez,
sobre las mismas diez variantes con esquinas fijadas, un núcleo, sesenta segundos
por ejecución. La puntuación máxima es de 480 aristas apareadas.
El bucle en sí es corto. Una iteración, recorrida a continuación.
> **[Figure]** Una iteración de destrucción-reparación, paso a paso — interactive: RepairLoopDiagram. Rendered on the canonical page (link above); not shown in this markdown export.
El objetivo no es ganar. La mayoría de las variantes terminan entre 360 y 379, y
la que mejor lo hace (446) lo logra partiendo de un tablero sólido obtenido por
backtracking en lugar de uno construido, lo que constituye en sí la lección
central del estudio. Reparar un simple tablero voraz en un núcleo durante un
minuto es poca cosa frente a las cadenas que emplean los récords; lo que el
estudio mide es *cuánto vale cada decisión del bucle*, cambiando una cosa a la vez
y midiendo el resultado con el mismo puntuador canónico que usan el estudio DFS y
el resto del sitio.
## La familia, y la clasificación
Cinco familias, dispuestas de modo que las vecinas difieran por una sola
decisión, todas ramificándose de un mismo bucle ancla depurado (arranque voraz,
destruir las celdas desapareadas, rellenado voraz, conservar el resultado salvo
que pierda puntuación, nunca reiniciar). El **tablero de partida** cambia el punto
donde el bucle comienza. El **operador de destrucción** cambia qué celdas levanta
cada iteración. La **reparación** cambia la manera en que se reconstruye el hueco.
La **aceptación** cambia el momento en que se conserva un movimiento no
mejorante. El **reinicio** cambia lo que ocurre una vez que el bucle se estanca.
> **[Interactive: RepairStudyLeaderboard]** Rendered on the canonical page (link above); not shown in this markdown export.
## Lo que el estudio encontró
- **Partir de un tablero sólido obtenido por backtracking gana el estudio
entero.** La variante que dedica sus primeros veinte segundos a ejecutar el
break-DFS del estudio DFS, y luego repara el tablero de poco más de 440 que
resulta, termina la más alta de todas, con una media de 446 (mejor resultado
449). La reparación solo añade un puñado de aristas por encima de ese tablero,
pero el tablero del que parte vale cien puntos más que una construcción voraz, y
eso se propaga hasta el final. Es la división del trabajo construir-y-luego-refinar
que emplean los récords, reproducida de principio a fin en un núcleo en un
minuto.
- **Entre las variantes con arranque voraz, la destrucción aleatoria se impone y
apuntar a los defectos resulta contraproducente.** Una destrucción ciega a la
geometría que levanta doce celdas *aleatorias* termina en una media de 402 (mejor
resultado 409) y sigue mejorando bien entrada la ejecución. Todo operador que
apunta a las celdas rotas termina por debajo, y cuanto más precisamente se
fija, peor lo hace: el ancla de las celdas desapareadas aterriza en 366, una
destrucción por componente conexa más grande en 350. Sobre un tablero mediocre
hay mejora disponible en todas partes, de modo que explorar vale más que atacar
donde ya duele. Eso se invierte en un tablero casi récord, donde los pocos
defectos restantes son lo único que queda por corregir.
- **El tablero de partida fija el suelo.** Una construcción voraz arranca en torno
a 348; una aleatoria arranca cerca de 18, y aunque el bucle la eleva unos
espectaculares 308 puntos, aun así termina por debajo de donde el arranque voraz
*comenzaba*. La construcción es la palanca, la reparación es el pulido.
- **La regla de aceptación es la otra palanca real.** El recocido simulado, que
desciende de vez en cuando para dejar una meseta, es la regla de aceptación más
fuerte por un margen claro (media 377, mejor resultado 394), muy por delante de
una escalada de colina estricta (361). Cuánto se permite un movimiento no
mejorante vale una diferencia de dieciséis puntos sobre el mismo bucle.
- **Los refinamientos ingeniosos no aportan nada aquí.** Una destrucción de banda
entera es inerte (cero mejoras en nueve de diez instancias). Un rellenado
*exacto* acotado de un hueco pequeño no supera a un rellenado voraz simple del
mismo hueco, un resultado negativo limpio: sus reconstrucciones localmente
perfectas cuestan suficientes iteraciones como para que más reconstrucciones
voraces y más baratas lleguen igual de lejos. Ni una patada aleatoria ni un
retorno-al-mejor ante un estancamiento despegan la puntuación de la referencia
sin reinicio.
Cada uno de estos puntos tiene su propio tratamiento: cómo está construido el
motor y qué significa cada estadística presentada están en la [página de
método](/es/research/lab/experiments/raphael-anjou/repair-study/method/), y las
comparaciones de destrucción, reparación, aceptación, reinicio y tablero de
partida se desarrollan en la [página de
resultados](/es/research/lab/experiments/raphael-anjou/repair-study/findings/).
## Cómo leer los números
Cada tablero se vuelve a puntuar con el único puntuador canónico, y no se confía
en la puntuación autodeclarada de ningún motor. El bucle mantiene su puntuación de
forma incremental a medida que coloca y levanta piezas, pero el número publicado
es siempre una nueva puntuación canónica del tablero producido. El rendimiento se
reporta en iteraciones de reparación por segundo y **nunca se compara entre
familias**, porque una iteración que ejecuta un rellenado exacto no es la misma
unidad de trabajo que una que ejecuta un rellenado voraz.
El eje a vigilar es el *estancamiento*: la iteración en la que el mejor global
mejoró por última vez, frente al total de iteraciones ejecutadas. Cuando la
primera es de unos pocos miles y la segunda de cientos de miles, la ejecución
encontró su respuesta pronto y luego molió la misma cuenca durante el resto del
minuto. Esa brecha es la forma medida de una observación de larga data sobre este
rompecabezas: la destrucción-reparación es una exploradora de cuencas soberbia y
prácticamente nunca escapa de la cuenca en la que aterriza.
Todo el aparato (el motor, las diez variantes, los resultados por ejecución
commiteados y los scripts de la grilla) reside bajo el [directorio de
referencia](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/repair-study)
del estudio, y `just experiments repair-study` reconstruye el motor y reejecuta
toda la grilla. El tablero, el puntuador y la capa de E/S provienen de una
[biblioteca
compartida](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/common)
que usa también el estudio DFS, de modo que un tablero reparado y uno obtenido por
backtracking se puntúan con exactamente el mismo código.
## Páginas de esta sección
- [Cómo está construido el estudio de la reparación](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/repair-study/method/) — El motor detrás del estudio de reparación: un único bucle componible de destrucción-reparación donde una variante es un cambio declarado sobre un padre, la IO y el scorer que comparte con el estudio DFS, un mapa de desajustes mantenido de forma incremental, y las definiciones de cada estadística que el estudio pone de relieve.
- [Qué mostró el estudio de la reparación](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/repair-study/findings/) — Las cinco comparaciones en el corazón del estudio de reparación, desarrolladas: la destrucción aleatoria ciega gana mientras que todo operador que apunta a los conflictos pierde; la construcción fija el suelo; el recocido simulado es la regla de aceptación más fuerte; y los refinamientos ingeniosos (recarga exacta, reinicios) no aportan nada con este presupuesto.
## Relacionado
- [Los experimentos de Raphaël Anjou](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/) — Un cuaderno de experimentos de búsqueda sobre Eternity II, organizado en torno a los motores compartidos sobre los que se ejecutan, las pipelines de combinación que persiguen la puntuación, cuatro estudios que desmontan un paradigma de búsqueda una decisión a la vez, y resoluciones exactas de final de partida. Cada uno expone su idea, su mejor tablero y las preguntas que deja abiertas. El mejor alcanza 463 de 480.
- [El estudio DFS](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/) — Una sola pregunta, planteada con cuidado: entre los backtrackers en profundidad para Eternity II, ¿qué aporta realmente cada orden de relleno, cada heurística y el mecanismo de ruptura? Una familia de backtrackers escritos desde cero, separados cada uno por un único cambio, ejecutados sobre las mismas diez variantes con esquinas fijadas, en un solo núcleo, durante sesenta segundos.
- [Búsqueda local y ALNS](https://eternity2.dev/es/research/build/local-search/local-search-alns/) — Destruir una parte del tablero, reconstruirla mejor y dejar que el algoritmo aprenda qué demoliciones rinden. La búsqueda de gran vecindario adaptativa es el pulidor más fiable de este proyecto, y la demostración más nítida del muro donde el pulido se detiene.
---
# Qué mostró el estudio de la reparación
> Las cinco comparaciones en el corazón del estudio de reparación, desarrolladas: la destrucción aleatoria ciega gana mientras que todo operador que apunta a los conflictos pierde; la construcción fija el suelo; el recocido simulado es la regla de aceptación más fuerte; y los refinamientos ingeniosos (recarga exacta, reinicios) no aportan nada con este presupuesto.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/repair-study/findings/
- Actualizado: 2026-07-16
- Temas: local-search, search-space, speed
- Fuente: Resultados por ejecución versionados (results.jsonl) e informe por familia (report.md) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/repair-study/results
---
Cinco comparaciones sostienen el [estudio de reparación](/es/research/lab/experiments/raphael-anjou/repair-study/).
Cada una aísla una decisión manteniendo las otras cuatro fijas en un bucle de
referencia simple: inicio voraz, destruir las celdas en desajuste, recarga voraz,
conservar el resultado salvo que pierda puntuación, nunca reiniciar. Todas las
puntuaciones son el número medio de aristas concordantes sobre las diez variantes
con esquinas fijadas, un solo núcleo, sesenta segundos. La tasa de iteración nunca
se compara entre familias.
## El tablero de partida: la palanca que el bucle no puede reemplazar
Cambie solo el tablero desde el que arranca el bucle, y todo lo demás de la
ejecución se deriva de él. Una construcción voraz empieza en torno a 348 y el bucle
la eleva a una media de 366. Un tablero aleatorio empieza cerca de 18 y el bucle lo
eleva unos enormes 308 puntos, hasta una media de 326. Esa elevación mayor no es el
bucle haciéndolo mejor; es el bucle haciendo mal el trabajo de la construcción. El
inicio aleatorio, tras millones de iteraciones, todavía termina por debajo de donde
el inicio voraz *empezaba*.
Este es el primer resultado del estudio, y el más firme: **la construcción es la
palanca, la reparación es el pulido.** Una construcción voraz de "color más escaso
primero" (la heurística de Selby y Riordan según la cual un color escaso debe
gastarse allí donde queda forzado) empieza un poco más alto aún y termina en una
media de 373, la mejor de los inicios *voraces*.
La prueba más nítida de este punto es partir de un tablero genuinamente fuerte en
lugar de uno voraz. La última variante de tablero de partida entrega al bucle un
tablero construido por el break-DFS del [estudio DFS](/es/research/lab/experiments/raphael-anjou/dfs-study/):
la ejecución dedica sus primeros veinte segundos a hacer backtracking hasta un
tablero en torno a 440, y luego lo repara durante los cuarenta restantes. Ese inicio
está cien puntos por encima de una construcción voraz, y se propaga directamente
hasta la llegada. Es la variante de mayor puntuación de todo el estudio, con una
media de 446 (mejor 449), muy por encima de los 402 del bucle de destrucción
aleatoria, y zanja la pregunta de construir-y-luego-refinar en torno a la cual gira
el resto del estudio: la reparación *sí* añade unas pocas aristas sobre un tablero
fuerte obtenido por backtracking, pero solo unas pocas, y el tablero del que parte
decide casi todo. Esta es exactamente la división del trabajo que emplean los
récords, y este estudio la reproduce de principio a fin en un núcleo en un minuto: un
backtracker para construir un buen tablero, y luego un bucle de reparación para
exprimir de él las últimas aristas.
## El operador de destrucción: atacar las roturas puede volverse en contra
Ahora fijemos el inicio voraz y cambiemos solo qué celdas levanta cada iteración.
Este es el eje que porta el resultado más sorprendente del estudio.
> **[Figure]** Los cuatro operadores de destrucción, sobre un mismo tablero de junturas rotas — interactive: DestroyOperatorDiagram. Rendered on the canonical page (link above); not shown in this markdown export.
- **Una destrucción aleatoria ciega a la geometría gana la comparación de
destrucción, con una media de 402 (mejor 409).** Al levantar doce celdas
*aleatorias* en lugar de las rotas, sigue muestreando nuevas regiones del tablero,
acepta casi tres cuartas partes de sus movimientos, y su mejor puntuación sigue
mejorando bien entrada la ejecución: su última mejora llega más allá de tres
millones de iteraciones, allí donde toda variante dirigida por conflictos hace
tiempo que se ha congelado. Es la mejor de todas las variantes que parten de un
tablero voraz (solo el inicio sembrado por DFS, una palanca completamente distinta,
termina más alto).
- **Todo operador dirigido por conflictos termina por debajo de ella, y cuanto más
se fija en las roturas, peor le va.** El ancla de "celdas en desajuste", que
levanta hasta una docena de las celdas rotas, promedia 366 y se estanca temprano:
arranca la misma maraña agrupada, la reconstruye vorazmente en casi la misma
disposición, y su mejor puntuación deja de moverse en unos pocos miles de
iteraciones. El operador de "componente más halo", que levanta toda una maraña
conexa (un hueco mucho mayor), lo hace peor aún, en 350, y su mejor ya no mejora
tras la iteración 211: un hueco de ese tamaño entrega a la recarga voraz un
subproblema que no sabe mejorar, de modo que casi nada llega a conservarse.
- **Una destrucción de banda entera es inerte.** Levantar las dos filas con más
roturas deja a la recarga voraz un subproblema casi tan difícil como el propio
puzzle; en nueve de las diez instancias no hace *ninguna* mejora en todo el minuto,
de modo que su puntuación reportada es simplemente su tablero de partida.
El patrón es limpio y merece enunciarse sin rodeos: sobre este inicio voraz
mediocre, cuanto más precisamente un operador apunta a las roturas existentes, peor
le va, y la destrucción aleatoria ciega gana. Esto es lo contrario de la intuición
natural, y de lo que funciona sobre un tablero *cercano al récord*, donde todo el
tablero está próximo al óptimo y donde el ajuste de la comunidad halló que los
operadores dirigidos por conflictos y por componentes eran los más valiosos,
precisamente porque los pocos desajustes restantes son lo único que queda por
corregir. Este estudio nunca alcanza ese régimen. Sesenta segundos sobre un tablero
mediocre dejan un amplio margen de mejora en todas partes, y ahí un operador que
reataca sin cesar el mismo grupo roto, o que arranca un hueco demasiado grande para
reconstruirlo bien, pierden ambos frente a uno que simplemente sigue intentando
nuevas regiones pequeñas. El hallazgo no es "la destrucción dirigida por conflictos
es mala" sino "qué operador gana depende de lo bueno que ya sea el tablero, y sobre
un tablero mediocre, explorar supera tanto a fijarse como a sobredestruir".
## Reparación: cómo se reconstruye el hueco
Fijemos la destrucción y cambiemos solo la recarga. Romper los empates exactos de
puntuación de la recarga voraz con una moneda sembrada, en lugar de forma
determinista, añade un poco de exploración y ayuda ligeramente, hasta una media de
365. La comparación más tajante es voraz contra recarga *exacta*, y hay que montarla
con cuidado para que sea una prueba limpia de un solo eje: la recarga exacta solo
compensa cuando el hueco es lo bastante pequeño para explorarlo, así que el estudio
la empareja con una destrucción pequeña (a lo sumo seis celdas en desajuste) y la
compara contra la *misma* destrucción pequeña recargada vorazmente, de modo que lo
único que cambia entre ambas es la recarga. Montada así, la recarga exacta corre en
cada iteración en lugar de replegarse a la voraz, reconstruyendo cada hueco pequeño a
su verdadero óptimo.
El resultado es un negativo limpio. La recarga exacta (media 360) **no** supera a la
recarga voraz del mismo hueco pequeño (media 363); si acaso queda un matiz por
detrás. Dos cosas lo explican. La recarga exacta acepta casi cada iteración, porque
una reconstrucción localmente óptima de un hueco de seis celdas casi nunca baja la
puntuación, de modo que el bucle deriva lateralmente en lugar de escalar. Y compra
esa optimalidad local a alrededor de un tercio del número de iteraciones, de modo que
en un minuto fijo explora menos el tablero. Sobre este puzzle, con este presupuesto,
una reconstrucción localmente perfecta de una región minúscula no vale lo que cuesta:
las reconstrucciones más baratas y ligeramente peores de la recarga voraz, ejecutadas
más a menudo, llegan igual de lejos. Esta es la misma pregunta de "la tasa de nodos
no es la puntuación" que plantean los motores heurísticos del estudio DFS, y aquí la
respuesta cae del lado de más iteraciones, más baratas, lo cual merece consignarse
precisamente porque tan a menudo se supone lo contrario.
## Aceptación: cuánto se permite un movimiento no mejorante importa
Fijemos el bucle y cambiemos solo cuándo se conserva un candidato no mejorante. De
los cinco ejes, este es el que más mueve la puntuación después del operador de
destrucción.
- **Una escalada de colina estricta, que conserva solo las mejoras estrictas, es la
más débil, con una media de 361.** Rechazar todo movimiento lateral la encierra en
la primera cuenca que encuentra; su tasa de aceptación es esencialmente cero.
- **Permitir movimientos iguales o mejores (el ancla) lo hace mejor, en 366.** Los
movimientos laterales le permiten derivar a través de las mesetas de puntuación
igual que dominan este paisaje.
- **Una regla de recocido simulado con enfriamiento es la aceptación más fuerte por un
margen claro, en 377 (mejor 394), entre las mejores de las variantes de inicio
voraz.** Permitir movimientos *empeorantes* ocasionales al principio, y luego
enfriar, le permite abandonar una meseta en la que la pura deriva lateral queda
atrapada, y su mejor puntuación sigue mejorando hasta alrededor de la iteración
veinte mil en lugar de congelarse en los primeros miles. Una regla de aceptación
tardía, que compara con la puntuación de unas decenas de iteraciones atrás, se sitúa
entre las dos en 369.
Así que la regla de aceptación es aquí una palanca real, no un detalle: de estricta a
recocido hay un vaivén de dieciséis puntos sobre el mismo bucle (361 a 377). Eso
merece enunciarse frente a una observación conocida del propio ajuste ALNS de la
comunidad: que a lo largo de un amplio rango de temperaturas de recocido las
puntuaciones finales eran esencialmente idénticas. Las dos no están en conflicto. Ese
ajuste se hizo sobre tableros cercanos al récord, donde el paisaje es un mar de
mesetas de puntuación igual y cualquier temperatura acepta casi todo; el tablero de
partida mediocre de este estudio todavía tiene estructura cuesta abajo real que
explotar, de modo que si la regla dará un paso cuesta abajo para escapar de una
meseta importa genuinamente. Qué regla de aceptación gana, como qué operador de
destrucción gana, depende de lo bueno que ya sea el tablero.
## Reinicio: ninguna perturbación mueve la aguja
Fijemos el bucle y cambiemos solo lo que ocurre una vez que se estanca. No hacer nada
deja a la ejecución triturando la misma cuenca durante el resto del minuto. Un
*golpe* aleatorio, que desplaza y recarga aleatoriamente un par de docenas de celdas
cuando el mejor no se ha movido en un rato, y un *retorno al mejor tablero hasta el
momento*, que reataca al titular, son las dos perturbaciones probadas. Ambas caen a
un punto del ancla sin reinicio (365 y 365, frente al 366 del ancla). Este es un
resultado nulo limpio: atornillar un detector de estancamiento y una perturbación al
bucle voraz-desajuste no lo ayuda, porque la perturbación o bien tira la estructura
que hacía bueno al tablero (el golpe) o bien retorna a un tablero en el que el mismo
operador ya se ha estancado (el retorno). Ninguna convierte el bucle en un evasor de
cuencas; sobre este puzzle, escapar de una cuenca requiere un movimiento distinto de
perturbar-y-reparar, que es exactamente lo que explican el
[muro de rigidez](/es/research/why/rigidity-wall/) y la
[estructura de σ-ciclos](/es/research/why/sigma-cycles/).
## El hilo conductor
Dos temas atraviesan las cinco comparaciones. El primero es que **las dos decisiones
que mueven la puntuación son el operador de destrucción y la regla de aceptación**, y
ambas la mueven en la misma dirección contraintuitiva: las elecciones ganadoras son
las que mantienen el bucle *explorando* en lugar de *explotando*. La destrucción
aleatoria supera a todo operador que apunta a las roturas; el recocido, que da un paso
cuesta abajo para abandonar una meseta, supera a toda regla que solo se mueve
lateralmente o cuesta arriba. Refinar la recarga y atornillar un reinicio, las dos
decisiones que intentan ser más ingeniosas acerca de una región en la que el bucle ya
está atascado, no aportan nada.
El segundo es por qué explorar gana aquí mientras que fijarse gana sobre un tablero
cercano al récord: **el bucle de reparación es un explorador de cuencas, no un evasor
de cuencas.** Sobre un tablero mediocre hay amplia estructura cuesta abajo en todas
partes, de modo que los movimientos que cubren más de ella ganan; sobre un tablero
cercano al récord no queda ninguna salvo un único ciclo entrelazado, de modo que los
movimientos que lo apuntan con precisión ganan. Ninguno de los dos regímenes permite a
perturbar-y-reparar escapar de una cuenca una vez que está en una. Por eso los
pipelines de construir-y-luego-refinar que alcanzan los mejores tableros de este
proyecto dividen el trabajo como lo hacen: un productor constructivo fuerte para
elegir una buena cuenca, y la reparación como último kilómetro dentro de ella, nunca
requerida a salir de ella.
## Relacionado
- [El estudio de la reparación](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/repair-study/) — La hermana del estudio DFS, para la otra manera en que se ataca Eternity II: destruir parte de un tablero, reconstruirla, conservar el cambio si ayuda. Una pregunta, planteada con cuidado. Qué aporta cada decisión de ese bucle: qué región destruir, cómo reconstruirla, cuándo conservar un movimiento, cuándo reiniciar, y desde qué tablero partir.
- [Cómo está construido el estudio de la reparación](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/repair-study/method/) — El motor detrás del estudio de reparación: un único bucle componible de destrucción-reparación donde una variante es un cambio declarado sobre un padre, la IO y el scorer que comparte con el estudio DFS, un mapa de desajustes mantenido de forma incremental, y las definiciones de cada estadística que el estudio pone de relieve.
- [Búsqueda local y ALNS](https://eternity2.dev/es/research/build/local-search/local-search-alns/) — Destruir una parte del tablero, reconstruirla mejor y dejar que el algoritmo aprenda qué demoliciones rinden. La búsqueda de gran vecindario adaptativa es el pulidor más fiable de este proyecto, y la demostración más nítida del muro donde el pulido se detiene.
---
# Cómo está construido el estudio de la reparación
> El motor detrás del estudio de reparación: un único bucle componible de destrucción-reparación donde una variante es un cambio declarado sobre un padre, la IO y el scorer que comparte con el estudio DFS, un mapa de desajustes mantenido de forma incremental, y las definiciones de cada estadística que el estudio pone de relieve.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/repair-study/method/
- Actualizado: 2026-07-16
- Temas: local-search, speed
- Fuente: El espacio de trabajo del motor (repair-engine, repair-run) sobre la biblioteca compartida e2-core / e2-io — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/repair-study/engine
---
Esta página es el aparato que hay detrás del [estudio de reparación](/es/research/lab/experiments/raphael-anjou/repair-study/):
cómo está construido el motor, por qué una nueva variante es barata de añadir, y
qué significa cada número de los resultados. Es el gemelo deliberado de la
[página de método del estudio DFS](/es/research/lab/experiments/raphael-anjou/dfs-study/method/),
y se apoya en la *misma* biblioteca compartida: el tablero, el conjunto de
piezas, el único scorer canónico y el contrato de IO provienen todos de un crate
`e2-core` / `e2-io` común que usa también el estudio de backtracking. Un tablero
reparado y un tablero obtenido por backtracking se puntúan, por tanto, con el
código idéntico, que es lo que permite que los números de ambos estudios se
sitúen sobre un mismo eje.
## Una variante es un cambio declarado sobre un padre
Cada algoritmo del estudio es el *mismo* bucle de destrucción-reparación,
parametrizado por cinco elecciones independientes:
- **tablero inicial**: el tablero desde el que arranca el bucle (aleatorio,
construcción voraz, o una construcción voraz que prioriza el color más raro);
- **operador de destrucción**: qué celdas retira cada iteración (aleatorias, las
celdas en desajuste, la peor banda de filas, o una componente conexa de
desajustes más su halo);
- **reparación**: cómo se rellena el hueco (voraz con el más restringido
primero, el mismo con desempates con ruido, o un relleno exacto acotado para
huecos pequeños);
- **aceptación**: si un candidato reemplaza al tablero de trabajo (conservar si
no es peor, solo mejoras estrictas, recocido simulado, o aceptación diferida);
- **reinicio**: qué ocurre ante un estancamiento (nada, una sacudida aleatoria,
o una vuelta al mejor tablero obtenido hasta el momento).
Una variante es un pequeño registro que nombra esas cinco elecciones, junto con
**el padre del que deriva y una descripción en una línea del único cambio que
añade**. Añadir una variante consiste en añadir un registro al registro, sin
código de bucle nuevo salvo que la idea sea una estrategia genuinamente nueva.
La matriz de «qué se apila sobre qué» de la página de resultados se genera a
partir de esas descripciones, de modo que no puede divergir del código que
realmente se ejecutó.
## El mapa de desajustes, mantenido de forma incremental
Un backtracker construye un tablero desde la nada; un bucle de reparación siempre
sostiene un tablero *completo* y lo edita. Las celdas que merece la pena atacar
son las que tocan una arista rota, así que el motor mantiene un recuento vivo,
por celda, de las aristas interiores rotas incidentes a ella. Colocar o retirar
una pieza actualiza solo las aristas alrededor de esa única celda, nunca el
tablero entero, de modo que un operador de destrucción guiado por conflictos
puede preguntar «¿qué celdas tocan un desajuste?» sin volver a recorrer todo. La
puntuación en curso se mantiene del mismo modo: cada colocación la ajusta según
el puñado de costuras que cambiaron. Un rebarrido completo ocurre exactamente una
vez, cuando se construye el tablero inicial; a partir de ahí el bucle es
incremental. Esto es lo que hace posibles cientos de miles de iteraciones en
sesenta segundos, y es la misma disciplina que la
[página teórica sobre ALNS](/es/research/build/local-search/local-search-alns/)
describe como mantener la destrucción a un coste proporcional al hueco, no al
tablero.
## El scorer es la única fuente de verdad
No se confía en la puntuación autodeclarada de ningún motor. La puntuación
incremental del bucle es un dispositivo de rendimiento; el número *publicado* es
siempre una repuntuación canónica fresca del tablero de salida, a través del
mismo scorer que usan el sitio y el estudio DFS (aristas apareadas, no
bordurías, adyacencias interiores, contadas a la derecha y hacia abajo por
celda). Un test comprueba que la puntuación incremental y la puntuación canónica
coinciden tras miles de colocaciones-y-retiradas aleatorias, de modo que se pueda
confiar en que el camino rápido sigue la verdad en vez de apartarse de ella.
## Las estadísticas que el estudio pone de relieve
Para cada ejecución el motor registra, y los resultados lo transportan hasta la
página:
- **puntuación final**: las aristas canónicamente apareadas (de 480) del mejor
tablero encontrado.
- **ganancia**: la puntuación final menos la puntuación del tablero inicial. Esto
aísla la contribución propia del bucle de reparación respecto de la
construcción de la que partió: una variante que arranca alta puede añadir poco
y aun así terminar alta, y es la ganancia la que distingue a las dos.
- **el estancamiento (última iteración récord vs iteraciones totales)**: la
iteración en la que el mejor global mejoró por última vez, comparada con
cuántas iteraciones compró el presupuesto. Este es el eje estrella del estudio:
cuando el primero está muy por debajo del segundo, la ejecución halló su
respuesta pronto y luego no movió nada.
- **tasa de aceptación**: la fracción de iteraciones que la regla de aceptación
conservó. Una tasa cercana a cero significa que el bucle propone cambios que
casi siempre rechaza, a menudo señal de que está reatacando la misma región.
- **tamaño medio de destrucción**: celdas retiradas por iteración, para que un
operador de hueco grande no se compare en silencio con uno de hueco pequeño.
- **iteraciones por segundo**: reportadas por variante y **nunca comparadas entre
familias**, porque una iteración que ejecuta un relleno exacto no es la misma
unidad de trabajo que una que ejecuta un relleno voraz.
- **reinicios**: perturbaciones disparadas, cero para una variante sin política
de reinicio.
La página también traza una **curva de convergencia** para unas pocas variantes
representativas: la mejor puntuación obtenida hasta el momento, muestreada cada
doscientas iteraciones, a medida que avanza una ejecución típica. Es la imagen
más clara del estancamiento: la curva sube con fuerza, luego se aplana mientras
el recuento de iteraciones sigue trepando.
## Honestidad sobre la velocidad del motor voraz
Como el motor MRV del estudio DFS, el bucle de reparación de aquí está escrito
primero para la claridad. El relleno voraz vuelve a recorrer el reservorio de
piezas restantes por cada celda que rellena, en vez de mantener listas de
candidatos de forma incremental, así que sus iteraciones por segundo son las de
este motor de código limpio, no lo mejor que un núcleo de reparación afinado
podría alcanzar. La clasificación por puntuación no depende de ello, puesto que
el rendimiento es un eje aparte nunca mezclado con la comparación de
puntuaciones, pero las cadencias de iteración deben leerse como las de este
motor, no como el techo de la destrucción-reparación.
## Lo que este estudio se abstiene deliberadamente de afirmar
Este es un estudio del bucle de reparación *desnudo*, una decisión a la vez, con
un presupuesto fijo pequeño. No es el pipeline récord: los tableros que alcanzan
mediados de los 450 y más allá combinan un productor constructivo potente,
ejecuciones más largas, y la reparación como pulido final, y varias de las
observaciones sobre los operadores que aparecen aquí se leerían de otro modo en
un tablero cercano al récord que en el mediocre arranque voraz del que parte el
bucle. Allí donde un resultado depende de la calidad del tablero inicial, la
página de observaciones lo dice. El propio afinamiento de la comunidad halló,
por ejemplo, que los operadores guiados por conflictos y por componentes son
valiosos precisamente en tableros casi óptimos, donde los pocos desajustes
restantes son lo único que queda por corregir, el régimen que las cortas
ejecuciones de este estudio nunca alcanzan.
## Reproducibilidad
El motor, las diez variantes, los resultados por ejecución versionados y los
scripts de rejilla viven todos bajo el
[directorio de soporte](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/repair-study)
del estudio. `just experiments repair-study` reconstruye el motor y vuelve a
lanzar toda la rejilla; la ejecución es determinista a una semilla fija, y la
disposición de las esquinas es el único eje de diversidad.
## Relacionado
- [El estudio de la reparación](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/repair-study/) — La hermana del estudio DFS, para la otra manera en que se ataca Eternity II: destruir parte de un tablero, reconstruirla, conservar el cambio si ayuda. Una pregunta, planteada con cuidado. Qué aporta cada decisión de ese bucle: qué región destruir, cómo reconstruirla, cuándo conservar un movimiento, cuándo reiniciar, y desde qué tablero partir.
- [Qué mostró el estudio de la reparación](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/repair-study/findings/) — Las cinco comparaciones en el corazón del estudio de reparación, desarrolladas: la destrucción aleatoria ciega gana mientras que todo operador que apunta a los conflictos pierde; la construcción fija el suelo; el recocido simulado es la regla de aceptación más fuerte; y los refinamientos ingeniosos (recarga exacta, reinicios) no aportan nada con este presupuesto.
- [Búsqueda local y ALNS](https://eternity2.dev/es/research/build/local-search/local-search-alns/) — Destruir una parte del tablero, reconstruirla mejor y dejar que el algoritmo aprenda qué demoliciones rinden. La búsqueda de gran vecindario adaptativa es el pulidor más fiable de este proyecto, y la demostración más nítida del muro donde el pulido se detiene.
---
# La escalera de tamaños
> Un banco que ejecuta cualquier solucionador, sin cambios, sobre tableros plantados totalmente resolubles con N = 8, 10, 12, 14, cada uno con un techo probado de 2N(N-1): el tamaño de colapso de un método se mide antes de gastar semanas en el 16×16 real.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/raphael-anjou/scaling-ladder/
- Actualizado: 2026-07-22
- Temas: structure, backtracking
- Reproducir: `just research-scaling-ladder`
- Fuente: Ansótegui et al., la transición de fase en los puzles de emparejamiento de bordes (contexto del umbral de dificultad) — https://doi.org/10.1007/978-3-540-85958-1_42
---
El 16×16 real es un lugar caro para descubrir que un método no escala. La
escalera de tamaños plantea antes una pregunta más barata: ejecuta cualquier
solucionador, sin modificarlo, sobre tableros plantados totalmente
resolubles con N = 8, 10, 12 y 14, cada uno con un techo probado, y lee el
tamaño en el que el método colapsa. Los dos solucionadores de referencia
incluidos se separan con nitidez y se degradan de forma monótona al subir la
escalera: exactamente la lectura que el banco existe para producir.
## Cómo funciona
Cada peldaño se construye hacia atrás desde una solución plantada, así que
es resoluble por construcción, y su objetivo de resolución completa sale
gratis: una malla N×N tiene exactamente 2N(N-1) adyacencias internas, el
tablero plantado las empareja todas y ningún tablero puede emparejar más.
Los cuatro peldaños llevan techos de 112, 180, 264 y 364. No hace falta
ningún solucionador externo para certificar nada; antes de cada
solucionador, el banco vuelve a puntuar el tablero plantado con el mismo
puntuador (borde excluido) que los solucionadores afrontarán y comprueba que
alcanza el techo exactamente. Esa comprobación está viva: un primer borrador
colocó un tablero pequeño en una malla de ancho 16, puntuó 28/60 y fue
atrapado por ella.
Cinco celdas de la solución se fijan como pistas al estilo del puzle
oficial, cada solucionador recibe un presupuesto fijo de 12 segundos de
reloj en un solo núcleo, y cada tablero devuelto se vuelve a puntuar de
forma independiente desde sus bordes; el auto-informe del solucionador no se
usa nunca. Una fila JSON por (solucionador, N, semilla) registra la
puntuación verificada, el techo, su cociente, si la resolución fue completa,
el número de nodos y un enlace al tablero. Cada tablero se abre en el
[visualizador](/viewer/): aquí hay un
[peldaño plantado N=8](/viewer/?puzzle=ladder_n8_c22_s1&puzzle_size=8&board_edges=adcaabtdacrbafkcabofabmbaflbaadfcnfatrunrsgrkwisohuwmgvhlqjgdadqfmcaupimgnupikonujvkvrnjjoordadocheaikrhujikokujvvlknqpvopsqdaepehbarglhinwgulsnltnlpkmtspskeaepbidaljqiwvojstivnwhtmjpwstljeaetdhbaqmvhoqwmimrqhqgmpsuqlgtseadgbeaavbaewfabrfafgcafucactcacdaac)
y el [mejor parcial N=14](/viewer/?puzzle=ladder_n14_c22_s5&puzzle_size=14&board_edges=abdaaclbafncadkfabqdafibacufadhcafkdadhfacqdaewcacueaadcducalijunowikwsoqjkwihpjuvjhhnnvkqonhihqqqqiwmsqunumdaenctbajrptwrlrsisrkroipwtrjpjwnlopouvlhvnuqrtvsjgruttjeaftbpbapmnplkwmsiskothitsltjlosovvlvgpvnqhgtosqgkootrgkfaerbwbanslwwnkssghnhiggljmiotjjvmttpmgmhwgmsrvwokhrgpukeafpbiealpuikvwphluvgrslmurrjskutmgsgknmghlkvijhhgiiuhhgfabhescauupswvjuukjvsjikrrwjkokrglqonmollwlmjoiwinwohqjnbaeqcidapgvijirgjsuiisnswlnskhmlqlthottlloptiswownusjhrneaehdgfavtwgrjhtuuwjnkmunqnkmirqtmtitglmpqggwpoqaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaocaeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa&hints=56.2-186.0-114.3-53.2-37.0)
producido por esta ejecución.
Los dos solucionadores incluidos cubren las dos familias que el estudio
original separa: una vuelta atrás en profundidad que solo coloca piezas que
encajan por completo (el miembro más simple de la familia propagativa) y un
rellenador voraz fila a fila, sin ninguna vuelta atrás.
## El resultado
En la ejecución original de trece métodos (13 métodos × 11 instancias × 3
semillas = 429 trabajos), la escalera separó las familias de solucionadores
por un peldaño entero: la familia propagativa, guiada por restricciones,
mantuvo un cociente perfecto de 1.000 hasta N=12 incluido (264 aristas de
264), los órdenes de «borde primero» ya habían colapsado hacia 0.15 a 0.22 a
ese tamaño, y en N=14 todos los métodos cayeron entre 0.055 y 0.157. La
reproducción archivada vuelve a ejecutar el banco de punta a punta con los
dos solucionadores de referencia:
> **[Figure]** Esperado vs medido (4 peldaños × 8 semillas × 2 solucionadores, presupuesto mononúcleo de 12 s) — interactive figure. Rendered on the canonical page (link above); not shown in this markdown export.
Toda la mecánica se reproduce: el techo probado gratuito, la certificación
de cada tablero plantado con el mismo puntuador que afrontan los
solucionadores, la re-puntuación independiente de cada tablero devuelto y la
degradación monótona del DFS, perfecto en N=8 y sin ninguna resolución
completa en N=14, mientras el voraz no resuelve por completo en ningún
sitio. La dispersión entre semillas es amplia en los peldaños altos (0.216 a
1.0 en N=12, 0.047 a 0.613 en N=14 para el DFS); por eso cada peldaño
conserva 8 semillas.
## Lo que no se sigue
- **El éxito con N pequeño no predice nada sobre el 16×16.** Los métodos
perfectos en N=12 valen casi nada un peldaño más arriba; el entregable es
la curva de degradación, nunca una clasificación a un solo tamaño. Para el
estado de la instancia real, véase
[la página de récords](/es/research/records/).
- **Escaleras de generadores distintos no son intercambiables.** La
profundidad del colapso depende del perfil de la instancia. Los peldaños
originales seguían el perfil de colores del puzle real (22 colores
interiores, 5 colores raros confinados al anillo adyacente al marco) y
llevaban hasta 10 u 11 piezas duplicadas en N=14; el generador del kit no
produce ningún duplicado ni anillo de colores raros, y el colapso en N=14
es visiblemente menos profundo en sus peldaños (parciales cerca de 0.6
frente a un suelo de 0.157 en la malla original). Las formas de las curvas
se transfieren; los puntos de ruptura exactos, no.
- **Que un solucionador de referencia débil falle un peldaño no refuta
nada.** Las filas perfectas hasta N=12 pertenecen a solucionadores
propagativos concretos aún no portados al kit; un solucionador
infradimensionado solo puede quedarse por debajo.
## Reproducir
`just research-scaling-ladder` reconstruye los cuatro peldaños desde el
generador con semillas (un binario por peldaño, porque el motor compartido
fija el tamaño del tablero en tiempo de compilación) y vuelve a ejecutar los
dos solucionadores con el presupuesto de 12 segundos, escribiendo una fila
JSONL por ejecución más un censo de peldaños con el enlace al visualizador
de cada tablero plantado. Reproduce la mecánica del banco y la forma de las
curvas; una igualdad celda a celda con la tabla original de trece métodos
exige el conjunto de instancias original archivado y el registro de
solucionadores portado, como detalla el plan de reproducción.
## Relacionado
- [Benchmark mono-núcleo](https://eternity2.dev/es/research/lab/experiments/single-core-benchmark/) — Quince solucionadores, los nuestros y nuestras implementaciones de los dos backtrackers récord de la comunidad, cada uno ejecutado una vez sobre diez variantes del puzzle oficial con las esquinas fijadas, un solo núcleo, 60 segundos por ejecución. El hallazgo: el número de nodos no es la puntuación.
- [Calibrado en el pico de dificultad](https://eternity2.dev/es/research/why/phase-transition/) — Eternity II utiliza 22 colores, repartidos entre 17 colores interiores y 5 reservados al marco, y ese número de alrededor de 17 se sitúa cerca del punto donde este tipo de puzzle es más difícil de resolver (la transición es una banda, no un entero único).
- [¿Es NP-completa esta instancia y cómo la codifico?](https://eternity2.dev/es/research/why/how-hard-is-this-instance/) — El emparejamiento de aristas es NP-completo como familia, pero eso no dice nada de un tablero 16×16 fijo: una instancia aislada es una constante, no un problema. Lo que sí es cierto es la dureza en el peor caso de la familia y la dureza empírica de esta instancia, y cómo escribir el puzzle para un solucionador SAT, de cobertura exacta o de PLE, con pequeños esbozos detallados. Una medición con tableros plantados pone cifras a la elección de la formulación: un acantilado de resolubilidad que un paradigma de búsqueda golpea y otro cruza, y que se mueve con el número de colores.
- [Los benchmarks de la comunidad](https://eternity2.dev/es/research/build/benchmarks/) — Cómo una comunidad a la que se le prohibió compartir las piezas construyó aun así una cultura de pruebas compartida: protocolos de verificación por conteos derivados, las suites Txibilis y para principiantes, duelos al número de nodos, enumeraciones completas y el único benchmark que sigue abierto hoy.
---
# Benchmark mono-núcleo
> Quince solucionadores, los nuestros y nuestras implementaciones de los dos backtrackers récord de la comunidad, cada uno ejecutado una vez sobre diez variantes del puzzle oficial con las esquinas fijadas, un solo núcleo, 60 segundos por ejecución. El hallazgo: el número de nodos no es la puntuación.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/single-core-benchmark/
- Actualizado: 2026-07-13
- Temas: speed, construction, backtracking
- Reproducir: `just experiments single-core-benchmark`
- Fuente: Motor ejecutable + resultados commiteados + scripts (el directorio de soporte de este experimento) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/single-core-benchmark
---
Dele a cada solucionador el mismo presupuesto, un núcleo y un minuto: ¿cuál gana?
La respuesta desmonta la intuición evidente. Varios solucionadores, los nuestros
y nuestras implementaciones de los dos backtrackers récord de la comunidad, se
ejecutaron cada uno una vez sobre diez variantes del puzzle oficial con las
esquinas fijadas, en mono-hilo, 60 segundos por ejecución. Cada tablero se volvió
a puntuar con un único solucionador canónico; no se confía en la puntuación
autodeclarada de ningún motor. La puntuación máxima posible es 480.
> **Cada motor aquí es código nuestro**
>
> `blackwood_style` y `verhaard_style` son **nuestras implementaciones reescritas desde cero** de los algoritmos publicados por Joshua Blackwood y Louis Verhaard, no los programas propios de los autores. El `eii` de Verhaard solo se distribuyó como binario Win32, así que una reimplementación (cuyas constantes se recuperaron de `eii.exe`) es la única forma de ejecutarlo siquiera. El C# real de Blackwood sí *es* [público](https://github.com/jblackwood345/EternityII_Solver), pero codifica de forma fija sus 256 piezas y su número de hilos, de modo que no puede leer las variantes de esta cuadrícula ni fijarse a un solo núcleo sin editarlo. Las puntuaciones de aquí miden nuestra lectura de cada algoritmo, no la ingeniería de los autores, y no deben citarse como «Blackwood obtiene N».
El ranking siguiente muestra los métodos que compiten por puntuación. Una segunda
familia, los preajustes CSP (un motor de arco-consistencia ejecutado bajo una
docena de perillas de ordenamiento), es una categoría distinta: su mejor preajuste
alcanza alrededor de 183, menos de la mitad de la puntuación de un contendiente,
por lo que no merece ninguna fila en el ranking. Ese barrido de preajustes es un
estudio por derecho propio, en su
[propia página](/es/research/lab/experiments/single-core-benchmark/csp-presets/).
## Lo que compra un minuto de un núcleo
Los dos backtrackers récord dominan este presupuesto. Nuestro motor de estilo
Verhaard alcanza una media de **440,8** (mejor 451) y nuestro motor de estilo
Blackwood **436,4** (mejor 440), ambos explorando de 20 a 40 millones de
nodos de búsqueda por segundo. Nada más se acerca: el DFS ingenuo se posa en
**365,6**, y el mejor preajuste CSP en torno a **183**.
La brecha entre esos dos grupos es el hallazgo. Las cuatro familias ven el mismo
puzzle y los mismos 60 segundos, y terminan separadas por 250 puntos. Lo que las
distingue no es la velocidad: los motores CSP son tres órdenes de magnitud más
lentos por nodo que los backtrackers y aun así vencen al DFS ingenuo en las
variantes favorables, porque cada nodo se poda en lugar de solo visitarse. El
número de nodos y la puntuación no son el mismo eje.
Lo que esta cuadrícula no puede decirte es dónde está el techo. El mejor tablero
de aquí (451) sigue quedándose a 13 puntos del récord de 5 pistas de la comunidad,
464, y la media del mejor motor se sitúa unos 24 por debajo; los récords no se
establecieron en un minuto, vinieron de granjas de cómputo y meses de esfuerzo.
Esto mide la eficiencia por núcleo con un presupuesto pequeño y fijo, nada más.
> **[Figure]** El ranking: puntuación media sobre diez variantes de esquinas, un solo núcleo, 60 s — interactive: BenchmarkLeaderboard. Rendered on the canonical page (link above); not shown in this markdown export.
## Leer la tabla
Los dos backtrackers encabezan este tablero y se mantienen ahí con estabilidad:
el motor de estilo Verhaard abarca de 437 a 451 a lo largo de las diez variantes,
el motor de estilo Blackwood de 431 a 440. La referencia ingenua es el suelo: un
365 rápido y lleno de basura que muestra a qué se parece un simple recuento de
aristas emparejadas sin ninguna calidad de tablero.
Las unidades de rendimiento difieren según la familia y nunca se comparan entre
sí. Los backtrackers cuentan nodos de búsqueda por segundo, los motores CSP lo
mismo pero entre 5 y 10 mil, porque cada uno de sus nodos ejecuta una
arco-consistencia completa. La familia CSP cambia rendimiento por poda, y por eso
explora muchísimos menos nodos y aun así vence al DFS ingenuo en las buenas
variantes.
## Qué hace cada contendiente
- **Verhaard y Blackwood (backtrackers, puestos 1 y 2).** DFS con ruptura
controlada por la profundidad, a 20 a 40 millones de nodos por segundo. Empujan
hasta 437 a 451 pero chocan contra un muro: el final de partida necesita mucho
más cómputo del que permiten 60 segundos. Blackwood encontró su 470 tras
alrededor de un mes en un solo PC, y lo calificó de «golpe de suerte»
([mensaje 10194](https://groups.io/g/eternity2/message/10194)).
- **DFS ingenuo (la referencia).** Rellena todo el tablero permitiendo cada
ruptura. En orden fila por fila (`anjou-naive_rowmajor`) alcanza un recuento
elevado de aristas emparejadas (365) pero un tablero de baja calidad lleno de
rupturas. Rápido, y basura. Se asienta en el tablero como un suelo: el número
que un método tiene que superar para valer algo. (La sensibilidad del DFS
ingenuo al orden de visita, y por qué la variante en espiral se desploma a 78,
está en la [página de preajustes CSP](/es/research/lab/experiments/single-core-benchmark/csp-presets/)
junto a las demás ablaciones del mismo motor.)
## Dónde se sitúan estos números
Esta cuadrícula limita cada motor a un núcleo durante 60 segundos, muy por debajo
del cómputo que produjo los récords de abajo. Mide la eficiencia por núcleo y la
calidad heurística, no la puntuación máxima alcanzable. Un motor que se clasifica
alto aquí alcanza buenos tableros a bajo coste; los números récord necesitan
muchos núcleos multiplicados por horas.
Cada variante de aquí fija las 5 pistas oficiales (más 3 esquinas, es decir 8
pistas en total), de modo que el techo pertinente es el **récord de 5 pistas de la
comunidad, 464**, y no el 470 con todas las pistas (que usa más que las 5 pistas).
Ese 464 es lo que marca la línea discontinua del ranking.
| referencia | puntuación | condiciones |
|:--|--:|:--|
| Récord comunitario de 5 pistas | 464 | Benjamin Riotte, julio de 2026 (las mismas 5 pistas que fijan estas variantes) |
| Mejor de esta cuadrícula (estilo Verhaard) | 451 | un núcleo, 60 s (media 440,8 sobre 10 variantes) |
| Estilo Blackwood en esta cuadrícula | 440 | un núcleo, 60 s (media 436,4 sobre 10 variantes) |
| Techo comunitario con todas las pistas | 470 | Blackwood, ~1 mes en un solo PC, usa más que 5 pistas |
## Método y reproducibilidad
Cada una de las diez variantes es el puzzle oficial más tres celdas de esquina
fijadas (disposiciones distintas de las piezas de esquina), de modo que las diez
comparten el conjunto de 256 piezas y las 5 pistas pero difieren en tres
restricciones de esquina. Se emiten tanto en JSON con el esquema del sitio (para
los motores nativos) como en CSV (para los motores autónomos) desde un único
generador, de manera que cada algoritmo ve instancias idénticas. Una ejecución
por puzzle, semilla fija; la disposición de las esquinas es el único eje de
diversidad. Cada ejecución emite una `.url` bucas, y la puntuación es el recuento
canónico de aristas emparejadas producido por el mismo solucionador, nunca la
autodeclaración del motor. No hubo ningún fallo en las 150 ejecuciones.
Cada motor de la cuadrícula es nuestro propio código de código abierto y se
ejecuta desde este repositorio, incluidos los dos escritos a partir de los
algoritmos publicados por la comunidad; ningún solucionador de terceros está
integrado aquí. La cuadrícula los mide todos; el ranking de arriba solo muestra
los cinco que compiten por puntuación, y la
[página de preajustes CSP](/es/research/lab/experiments/single-core-benchmark/csp-presets/)
muestra el resto. El workspace de crates, las diez variantes, los resultados
commiteados por ejecución y los scripts de la cuadrícula residen todos bajo el
[directorio de soporte](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/single-core-benchmark)
del experimento, y `just experiments single-core-benchmark` compila los motores y
relanza toda la cuadrícula. La familia nativa (el ingenuo y los preajustes CSP)
es un único binario seleccionado por preajuste; los dos backtrackers son un
binario cada uno, gobernados por un pequeño wrapper. Ambos hablan el mismo
contrato de puzzle-de-entrada, url-bucas-de-salida, y cada tablero se vuelve a
puntuar con el único solucionador canónico.
## Hallazgos complementarios
El perfilado situó el 96,6 por ciento del tiempo de la familia CSP en un único
bucle AC-3 fuertemente preoptimizado. Ese motor ya está en su techo de
rendimiento; las velocidades del benchmark son sus velocidades reales, no una
brecha de implementación. Por otra parte, las constantes Blackwood de la comunidad
no se transfieren de un etiquetado de colores a otro: sus colores privilegiados
publicados obtuvieron 387 en nuestro etiquetado frente a 435 para un reajuste, una
brecha de 48 puntos que nuestro Blackwood cierra reajustando solo los ID de color
relativos al etiquetado y respetando cada elemento estructural de la
especificación publicada.
## Trabajo abierto
La cuadrícula ejecuta nuestras implementaciones. Dos de los tres motores récord de
la comunidad pueden en principio ejecutarse directamente, y esa es la siguiente
medición evidente:
- **El generador en C de Peter McGavin.** Publicó el código fuente en la lista en
enero de 2026 como `genbody71.zip`
([mensaje 11749](https://groups.io/g/eternity2/message/11749)). Compila en
Apple silicon con `clang` y su pasada de generación emite un `body.c` de 10 363
líneas especializado para un solo puzzle. Es el motor más rápido que la
comunidad ha medido, a 295 M de colocaciones/s en la CPU de Joe
([mensaje 11750](https://groups.io/g/eternity2/message/11750)), y está ausente
de esta cuadrícula.
- **El C# de Joshua Blackwood.** [Público y bajo
GPL-3.0](https://github.com/jblackwood345/EternityII_Solver); compila sin
modificar en .NET 8. Pero codifica de forma fija las 256 piezas en `Util.cs`,
fija `number_virtual_cores = 64`, y no toma argumentos, de modo que fijarlo a un
solo núcleo o alimentarlo con las variantes de esta cuadrícula supone editar su
código fuente, punto en el que el artefacto ya no es puramente suyo. Ejecutarlo
tal como se publicó, sobre el puzzle simple, es la forma fiel de esa medición.
- **El `eii` de Louis Verhaard** no puede ejecutarse en absoluto: la descarga
desde su propio sitio entrega `eii.exe` y ningún código fuente, razón por la
cual nuestro motor lo reconstruye a partir del binario.
Ninguno de estos motores está integrado en este repositorio; ambos se descargan y
ejecutan localmente en el momento de la medición.
## Páginas de esta sección
- [Presets CSP, medidos](https://eternity2.dev/es/research/lab/experiments/single-core-benchmark/csp-presets/) — Un solo motor de propagación de restricciones, ejecutado bajo una docena de presets de ordenación y de propagadores, sobre las mismas diez variantes con esquinas fijadas que el ranking. Un estudio de lo que aporta cada ajuste, mantenido fuera del ranking principal porque el mejor preset alcanza menos de la mitad de la puntuación de un contendiente.
## Relacionado
- [PRIOR](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/prior/) — Construir un tablero desde cero, resolviendo los empates según la posición habitual de las piezas en los buenos tableros ya conocidos. Alcanza una puntuación alta sin ningún tablero de partida que copiar.
- [Búsqueda en haz](https://eternity2.dev/es/research/build/construct/beam-search/) — Mantener con vida los K tableros parciales más prometedores a la vez y hacerlos crecer celda a celda. La búsqueda en haz es el motor de los constructores desde cero de este proyecto, y una ilustración nítida de por qué la anchura por sí sola se estanca en las profundidades del interior.
---
# Presets CSP, medidos
> Un solo motor de propagación de restricciones, ejecutado bajo una docena de presets de ordenación y de propagadores, sobre las mismas diez variantes con esquinas fijadas que el ranking. Un estudio de lo que aporta cada ajuste, mantenido fuera del ranking principal porque el mejor preset alcanza menos de la mitad de la puntuación de un contendiente.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/lab/experiments/single-core-benchmark/csp-presets/
- Actualizado: 2026-07-15
- Temas: backtracking, search-space
- Reproducir: `just experiments single-core-benchmark`
- Fuente: Motor ejecutable + resultados versionados + scripts (el directorio de respaldo de este experimento) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/single-core-benchmark
---
El ranking del [benchmark mono-núcleo](/es/research/lab/experiments/single-core-benchmark/)
muestra los métodos que compiten en puntuación. Esta página muestra el resto:
una docena de presets de un solo motor de satisfacción de restricciones, más el
DFS ingenuo en su orden de visita más débil. No son una docena de solucionadores.
Son un único núcleo de arco-consistencia con distintas cabezas puestas, conservado
para que el coste exacto de cada técnica clásica se lea en un número en lugar de
discutirse.
> **[Figure]** Presets CSP: puntuación media sobre diez variantes con esquinas, un núcleo, 60 s — interactive: BenchmarkLeaderboard. Rendered on the canonical page (link above); not shown in this markdown export.
## Lo que aporta cada ajuste
Los presets varían dos cosas: el orden en que el motor asigna las celdas, y con
cuánta fuerza propaga antes de comprometerse. Manteniendo fijos el puzzle y el
presupuesto, la diferencia de puntuación entre dos presets es el valor de ese
único ajuste.
- **La ordenación por el valor menos restrictivo ayuda.** `anjou-gacolor_ac3_lcv`
alcanza una media de 114 frente al simple `anjou-gacolor_ac3` en 76: elegir el
valor que descarta la menor cantidad de vecinos vale aquí unos 38 puntos.
- **Algunos ajustes son inertes a esta profundidad.** Tres presets
(`anjou-gacolor_ac3`, `anjou-gacolor_ac3_ns1`, `anjou-verhaard_preferred`)
produjeron tableros idénticos al byte en este puzzle. NS-1 y la ordenación
preferida no añaden nada en 60 segundos: el motor nunca busca lo bastante hondo
para que muerdan.
- **La ordenación borde primero es el preset más fuerte.** `anjou-border_first_lcv`
y `anjou-rare_color_first` encabezan el barrido en torno a 183, al fijar el
marco sobre-restringido antes que el interior libre. Aun así es menos de la
mitad de la puntuación de un contendiente.
## Por qué ninguno compite
Cada preset es bimodal. En una disposición de esquinas favorable, la búsqueda por
arco-consistencia alcanza de 340 a 349; en una hostil, se desploma hasta unos 55,
atrapada en una cuenca mala de la que no puede salir en 60 segundos. La media se
mantiene baja porque las esquinas malas la arrastran hacia abajo, y ningún ajuste
de ordenación corrige el problema de la cuenca. Esa es la verdadera historia de
esta familia: la propagación hace que cada nodo esté bien podado pero sea costoso,
de modo que la búsqueda es fuerte donde la instancia es indulgente e impotente
donde no lo es. Los motores constructivos del ranking nunca caen en esa trampa,
razón por la cual un preset en 183 está en una página distinta de la de los
contendientes del ranking, que llegan hasta 451.
## El DFS ingenuo también está aquí, por una sola razón
La búsqueda en profundidad ingenua con todas las rupturas permitidas no es un
preset CSP, pero su orden de visita pertenece a la misma lección. En orden por
filas (`anjou-naive_rowmajor`, en el ranking como referencia) alcanza 365; el
mismo DFS en orden de visita en espiral (`anjou-naive_spiral`) se desploma a una
media de 78. La sola elección del orden de visita cuesta a la búsqueda ingenua
casi 290 puntos, la misma clase de sensibilidad a la ordenación que muestran los
presets CSP, a mayor escala.
## Método y reproducibilidad
Estos presets se ejecutaron en la misma cuadrícula que el ranking: diez variantes
del puzzle oficial, cada una con tres celdas de esquina fijadas, un núcleo, 60
segundos, semilla fija, una ejecución por variante. Cada tablero se vuelve a
puntuar con el único puntuador canónico de aristas emparejadas, nunca con la
auto-declaración del motor. El motor, las diez variantes, los resultados
versionados por ejecución y los scripts viven bajo el
[directorio de respaldo](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/single-core-benchmark)
del experimento, y `just experiments single-core-benchmark` reejecuta la
cuadrícula entera, contendientes y presets juntos.
## Relacionado
- [Benchmark mono-núcleo](https://eternity2.dev/es/research/lab/experiments/single-core-benchmark/) — Quince solucionadores, los nuestros y nuestras implementaciones de los dos backtrackers récord de la comunidad, cada uno ejecutado una vez sobre diez variantes del puzzle oficial con las esquinas fijadas, un solo núcleo, 60 segundos por ejecución. El hallazgo: el número de nodos no es la puntuación.
- [La consistencia de arco, desde AC-3 en adelante](https://eternity2.dev/es/research/build/reduce/arc-consistency/) — El forward checking mira un movimiento por delante; la consistencia de arco obliga a la lista de candidatos de cada celda a defenderse frente a la de cada vecina, hasta un punto fijo. El AC-3 de Mackworth, los refinamientos óptimos que vinieron después, y lo que toda esa familia midió realmente en este puzzle, incluido dónde deja de ser correcta.
- [Órdenes de relleno](https://eternity2.dev/es/research/build/backtracking/fill-order/) — El orden en que un algoritmo de backtracking visita las 256 celdas es su única libertad: no cuesta nada en tiempo de ejecución y mueve el tamaño del árbol de búsqueda en varios órdenes de magnitud. Veinte años de ciencia comunitaria, desde las guerras entre fijo y dinámico y las carreras de estrategias hasta el cuadrado mágico 10×16 y la búsqueda en peine de Verhaard, responden todos a la misma pregunta: ¿qué camino a través del tablero es el más barato?
---
# Problemas abiertos
> La frontera abierta de Eternity II reunida en un solo lugar: cada ángulo que todavía merece un intento, el muro que ataca, qué se ha probado y dónde se detuvo, y si es un objetivo accesible para principiantes o uno difícil y bien cartografiado.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/open-problems/
- Actualizado: 2026-07-21
- Fuente: Archivo de la lista de correo eternity2 (groups.io): donde se anuncian y discuten los objetivos abiertos — https://groups.io/g/eternity2
---
Este es el tablero de los ángulos abiertos: una fila por cada dirección que
todavía merece un intento. Cada entrada plantea la pregunta en una línea, nombra
el muro que ataca (tomado de [por qué es difícil](/es/research/why/)), remite a lo
que ya se ha probado y a dónde se detuvo (en el
[mapa de muros y métodos](/es/research/why/walls-and-methods/) y los
[callejones sin salida](/es/research/build/dead-ends/)), y etiqueta su accesibilidad.
Las etiquetas dicen lo que dicen: **accesible para principiantes** es un objetivo
que puedes tomar sin una década de contexto; **difícil, bien cartografiado** es
un objetivo que muchos intentos sólidos han trazado sin que ninguno lo cruzara;
**sin atender** es un ángulo en el que nadie trabaja activamente, algo distinto
de uno que fue atacado y resistió.
Para el estado del arte, la puntuación vive en la página de
[records](/es/research/records/); esta página solo muestra lo que sigue abierto.
## La brecha de 470 a 480
> **¿Puede algún método cruzar del techo de 470 a un 480 completo?**
>
> La vía canónica. El mejor tablero que respeta solo la pista de inicio obligatoria está en 470/480 desde que la comunidad lo alcanzó, y un 480 diseñado es un hecho dado: la editorial construyó el puzle a partir de una solución, así que un tablero perfecto existe y solo su ubicación queda abierta.
**Muro.** [Rigidez](/es/research/why/rigidity-wall/): los tableros record son islas
localmente congeladas, y las diez aristas que faltan están al otro lado de
[todos los muros estructurales a la vez](/es/research/why/walls-and-methods/).
**Probado, y dónde se detuvo.** Todo método del
[mapa de muros y métodos](/es/research/why/walls-and-methods/) termina contra la
rigidez; las construcciones desde cero y desde el corpus se estancan entre 458 y
463, y ninguna cruza el techo. La fuerza de cálculo bruta tampoco lo cierra, lo
que queda registrado bajo [lanzar más cálculo contra el muro](/es/research/build/dead-ends/).
**Etiqueta.** Difícil, bien cartografiado. Es la cumbre de todo el puzle: se sabe
mucho sobre por qué resiste, y por eso mismo un cruce nuevo sería noticia.
## El objetivo estricto de cinco pistas, de 464 a 465
> **¿Puede un tablero que honra las cinco pistas oficiales superar 464?**
>
> La línea estricta de cinco pistas se sigue por separado de la línea abierta de 470, porque [la mayor parte del avance en el record abierto se hizo sin las pistas](/es/research/build/clue-puzzles/). El mejor tablero que respeta las cinco colocaciones es 464.
**Muro.** [Rigidez](/es/research/why/rigidity-wall/) de nuevo, más las colocaciones de
pistas que estrechan la región alcanzable: menos tableros satisfacen las cinco,
así que el pajar es más pequeño, pero la aguja también.
**Probado, y dónde se detuvo.** El 464 es la marca vigente de la línea estricta en
la página de [puzles con pistas](/es/research/build/clue-puzzles/); las construcciones
estrictas y re-compresiones del proyecto alcanzan la clase de los 460 sin pasarla,
como se traza en el [mapa de muros y métodos](/es/research/why/walls-and-methods/).
**Etiqueta.** Difícil, bien cartografiado, pero un paso más corto que la brecha de
470 a 480: de 464 a 465 es una sola arista, en una línea donde la región alcanzable
es más ceñida y por tanto más fácil de razonar que el record abierto.
## El 10x10 sin pistas set_2 de Brendan Owen
> **Resolver set_2, el 10x10 sin pistas que nunca se ha resuelto.**
>
> Brendan Owen publicó un par de 10x10 generados sin pistas con sus estadísticas. Uno (set_1) cayó; el otro (set_2) nunca se ha resuelto y sigue siendo el próximo peldaño acordado por la comunidad por debajo del 16x16 completo.
**Muro.** La misma dificultad de emparejar aristas que el puzle completo, a un
tamaño que una sola máquina sí puede terminar. Set_1 exigió una búsqueda amplia
pero acotada, así que set_2 es un objetivo de ingeniería de búsqueda, no uno
estructural.
**Probado, y dónde se detuvo.** La historia completa está en la página de
[benchmarks](/es/research/build/benchmarks/#los-1010-de-brendan-uno-cayó-el-otro-sigue-en-pie):
set_1 se resolvió, las estadísticas de set_2 se conocen, y
[sigue en pie](/es/research/build/benchmarks/#los-1010-de-brendan-uno-cayó-el-otro-sigue-en-pie).
**Etiqueta.** Accesible para principiantes. Es el único objetivo abierto
dimensionado para una máquina personal y un backtracker bien afinado en lugar de
un clúster de cálculo, así que es el primer intento real recomendado.
## Cruzar una cuenca de rigidez
> **¿Existe algún camino local de una cuenca record a otra?**
>
> Cada tablero record vive en una cuenca que las pruebas MIP muestran localmente óptima hasta un halo de varias celdas. La pregunta abierta es si alguna secuencia de pequeños movimientos legales alcanza otra cuenca en absoluto.
**Muro.** [Rigidez](/es/research/why/rigidity-wall/) en su forma más nítida, y
[por qué saltar de cuenca parece imposible](/es/research/why/sigma-cycles/): el paso de
un gran tablero a uno mejor es un único intercambio gigante e indivisible, sin
gradiente que seguir.
**Probado, y dónde se detuvo.** El teorema de rigidez registra pruebas MIP de
optimalidad de halo en varias cuencas, y la búsqueda de una cadena corta de escape
entre cuencas falló por una razón estructural expuesta en
[por qué saltar de cuenca parece imposible](/es/research/why/sigma-cycles/). La entrada
[recombinar dos buenos tableros](/es/research/build/dead-ends/) es el mismo muro visto
desde el lado del cruce.
**Etiqueta.** Difícil, bien cartografiado. Un solo movimiento de cruce, o una prueba
de que ninguno existe, cambiaría cómo se juzga todo método de búsqueda local.
## El muro de memoria del meet-in-the-middle
> **¿Pueden las dos mitades de una búsqueda meet-in-the-middle encontrarse a tamaño real?**
>
> Hacer que dos búsquedas parciales se encuentren en el medio es completo en principio, pero el número de tableros parciales a almacenar crece unas veinte veces por cada error de emparejamiento adicional tolerado, así que las mitades dejan de encontrarse mucho antes del 16x16 completo.
**Muro.** El coste de la exactitud medido directamente: el enfoque
[meet-in-the-middle](/es/research/build/exact/meet-in-the-middle/) es exacto, pero su
memoria supera lo que cualquier máquina puede contener.
**Probado, y dónde se detuvo.** BANDSAW resolvió una banda de final de partida a
optimalidad probada y, al hacerlo, midió el crecimiento de unas veinte veces por
error en ambos lados, así que encontrarse en el medio deja de compensar a tamaño
real; ese resultado es la [fila BANDSAW](/es/research/why/walls-and-methods/) del mapa.
Una mejor representación, o un encuentro con pérdida que siga siendo correcto, es
la palanca abierta.
**Etiqueta.** Difícil, bien cartografiado. El muro aquí está cuantificado, así que
el progreso es medible: cualquier codificación que baje el factor de crecimiento
por error es una ganancia real, incluso sin una resolución completa.
## Un eje de diversidad más allá del parallel tempering
> **¿Existe un mecanismo de búsqueda que encuentre cuencas nuevas de forma fiable, más allá del parallel tempering?**
>
> Casi todo método redescubre el mismo puñado de cuencas. En un barrido completo de métodos, solo el parallel tempering produjo de forma fiable cuencas genuinamente nuevas, y aun él se estanca pronto.
**Muro.** [Rigidez](/es/research/why/rigidity-wall/) vista como un cuello de botella de
diversidad: la restricción no es la puntuación que un método alcanza, sino el
número de cuencas distintas que sabe encontrar, y el arsenal estándar encuentra
demasiado pocas.
**Probado, y dónde se detuvo.** El estudio de diversidad está escrito en el
[mapa de muros y métodos](/es/research/why/walls-and-methods/): la búsqueda local
adaptativa, la colocación en serpiente y la parte alta de la distribución de un
generador entrenado recaen todas en las cuencas conocidas, y solo el parallel
tempering escapa de forma fiable. [Generar tableros con un transformador](/es/research/build/dead-ends/)
es uno de los intentos de diversidad que no se sostuvieron.
**Etiqueta.** Sin atender, y abierto. A diferencia de los objetivos cartografiados
de arriba, este no tiene una lista de ataques trazada esperando a ser batida: un
mecanismo de diversidad realmente nuevo es una idea que nadie ha plantado todavía,
lo que lo convierte en la entrada más especulativa y la menos restringida por el
trabajo previo.
## ¿Es la rigidez local una consecuencia del colapso de distinción de la ley de área?
> **¿Los tableros record se congelan porque los parciales distintos colapsan, o es una coincidencia de escala?**
>
> Los movimientos más pequeños que separan los mejores tableros conocidos y la escala a la que colapsan los tableros parciales realmente distintos son ambos un parche de unos cientos de celdas. La pregunta abierta es si eso es un vínculo causal, la rigidez derivada de la ley de área, o dos hechos independientes que por casualidad comparten una escala de longitud.
**Muro.** [Rigidez](/es/research/why/rigidity-wall/) y
[la ley de área](/es/research/why/entropy-area-law/). La rigidez se establece de
forma independiente, por pruebas MIP de optimalidad de halo y un halo SAT
depositado; la ley de área es una estimación de distinción. Reducir una a la otra
las ataría, pero nada en el sitio lo deriva.
**Probado, y dónde se detuvo.** La [página de la ley de área](/es/research/why/entropy-area-law/)
observa la escala compartida y enlaza a
[por qué el salto de cuenca parece imposible](/es/research/why/sigma-cycles/); no
afirma que la rigidez esté causada por el colapso. El resultado de rigidez es
exacto y región por región, y se sostiene solo sin invocar la ley de área.
Ninguna página afirma el puente causal, que es justo por lo que figura aquí como
pregunta.
**Etiqueta.** Difícil, bien cartografiado. Ambos extremos están entre los muros
más estudiados de la sección; la parte abierta es la arista entre ellos, y
cerrarla en cualquier sentido replantearía cómo se leen los dos muros.
## ¿Produce el pico de dificultad el perfil de ramificación de sin movimientos forzados?
> **¿El alto factor de ramificación viene impuesto por situarse en el pico de una solución?**
>
> Cada celda interior conserva de 73 a 137 piezas legales, y el puzzle se sitúa en la transición de fase de alrededor de una solución esperada. Ambos se agrupan como «nada local que podar», pero ninguna derivación ata el conteo de ramificación a situarse en unos 17 colores interiores.
**Muro.** [Sin movimientos forzados](/es/research/why/no-forced-moves/) y
[el pico de dificultad](/es/research/why/phase-transition/). El conteo de
ramificación es un conteo de candidatos por celda sobre el conjunto de piezas; el
pico es un enunciado sobre el número de soluciones a 17 colores. Un puzzle podría
en principio tener uno sin el otro.
**Probado, y dónde se detuvo.** [Poda contra velocidad](/es/research/why/prune-vs-speed/)
y el [mapa muro-método](/es/research/why/walls-and-methods/) agrupan ambos muros bajo
el mismo tema, que no hay nada local que podar, lo cual es una unión temática y no
una afirmación causal. Ninguna página deriva el perfil de ramificación del conteo
de colores.
**Etiqueta.** Difícil, bien cartografiado. Los dos muros están medidos con
exactitud cada uno; la pieza que falta es la derivación que los conecta, la cual
convertiría un tema compartido en un mecanismo.
## ¿Limita la geometría de los sigma-ciclos la búsqueda constructiva, no solo la reparación local?
> **¿Es el muro de los sigma-ciclos la razón de que los productores beam y DFS también saturen, o solo la búsqueda local?**
>
> El movimiento entre dos tableros record es un ciclo indivisible de muchas celdas, y cada prefijo propio puntúa menos; eso muestra por qué la reparación local no puede cruzar entre cuencas. La pregunta abierta es si la misma geometría limita a los productores DFS y beam constructivos, que saturan entre 458 y 463 por razones calculadas solo entre tableros terminados, no dentro del árbol de búsqueda.
**Muro.** [Sigma-ciclos](/es/research/why/sigma-cycles/) y
[rigidez](/es/research/why/rigidity-wall/), vistos en el eje de diversidad. El
resultado de los sigma-ciclos es un enunciado exacto sobre cada par de tableros
incluidos, pero se calcula entre tableros record terminados, no sobre el árbol de
búsqueda constructivo que los produce.
**Probado, y dónde se detuvo.** El [mapa muro-método](/es/research/why/walls-and-methods/)
documenta que los productores desde cero y beam saturan como los demás, y la
encuesta de diversidad halló que el arsenal estándar redescubre una y otra vez
las mismas cuencas. Extender el mecanismo de los sigma-ciclos para explicar ese
techo constructivo, en lugar de solo el de la reparación local, no está probado y
no se afirma en ninguna parte del sitio.
**Etiqueta.** Difícil, bien cartografiado, y cercano a la pregunta de diversidad
de arriba: una prueba de que la misma geometría de ciclo gobierna la saturación
constructiva unificaría dos techos observados de forma independiente.
## De dónde salieron, y dónde escribir uno
Cada afirmación de arriba se apoya en una página ya presente en este wiki: los
muros en [por qué es difícil](/es/research/why/), los intentos detenidos en el
[mapa de muros y métodos](/es/research/why/walls-and-methods/) y los
[callejones sin salida](/es/research/build/dead-ends/), los objetivos de referencia en
la página de [benchmarks](/es/research/build/benchmarks/). Si tomas uno de ellos y se
mueve, [el cuaderno está abierto](/es/research/contribute/) y hay un lugar para el informe.
## Relacionado
- [Récords y solucionadores](https://eternity2.dev/es/research/records/) — Eternity II nunca se ha resuelto, pero casi dos décadas de esfuerzo colectivo han llevado el mejor tablero a 470/480. Quién ostenta qué, cómo lo lograron y por qué algunos tableros «480» anunciados no corresponden al puzzle real.
- [Qué muro detiene a qué método](https://eternity2.dev/es/research/why/walls-and-methods/) — La sección de investigación tiene dos vertientes: los muros estructurales que hacen difícil a Eternity II, y los algoritmos concebidos para franquearlos. Esta página es el puente: cada método enfrentado al muro que realmente ataca, y la puntuación en la que ese muro lo detuvo.
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [Callejones sin salida](https://eternity2.dev/es/research/build/dead-ends/) — Enfoques que probamos que parecen prometedores y no mueven la aguja en Eternity II, documentados con lo que encontramos para que inviertas tu tiempo en otra parte.
- [Los benchmarks de la comunidad](https://eternity2.dev/es/research/build/benchmarks/) — Cómo una comunidad a la que se le prohibió compartir las piezas construyó aun así una cultura de pruebas compartida: protocolos de verificación por conteos derivados, las suites Txibilis y para principiantes, duelos al número de nodos, enumeraciones completas y el único benchmark que sigue abierto hoy.
- [Encuentro en el medio](https://eternity2.dev/es/research/build/exact/meet-in-the-middle/) — Enumerar dos mitades de un problema y unirlas en una interfaz compartida, intercambiando memoria por un exponente reducido a la mitad. El truco clásico de Horowitz–Sahni, qué aspecto tiene sobre bandas del tablero, y qué midió el experimento BANDSAW de este proyecto, incluido el método unilateral que lo superó.
- [Contribuye con tus investigaciones](https://eternity2.dev/es/research/contribute/) — Este wiki es el hogar de investigación de la comunidad, y hay sitio en él para tu trabajo. Tres formas de publicarlo, desde un mensaje en la lista de correo hasta una pull request, más el pequeño conjunto de reglas de la casa que mantiene cada página digna de confianza.
---
# Artículos
> La literatura académica sobre Eternity II y los puzzles de emparejamiento de aristas, extraída de las notas de investigación del proyecto y de la lista de lecturas de la comunidad, y ordenada según lo útil que resulta realmente cada artículo si tu objetivo es escribir un solucionador.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/papers/
- Actualizado: 2026-07-15
- Temas: exact-methods, search-space
---
En resumen: los resultados de complejidad explican por qué el problema es
difícil, los artículos SAT/CSP muestran por qué los solucionadores genéricos
chocan contra un muro, y son los artículos sobre propagación de restricciones y
grandes vecindarios cuyas ideas reaparecen en los solucionadores más potentes.
> **[Interactive: PapersView]** Rendered on the canonical page (link above); not shown in this markdown export.
---
# Quién es quién en la investigación de E2
> Dos décadas de investigación sobre Eternity II fueron obra de personas concretas, en una lista de correo. Esta página es la galería: quiénes son, qué aportó cada una y dónde leerlo en sus propias palabras. Un agradecimiento tanto como un índice.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/people/
- Actualizado: 2026-07-02
- Fuente: Brendan Owen deriva el diseño 17+5 como el puzzle más difícil posible (mensaje groups.io 1947) — https://groups.io/g/eternity2/message/1947
- Fuente: El relato en primera persona de Louis Verhaard sobre el 467: «fue mi programa el que hizo el trabajo» (mensaje groups.io 6891) — https://groups.io/g/eternity2/message/6891
- Fuente: Peter McGavin resuelve el benchmark 10×10 de Brendan Owen (mensaje groups.io 9686) — https://groups.io/g/eternity2/message/9686
- Fuente: El 470 de Joshua Blackwood, el récord vigente (mensaje groups.io 10117) — https://groups.io/g/eternity2/message/10117
- Fuente: Al Hopfer enuncia el equilibrio de borde NS-1 (mensaje groups.io 10754) — https://groups.io/g/eternity2/message/10754
- Fuente: Brendan Owen regresa a la lista tras catorce años (mensaje groups.io 11500) — https://groups.io/g/eternity2/message/11500
---
Las [páginas de historia](/es/research/community/hunt/) cuentan la aventura de la
comunidad en orden cronológico; esta página la cuenta por persona. Casi todo lo
que este wiki sabe (cada récord, cada teoría, cada herramienta y cada
[callejón sin salida documentado](/es/research/build/dead-ends/)) se remonta a
alguien que lo publicó en la
[lista de correo eternity2](https://groups.io/g/eternity2), casi siempre de
forma gratuita, a menudo durante años. Considera esta galería un índice y un
agradecimiento a la vez. Los nombres aparecen tal como cada cual firmaba sus
mensajes públicos; cada afirmación enlaza a un mensaje.
Muchas de las personas de abajo tienen su propia página de contribuidor: un
nombre en **negrita con enlace** la abre, reuniendo su perfil, sus mensajes con
fuente y todas las páginas que hayan escrito aquí.
[Raphaël Anjou](/es/research/people/raphael-anjou/), que mantiene el wiki y dirige
los experimentos del laboratorio, tiene la suya también, un investigador más
entre los demás. Los nombres sin enlace están documentados directamente aquí,
en esta página.
## Los fundadores y los analistas del lanzamiento (2000–2007)
### [Brendan Owen](/es/research/people/brendan-owen/)
El fundador. Owen creó el grupo eternity_two en octubre de 2000, seis años y
medio antes de que el puzzle existiera
([msg 384](https://groups.io/g/eternity2/message/384)), y le dio su tono
científico: en los dos días siguientes al anuncio de enero de 2007 ya había
derivado la fórmula del número esperado de soluciones que convierte la
dificultad en un parámetro de diseño
([msg 38](https://groups.io/g/eternity2/message/38)), y el fin de semana del
lanzamiento digitalizó las piezas reales y publicó la primera estimación del
número de soluciones ([msg 987](https://groups.io/g/eternity2/message/987)).
Sus resultados emblemáticos: la prueba de que un reparto de colores 17+5 es el
16×16 más difícil posible
([msg 1947](https://groups.io/g/eternity2/message/1947)), el modelo exacto del
árbol de búsqueda que hoy se llama
[teoría compleja](/es/research/why/complex-theory/)
([msg 5197](https://groups.io/g/eternity2/message/5197),
[msg 5209](https://groups.io/g/eternity2/message/5209)), los
[puzzles de referencia](/es/research/build/benchmarks/) 9×9/10×10 en los que la
comunidad todavía compite, y la prueba en forma cerrada de la profundidad de
pico 256 × (1 − 1/e)
([msg 8125](https://groups.io/g/eternity2/message/8125)). Tras una despedida al
cierre del concurso
([msg 8429](https://groups.io/g/eternity2/message/8429)), regresó en 2025,
afinando su propio modelo
([msg 11500](https://groups.io/g/eternity2/message/11500),
[msg 11546](https://groups.io/g/eternity2/message/11546)).
### [Günter Stertenbrink](/es/research/people/gunter-stertenbrink/)
Un veterano de Eternity I y el primero en provocar las estimaciones del grupo:
en 2001 preguntó, años antes de los hechos, cómo se diseñaría un puzzle dotado
de un premio colosal y con solo un ~1 % de probabilidades de ser resuelto en
diez años ([msg 15](https://groups.io/g/eternity2/message/15)), y recibió las
afirmaciones de prensa de 2005 con «So we can conclude, the end of the universe
is in several years.» ([msg 34](https://groups.io/g/eternity2/message/34)).
Durante dos décadas verificó los números de la lista, desde las conversiones a
cobertura exacta de 2007 hasta el registro de hardware de «nodos por vatio» de
la década de 2010.
### [Dave Clark](/es/research/people/dave-clark/)
Autor del solucionador distribuido ESolve para Eternity I, se reincorporó en
2001 ([msg 21](https://groups.io/g/eternity2/message/21)) y construyó
eternity2.net, el proyecto BOINC que fue el rostro público de la comunidad en
2007 ([msg 756](https://groups.io/g/eternity2/message/756)). Lo cerró con una
contabilidad completa: 1,6 TFlops, más de 10^19 operaciones, ninguna solución
([msg 3511](https://groups.io/g/eternity2/message/3511)). Liberó el código de
su solucionador ([msg 3716](https://groups.io/g/eternity2/message/3716)) y dejó
a los archivos su mejor fuente primaria sobre la creación del puzzle: su
conversación telefónica con Monckton, describiendo cómo se generó la solución y
se guardó bajo llave ([msg 4177](https://groups.io/g/eternity2/message/4177)).
### Txibilis
Angel de Vicente, que firmaba Txibilis, construyó la suite estándar de tableros
de referencia de tipo E2
([msg 1886](https://groups.io/g/eternity2/message/1886)) y era el mejor
diseñador manual de [órdenes de relleno](/es/research/build/backtracking/fill-order/)
de la comunidad. Su duelo con el optimizador automatizado de doc_s_smith hizo
caer los recuentos de nodos de la búsqueda exhaustiva en varios órdenes de
magnitud ([msg 2928](https://groups.io/g/eternity2/message/2928)). La cultura
del benchmark que más tarde validó la teoría compleja comienza con él.
### doc_s_smith
En pleno duelo, la lista descubrió quién era doc_s_smith: Dietmar Wolz, el
descubridor de la mayoría de las soluciones conocidas de Eternity I
([msg 2972](https://groups.io/g/eternity2/message/2972)). Su optimizador de
estrategia automatizado estableció récords de benchmark en 2007
([msg 2896](https://groups.io/g/eternity2/message/2896)); de vuelta en 2010,
publicó una caja de herramientas Java que convirtió la lista en un taller de
algoritmos ([msg 7755](https://groups.io/g/eternity2/message/7755)) y dio a la
era del posconcurso su objetivo de trabajo: «beat 468 matching edges»
([msg 7803](https://groups.io/g/eternity2/message/7803)).
### kubzpa
Autor del primer artículo serio sobre el recuento de soluciones, que situaba a
E2 en cerca de 15 millones de soluciones
([msg 3497](https://groups.io/g/eternity2/message/3497)), y del resultado de
imposibilidad más pulcro de la época: el argumento de paridad que muestra que
ningún tablero puede puntuar exactamente 479 por sus costuras interiores
([msg 1640](https://groups.io/g/eternity2/message/1640)). Se sostuvo diecisiete
meses, hasta que Verhaard señaló el único resquicio
([msg 6317](https://groups.io/g/eternity2/message/6317)): dar la vuelta a una
pieza de borde cuyas dos aristas de borde exteriores comparten un color, y el
tablero se lee como un 479 mientras esas aristas de borde no puntuadas quedan
intactas. Es un tecnicismo del borde no puntuado, no una brecha en el cálculo
de paridad interior, que sigue en pie, como el propio Verhaard señaló: 479
«cannot be achieved in another way»
([msg 6319](https://groups.io/g/eternity2/message/6319)).
### mjqxxxx
Michael Quist era el árbitro matemático de la lista. Publicó el primer marco de
recuento plenamente riguroso para los puzzles de tipo E2
([msg 1221](https://groups.io/g/eternity2/message/1221)), afinó la teoría del
equilibrio de borde
([msg 2098](https://groups.io/g/eternity2/message/2098)), y sus revisiones
detectaron los fallos que hicieron sólidos los resultados de los demás. Kubzpa
enmendó su artículo sobre el recuento de soluciones después de que su revisión
detectara una ejecución Monte Carlo defectuosa
([msg 3589](https://groups.io/g/eternity2/message/3589)).
## Los años del premio (2007–2010)
### [Louis Verhaard](/es/research/people/louis-verhaard/)
La única persona a la que el puzzle pagó jamás. Su solucionador eii, hecho
público «because I am stuck»
([msg 5940](https://groups.io/g/eternity2/message/5940)), encontró el 467 que
ganó el premio de escrutinio de 10 000 $, inscrito bajo el nombre de su esposa,
Anna Karlsson, como él mismo confirmó: «Anna is my wife… it was my program that
did the job» ([msg 6349](https://groups.io/g/eternity2/message/6349),
[msg 6891](https://groups.io/g/eternity2/message/6891),
[msg 7451](https://groups.io/g/eternity2/message/7451)). Sus métodos se
volvieron canónicos: los órdenes de relleno en peine (comb-search)
([msg 6112](https://groups.io/g/eternity2/message/6112)) y el deslizamiento de
aristas controlado por la profundidad
([msg 7321](https://groups.io/g/eternity2/message/7321)). Fue también el
defensor más acérrimo de la teoría compleja: «the finest work that has ever
been published about E2»
([msg 7810](https://groups.io/g/eternity2/message/7810)), y su 467 se sostuvo
doce años.
### Yannick Kirschhoffer
Autor del Eternity II Editor, el editor y la interfaz de solucionador Java
multiplataforma publicados en febrero de 2008
([msg 4544](https://groups.io/g/eternity2/message/4544)) que se convirtió en la
herramienta de tablero estándar de la comunidad durante años. Todavía ofrecía
ayuda con su código cuando este resurgió en 2012
([msg 9064](https://groups.io/g/eternity2/message/9064)).
### Fred
Firmando como Eternity Blogger, Fred construyó E2Lab en una ráfaga de
publicaciones casi diarias en el otoño de 2009
([msg 7148](https://groups.io/g/eternity2/message/7148)), un editor/solucionador
cuya retirada deliberada de su propio «botón mágico», «to respect the game
rules», dice mucho sobre la ética de la lista
([msg 7150](https://groups.io/g/eternity2/message/7150)). Su blog alojó las
tablas de la comunidad durante los años del posconcurso.
### [Al Hopfer](/es/research/people/al-hopfer/)
Un habitual desde 2008 y el teórico del borde de la comunidad. Su «doctrina del
equilibrio» para la generación de puzzles aparece en 2009
([msg 6842](https://groups.io/g/eternity2/message/6842),
[msg 6844](https://groups.io/g/eternity2/message/6844)); en 2022 enunció la
condición exacta que este wiki llama el
[equilibrio de borde NS-1](/es/research/why/border-balance/)
([msg 10754](https://groups.io/g/eternity2/message/10754),
[msg 10757](https://groups.io/g/eternity2/message/10757)), y la respaldó con un
parcial de 222 piezas con el borde completado, enteramente documentado
([msg 10862](https://groups.io/g/eternity2/message/10862)).
## La larga década (2010–2019)
### [Peter McGavin](/es/research/people/peter-mcgavin/)
El pilar de la época, y posiblemente el investigador más determinante del
puzzle después de Owen. Su trabajo tiene [su propia página](/es/research/lab/experiments/peter-mcgavin/backtracker/).
Calculó el número canónico de aproximadamente 14 702 soluciones esperadas
([msg 8924](https://groups.io/g/eternity2/message/8924)), transcribió la teoría
compleja a LaTeX ([msg 9188](https://groups.io/g/eternity2/message/9188)) y más
tarde a código C exacto
([msg 11197](https://groups.io/g/eternity2/message/11197)), que este sitio
adapta. En 2017 resolvió el 10×10 sin pistas de Owen en unos 180 años-núcleo,
dentro de las barras de error de la teoría, su validación más fuerte hasta la
fecha ([msg 9686](https://groups.io/g/eternity2/message/9686),
[msg 9688](https://groups.io/g/eternity2/message/9688)), y en 2020 ostentó el
récord él mismo: «New record score of 469! Only 11 breaks!»
([msg 10045](https://groups.io/g/eternity2/message/10045)).
### Tony Wauters
La academia en persona. Publicó el artículo hiperheurístico de su equipo,
revisado por pares (461/480 en una hora), y se quedó a responder preguntas
([msg 9017](https://groups.io/g/eternity2/message/9017),
[msg 9023](https://groups.io/g/eternity2/message/9023)), y su equipo continuó
con los trabajos de MILP y Max-Clique de 2017
([msg 9683](https://groups.io/g/eternity2/message/9683)).
### Michael Field
Un veterano de los solucionadores más rápidos de los primeros años, convertido
en el realista del hardware del grupo: su diseño de backtracker sobre FPGA
proyectaba unos 5 G emplazamientos por segundo y por chip
([msg 9226](https://groups.io/g/eternity2/message/9226)), y sus análisis de
capacidad de las vías GPU y FPGA le dijeron a la lista qué podía y qué no podía
comprar el silicio ([msg 9003](https://groups.io/g/eternity2/message/9003)).
### Arnaud Carré
Llegó en 2009 y redefinió el estándar de velocidad en 2014 con un solucionador
mononúcleo de 114,5 millones de recursiones por segundo, ofrecido como
referencia de comparación
([msg 9233](https://groups.io/g/eternity2/message/9233)), y regresó en 2018
para las carreras de benchmark.
### Adam Miles
El flanco GPU. Al llegar en 2017, pasó de los trucos de bits en CPU a un
solucionador de cómputo DirectX 12 que corría en una Xbox One X
([msg 9811](https://groups.io/g/eternity2/message/9811)) y volvió a verificar
de forma exhaustiva en GPU el conjunto 9×9 número 1 de Owen: las mismas 2
soluciones que el censo de CPU de 2014, en 25,4 horas
([msg 9822](https://groups.io/g/eternity2/message/9822)).
### JSA
El verificador de la comunidad y, más tarde, su salvador. En 2009 reprodujo el
467 con el solucionador público de Verhaard, unos 82 días en un solo PC,
registrando con precisión cuánto se enrarece el aire por encima de 466
([msg 6687](https://groups.io/g/eternity2/message/6687)). Cuando Yahoo anunció
que borraría los archivos en 2019, JSA pagó la tarifa de transferencia a
groups.io, ofreciendo «I can pay for the first 5 years»
([msg 2](https://groups.io/g/eternity2/message/2)), y aún redacta los mensajes
de bienvenida del grupo
([msg 11771](https://groups.io/g/eternity2/message/11771)).
### Ole Knudsen
Kronjuvel (Kron) estuvo ahí desde los primerísimos años, reivindicó a
posteriori un parcial de 231 piezas de octubre de 2007
([msg 7563](https://groups.io/g/eternity2/message/7563)) y, como propietario
del grupo, creó el nuevo hogar en groups.io durante la migración de 2019. El
mensaje de bienvenida de 2026 se abre con un homenaje a él; ha desaparecido de
la lista desde 2023
([msg 11771](https://groups.io/g/eternity2/message/11771)).
## La ola de récords y la era moderna (2019–2026)
### [Joshua Blackwood](/es/research/people/joshua-blackwood/)
El desconocido que puso fin al congelamiento de doce años. Ignorado por la
lista, anunció un 468 en Reddit en agosto de 2020
([msg 10032](https://groups.io/g/eternity2/message/10032)), liberó el código de
su solucionador días después
([msg 10037](https://groups.io/g/eternity2/message/10037)) junto con raros
resultados negativos (SAT, GPU y cachés 2×2 todos medidos y descartados,
[msg 10056](https://groups.io/g/eternity2/message/10056)), y en marzo de 2021
publicó el 470 que aún se mantiene
([msg 10117](https://groups.io/g/eternity2/message/10117)), hallado con el
código público exacto
([msg 10161](https://groups.io/g/eternity2/message/10161)). Su algoritmo está
[decodificado en este wiki](/es/research/lab/experiments/joshua-blackwood/solver/).
### [Jef Bucas](/es/research/people/jef-bucas/)
La infraestructura de la era moderna. Dio la alarma que desencadenó la
migración de los archivos
([msg 9920](https://groups.io/g/eternity2/message/9920)), construyó el
visualizador de tableros [e2.bucas.name](https://e2.bucas.name) que se
convirtió en el libro de récords de la comunidad
([msg 9955](https://groups.io/g/eternity2/message/9955)), reescribió el
solucionador de Blackwood en C bajo el nombre de libblackwood, duplicando
grosso modo su velocidad y alimentando la ola de 469 de noviembre de 2020
([msg 10065](https://groups.io/g/eternity2/message/10065),
[msg 10078](https://groups.io/g/eternity2/message/10078),
[msg 10067](https://groups.io/g/eternity2/message/10067)), e igualó el 470 en
2024 ([msg 11401](https://groups.io/g/eternity2/message/11401)), acreditando
siempre a Blackwood. Su estudio de parámetros wrapper_blackwood se republica
[en este wiki](/es/research/lab/experiments/joshua-blackwood/solver/) con su
permiso ([msg 11905](https://groups.io/g/eternity2/message/11905)).
### Carlos Fernandez
El cirujano de tableros. Produjo un 469 mediante el intercambio de una sola
pieza del tablero récord de McGavin
([msg 10074](https://groups.io/g/eternity2/message/10074)), una variante 470 de
borde reorganizado ([msg 11403](https://groups.io/g/eternity2/message/11403)),
resoluciones de cuadrante 14×14 en cuatro minutos
([msg 10802](https://groups.io/g/eternity2/message/10802)) y peldaños altos de
la escalera de las cinco pistas
([msg 11068](https://groups.io/g/eternity2/message/11068)).
### Bruno Gauthier
Un veterano de la velocidad de la época de 2014, cuyo solucionador en Forth
corría a 80–90 millones de nodos por segundo
([msg 9265](https://groups.io/g/eternity2/message/9265)), ostentó el récord más
estricto de los anales durante más de tres años: 460/480 con las cinco piezas
de pista en sus posiciones oficiales, desde 2023
([msg 11074](https://groups.io/g/eternity2/message/11074)) hasta el 464 de
Benjamin Riotte en julio de 2026.
### Benjamin Riotte
Poseedor del récord estricto de las cinco pistas. En julio de 2026 llevó el
mejor tablero que respeta los cinco emplazamientos de pistas desde el 460 de
larga data de Gauthier hasta **464/480** (16 aristas rotas), con su propio DFS
Blackwood modificado
([groups.io](https://groups.io/g/eternity2/message/11919)). Igor Pejic alcanzó
el mismo rango 463–464 de forma independiente en el mismo hilo. Fue el primer
movimiento en la línea estrictamente canónica en más de tres años.
### [Marijn Heule](/es/research/people/marijn-heule/)
El punto de contacto del mundo SAT. En el hilo SAT de largo recorrido, un
colaborador de Marijn Heule informó de que el equipo de Heule había
reimplementado y mejorado la codificación tras los resultados de benchmark SAT
de 2008 ([msg 10969](https://groups.io/g/eternity2/message/10969)), el estado
del arte del flanco de los métodos exactos, que aún debatía codificaciones CNF
de 4 GB el último día de los archivos
([msg 11822](https://groups.io/g/eternity2/message/11822)).
### [Raphaël Anjou](/es/research/people/raphael-anjou/)
Mantiene este wiki y dirige los experimentos catalogados en
[el laboratorio](/es/research/lab/); sus informes se reúnen en su
[página de contribuidor](/es/research/people/raphael-anjou/), un investigador más
entre los demás.
### [William Millilaw](/es/research/people/william-millilaw/)
Llevó a cabo una densa campaña de solucionador de dos semanas en 2026,
registrada en su mayor parte como refutaciones de métodos que no descifran el
puzzle. Dos de sus resultados afinan el techo: una prueba de congelación por
réplica y una prueba de residuo SAT en halo que muestra que los tableros récord
son óptimos locales estrictos. Reprodujimos la segunda sobre los tableros
públicos, y aterriza en el [muro de rigidez](/es/research/why/rigidity-wall/) junto
a las pruebas de programación entera
([reproducción](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/rigidity-sat-halo)).
### onesmallstep
Fundó el servidor de Discord de la comunidad en noviembre de 2021 y lo mantuvo
con vida durante los años tranquilos (reportado en el Discord de la comunidad,
noviembre de 2021; sin enlace a mensaje público). Solucionador dedicado por
derecho propio (mejor puntuación autodeclarada en torno a 466–467), es también
la razón por la que el wiki en su día arrastró por error un «470 de 2025»: un
*relevo* de récord malinterpretado como una *reivindicación* de récord,
corregido aquí a partir del propio archivo de Discord.
### Reinout Annaert
El cazador metódico de la era Discord: una mejor puntuación autodeclarada de
469, la subcultura de las series lineales (parciales consecutivos de 229 y 230
piezas) y el hombre que zanjó de dónde vienen los emplazamientos de las pistas:
«They directly come from Tomy's Hint Puzzles» (reportado en el Discord de la
comunidad, diciembre de 2024; sin enlace a mensaje público). En la lista de
correo confirma que conserva figuras de soluciones que puntúan por encima de
467/480 ([msg 11549](https://groups.io/g/eternity2/message/11549)). Sus
sugerencias también moldearon la hoja de ruta del área de juego de este sitio.
## Y muchos más
Ninguna galería de este tamaño está completa. Entre los muchos que aquí tienen
su lugar: Alan O'Donnell, que tuvo el primer solucionador funcional pocas
semanas después del anuncio
([msg 64](https://groups.io/g/eternity2/message/64)); Max, el compañero de
entrenamiento de Verhaard en la carrera hacia el 467, cuyo propio mejor fue 465
([msg 6348](https://groups.io/g/eternity2/message/6348)); istarinz, que superó
los 558 millones de emplazamientos por segundo en 2008 y se convirtió en la
autoridad del grupo en verificación por búsqueda exhaustiva
([msg 6212](https://groups.io/g/eternity2/message/6212)); antminder, cuyo
híbrido de asignación-reparación promediaba un 462 al día en 2008
([msg 5589](https://groups.io/g/eternity2/message/5589)); Pierre Schaus, cuyo
artículo de programación por restricciones aportó ese operador de reparación
([msg 5601](https://groups.io/g/eternity2/message/5601)); capiman26061973,
fundador de la escalera de las cinco pistas
([msg 11037](https://groups.io/g/eternity2/message/11037)) y del programa de
minería de combinaciones inválidas
([msg 7768](https://groups.io/g/eternity2/message/7768)); David Barr, autor de
solucionadores GPU y de navegador de código abierto a lo largo de una década
([msg 9367](https://groups.io/g/eternity2/message/9367),
[msg 11121](https://groups.io/g/eternity2/message/11121)); Henk van der
Griendt, que dio con el anuncio del premio que todos los demás habían pasado por
alto ([msg 6337](https://groups.io/g/eternity2/message/6337)); y
juraj.pivovarov, la conciencia del prototipado rápido de la comunidad
([msg 9411](https://groups.io/g/eternity2/message/9411)).
## Correcciones bienvenidas
Esta página siempre estará incompleta, y puede que esté equivocada en algunos
puntos: un resultado mal atribuido, un nombre que falta, una grafía preferida.
Si alguno de ellos te concierne, a ti o a tu trabajo, dilo en la
[lista de correo](https://groups.io/g/eternity2) o a través de la
[página de contribución](/es/research/contribute/): las correcciones llegan con las
mismas reglas de fuentes que todo lo demás aquí, y el crédito es el objeto
mismo de esta página.
## Relacionado
- [La cacería, una historia (parte I: 2000-2009)](https://eternity2.dev/es/research/community/hunt/) — La historia de la comunidad, desde una lista de correo fundada siete años antes de que el puzzle existiera hasta el premio de escrutinio de 10.000 $ ganado bajo un nombre prestado, con cada suceso rastreado hasta su mensaje original. Parte I de una crónica en desarrollo.
- [La cacería, una historia, parte II: 2009-2026](https://eternity2.dev/es/research/community/hunt-part-2/) — Diecisiete años después del premio: el concurso muere con su solución encerrada en una caja fuerte, 467 se mantiene durante una década, el archivo sobrevive al cierre de Yahoo por cuestión de días, y luego un desconocido venido de Reddit reescribe el libro de récords. Cada suceso está vinculado a su mensaje original.
- [Récords y solucionadores](https://eternity2.dev/es/research/records/) — Eternity II nunca se ha resuelto, pero casi dos décadas de esfuerzo colectivo han llevado el mejor tablero a 470/480. Quién ostenta qué, cómo lo lograron y por qué algunos tableros «480» anunciados no corresponden al puzzle real.
---
# Récords y solucionadores
> Eternity II nunca se ha resuelto, pero casi dos décadas de esfuerzo colectivo han llevado el mejor tablero a 470/480. Quién ostenta qué, cómo lo lograron y por qué algunos tableros «480» anunciados no corresponden al puzzle real.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/records/
- Actualizado: 2026-07-22
- Fuente: Archivo de la lista de correo eternity2 (groups.io): los anuncios de récords; se requiere cuenta gratuita para leer — https://groups.io/g/eternity2
- Fuente: Wikipedia: el puzzle Eternity II (el premio de 2 M$, la fecha límite de 2010 y el 467 de Verhaard) — https://en.wikipedia.org/wiki/Eternity_II_puzzle
- Fuente: El relato del propio Louis Verhaard sobre su solucionador de 467 — https://www.shortestpath.se/eii/eii_details.html
- Fuente: e2.bucas.name (Jef Bucas): el visor de tableros de la comunidad; cada tablero enlazado puede volver a puntuarse allí — https://e2.bucas.name
---
Esta página sigue la puntuación: quién ostentaba el mejor tablero en cada
momento, y cómo lo consiguió. Para el relato en torno a las cifras, los puntos
de inflexión que hicieron avanzar el puzzle, consulta la [historia de un
vistazo](/es/research/history/); los métodos más potentes viven en la lista de
correo y en Discord, no en las revistas científicas.
> **[Interactive: RecordsView]** Rendered on the canonical page (link above); not shown in this markdown export.
## Linaje del cuaderno: cómo se alcanzaron las cifras propias del proyecto
Esta sección trata del cuaderno del proyecto, no de la escalera de récords de
la comunidad. Nada de lo que sigue es un récord comunitario: cada marca de las
tablas de arriba (470 en el régimen de «solo pieza de partida», 464 con las
cinco pistas) queda por encima de cada fila de abajo. Estas filas existen para
que las cifras propias del proyecto puedan rastrearse, cada una con su
convención de puntuación explícita. Los métodos están documentados en
[el laboratorio](/es/research/lab/).
| Fecha | Tablero | Puntuación | Convención de puntuación | Cómo |
| --- | --- | --- | --- | --- |
| 2026-07-13 | Tablero del productor, en bruto | 457/480 | Las cinco pistas en sus casillas oficiales; aristas coincidentes sobre 480 | Un productor de búsqueda en haz con un orden de relleno en peine; este es el tablero en bruto, antes de cualquier reparación. |
| 2026-07-13 | El mismo tablero, tras la reparación | 461/480 | Las cinco pistas en sus casillas oficiales; aristas coincidentes sobre 480 | Una pasada de destrucción y reparación elevó el 457 en bruto a 459, luego 460 y luego 461. El propio bucle se estudia en [el estudio de reparación](/es/research/lab/experiments/raphael-anjou/repair-study/). |
| 2026-07 | PALIMPSEST | 463/480 | Solo la pieza de partida; aristas coincidentes sobre 480 | Un prior de colocación extraído del corpus de tableros de la comunidad, más destrucción y reparación dirigidas. Descrito en [PALIMPSEST](/es/research/lab/experiments/raphael-anjou/learning/palimpsest/). |
Las dos convenciones no se comparan entre sí: una puntuación de «solo pieza de
partida» y una de cinco pistas apuntan a objetivos distintos, y por eso cada
fila nombra la suya. Bajo la convención de cinco pistas, lo mejor del proyecto
es 461 frente al 464 de la comunidad; en el régimen de «solo pieza de partida»,
lo mejor es 463 frente al 470 de la comunidad.
## Relacionado
- [Historia: los grandes hitos](https://eternity2.dev/es/research/history/) — La historia de Eternity II de un vistazo, desde la lista de correo fundada en 2000 hasta el récord de 470 que aún se mantiene. Una cronología recorrible de los momentos decisivos, cada uno con enlace a la historia completa en dos partes y al mensaje donde ocurrió.
- [Experimentos](https://eternity2.dev/es/research/lab/experiments/) — Los experimentos de búsqueda con nombre del laboratorio, una sección por investigador. Cada uno es un run real contra Eternity II con su idea, su mejor tablero y las preguntas que dejó abiertas. El cuaderno de Raphaël Anjou está aquí completo; el cuaderno queda abierto a cualquier otra persona.
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
---
# Números de referencia
> Recuentos exactos de cuántas maneras válidas hay de rellenar un bloque pequeño en una posición dada del tablero oficial de Eternity II, bajo reglas cada vez más restrictivas: números fiables para contrastar el código de emparejamiento de aristas y de restricciones de tu solucionador.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/reference/
- Actualizado: 2026-07-11
- Temas: backtracking
- Reproducir: `just research-subgrid`
- Fuente: Recuentos de subcuadrículas publicados por sylvogel (mensaje groups.io 11879) — https://groups.io/g/eternity2/message/11879
- Fuente: Generador Rust reproducible de este proyecto + resultados versionados (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/subgrid-placement-counts
---
¿De cuántas maneras distintas, respetando el emparejamiento de aristas, se puede
rellenar un bloque pequeño del tablero oficial? Estos recuentos son la verdad de
referencia contra la que probar un solucionador: si tu código de emparejamiento
de aristas y de restricciones discrepa con los números de abajo en una esquina
2×2, el error está en tu código, no en la tabla.
Las cifras en redonda están calculadas a partir del juego de piezas oficial por
el generador Rust reproducible de este proyecto (enlazado más abajo), de modo que
cualquiera puede volver a calcularlas. El puñado de cifras en cursiva son
recuentos demasiado grandes para enumerarlos exactamente en segundos (de decenas
de miles de millones a decenas de billones de rellenos); esos son **los valores
publicados por sylvogel**, reproducidos aquí por exhaustividad y acreditados en
las fuentes. Todo lo demás se recalcula aquí desde cero.
> **[Interactive: ReferenceTableView]** Rendered on the canonical page (link above); not shown in this markdown export.
## Relacionado
- [Hechos y cifras establecidos](https://eternity2.dev/es/research/build/known-facts/) — Las cifras que todo investigador de Eternity II acaba redemostrando, reunidas en un solo lugar con su procedencia: la definición del puzzle, la colocación de las pistas, las convenciones de puntuación, la tabla de récords, el tamaño del espacio de búsqueda y los recuentos estructurales.
- [Los benchmarks de la comunidad](https://eternity2.dev/es/research/build/benchmarks/) — Cómo una comunidad a la que se le prohibió compartir las piezas construyó aun así una cultura de pruebas compartida: protocolos de verificación por conteos derivados, las suites Txibilis y para principiantes, duelos al número de nodos, enumeraciones completas y el único benchmark que sigue abierto hoy.
---
# Por qué es difícil
> Eternity II no es difícil por accidente. Fue diseñado para resistir el ingenio, y los muros estructurales medibles (rigidez, entropía, patrones prohibidos) explican por qué ninguna búsqueda, por ingeniosa que sea, ha llegado al final.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/
- Actualizado: 2026-07-21
---
Eternity II no es difícil por accidente. Esta es la ciencia de por qué ninguna
búsqueda, por ingeniosa que sea, ha llegado al final: el diseño del puzzle y los
muros estructurales que aparecen en cuanto empiezas a medir.
> **[Interactive: ScoringPrimer]** Rendered on the canonical page (link above); not shown in this markdown export.
## Por dónde empezar
- **[Qué muro detiene a qué método](/es/research/why/walls-and-methods/)** alinea
cada método frente al muro que ataca y el score donde ese muro lo detuvo. El
mapa de una página, y el lugar para orientarse primero.
- **[El muro de rigidez](/es/research/why/rigidity-wall/)** es el muro contra el que
termina casi todo método: los récords son islas localmente congeladas, sin
gradiente hacia un tablero mejor.
- **[El pico de dificultad](/es/research/why/phase-transition/)** explica por qué los
recuentos de piezas y colores caen justo donde la búsqueda es peor.
- **[Sin movimientos forzados](/es/research/why/no-forced-moves/)** es el muro que se
siente primero: cada celda interior conserva decenas de piezas legales, así que
la búsqueda nunca se estrecha por sí sola.
Si llegaste preguntándote si el tablero es
[NP-completo, y cómo codificarlo](/es/research/why/how-hard-is-this-instance/),
empieza por ahí: el emparejamiento de aristas es NP-completo como familia, pero
una instancia 16×16 fija es una constante, no un problema.
## Diseñado para resistir el ingenio
Eternity I cayó en 2000 porque Alex Selby y Oliver Riordan descubrieron que el
puzzle tenía muchísimas más soluciones de las que su diseñador creía, y dirigieron
su búsqueda hacia las regiones más "densas en soluciones". Para Eternity II, la
editorial contrató a los ganadores: Selby y Riordan ayudaron a diseñar y someter
a pruebas de resistencia el nuevo puzzle para que ningún atajo estadístico de ese
tipo sobreviviera.
Las huellas visibles de esa validación: una única solución diseñada e integrada
en recuentos de colores equilibrados, ninguna pieza con simetría de rotación,
ninguna pieza duplicada, y parámetros de número de piezas y número de colores
situados en el pico empírico de dificultad (confirmado más tarde por Ansótegui et
al.). El puzzle no es difícil por accidente. Fue ajustado para serlo.
Algo que parece una decisión de diseño pero no lo es: el borde utiliza su propio
conjunto de cinco motivos, separado del interior. Esa separación es automática, no
deliberada. Como el reborde exterior es gris uniforme, cada pieza de borde tiene
su arista gris fijada hacia afuera, de modo que sus aristas de color solo se
encuentran con otras aristas de borde (lateralmente) o con el interior (hacia
dentro), y los dos conjuntos nunca se tocan. Los motivos de borde podrían ser
cualesquiera cinco colores, incluso un reetiquetado de los del interior, sin
cambiar en nada el puzzle. Parecen "raros" solo porque hay menos aristas de borde
que colorear, no porque los diseñadores confinaran un recurso escaso al marco para
frustrar a los solucionadores. (Gracias a Vasily V. en la lista de groups.io por
la corrección.)
## Los muros estructurales
Más allá del relato de diseño, el puzzle posee una estructura medible que explica
la brecha entre el mejor tablero conocido (470/480) y una solución completa,
publicada abajo con el cálculo exacto que sustenta cada muro.
Una forma útil de sostener todo esto junto es leer
[un tablero completo como una palabra de código](/es/research/why/permutation-code-wall/):
sus 480 junturas interiores son comprobaciones de tipo paridad, el score es 480
menos el número que falla, y la regla «cada pieza una sola vez» se vuelve un
código de permutación superpuesto a las comprobaciones de color. La lente
renombra el score en vez de añadir un número, pero coloca las dos restricciones
duras en un mismo marco, y el recuento que la sustenta se reproduce exactamente.
En la misma clave algebraica, los
[invariantes de flujo](/es/research/why/flux-invariants/) ponderan cada color de
arista y leen cada pieza como un vector con signo: las costuras interiores se
cancelan, el tablero entero suma cero, y un cuarto de vuelta multiplica el vector
por la unidad imaginaria, de modo que la ley es de rango complejo pleno 22 en el
conjunto oficial y cada uno de sus bits es invisible al conteo de colores.
Algunos de estos muros son el mismo enunciado visto a escalas distintas. El
[robo de pieza](/es/research/why/piece-theft/), donde una pieza escasa gastada pronto
mata de hambre a una celda filas después, es la cara a escala de celda de la
[ley de área](/es/research/why/entropy-area-law/): ambos son la regla «cada pieza una
sola vez», la regla discreta que carga con la dificultad, una sentida como una
sola celda muerta y otra medida como el colapso de los tableros realmente
distintos más allá de un parche de unos cientos de celdas. A la escala de un
relleno entero, el mismo acoplamiento produce
[una región difícil que no se puede diseñar de otro modo](/es/research/why/irreducible-hard-region/):
rellena el tablero en cualquier orden fijo y la dificultad se junta en la banda
que terminas al final, de modo que una descomposición reubica la dureza en vez de
eliminarla. Los
[patrones prohibidos](/es/research/why/forbidden-patterns/) quedan al lado, en otro
eje: cuentan exactamente con qué rapidez los parches pequeños agotan sus
disposiciones legales bajo el mero emparejamiento de colores, mientras que el
colapso de la ley de área es la capa aparte «una sola vez» superpuesta a parches
válidos en color. Ambos son conteos exactos de escasez coherentes, no el mismo
eje, y las páginas los mantienen separados a propósito. Si se sostienen los
vínculos causales más profundos, si la rigidez es en sí una consecuencia del
colapso de distinción con el que comparte una escala de en torno al centenar de celdas, y si
la geometría de los sigma-ciclos es lo que limita la búsqueda constructiva, son
preguntas abiertas del tablero de [problemas abiertos](/es/research/open-problems/),
no afirmaciones hechas aquí.
## Páginas de esta sección
- [Por qué un ordenador más rápido no ayuda](https://eternity2.dev/es/research/why/prune-vs-speed/) — La idea más importante de la búsqueda combinatoria difícil: reducir el espacio que se explora vence, por un margen exponencial, a explorarlo más rápido. Eternity II está diseñado para que apenas puedas reducirlo.
- [Un conjunto de piezas extremo en cada eje medido](https://eternity2.dev/es/research/why/why-e2-is-hard/) — Mida las 256 piezas oficiales sin ningún solucionador a la vista y cada puerta estructural está cerrada: ninguna pieza simétrica por rotación, 5 parejas gemelas entre 32 640 emparejamientos, un tope de 307 sobre 480 si nada gira, presupuestos de color que se emparejan a exactamente 480 sin holgura, y una paleta 17+5 situada en el punto de una-solución-esperada.
- [Qué muro detiene a qué método](https://eternity2.dev/es/research/why/walls-and-methods/) — La sección de investigación tiene dos vertientes: los muros estructurales que hacen difícil a Eternity II, y los algoritmos concebidos para franquearlos. Esta página es el puente: cada método enfrentado al muro que realmente ataca, y la puntuación en la que ese muro lo detuvo.
- [¿Es NP-completa esta instancia y cómo la codifico?](https://eternity2.dev/es/research/why/how-hard-is-this-instance/) — El emparejamiento de aristas es NP-completo como familia, pero eso no dice nada de un tablero 16×16 fijo: una instancia aislada es una constante, no un problema. Lo que sí es cierto es la dureza en el peor caso de la familia y la dureza empírica de esta instancia, y cómo escribir el puzzle para un solucionador SAT, de cobertura exacta o de PLE, con pequeños esbozos detallados. Una medición con tableros plantados pone cifras a la elección de la formulación: un acantilado de resolubilidad que un paradigma de búsqueda golpea y otro cruza, y que se mueve con el número de colores.
- [La teoría compleja: contar el árbol de búsqueda antes de recorrerlo](https://eternity2.dev/es/research/why/complex-theory/) — La teoría compleja de Brendan Owen estima la anchura del árbol de búsqueda a cada profundidad, e incluso cuántas soluciones existen en total. Muchos en la comunidad la consideran lo más importante que hay que entender sobre Eternity II.
- [Por qué 479 es imposible](https://eternity2.dev/es/research/why/parity-defect-floor/) — Un argumento de conteo sobre el juego de piezas oficial prohíbe una puntuación de exactamente 479/480: las semiaristas de cada color vienen en cantidades pares, y una sola unión rota dejaría dos cuentas impares. El suelo bajo lo perfecto es 478, y a lo sumo 76 cuasi-soluciones a un movimiento pueden rodear una solución.
- [Calibrado en el pico de dificultad](https://eternity2.dev/es/research/why/phase-transition/) — Eternity II utiliza 22 colores, repartidos entre 17 colores interiores y 5 reservados al marco, y ese número de alrededor de 17 se sitúa cerca del punto donde este tipo de puzzle es más difícil de resolver (la transición es una banda, no un entero único).
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [El muro de 470: una frontera de fase, no un límite de ingeniería](https://eternity2.dev/es/research/why/the-470-wall/) — La meseta comunitaria en los 460 altos se lee como una frontera de fase entrópica de la instancia, no como un límite de la ingeniería de solvers: el cálculo exacto sobre el juego oficial da una densidad de restricciones cercana a 0,0094, un paisaje recocido que se derrumba por encima de 470 y solo cruza 1 en 480, y un número esperado de 10 a 20 soluciones perfectas casi ortogonales entre sí. Los números del lado de la instancia son exactos; el cuadro de la brecha de solapamiento en 16x16 es una conjetura declarada.
- [La entropía y la ley de área](https://eternity2.dev/es/research/why/entropy-area-law/) — Eternity II tiene dos reglas: los bordes deben coincidir y cada pieza se usa una sola vez. La primera es generosa. Toda la dificultad reside en la segunda.
- [Patrones prohibidos](https://eternity2.dev/es/research/why/forbidden-patterns/) — Casi todo pequeño conjunto de piezas que podrías construir es imposible. Para un cuadrado 2×2, el 99,72 % de las formas de colocar cuatro piezas nunca podrá encajar.
- [Sin jugadas forzadas](https://eternity2.dev/es/research/why/no-forced-moves/) — La manera habitual de resolver un puzzle lógico es encontrar un lugar donde solo encaja una pieza, colocarla y repetir. Aquí ese recurso no existe: cada pieza interior tiene entre 73 y 137 vecinas posibles, y ninguna queda jamás fijada a una sola opción.
- [Pureza del anillo: el borde es un subpuzle cerrado, sin holgura](https://eternity2.dev/es/research/why/ring-purity/) — Cinco de los 22 colores nunca tocan las 196 piezas interiores. La lista de piezas obliga a toda solución válida a gastar las 120 semiaristas de marco en el anillo del borde: un subpuzle autónomo con holgura exactamente nula (120 = 120), un circuito euleriano sobre cinco vértices, acoplado al interior solo por 56 aristas orientadas hacia dentro.
- [Invariantes de flujo: una ley de rotación que el conjunto oficial cumple exactamente](https://eternity2.dev/es/research/why/flux-invariants/) — Pondere cada color de arista y lea cada pieza como un vector con signo, este menos oeste en un eje, sur menos norte en el otro. Sumado sobre cualquier región, las costuras interiores se cancelan y solo sobrevive el borde, de modo que el tablero totaliza cero. Un cuarto de vuelta gira el vector un ángulo recto, lo que vuelve la ley álgebra en los enteros de Gauss.
- [Por qué el basin-hopping parece imposible](https://eternity2.dev/es/research/why/sigma-cycles/) — Si no puedes mejorar un tablero excelente puliéndolo, quizá puedas saltar a otro tablero excelente. En cada par de récords probado, no puedes, y vale la pena ver la razón estructural que lo explica.
- [El puzzle no tiene función de altura](https://eternity2.dev/es/research/why/no-height-function/) — Toma el truco del físico que vuelve solubles los defectos cristalinos e intenta convertir un empalme mal casado en una dislocación con una carga conservada. Fracasa de tres maneras: una altura escalar es ciega a las roturas, el conjunto de roturas forma cadenas abiertas y no bucles cerrados, y la corriente orientada por color no se conserva. Solo sobrevive un bit de paridad sin signo.
- [Dónde viven los desajustes](https://eternity2.dev/es/research/why/mismatch-geometry/) — Un tablero casi perfecto no reparte sus escasos errores de forma uniforme. Los concentra en una sola banda de cinco filas y deja todo lo demás impecable. ¿Qué banda? Lo decide la dirección en la que la búsqueda rellenó el tablero, y puede verse el reflejo en los tableros récord reales.
- [La región difícil que no se puede diseñar de otro modo](https://eternity2.dev/es/research/why/irreducible-hard-region/) — Rellena un tablero en cualquier orden fijo y los tres cuartos de arriba entran con soltura, mientras la dificultad se amontona en la banda que terminas al final. En cuarenta tableros generados, todo lo que sobra cae en la mitad inferior cada vez; baraja el orden de relleno y se dispersa, así que la región difícil la fabrica el barrido, no está escondida en el tablero.
- [La inmediatez de las restricciones: todo orden de llenado paga los mismos 480](https://eternity2.dev/es/research/why/constraint-immediacy/) — Sume, para cualquier orden de visita del tablero 16x16, el número de vecinos ya colocados que cada celda enfrenta en el instante en que se rellena: el total es exactamente 480, sea cual sea el orden. Un orden de llenado no puede añadir restricción; solo elige cuándo se aplica cada una. Lo que separa a los órdenes es la inmediatez, la distancia entre una decisión y su refutación, y solo los extremos de esa clasificación pertenecen al puzzle y no al motor.
- [El robo de piezas, donde mueren los solucionadores](https://eternity2.dev/es/research/why/piece-theft/) — Un solucionador rellena unas pocas filas sin esfuerzo y luego choca contra un muro en mitad del tablero. He aquí el mecanismo: una pieza escasa gastada en el lugar equivocado, varias filas atrás.
- [El tablero como palabra de código](https://eternity2.dev/es/research/why/permutation-code-wall/) — Lee un tablero completo como una palabra de código cuyas 480 junturas interiores son comprobaciones de tipo paridad, y el score de aristas emparejadas pasa a ser 480 menos el número de comprobaciones fallidas. Es una lente limpia que descansa sobre una sola identidad portante, y conviene ser preciso sobre lo que la vista de códigos correctores aporta y lo que solo renombra.
- [Dónde colocas las pistas importa más que cuántas](https://eternity2.dev/es/research/why/hint-geometry/) — En un puzzle de 16×16 construido como Eternity II, dieciocho pistas repartidas por el tablero lo resuelven en minutos, mientras que amontonarlas en filas contiguas necesita un centenar solo para bajar la búsqueda a decenas de miles de millones de colocaciones. La posición, no la cantidad, es la palanca, y apunta directamente a la fase final.
- [Enlazar las pistas pronto no ayuda, perjudica](https://eternity2.dev/es/research/why/clue-corridors/) — Unir pares de pistas con pasillos de piezas tendidos pronto parece añadir restricciones. El recuento dice lo contrario: un pasillo de ancho 1 entre las dos pistas más cercanas admite unos dos mil billones de rellenos distintos, así que no excluye casi nada mientras gasta piezas que la fase final va a necesitar. En un A/B controlado, cada brazo con pasillos perdió frente a su propio control en todos los tamaños de tablero.
- [Los colores raros viven en el marco](https://eternity2.dev/es/research/why/rare-color-geography/) — Cinco de los 22 colores de Eternity II aparecen solo a lo largo del anillo de borde, cada uno en exactamente 24 aristas, nunca una sola vez en el interior. Una separación estructural que moldea la forma en que cada solucionador trata el marco.
- [El marco no es la cuenca: un borde distinto no abre un tablero más alto](https://eternity2.dev/es/research/why/frame-is-not-the-basin/) — El anillo del borde es la parte más restringida del rompecabezas, así que un borde fuerte distinto debería fijar un interior alto distinto. No lo hace. Muchos bordes completamente emparejados y distintos, cada uno completado por un mismo productor de interior fijo, dan cimas casi máximamente distintas entre sí pero uniformemente bajas, ninguna cerca de la franja récord. El borde diversifica el tablero sin predecir su techo.
- [El equilibrio del borde](https://eternity2.dev/es/research/why/border-balance/) — Un tablero resuelto esconde una sencilla ley contable: cada color que el borde entrega al interior, el interior se lo devuelve al instante. Rómpela y sabrás de inmediato que el tablero es incorrecto; respetarla, en cambio, no garantiza nada.
- [Diseñado para ser irresoluble: la receta](https://eternity2.dev/es/research/why/design-recipe/) — Eternity II sigue una receta para lograr el puzzle de emparejamiento de aristas más difícil posible: forma compacta, sin piezas simétricas ni duplicadas, paletas separadas, frecuencias planas, una sola solución esperada. La comunidad aplicó ingeniería inversa a cada ingrediente en el año del lanzamiento.
- [La cosecha de teoremas: trece leyes estructurales](https://eternity2.dev/es/research/why/theorem-sweep/) — Un solo arco de investigación, trece familias de teoremas estructurales: pureza del anillo, el suelo de paridad en 479, el muro de 470 como frontera de fase, los invariantes de flujo, la ley de área entrópica, y los resultados de imposibilidad que ponen precio a cada atajo clásico. Esta página es el mapa.
---
# El equilibrio del borde
> Un tablero resuelto esconde una sencilla ley contable: cada color que el borde entrega al interior, el interior se lo devuelve al instante. Rómpela y sabrás de inmediato que el tablero es incorrecto; respetarla, en cambio, no garantiza nada.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/border-balance/
- Actualizado: 2026-07-22
- Temas: search-space, structure
- Reproducir: `just research-border-mismatch-share`
- Fuente: Equilibrio de los tipos de arista del borde observado en el verano de lanzamiento (angwin_uk, agosto de 2007) — https://groups.io/g/eternity2/message/2073
- Fuente: La condición de borde más fuerte de mjqxxxx: recuentos pares, repartidos a partes iguales entre aristas izquierda y derecha (agosto de 2007) — https://groups.io/g/eternity2/message/2098
- Fuente: Observación de Brendan Owen sobre el emparejamiento de recuentos de aristas en los juegos plantados (junio de 2007) — https://groups.io/g/eternity2/message/422
- Fuente: Enunciado de Hopfer (2022) de la condición de igualdad de multiconjuntos (groups.io msg 10754) — https://groups.io/g/eternity2/message/10754
- Fuente: Reformulación nítida de Hopfer: la misma mezcla de imágenes internas en las 56 piezas de borde (msg 10757) — https://groups.io/g/eternity2/message/10757
---
Fíjate solo en la costura entre el anillo exterior de piezas de borde y el
primer anillo de piezas interiores. Cada arista que cruza esa costura muestra un
color, contado una vez desde el lado del borde y una vez desde el lado del
interior. En cualquier solución completa los dos recuentos son idénticos: el
multiconjunto de colores que el borde presenta hacia dentro iguala exactamente
al multiconjunto que el interior presenta hacia fuera.
Llamemos **déficit** a ese desequilibrio, $\Delta$: la mitad del desajuste total
entre los dos recuentos. Un tablero terminado y correcto tiene $\Delta = 0$. Las
cuatro soluciones completas conocidas, sobre cuatro juegos de piezas distintos,
la satisfacen todas exactamente. Así, $\Delta > 0$ es un certificado de que un
tablero nunca podrá completarse: una condición necesaria, real y de bajo coste.
## La ley, en una línea
A través de la costura borde↔interior, los colores que el borde muestra hacia
dentro y los colores que el interior muestra hacia fuera forman el mismo
multiconjunto. Escribiendo $A[c]$ y $B[c]$ para los dos recuentos por color:
$$
\Delta \;=\; \tfrac{1}{2} \sum_{c} \bigl|\, A[c] - B[c] \,\bigr| \;=\; 0 .
$$
## Verlo en un tablero real
Un tablero 8×8 resuelto parte en equilibrio ($\Delta = 0$). Levanta una pieza de
borde y observa qué colores se desequilibran, y cómo trepa el déficit. Prueba
luego el botón de intercambio, y observa la trampa.
> **[Figure]** Interactivo: el déficit de equilibrio del borde NS-1 — interactive: Ns1Lab. Rendered on the canonical page (link above); not shown in this markdown export.
## La trampa, y por qué importa
Intercambiar dos piezas de borde deja $\Delta$ en 0. El intercambio mueve
colores a lo largo de la costura sin modificar ninguno de los dos recuentos, de
modo que el invariante es ciego a ello. Peor aún, en una casi-solución la mayor
parte de los errores restantes no están en la costura del borde en absoluto. Se
asientan de interior a interior, allí donde NS-1 nunca mira. En los nueve
tableros de la clase 469 del corpus, de las 99 aristas no emparejadas que
quedan, el 86,9 % se asienta de interior a interior y ni una sola es de borde a
borde; solo el 13,1 % restante cae en la costura que inspecciona NS-1. El
invariante es ciego a la gran mayoría de lo que sigue mal.
Ahí está toda la textura de Eternity II en miniatura. Una comprobación por
limpia que sea nunca dice más que "definitivamente roto", jamás "definitivamente
correcto". El puzzle resiste todo certificado barato de progreso.
## ¿Es útil, entonces?
Sí, como podador de fin de búsqueda. Una vez que el solucionador ha cerrado el
anillo de borde, imponer $\Delta = 0$ rechaza una porción útil de los
callejones sin salida profundos al precio de una sola pasada sobre las 56
aristas de la costura (cuán grande es esa porción está en cola para medición
exacta, todavía no un banco fijado). Es necesario-pero-laxo: descarta los
estados malos a bajo coste y deja intacta la parte difícil, el interior.
## Relacionado
- [Los colores raros viven en el marco](https://eternity2.dev/es/research/why/rare-color-geography/) — Cinco de los 22 colores de Eternity II aparecen solo a lo largo del anillo de borde, cada uno en exactamente 24 aristas, nunca una sola vez en el interior. Una separación estructural que moldea la forma en que cada solucionador trata el marco.
- [Patrones prohibidos](https://eternity2.dev/es/research/why/forbidden-patterns/) — Casi todo pequeño conjunto de piezas que podrías construir es imposible. Para un cuadrado 2×2, el 99,72 % de las formas de colocar cuatro piezas nunca podrá encajar.
- [Sin jugadas forzadas](https://eternity2.dev/es/research/why/no-forced-moves/) — La manera habitual de resolver un puzzle lógico es encontrar un lugar donde solo encaja una pieza, colocarla y repetir. Aquí ese recurso no existe: cada pieza interior tiene entre 73 y 137 vecinas posibles, y ninguna queda jamás fijada a una sola opción.
---
# Enlazar las pistas pronto no ayuda, perjudica
> Unir pares de pistas con pasillos de piezas tendidos pronto parece añadir restricciones. El recuento dice lo contrario: un pasillo de ancho 1 entre las dos pistas más cercanas admite unos dos mil billones de rellenos distintos, así que no excluye casi nada mientras gasta piezas que la fase final va a necesitar. En un A/B controlado, cada brazo con pasillos perdió frente a su propio control en todos los tamaños de tablero.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/clue-corridors/
- Actualizado: 2026-07-22
- Temas: structure, search-space
- Reproducir: `cd research/topics/clue-corridors/compute && cargo run --release --bin corridors > ../results/corridor_counts.json`
- Fuente: Colocaciones oficiales de las pistas (celdas 34, 45, 135, 210, 221; datos de la instancia en e2.bucas.name) — https://e2.bucas.name/
---
Las cinco pistas son las únicas celdas del puzzle oficial cuyo contenido se
conoce con certeza. Mire el tablero un minuto y una idea se presenta sola:
conectarlas. Tender una cadena corta de piezas de pista a pista, convertir
cada cadena en una espina fija, y esperar que esas espinas restrinjan todo lo
que viene después. La idea me gustó lo bastante como para medirla, y la
medición es un negativo limpio por partida doble. Un recuento exacto muestra
que un pasillo de pista a pista admite unos dos mil billones de rellenos
distintos, así que comprometerse con uno no restringe casi nada; y en un A/B
controlado, cada brazo que tendía sus pasillos pronto terminó peor que el
mismo solucionador sin ellos, en todos los tamaños de tablero probados.
## Cinco islas, y los puentes entre ellas
Las pistas ocupan las celdas 34, 45, 135, 210 y 221, es decir
(x, y) = (2, 2), (13, 2), (7, 8), (2, 13) y (13, 13): cuatro a dos celdas de
las esquinas, una justo a la izquierda del centro. Sus distancias de
Manhattan por pares van de 10 a 22. Ningún par de pistas está cerca de ser
adyacente: el puente más corto entre dos de ellas es una cadena de diez
colocaciones.
Lo que vale una colocación de cadena depende de cuántos lados tenga que
casar. Con $n = 196$ piezas interiores y $C = 22$ colores interiores
declarados, una celda que debe casar con $k$ vecinos ya colocados tiene en
esperanza $b_k = 4n / C^k$ candidatos legales: $b_1 \approx 35{,}6$,
$b_2 \approx 1{,}62$, $b_3 \approx 0{,}074$. Una colocación solo poda, en
esperanza, cuando $b_k$ cae por debajo de 1, lo que exige $k \ge 3$ lados
casados. Un pasillo de ancho 1 se construye por entero con colocaciones a
$k = 1$: cada pieza nueva solo toca a la anterior y hereda unos 36 candidatos
legales en cada paso.
## Lo que vale un pasillo: dos mil billones de rellenos
La tabla de ramificación es un modelo uniforme, así que el verificador
también cuenta de forma exacta sobre el juego de piezas real. El juego real
es, si acaso, más permisivo: el número de pares (pieza, rotación) que
presentan un color interior dado en un lado dado promedia 46,1 (de 43 a 49),
frente al 35,6 del modelo. Construya la matriz de transferencia $T[a][b]$ que
cuenta las piezas interiores que muestran el color $a$ en un lado y el color
$b$ en el lado opuesto, elévela a la longitud del pasillo, y sus potencias
dan recuentos exactos de caminos. Para el pasillo de longitud 10 entre el par
de pistas más cercano, con los dos colores de los extremos fijados por las
pistas, ese recuento es $2{,}59\times10^{15}$ caminos (la media sobre pares
de colores). Un camino puede reutilizar una pieza; aplicar la corrección de
distinción de campo medio $\prod_{j=0}^{9}(1 - j/196) = 0{,}792$ deja
$2{,}05\times10^{15}$ rellenos con piezas todas distintas. Mi primera pasada
por este recuento, con un modelo de piezas algo más estricto, daba
$1{,}9\times10^{15}$; el verificador archivado se asienta en
$2{,}05\times10^{15}$, y la conclusión no se mueve entre ambos.
Un compromiso satisfacible de dos mil billones de maneras no es una
restricción en ningún sentido útil. Tenderlo excluye una fracción ínfima del
espacio de búsqueda, mientras retira diez piezas del fondo común a $k = 1$,
justo donde la aritmética dice que la búsqueda no recupera nada. Conecte dos
o tres pares de pistas y la factura sube a entre 10 y 20 piezas gastadas
antes de que se haya rellenado una sola celda realmente restringida.
## El A/B: todos los brazos con pasillo perdieron
El recuento dice que el pasillo no aporta nada; hace falta un experimento
para mostrar que cuesta. La tanda original del estudio comparó tres brazos
que no difieren más que en la fase de pasillos: un control (pistas fijadas, y
después un relleno voraz de contacto máximo con reinicios), un brazo de
pasillo de ancho 1, y un brazo de cinta de ancho 2, cada uno tendiendo sus
rutas de pista a pista antes del relleno idéntico. Corrió sobre instancias
escaladas con geometría de pistas fiel, en tamaños N = 8 a 16, con 12
semillas emparejadas por celda y 20 segundos por ejecución en un solo núcleo.
| Tablero | Media del control | Pasillo ancho 1 | Cinta ancho 2 |
|---:|---:|---:|---:|
| 8×8 | 92,50 | -4,67 | -3,00 |
| 10×10 | 144,17 | -9,58 | -5,50 |
| 12×12 | 209,83 | -13,58 | -6,75 |
| 14×14 | 285,67 | -12,00 | -7,83 |
| 16×16 | 377,17 | -17,67 | -8,08 |
Las puntuaciones son aristas casadas, y cada delta enfrenta un brazo a su
propio control sobre semillas emparejadas. Cada brazo con pasillo perdió
frente a su control en todos los tamaños, con Wilcoxon emparejado
$|z| \ge 2{,}80$. El daño crece con los tableros, y con ellos los pasillos:
una pérdida media de 4,7 aristas en N = 8 se convierte en 17,7 en N = 16,
donde las dos distribuciones de puntuación se separan del todo (la peor
semilla del control marcó 373; la mejor del brazo de pasillo, 365). Y
ensanchar el pasillo a una cinta de 2 celdas, lo que permite que su segunda
fila llegue con 2 contactos en vez de 1, reduce el daño aproximadamente a la
mitad en todos los tamaños. Esa es exactamente la dependencia del ancho que
el recuento predice, y es lo que ata el mecanismo a la medición.
## Qué descarta, y qué deja abierto
El negativo es preciso: tender pronto pasillos de pista a pista de ancho 1
(o 2) perjudica, y más pasillo perjudica más. La misma aritmética que los
condena señala también dónde la restricción es real: las celdas colocadas
con 2 o más contactos, ya que solo $k \ge 3$ poda de verdad y $k = 2$ se
acerca. Hacer crecer regiones compactas ancladas en las pistas, donde la
mayoría de las celdas llegan con varios contactos, es un movimiento distinto
que este experimento no toca.
El resultado encaja además con lo que los estudios de pistas encuentran una
y otra vez. En un puzzle 16×16 emparentado,
[la posición de las pistas importa más que su número](/es/research/why/hint-geometry/)
porque el valor de una pista está en alcanzar la parte del tablero donde la
búsqueda sufre; y en
[el estudio de pistas del laboratorio](/es/research/lab/experiments/raphael-anjou/hint-study/),
las cinco pistas oficiales por sí solas nunca ayudaron a un backtracker
cronológico en los tableros probados. Un pasillo es la manera extrema de
malgastar ese regalo: cobra las cinco celdas fijas de inmediato, en la región
más barata de la búsqueda, y lo paga con el fondo de piezas. Como los
negativos del [barrido de teoremas](/es/research/why/theorem-sweep/), este viene
con su precio: para que enlazar las pistas compense, sus celdas tendrían que
llegar con tres contactos, y un camino de ancho 1 no lo logra nunca.
> **Note**
>
> El lado del recuento se reproduce de forma exacta: el verificador del directorio del tema recalcula la geometría de las pistas, la tabla de ramificación, la oferta de colores y los recuentos de pasillos por matriz de transferencia desde el juego de piezas oficial en alrededor de un segundo, y su salida está archivada en results/corridor_counts.json. La tabla A/B es la medición original del estudio: la repetición empaquetada de los tres brazos está especificada en el plan de reproducción del tema y sus tablas aún no están archivadas, así que lea esos deltas como el registro de una tanda, con la confirmación de una tanda fresca todavía pendiente.
## Relacionado
- [Dónde colocas las pistas importa más que cuántas](https://eternity2.dev/es/research/why/hint-geometry/) — En un puzzle de 16×16 construido como Eternity II, dieciocho pistas repartidas por el tablero lo resuelven en minutos, mientras que amontonarlas en filas contiguas necesita un centenar solo para bajar la búsqueda a decenas de miles de millones de colocaciones. La posición, no la cantidad, es la palanca, y apunta directamente a la fase final.
- [El estudio de las pistas](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/hint-study/) — Darle a un backtracker cinco piezas correctas gratis, en la geometría misma de las pistas del puzzle. Resulta que no ayuda, y según el orden de relleno puede dañar gravemente, porque una pieza fijada es una restricción dura que un orden de relleno fijo debe satisfacer al llegar. Una familia de órdenes de relleno, ejecutada sobre los mismos tableros con pistas, un solo núcleo, medida contra la ausencia total de pistas.
- [La cosecha de teoremas: trece leyes estructurales](https://eternity2.dev/es/research/why/theorem-sweep/) — Un solo arco de investigación, trece familias de teoremas estructurales: pureza del anillo, el suelo de paridad en 479, el muro de 470 como frontera de fase, los invariantes de flujo, la ley de área entrópica, y los resultados de imposibilidad que ponen precio a cada atajo clásico. Esta página es el mapa.
---
# La teoría compleja: contar el árbol de búsqueda antes de recorrerlo
> La teoría compleja de Brendan Owen estima la anchura del árbol de búsqueda a cada profundidad, e incluso cuántas soluciones existen en total. Muchos en la comunidad la consideran lo más importante que hay que entender sobre Eternity II.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/complex-theory/
- Actualizado: 2026-07-02
- Temas: structure, backtracking
- Fuente: La forma cerrada del pico de profundidad de Brendan Owen, 256·(1−1/e) (groups.io msg 8125, 2010) — https://groups.io/g/eternity2/message/8125
- Fuente: La resolución 10×10 de Peter McGavin que valida la teoría compleja (groups.io msg 9686, 2017) — https://groups.io/g/eternity2/message/9686
- Fuente: Las estimaciones del número de soluciones de Brendan Owen (groups.io message 5209) — https://groups.io/g/eternity2/message/5209
- Fuente: La implementación de referencia y la tabla de profundidades de Peter McGavin (groups.io message 11197) — https://groups.io/g/eternity2/message/11197
- Fuente: La tabulación «Backtracker estimates» de Brendan Owen para los puzzles con pistas y E2 (groups.io Databases) — https://groups.io/g/eternity2/databases
- Fuente: La validación estimado-frente-a-real de Brendan Owen, «NxM puzzles using Eternity II subset pieces» (groups.io Files, carpeta Brendan) — https://groups.io/g/eternity2/files/Brendan/NxM_actual_theory.pdf
- Fuente: El estudio heurística-frente-a-número-de-nodos de Brendan Owen, «Heuristics: 20×2 rectangle» (groups.io Files, carpeta Brendan) — https://groups.io/g/eternity2/files/Brendan/heuristics.pdf
- Fuente: La medición profundidad-frente-a-tiempo del backtracker de Joe, muestra de 1 mil millones de iteraciones (groups.io msg 11725, 2026) — https://groups.io/g/eternity2/message/11725
---
> **De quién es esta idea**
>
> La teoría compleja se debe a Brendan Owen, uno de los verificadores del puzzle; Peter McGavin la [implementó en C](https://groups.io/g/eternity2/message/11197) con aritmética de precisión arbitraria y publicó las cifras. La recogemos aquí porque un miembro de la comunidad (Dan Karlsson) señaló con razón que faltaba, y porque sustenta casi todas las buenas decisiones que se pueden tomar sobre un solucionador, ante todo la elección del orden de búsqueda.
## La idea
Toma un orden de recorrido y recórrelo celda a celda. En cada celda nueva, una
pieza sin usar tomada al azar encaja con sus vecinas ya colocadas con cierta
probabilidad: un producto de probabilidades de coincidencia de color por arista.
Multiplica eso por cuántas piezas quedan y obtienes el número esperado de formas
de extender el tablero una celda más. Encadena este cálculo por las 256 celdas y
tienes una estimación en forma cerrada de la anchura del árbol de búsqueda a cada
profundidad y, en la última celda, de cuántas soluciones completas tiene el
puzzle.
Es un promedio, no un recuento exacto: supone que los 22 colores de arista se
extraen de forma independiente, cosa que no ocurre (cuatro aristas están soldadas
a una misma pieza rígida). Pero, calibrado contra puzzles pequeños cuyo número
real se conoce, acierta con un margen de un factor de dos. Es más que suficiente
para ver la forma.
## Las cifras destacadas
| Pistas colocadas | Soluciones esperadas |
| ------------------------------------ | -------------------- |
| Una pista (solo la pieza central) | ≈ 14 702 |
| Las cinco pistas oficiales | ≈ 1 |
Con solo la pieza central obligatoria, el puzzle tiene del orden de quince mil
soluciones; añade las otras cuatro pistas y el número esperado cae a
aproximadamente $4\times10^{-8}$: de forma abrumadora, exactamente una. Esta es
la razón formal por la que el puzzle de 5 pistas tiene una única solución
diseñada.
## Las mismas cifras, contrastadas con la realidad
Brendan tabuló la estimación no solo para E2, sino también para los cuatro
*puzzles con pistas* más pequeños, y es aquí donde se gana la confianza. Los
puzzles con pistas son lo bastante pequeños como para que sus árboles se hayan
explorado exhaustivamente, de modo que la estimación queda justo al lado del
número real. Acierta con un margen de un factor de dos, la calibración que esta
página no deja de prometer. La tabla también registra el mejor orden de relleno
conocido para cada puzzle, y no todos son iguales: el orden es una elección que
la forma del espacio de búsqueda recompensa o penaliza, no una propiedad del
puzzle.
> **[Interactive: ClueEstimatesTable]** Rendered on the canonical page (link above); not shown in this markdown export.
Los puzzles con pistas son cuatro puntos de datos; Brendan comprobó el modelo de
forma mucho más amplia. Su estudio **«NxM puzzles using Eternity II subset
pieces»** representa los nodos por solución estimados frente al número *real*
para del orden de un centenar de tableros más pequeños construidos con las
propias piezas de E2, y sobre un eje log-log la nube se ciñe a la diagonal a lo
largo de once órdenes de magnitud, desde diez nodos hasta $10^{11}$. Ese es el
fundamento real para confiar en la estimación sobre un tablero demasiado grande
como para explorarlo alguna vez: ha acertado en todas partes donde *podía*
comprobarse. Un estudio complementario muestra incluso que una puntuación
estática facilísima (la suma de los recuentos de coincidencias de arista por
celda, al cuadrado) predice el número total de nodos de un rectángulo con un
$R^2$ de alrededor de 0,84, más evidencia de que el coste de la búsqueda está
inscrito en la estructura del tablero antes de colocar una pieza.
## El embudo
Representa la anchura esperada a cada profundidad y aparecen tres regímenes. Su
forma es lo que la comunidad llama el embudo de E2. Lanza el barrido de abajo y
observa el contador: sube astronómicamente, luego apenas se mueve
durante un centenar de celdas a lo largo de la meseta, ese avance plano por una
banda astronómicamente ancha es el muro, antes de que las últimas sesenta piezas
lo hagan bajar de nuevo en embudo.
> **[Figure]** interactive: ComplexFunnelAnimated. Rendered on the canonical page (link above); not shown in this markdown export.
## Pruébalo: el orden decide el embudo
La misma estimación, ejecutada en vivo para distintos órdenes de recorrido. El
pico de la meseta (el punto más ancho que la búsqueda debe cruzar) lo decide el
orden por sí solo, antes de colocar un solo nodo.
> **[Figure]** Interactivo: el embudo del espacio de búsqueda — interactive: ComplexFunnelLab. Rendered on the canonical page (link above); not shown in this markdown export.
## Tres regímenes
- **Crecimiento (profundidad 1–50).** Las soluciones se multiplican
geométricamente de una a unas $10^{27}$. Cada colocación es prácticamente
gratuita; todavía nada te limita.
- **Meseta (profundidad 50–200).** El árbol está en su punto más ancho, unas
$10^{45}$ formas de extender, mientras que el número de soluciones apenas se
mueve. Aquí es donde los backtrackers pasan la mayor parte de su tiempo: una
muestra empírica ([groups.io msg 11725](https://groups.io/g/eternity2/message/11725),
un cálculo de 1 mil millones de iteraciones) midió el 99 % del tiempo del
backtracker a profundidad $>132$ y el 70 % a profundidad $>150$, es decir, en
el fondo del árbol y no al principio.
- **Colapso (profundidad 200–256).** La anchura cae de $10^{45}$ de vuelta a
unas $10^{4}$. Las ~60 últimas piezas están fuertemente restringidas: cada una
colocada elimina órdenes de magnitud de ramas. El final de partida es
localmente fácil; lo difícil es llegar a él.
## Por qué cambia tu forma de buscar
Si casi todo el trabajo está en la meseta, el objetivo no es la velocidad bruta.
Es cruzar la meseta hasta la entrada del embudo (en torno a la profundidad 200),
tras la cual la búsqueda se encadena de forma determinista. Y como la teoría
compleja puntúa un orden de recorrido antes de ejecutarlo, se pueden comparar
órdenes por la altura del pico de su meseta en lugar de por ensayo y error. Esa
es la versión rigurosa de una regla que este sitio enuncia por todas partes: el
orden de relleno es una elección de primer orden, y el recorrido de McGavin, de
la esquina inferior izquierda y de izquierda a derecha, se eligió porque la
teoría compleja decía que era bueno.
## Piezas más grandes
La misma idea funciona si colocas piezas de 2×2 o 3×3 en lugar de piezas sueltas:
un bloque entero de celdas se compromete de golpe, con sus aristas internas ya
coincidentes. El [terreno de juego de rutas de búsqueda](/playground/paths/) te
permite hacerlo de verdad: elige una forma de bloque (1×1, 2×1, 2×2, 3×3, …) y
estampa bloques sobre la cuadrícula para construir una ruta por bloques. Lánzala
a competir y un solucionador de macropiezas dedicado compromete un subensamblaje
válido entero por bloque en lugar de una pieza cada vez, de modo que la búsqueda
avanza región por región. La estimación del pico de meseta que va al lado sigue
puntuando el orden de celdas que implican tus bloques, prediciendo el coste antes
de que ejecutes un solo nodo.
## Lo que no puede ver
La teoría compleja es una estimación de primer momento, así que es ciega a una
cosa: si los numerosos tableros parciales contados son genuinamente distintos.
Los [resultados de entropía y ley de área](/es/research/why/entropy-area-law/)
muestran que la distinción se colapsa a medida que crece el área rellenada, un efecto de
segundo orden que el modelo de aristas independientes no puede captar. Así que
usa la teoría compleja para elegir órdenes y leer la forma del árbol, nunca como
un recuento exacto ni como una cota.
## Procedencia y validación
El rastro escrito de la teoría corre a través de la lista de correo. Brendan
Owen publicó el modelo terminado en abril de 2008
([msg 5197](https://groups.io/g/eternity2/message/5197),
[5209](https://groups.io/g/eternity2/message/5209)), y más tarde demostró una
elegante forma cerrada: para un orden de recorrido, el pico del número de nodos
se sitúa a la profundidad
$256\,(1 - 1/e) \approx 161.8$
([msg 8125](https://groups.io/g/eternity2/message/8125)); el embudo de arriba
culmina ahí empíricamente. Peter McGavin compuso la teoría
([msg 9188](https://groups.io/g/eternity2/message/9188)), publicó la cifra de
14 702 soluciones esperadas ya en 2011
([msg 8924](https://groups.io/g/eternity2/message/8924)), y en 2017 entregó su
validación más contundente: resolvió el benchmark 10×10 sin pistas de Brendan
explorando las primeras filas ordenadas por teoría compleja: unos 180 años-núcleo,
cayendo dentro de las predicciones de la teoría
([msg 9686](https://groups.io/g/eternity2/message/9686),
[9688](https://groups.io/g/eternity2/message/9688)). Su implementación C de
referencia de 2024 ([msg 11197](https://groups.io/g/eternity2/message/11197)) es
lo que el estimador en vivo de esta página porta, línea por línea.
## Relacionado
- [Por qué un ordenador más rápido no ayuda](https://eternity2.dev/es/research/why/prune-vs-speed/) — La idea más importante de la búsqueda combinatoria difícil: reducir el espacio que se explora vence, por un margen exponencial, a explorarlo más rápido. Eternity II está diseñado para que apenas puedas reducirlo.
- [Calibrado en el pico de dificultad](https://eternity2.dev/es/research/why/phase-transition/) — Eternity II utiliza 22 colores, repartidos entre 17 colores interiores y 5 reservados al marco, y ese número de alrededor de 17 se sitúa cerca del punto donde este tipo de puzzle es más difícil de resolver (la transición es una banda, no un entero único).
- [La entropía y la ley de área](https://eternity2.dev/es/research/why/entropy-area-law/) — Eternity II tiene dos reglas: los bordes deben coincidir y cada pieza se usa una sola vez. La primera es generosa. Toda la dificultad reside en la segunda.
- [¿Es NP-completa esta instancia y cómo la codifico?](https://eternity2.dev/es/research/why/how-hard-is-this-instance/) — El emparejamiento de aristas es NP-completo como familia, pero eso no dice nada de un tablero 16×16 fijo: una instancia aislada es una constante, no un problema. Lo que sí es cierto es la dureza en el peor caso de la familia y la dureza empírica de esta instancia, y cómo escribir el puzzle para un solucionador SAT, de cobertura exacta o de PLE, con pequeños esbozos detallados. Una medición con tableros plantados pone cifras a la elección de la formulación: un acantilado de resolubilidad que un paradigma de búsqueda golpea y otro cruza, y que se mueve con el número de colores.
---
# La inmediatez de las restricciones: todo orden de llenado paga los mismos 480
> Sume, para cualquier orden de visita del tablero 16x16, el número de vecinos ya colocados que cada celda enfrenta en el instante en que se rellena: el total es exactamente 480, sea cual sea el orden. Un orden de llenado no puede añadir restricción; solo elige cuándo se aplica cada una. Lo que separa a los órdenes es la inmediatez, la distancia entre una decisión y su refutación, y solo los extremos de esa clasificación pertenecen al puzzle y no al motor.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/constraint-immediacy/
- Actualizado: 2026-07-22
- Temas: backtracking, search-space
- Reproducir: `cd research/topics/constraint-immediacy/compute && cargo run --release -- repro-korder ../results`
- Fuente: El kit de reproducción tras esta página: verificador de conteos de restricciones, solver sencillo de dos brazos, resultados archivados (research/topics/constraint-immediacy) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/constraint-immediacy
---
Hay una intuición recurrente sobre los backtrackers de Eternity II: si la
búsqueda visitara primero las cinco celdas con pista, siguiendo un camino
que las enlace pronto, las pistas "restringirían el puzzle antes" y el árbol
de búsqueda se encogería. La intuición suena bien y la contabilidad dice lo
contrario. Ningún orden de llenado restringe el puzzle más que otro. Lo que
un orden controla de verdad es *cuándo* se aplica cada restricción, y esa
pregunta de calendario tiene una respuesta nítida: las restricciones que se
pagan tarde son las caras.
## Una suma que ningún orden puede cambiar
Fije un orden de visita completo de las 256 celdas. Cuando se rellena la
celda $i$, llame $k_i$ al número de sus vecinas ya colocadas: el número de
restricciones de arista que la pieza nueva debe satisfacer en ese instante.
Cada junta interior del tablero se comprueba exactamente una vez, por el
extremo que se coloca en segundo lugar. La suma de los $k_i$ es por tanto el
número de juntas interiores, que en el tablero 16x16 vale
$2 \times 16 \times 15 = 480$, las mismas 480 juntas que cuenta el
[suelo de paridad](/es/research/why/parity-defect-floor/). El total es
invariante respecto del camino:
$$\sum_i k_i = 480 \quad \text{para todo orden de visita.}$$
El kit de reproducción lo comprueba de forma exacta para cinco órdenes de
visita sobre el tablero oficial. Los cinco suman 480; lo único que cambia es
cómo se reparte el total:
| orden | k=0 | k=1 | k=2 | k=3 | k=4 | suma |
|---|---|---|---|---|---|---|
| hint-link | 1 | 75 | 137 | 41 | 2 | 480 |
| outer-spiral | 1 | 58 | 170 | 26 | 1 | 480 |
| row-major | 1 | 30 | 225 | 0 | 0 | 480 |
| bustrófedon | 1 | 30 | 225 | 0 | 0 | 480 |
| border-first | 1 | 58 | 170 | 26 | 1 | 480 |
Estas cinco cifras son las mediciones originales del motor del estudio fuente; la reproducción empaquetada cubre el invariante y los dos solucionadores simples de abajo, no esta tabla.
El orden fila a fila (row-major) es casi uniforme: pasadas la primera fila y
la primera columna, cada celda enfrenta exactamente dos restricciones. El
orden hint-link (un camino que encadena pronto las cinco celdas con pista
mediante corredores de enlace) paga sus 41 celdas a tres restricciones y sus
2 celdas a cuatro colocando antes 75 celdas comprobadas contra una sola
vecina. La ley de conservación lo convierte en un trueque, nunca en una
ganancia: una celda solo puede enfrentar tres o cuatro vecinas colocadas
porque otras celdas se colocaron casi sin comprobación antes que ella.
## La inmediatez: cuándo llega la factura
Si el volumen total de restricciones está fijado, ¿qué distingue a los
órdenes en la práctica? El coste de una colocación errónea es el tamaño del
subárbol que la búsqueda explora antes de que aflore la refutación. Un orden
con largos tramos sub-restringidos (series de celdas comprobadas contra una
sola vecina, con decenas de candidatas cada una) seguidos de cierres
sobre-restringidos (celdas comprobadas contra tres o cuatro) falla *al
final*: los errores cometidos a bajo precio en el corredor solo se detectan
en el cierre, un subárbol entero después. Un orden que mantiene cerca de
cero la distancia entre una decisión y su refutación falla *de inmediato*, y
ahí vive todo el beneficio.
Ese es el principio de inmediatez de las restricciones: restringir pronto es
lo correcto exactamente cuando la restricción pone a prueba cada decisión en
el acto. El orden borde-primero (border-first) compromete primero el
subconjunto más restringido (las 60 piezas de borde, que en el perímetro
solo admiten una orientación), de modo que sus restricciones se aplican en
el momento en que nacen. El camino hint-link es el caso opuesto, precocidad
geométrica sin inmediatez: las pistas se alcanzan pronto, pero a lo largo de
corredores cuyas colocaciones quedan casi sin probar hasta que el tablero se
cierra a su alrededor.
## Lo que midió el motor
El principio se extrajo de ejecuciones a orden fijo del motor de búsqueda
del proyecto, la misma familia que examina el
[estudio DFS](/es/research/lab/experiments/raphael-anjou/dfs-study/). Aquí y más
abajo, las puntuaciones son aristas interiores emparejadas sobre 480 según
el puntuador canónico que excluye el perímetro; ninguno de estos números es
una reclamación de récord, y las tablas de récords viven en
[/research/records](/es/research/records/).
| orden | aristas emparejadas (motor) |
|---|---|
| hint-link | 51 |
| outer-spiral | 204 |
| costura de dos frentes | 3 a 5 por debajo de row-major |
| row-major | 433 |
| border-first | 445 |
Un solo principio cubre toda la tabla: hint-link y la espiral fallan al
final y se hunden; row-major es uniforme y sólido; border-first añade una
prueba inmediata sobre las piezas más restringidas y acaba en cabeza.
## La contraprueba con un solver sencillo
Una clasificación medida en un solo motor puede ser una propiedad de ese
motor. Para separar ambas cosas, la reproducción relanzó los cinco órdenes
sobre un solver deliberadamente sencillo, dos brazos a 60 s por orden y por
brazo sobre el tablero oficial, un solo núcleo en Apple Silicon: una pasada
voraz de mejor ajuste que rellena todo el tablero tolerando fallos, y una
búsqueda en profundidad de ajuste perfecto con vuelta atrás cronológica,
puntuada sobre su prefijo consistente más profundo (16 a 47 mil millones de
nodos por orden, así que el presupuesto se gastó de verdad). El fichero de
resultados guarda un enlace al visor para cada tablero final.
| orden | voraz | puntuación DFS | profundidad DFS |
|---|---|---|---|
| hint-link | 316 | 44 | 60/256 |
| outer-spiral | 366 | 28 | 35/256 |
| row-major | 343 | 344 | 194/256 |
| bustrófedon | 359 | 342 | 193/256 |
| border-first | 358 | 28 | 35/256 |
Lo que sobrevive al cambio de motor son los extremos. Hint-link es con
diferencia el peor orden de ajuste perfecto, y su puntuación DFS de 44 cae
cerca del 51 del motor. Row-major y el bustrófedon son el medio de tabla
sólido en ambos brazos. Y sobre el tablero oficial el brazo voraz mantiene a
border-first por delante de row-major, 358 contra 343, la misma dirección
que el 445 contra 433 del motor.
Lo que no sobrevive es todo lo demás. Bajo el DFS sencillo la espiral ya no
se hunde en una clase propia (empata con border-first, coherente con que los
dos órdenes comparten aquí un perfil de restricciones idéntico y las mismas
60 primeras celdas), y el propio border-first choca con un muro de cierre
del perímetro a profundidad 35 de 256 en lugar de liderar. Sobre cuatro
tableros 16x16 generados con marco, la ventaja voraz se invierte sin más:
row-major gana el brazo voraz en 4 de 4 semillas y el brazo en profundidad
en 4 de 4, con la puntuación DFS de border-first oscilando entre 28 y 366
según la semilla. El enunciado riguroso de esta página tiene por tanto dos
caras: el invariante y los extremos pertenecen al puzzle; el medio fino de
cualquier clasificación de órdenes de llenado pertenece al motor que la
produjo.
## Dónde queda la palanca
La ley de conservación acota lo que la geometría puede hacer por sí sola. Un
perfil uniforme de dos restricciones es el mejor calendario que un orden de
visita puede alcanzar, porque las celdas que enfrentan tres o cuatro vecinas
colocadas solo existen aguas abajo de celdas colocadas casi sin
comprobación. Row-major ya alcanza ese perfil, y los veinte años de
ingeniería comunitaria de órdenes de llenado repasados en la
[página de órdenes de llenado](/es/research/build/backtracking/fill-order/) son
refinamientos dentro de ese marco. Cualquier vinculación temprana adicional
tiene que ser informacional en vez de geométrica: propagar lo que la reserva
de piezas restante aún puede servir (el modo de fallo que hace visible el
[robo de piezas](/es/research/why/piece-theft/)), a prioris de colocación,
reservas de candidatas restringidas, puertas de poda calculadas. La propia
invariancia es un pequeño enunciado exacto en el espíritu del
[barrido de teoremas](/es/research/why/theorem-sweep/): no es profundo, pero
cierra una puerta con limpieza. Nadie encogerá esta búsqueda desviando el
camino por el tablero; las 480 comprobaciones se deben íntegras, en todo
camino, y solo su calendario queda en manos de quien busca.
## Relacionado
- [El robo de piezas, donde mueren los solucionadores](https://eternity2.dev/es/research/why/piece-theft/) — Un solucionador rellena unas pocas filas sin esfuerzo y luego choca contra un muro en mitad del tablero. He aquí el mecanismo: una pieza escasa gastada en el lugar equivocado, varias filas atrás.
- [La cosecha de teoremas: trece leyes estructurales](https://eternity2.dev/es/research/why/theorem-sweep/) — Un solo arco de investigación, trece familias de teoremas estructurales: pureza del anillo, el suelo de paridad en 479, el muro de 470 como frontera de fase, los invariantes de flujo, la ley de área entrópica, y los resultados de imposibilidad que ponen precio a cada atajo clásico. Esta página es el mapa.
- [Órdenes de relleno](https://eternity2.dev/es/research/build/backtracking/fill-order/) — El orden en que un algoritmo de backtracking visita las 256 celdas es su única libertad: no cuesta nada en tiempo de ejecución y mueve el tamaño del árbol de búsqueda en varios órdenes de magnitud. Veinte años de ciencia comunitaria, desde las guerras entre fijo y dinámico y las carreras de estrategias hasta el cuadrado mágico 10×16 y la búsqueda en peine de Verhaard, responden todos a la misma pregunta: ¿qué camino a través del tablero es el más barato?
- [El estudio DFS](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/dfs-study/) — Una sola pregunta, planteada con cuidado: entre los backtrackers en profundidad para Eternity II, ¿qué aporta realmente cada orden de relleno, cada heurística y el mecanismo de ruptura? Una familia de backtrackers escritos desde cero, separados cada uno por un único cambio, ejecutados sobre las mismas diez variantes con esquinas fijadas, en un solo núcleo, durante sesenta segundos.
---
# Diseñado para ser irresoluble: la receta
> Eternity II sigue una receta para lograr el puzzle de emparejamiento de aristas más difícil posible: forma compacta, sin piezas simétricas ni duplicadas, paletas separadas, frecuencias planas, una sola solución esperada. La comunidad aplicó ingeniería inversa a cada ingrediente en el año del lanzamiento.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/design-recipe/
- Actualizado: 2026-07-02
- Temas: structure
- Fuente: guenter stertenbrink plantea el problema de diseño: un puzzle con ~1 % de probabilidad de caer en diez años (msg 15, febrero de 2001) — https://groups.io/g/eternity2/message/15
- Fuente: Brendan Owen, Diseñar el puzzle más difícil: la receta completa y la derivación del 17,14 (msg 1947, agosto de 2007) — https://groups.io/g/eternity2/message/1947
- Fuente: Brendan Owen, Estimaciones del puzzle más difícil: la tabla de parámetros más duros para cada tamaño de tablero (msg 2164) — https://groups.io/g/eternity2/message/2164
- Fuente: Brendan Owen, Frecuencias de las piezas: la distribución plana que acabó con el método de Eternity I (msg 1667) — https://groups.io/g/eternity2/message/1667
- Fuente: Brendan Owen citando The Times: Selby y Riordan escribieron el generador para Monckton (msg 3373) — https://groups.io/g/eternity2/message/3373
- Fuente: El relato de Dave Clark de una llamada telefónica con Christopher Monckton sobre cómo se generó el puzzle (msg 4177) — https://groups.io/g/eternity2/message/4177
- Fuente: El censo del espacio de diseño de las piezas: 256 piezas de unas 21 000 posibles, formas simétricas evitadas (msgs 8014–8034; censo en msg 8025) — https://groups.io/g/eternity2/message/8025
- Fuente: Brendan Owen sobre la solución de los diseñadores guardada bajo llave en una caja fuerte (msg 8823) — https://groups.io/g/eternity2/message/8823
---
Eternity II no es un puzzle que resulte ser difícil por casualidad. Es el
producto de una receta: una breve lista de reglas de diseño que, aplicadas en
conjunto, producen el puzzle de emparejamiento de aristas más difícil que un
número dado de piezas puede formar, garantizando al mismo tiempo que existe una
solución. Lo notable es que la receta no fue filtrada ni publicada por los
diseñadores. La comunidad la reconstruyó, ingrediente a ingrediente, en cuestión
de semanas tras el lanzamiento, en su mayor parte en un único mensaje de agosto
de 2007 firmado por Brendan Owen y titulado, muy apropiadamente, «Diseñar el
puzzle más difícil»
([msg 1947](https://groups.io/g/eternity2/message/1947)).
Esta página recorre esa receta: qué es cada regla, qué le cuesta a cualquiera que
intente resolver el puzzle y de dónde procede cada afirmación. La medición del
ingrediente más afilado (el número de colores situado exactamente sobre el pico
de dificultad) tiene [su propia página](/es/research/why/phase-transition/); aquí
ocupa su lugar entre los demás.
## El problema precedió al puzzle
El problema de diseño se planteó en la lista de correo seis años antes de que
nadie tuviera que resolverlo. En febrero de 2001, con Eternity I apenas frío y
Eternity II aún como rumor, guenter stertenbrink preguntó al grupo cómo se
diseñaría un puzzle con un premio de 5 M£ de modo que tuviera solo alrededor de
un 1 % de probabilidad de ser resuelto en diez años
([msg 15](https://groups.io/g/eternity2/message/15)). Las respuestas
discutieron escalar una dificultad al estilo de Eternity I e incluso ocultar
problemas criptográficos en las aristas.
Esa es exactamente la cuerda floja que debe recorrer un puzzle con premio.
Hazlo demasiado fácil y el premio se pierde; eso es lo que le ocurrió a
Eternity I, que cayó en 2000 porque tenía muchísimas más soluciones de las que
su diseñador creía. Hazlo literalmente imposible y el concurso es un fraude. La
meta es un puzzle del que se puede demostrar que tiene una solución, situado de
tal manera que ninguna cantidad realista de cómputo la encuentre dentro de la
ventana del concurso. Los diseñadores de Eternity II habían visto morir a
Eternity I, y la receta que sigue se lee como una respuesta punto por punto.
## La receta, ingrediente a ingrediente
### Mantener la forma compacta
La primera regla de la derivación de Owen: usar un tablero compacto, el cuadrado
16×16, en lugar de cualquier forma alargada o irregular
([msg 1947](https://groups.io/g/eternity2/message/1947)). Una forma compacta
maximiza la proporción de uniones interiores, donde la incertidumbre es mayor, y
no deja brazos estrechos ni pasillos que un solucionador pudiera agotar a bajo
coste y usar como punto de anclaje. Owen verificó después la consecuencia de
forma experimental: en diseños 16×16 comparables con paletas desequilibradas
siempre hay alguna región más barata de teselar primero (para un reparto 2/19,
empezar por el centro sale más de cien veces más barato que un barrido por
filas), pero con los parámetros reales de E2 no existe ninguna región así. El
diseño no tiene, en sus propias palabras, «ninguna zona débil por donde empezar
a teselar»
([msg 5263](https://groups.io/g/eternity2/message/5263), comparación de diseños
[msg 5243](https://groups.io/g/eternity2/message/5243)).
### Sin piezas simétricas, sin duplicados
Cada una de las 256 piezas es única, y ninguna es simétrica por rotación
([msg 1947](https://groups.io/g/eternity2/message/1947)). En 2010 la comunidad
contabilizó el espacio de diseño para ver hasta qué punto esto es deliberado:
con 5 patrones de marco y 17 patrones interiores hay aproximadamente 21 000
diseños de pieza posibles, incluidas formas como *aaaa* y *abab* que se
repiten bajo rotación. El conjunto real las evita todas de forma ostensible
([msgs 8014–8034](https://groups.io/g/eternity2/message/8014)).
La consecuencia es la ausencia de regalos. Un par duplicado permitiría reescribir
cualquier solución intercambiando las dos piezas, duplicando gratis el número de
soluciones; una pieza con simetría de rotación colapsaría orientaciones y
encogería el espacio de decisión. Negar ambas cosas mantiene el número esperado
de soluciones fijado exactamente donde los diseñadores lo querían y entrega al
solucionador exactamente cero simetría que explotar: cada colocación es una
decisión plena e independiente entre 4 orientaciones de piezas distintas.
Hay una segunda razón, más discreta, para prohibir las piezas simétricas, y Owen
la midió. Una pieza simétrica no solo es estructuralmente redundante, sino que
además es más fácil de *colocar*, porque encaja en más contextos. Construyó un
conjunto de 289 piezas (las 17 formas con simetría de 90 grados, las 136 formas
con simetría de 180 grados y 136 piezas asimétricas aleatorias), teseló un
pequeño rectángulo de todas las maneras posibles y contó con qué frecuencia
aparecía cada pieza en el conjunto de los 759 millones de soluciones. Las piezas
asimétricas aparecían **2,08 veces** más a menudo que las de simetría de 180
grados y **4,14 veces** más a menudo que las de simetría de 90 grados
([msg 2076](https://groups.io/g/eternity2/message/2076)). Así que las piezas
simétricas son las *difíciles de teselar*, y un puzzle que las hubiera incluido
habría entregado al solucionador precisamente el asidero de teselabilidad
desigual que las [frecuencias de color planas](#hacer-que-toda-frecuencia-sea-plana)
están destinadas a eliminar. Prohibirlas mantiene cada pieza más o menos
igual de difícil de colocar, sin ninguna fácil que reservar para el final.
### Dos paletas, estrictamente separadas
Los 22 colores se reparten en 17 colores interiores y 5 que solo aparecen en las
uniones entre piezas de borde, nunca en el interior
([msg 1947](https://groups.io/g/eternity2/message/1947)). Esto convierte el marco
en su propio subpuzzle, cuya dificultad puede ajustarse de forma independiente
del interior, de modo que ninguna de las dos partes es un punto de entrada
blando: el mismo acto de equilibrio que la forma compacta, aplicado a la paleta.
Los cinco colores exclusivos del marco son además los raros, puestos en
cuarentena en el borde: al haber menos piezas de borde que de interior, y como
las celdas de borde admiten una sola orientación, la receta de Owen nivela los
dos grupos para que sus piezas sigan siendo más o menos igual de fáciles de
colocar, en lugar de dejar el marco como un punto de entrada blando y desigual
([msg 1947](https://groups.io/g/eternity2/message/1947)). Esa firma visible
tiene [su propia página](/es/research/why/rare-color-geography/).
### Hacer que toda frecuencia sea plana
Cuando Owen digitalizó su conjunto el día del lanzamiento, encontró la
distribución de colores de arista «tan plana como podía ser»: 24 aristas de cada
uno de los 5 colores de unión de borde, 48–50 de cada uno de los 17 colores
interiores ([msg 1054](https://groups.io/g/eternity2/message/1054)).
Este único ingrediente es el que acabó con la estrategia de Eternity I.
Eternity I se resolvió en gran parte mediante el ordenamiento por dificultad de
las piezas: las teselabilidades de sus piezas variaban enormemente, de modo que
los solucionadores podían reservar las piezas más fáciles para el final y dejar
que las estadísticas los llevaran a buen puerto. Dos semanas después del
lanzamiento, Owen mostró que la distribución plana de E2 vuelve inútil ese
enfoque: cuando cada color es igual de común, cada pieza es más o menos igual de
teselable, y ninguna heurística de ordenamiento gana tracción
([msg 1667](https://groups.io/g/eternity2/message/1667)). Como lo expresó en
respuesta doc_s_smith, una de las personas que realmente resolvieron Eternity I,
la selección de la posición más restringida se convirtió en «nuestra única otra
esperanza» ([msg 1722](https://groups.io/g/eternity2/message/1722)).
### Apuntar a exactamente una solución
El último ingrediente fija los propios recuentos de colores. Owen razonó hacia
atrás a partir del requisito de «alrededor de una solución esperada»: imponer que
el número esperado de teselados interiores sea 1 y resolver para el número de
colores interiores da
$$I = (196! \cdot 4^{196})^{1/392} \approx 17.14$$
Redondea a 17, añade los 5 colores de borde ajustados por separado, y tienes la
paleta exacta de Eternity II
([msg 1947](https://groups.io/g/eternity2/message/1947)). Owen respaldó la
derivación con simulaciones, defendió el 17+5 frente al diseño vecino 16+8 de la
misma familia de una solución esperada, ya que equilibra mejor la teselabilidad
de las piezas de borde e interiores y no deja ninguna entrada barata por el marco
([msg 2426](https://groups.io/g/eternity2/message/2426)), y lo completó con una
tabla de los parámetros más duros para cada tamaño de tablero, una receta general
de la que E2 es la fila 16×16
([msg 2164](https://groups.io/g/eternity2/message/2164)).
Una solución esperada no es un capricho estético arbitrario. Es el ajuste en el
que las soluciones son tan escasas como pueden serlo sin dejar de existir: el
pico de la transición de fase, el punto en el que se puede demostrar que la
búsqueda está en su peor momento. Esa medición, y los análisis publicados que más
tarde confirmaron el número de Owen, viven en la
[página del pico de dificultad](/es/research/why/phase-transition/). El reverso
prueba que la perilla es real: un diseño 16×16 deliberadamente *relajado* que se
discutió en la lista tiene alrededor de 10^42 soluciones esperadas, aunque Owen
advirtió que incluso ese no es ningún paseo
([msg 4968](https://groups.io/g/eternity2/message/4968)).
## Quién lo diseñó realmente
Christopher Monckton inventó la franquicia Eternity y puso el premio, pero su
idea original para la secuela era un puzzle tridimensional de 1001 piezas. Owen
lo relató señalando que «el diseño real es de Alex y Oliver»
([msg 2697](https://groups.io/g/eternity2/message/2697)). Alex Selby y Oliver
Riordan son los dos matemáticos que ganaron Eternity I al descubrir que tenía
muchas más soluciones de las previstas; Monckton contrató a quienes lo habían
vencido. El grupo lo sospechó semanas antes del lanzamiento
([msg 716](https://groups.io/g/eternity2/message/716)), lo vio confirmado en un
folleto oficial de Tomy (el inventor se reunió con los ganadores de E1 en un
programa matutino de televisión y les pidió que trabajaran en el desarrollo de
E2; [msg 901](https://groups.io/g/eternity2/message/901)), y finalmente lo
rastreó hasta un artículo de The Times: Selby y Riordan diseñaron el programa
generador del puzzle ([msg 3373](https://groups.io/g/eternity2/message/3373)).
Esa procedencia explica la precisión de la receta. El único equipo del planeta
con experiencia de primera mano de cómo fracasa estadísticamente un puzzle con
premio fue pagado para asegurarse de que ese modo de fallo había desaparecido.
Cada ingrediente anterior (planitud, ausencia de duplicados, paletas
equilibradas, una solución esperada) cierra una puerta que el propio Selby y
Riordan habían atravesado en 2000.
## Cómo se generaron las piezas: un relato de segunda mano
El único relato detallado del proceso de generación que hay en el archivo es de
segunda mano y debe leerse como tal. Dave Clark, fundador del proyecto
distribuido eternity2.net, contó una larga conversación telefónica que mantuvo
con Monckton el 26 de julio de 2007: el puzzle se generó a partir de la entropía
tecleada al teclado por los jueces del concurso (unas 200 entradas), regenerado
hasta que los jueces quedaron satisfechos, luego impreso una sola vez y guardado
en la caja fuerte. Monckton le describió el generador de números aleatorios como
uno que usa «residuos gaussianos de potencias de números primos elegidos
adecuadamente», lo que Clark interpretó como la propia implementación de Selby y
Riordan ([msg 4177](https://groups.io/g/eternity2/message/4177)). El hilo
consideró brevemente la idea de atacar un generador criptográficamente débil; una
respuesta señaló que si la construcción era de tipo Blum–Blum–Shub sería
demostrablemente difícil ([msg 4180](https://groups.io/g/eternity2/message/4180)).
Nada salió de esa vía, pero el relato sigue siendo la mejor fuente casi primaria
del archivo sobre el verdadero origen de las 256 piezas.
## La póliza de seguro
Un puzzle diseñado para no ser resuelto nunca todavía tiene que demostrar que
*puede* serlo. El material de lanzamiento de Tomy declaraba que nadie, ni el
inventor ni los diseñadores, conoce la solución: el generador la imprimió «entre
páginas de texto aleatorio mientras todas las partes estaban fuera de la sala», y
la salida se selló ante testigos
([msg 901](https://groups.io/g/eternity2/message/901)). Una vez que el concurso
terminó sin ganador, Owen dio la afirmación que aún se cita hoy: «Estoy seguro de
que Alex y Oliver crearon una solución cuando Chris les pagó para generar un
puzzle prácticamente imposible», y que yace oculta entre resmas de texto impreso
guardadas bajo llave en una caja fuerte, como seguro frente a cualquier
impugnación legal de la buena fe del concurso
([msg 8823](https://groups.io/g/eternity2/message/8823)).
Esa caja fuerte es el ingrediente final de la receta. La solución diseñada es lo
que permite al puzzle situarse en una solución esperada en lugar de en cero:
existencia garantizada por construcción, descubrimiento tarificado más allá del
alcance de cualquier concursante.
## Qué significa la receta si atacas el puzzle hoy
Cada atajo genérico al que podrías recurrir fue anticipado y tarificado hace casi
dos décadas. El ordenamiento por frecuencia de las piezas murió con la
distribución plana. Los trucos de simetría y de duplicados no tienen nada a lo
que aferrarse. No hay ninguna región blanda que teselar primero, ningún
desequilibrio de paleta que usar como palanca, y el número de colores se sitúa en
el ajuste exacto donde la búsqueda es peor. El techo bruto de la comunidad solo
se ha movido dos veces en veinte años (467 en 2008, 470 en 2021) y ahí se
mantiene desde entonces (la vía de pistas estrictas, en cambio, ha seguido
avanzando por su cuenta; véase [/research/records](/es/research/records/)); esa
meseta es la lectura empírica de un diseño que funcionó precisamente como se
pretendía. Eso no vuelve
el puzzle imposible: una solución existe de forma certificada, impresa y guardada
bajo llave. Significa que la brecha restante no es un problema de ajuste. Lo que
la cierre tendrá que ser una idea que los diseñadores no pudieran anticipar. Eso
es, al fin y al cabo, para lo que sirve este wiki.
## Relacionado
- [Calibrado en el pico de dificultad](https://eternity2.dev/es/research/why/phase-transition/) — Eternity II utiliza 22 colores, repartidos entre 17 colores interiores y 5 reservados al marco, y ese número de alrededor de 17 se sitúa cerca del punto donde este tipo de puzzle es más difícil de resolver (la transición es una banda, no un entero único).
- [Los colores raros viven en el marco](https://eternity2.dev/es/research/why/rare-color-geography/) — Cinco de los 22 colores de Eternity II aparecen solo a lo largo del anillo de borde, cada uno en exactamente 24 aristas, nunca una sola vez en el interior. Una separación estructural que moldea la forma en que cada solucionador trata el marco.
- [La cacería, una historia (parte I: 2000-2009)](https://eternity2.dev/es/research/community/hunt/) — La historia de la comunidad, desde una lista de correo fundada siete años antes de que el puzzle existiera hasta el premio de escrutinio de 10.000 $ ganado bajo un nombre prestado, con cada suceso rastreado hasta su mensaje original. Parte I de una crónica en desarrollo.
---
# La entropía y la ley de área
> Eternity II tiene dos reglas: los bordes deben coincidir y cada pieza se usa una sola vez. La primera es generosa. Toda la dificultad reside en la segunda.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/entropy-area-law/
- Actualizado: 2026-07-22
- Temas: structure
- Reproducir: `just research-entropy-area-law`
- Fuente: El lema de subaditividad de Fekete, el teorema que garantiza la existencia misma del límite de entropía h∞ — https://en.wikipedia.org/wiki/Subadditivity#Subadditive_sequences
- Fuente: La entropía de Shannon de una fuente, las cantidades h(n) medidas aquí — https://doi.org/10.1002/j.1538-7305.1948.tb01338.x
---
CartesianGrid,
Line,
LineChart,
ResponsiveContainer,
Tooltip,
XAxis,
YAxis,
} from "recharts";
Olvidemos por un momento la regla de usar cada pieza una sola vez y tratemos
las 196 piezas interiores como piezas reutilizables. Al contar los bloques
enteramente compatibles, se observa que crecen exponencialmente con el
tamaño: no faltan formas localmente válidas de teselar. La gramática de
coincidencia es rica, no restrictiva.
Esa riqueza se puede medir exactamente. Para una banda de ancho $n$, la tasa
de crecimiento por celda es una densidad de entropía $h(n)$, y la sucesión
decrece hacia el verdadero valor bidimensional a medida que la banda se
ensancha.
## La entropía de la gramática, ancho a ancho
> **[Figure]** interactive: EntropyChart. Rendered on the canonical page (link above); not shown in this markdown export.
## Luego golpea la ley de área
Ahora restablezcamos la regla de usar cada pieza una sola vez y preguntémonos
con qué frecuencia un bloque $n \times n$ compatible en colores emplea
realmente piezas distintas. Llamémoslo $\rho(n)$. Lo contamos de forma exacta,
en el repositorio: para cada tamaño de bloque interior contamos $A(n)$, los
rellenos compatibles en colores cuando las piezas pueden repetirse, y $B(n)$,
los que usan piezas distintas, y tomamos $\rho(n) = B(n)/A(n)$. Se derrumba, y
se derrumba según el área, no según el perímetro:
$$
\rho(n) \;\approx\; \exp(-\alpha\, n^2), \qquad \alpha \approx 0.044.
$$
El exponente se ajusta por mínimos cuadrados sobre el rango contado con
exactitud: $A$ y $B$ se calculan aquí para $n$ hasta $3$ (y $A$ hasta $4$), con
$B(2) = 4\,059\,952$ coincidiendo con la tabla de referencia de sub-bloques del
repositorio. El exponente por bloque aún crece en ese pequeño rango (0,029 en
$n=2$, 0,048 en $n=3$), así que 0,044 es una estimación baja del valor para
bloques grandes. En $n=4$ el recuento reutilizable $A(4)$ ya alcanza
$6{,}3\times10^{16}$, más allá de la enumeración distinta exacta en un tiempo
razonable; por eso la curva más allá de $n=3$ es una extrapolación del ajuste.
Un decaimiento por ley de área es brutal porque el área crece de forma
cuadrática. Por extrapolación, la fracción de bloques realizables cae por
debajo de uno entre mil hacia las 155 celdas. (Un estudio fuera del sitio
anterior reportaba un $\alpha \approx 0.085$ más pronunciado y un umbral hacia
las 80 celdas; los recuentos exactos del repositorio sobre $n \le 3$ dan las
cifras más suaves de aquí, y el exponente por bloque creciente es compatible con
que el valor fuera del sitio se alcance en bloques mayores.)
> **[Figure]** interactive: RhoChart. Rendered on the canonical page (link above); not shown in this markdown export.
## Ver cómo se abre la brecha
La misma idea aplicada a las piezas reales, contadas exactamente. Varía el
tamaño del bloque y observa cuántos bloques compatibles en colores sobreviven
a la regla de usar cada pieza una sola vez.
> **[Figure]** Interactivo: colapso de la distinción y decaimiento de rho — interactive: EntropyScarcityLab. Rendered on the canonical page (link above); not shown in this markdown export.
## Por qué importa
Un colapso del orden de la centena de celdas está a la escala de los
movimientos más pequeños que separan los mejores tableros conocidos. La
gramática de coincidencia se mantiene rica, y luego la regla de distinción la
colapsa sobre el área. Así que el muro no está en la parte que parece difícil,
la coincidencia de colores; está en la regla silenciosa de que cada pieza se
usa una sola vez, cuyo coste crece con el área, sobre un tablero apenas lo
bastante grande como para que muerda.
Ver [por qué el basin-hopping es imposible](/es/research/why/sigma-cycles/).
## El teorema, en breve
La entropía por ancho tiene un límite bien definido. Unir lado a lado una
banda de ancho $n_1$ y una de ancho $n_2$ solo añade una restricción de
costura, de modo que los valores propios satisfacen
$$
\lambda_{n_1+n_2} \;\le\; \lambda_{n_1}\,\lambda_{n_2}.
$$
Al tomar logaritmos, $\log \lambda_n$ se vuelve subaditiva, y el lema de
Fekete da el límite como un ínfimo, que es exactamente la razón por la que la
curva de arriba decrece:
$$
h_\infty \;=\; \lim_{n\to\infty}\frac{\log_{10}\lambda_n}{n} \;=\; \inf_n \frac{\log_{10}\lambda_n}{n}.
$$
La cota superior es la tasa puramente horizontal: ignorar las restricciones
verticales solo añade bloques, de modo que
$$
0 \;<\; h_\infty \;\le\; \log_{10}\lambda_H \;=\; 1.6645,
$$
con $\lambda_H = 46.18$ el radio espectral de la matriz de compatibilidad de
colores en horizontal. La positividad se cumple porque la gramática admite
exponencialmente muchas cadenas, de modo que la densidad está estrictamente
comprendida entre cero y 1,6645, medida en torno a 0,67.
Lo que el teorema demuestra es que existe un límite positivo y que está acotado
superiormente por $\log_{10}(46.18) = 1.6645$. Su valor concreto en torno a
0,67 proviene de un barrido fuera de línea. El exponente de ley de área
$\alpha \approx 0.044$ se ajusta aquí a partir de los recuentos de bloques
exactos del repositorio sobre $n \le 3$; su extrapolación a bloques mayores (y
el umbral de las ~155 celdas) va más allá del rango contado con exactitud. El
teorema no fija esos valores.
## Relacionado
- [Calibrado en el pico de dificultad](https://eternity2.dev/es/research/why/phase-transition/) — Eternity II utiliza 22 colores, repartidos entre 17 colores interiores y 5 reservados al marco, y ese número de alrededor de 17 se sitúa cerca del punto donde este tipo de puzzle es más difícil de resolver (la transición es una banda, no un entero único).
- [Por qué un ordenador más rápido no ayuda](https://eternity2.dev/es/research/why/prune-vs-speed/) — La idea más importante de la búsqueda combinatoria difícil: reducir el espacio que se explora vence, por un margen exponencial, a explorarlo más rápido. Eternity II está diseñado para que apenas puedas reducirlo.
- [Patrones prohibidos](https://eternity2.dev/es/research/why/forbidden-patterns/) — Casi todo pequeño conjunto de piezas que podrías construir es imposible. Para un cuadrado 2×2, el 99,72 % de las formas de colocar cuatro piezas nunca podrá encajar.
- [El robo de piezas, donde mueren los solucionadores](https://eternity2.dev/es/research/why/piece-theft/) — Un solucionador rellena unas pocas filas sin esfuerzo y luego choca contra un muro en mitad del tablero. He aquí el mecanismo: una pieza escasa gastada en el lugar equivocado, varias filas atrás.
- [Contar soluciones: medir lo que no se puede encontrar](https://eternity2.dev/es/research/build/analysis/solution-counting/) — Nadie ha visto jamás una solución completa de Eternity II y, sin embargo, la comunidad sabe, con un margen de un factor de dos, cuántas existen. Esta página cuenta la historia y el oficio de ese número: censos exactos en tableros pequeños, la fórmula de esperanza y su convergencia sobre 14 702 a lo largo de veinte años, y las estimaciones por búsqueda podada en las que solo se confió cuando cuatro ejecuciones independientes coincidieron.
---
# Invariantes de flujo: una ley de rotación que el conjunto oficial cumple exactamente
> Pondere cada color de arista y lea cada pieza como un vector con signo, este menos oeste en un eje, sur menos norte en el otro. Sumado sobre cualquier región, las costuras interiores se cancelan y solo sobrevive el borde, de modo que el tablero totaliza cero. Un cuarto de vuelta gira el vector un ángulo recto, lo que vuelve la ley álgebra en los enteros de Gauss.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/flux-invariants/
- Actualizado: 2026-07-22
- Temas: structure
- Fuente: Invariantes de flujo: topic de reproducción con el artículo, el verificador versionado y el JSON de resultados (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/flux-invariants
- Fuente: Conway y Lagarias, Tiling with polyominoes and combinatorial group theory: los invariantes de palabra de borde que esta ley adapta al emparejamiento de aristas (JCTA 1990) — https://doi.org/10.1016/0097-3165(90)90057-4
- Fuente: Brendan Owen digitaliza el conjunto de piezas: el histograma de colores que esta ley confronta (groups.io msg 1054, julio de 2007) — https://groups.io/g/eternity2/message/1054
- Fuente: Brendan Owen, Design the hardest puzzle: la separación deliberada de las paletas de borde e interior (groups.io msg 1947, agosto de 2007) — https://groups.io/g/eternity2/message/1947
---
Los scores de esta página siguen la convención de emparejamiento de aristas: el
score de un tablero es el número, de las 480 junturas interiores, cuyas dos
medias aristas muestran el mismo color. Una solución completa vale 480. Los
invariantes de abajo no tratan del score de un tablero; tratan de las rotaciones
de piezas que un tablero-480 válido tiene derecho a emplear, y se cumplen para
toda solución válida, sea cual sea su score.
## La idea en una línea
Dé a cada uno de los 22 colores de arista un peso numérico, con el color de borde
gris pesando cero. Lea una pieza colocada como un vector de dos dimensiones: su
peso este menos su peso oeste en el eje horizontal, su peso sur menos su peso
norte en el eje vertical. Ahora sume ese vector sobre un bloque de piezas
colocadas. Cada costura interior del bloque es compartida por dos piezas, y entra
en la suma una vez con signo más desde una pieza y una vez con signo menos desde
su vecina, el mismo color en ambas caras, de modo que las dos se cancelan. Nada
sobrevive a la suma salvo el borde exterior del bloque.
Sobre el tablero entero ese borde exterior es el reborde gris, de peso cero, así
que el total es exactamente el vector nulo. Es una ley de conservación, la prima
discreta de un teorema de la divergencia: el flujo que sale de toda región iguala
al flujo que cruza su frontera, y para el tablero entero la frontera no lleva
flujo alguno.
## Por qué un cuarto de vuelta trae los números complejos
El vector no es ciego a la rotación. Gire una pieza noventa grados en sentido
horario y su color norte pasa al este, el este al sur, el sur al oeste, el oeste
al norte. Siga lo que eso le hace al vector y los ejes horizontal y vertical se
intercambian con un signo: el nuevo vector es el viejo girado un ángulo recto. En
el plano, un giro de ángulo recto es una multiplicación por la unidad imaginaria.
Así que si escribe el vector como un número complejo, un cuarto de vuelta de la
pieza lo multiplica por $i$, y las cuatro rotaciones que una pieza cuadrada puede
tomar corresponden a las cuatro potencias $1, i, -1, -i$.
Ese solo hecho es lo que eleva una identidad de contabilidad a álgebra. La ley de
conservación, escrita color por color, dice que cierta suma de enteros de Gauss,
un término por pieza, cada uno multiplicado por una potencia de $i$ fijada por la
rotación elegida de esa pieza, debe dar cero. Es una restricción no sobre dónde
van las piezas sino sobre qué rotaciones puede adoptar el conjunto entero.
## La familia completa, y qué es nuevo
El grupo de rotación de un cuadrado tiene cuatro caracteres, y la ley de flujo es
solo uno de ellos. Descomponer la pieza según los cuatro da el retículo completo
de los invariantes lineales, intrínsecos a la pieza, del emparejamiento de
aristas: nada lineal se le escapa. Los cuatro miembros son un simple censo de
colores (ciego a la rotación, el recuento total de cada color en la pieza), la ley
de flujo gaussiana que se acaba de describir, su conjugado complejo (la misma
información), y un cuarto miembro, de valores enteros, que acopla la elección de
cada pieza sobre qué par de aristas opuestas queda horizontal al color de tablero
de ajedrez de su celda. Este último es el eco, del lado del emparejamiento de
aristas, de la obstrucción de bicoloración que Conway y Lagarias usaron para el
teselado con poliominós, el método de palabra de borde del que toda esta familia
está adaptada.
El censo no es novedad: es solo conteo de colores. El valor de la ley de flujo es
que ella sí lo es. En el conjunto oficial su sombra ciega a la rotación, la
versión que se obtiene al olvidar la $i$ y fusionar más y menos, es idénticamente
nula para los 22 colores, porque todo recuento de color en el tablero es par.
Dicho de otro modo, el conteo de colores ya sabe todo lo que la sombra podría
decirle, y no sabe nada más. Cada restricción que la ley de flujo impone más allá
de esa sombra es información realmente nueva que un censo no puede ver.
## El álgebra lineal en la instancia real
Alinee los 22 colores como filas y las 256 piezas como columnas, y los
coeficientes de flujo por pieza forman una matriz. Su rango mide cuánto restringe
realmente la ley al puzzle. Recalculados sobre el conjunto oficial de 256 piezas,
los números salen así.
22
rango complejo, pleno (22 de 22 colores)
40
restricciones reales independientes
21
restricciones de paridad independientes (mod 2)
Un rango complejo pleno de 22 significa que la ley liga los 22 colores a la vez,
sin que ningún color quede fuera como variable libre. Dividir las ecuaciones
complejas en sus partes real e imaginaria da 40 restricciones reales
independientes sobre la asignación de rotaciones. Y reducir todo el sistema módulo
2, donde la rotación de una pieza colapsa a un único bit de paridad (un cuarto de
vuelta y un tres cuartos de vuelta se vuelven iguales módulo 2), deja 21
restricciones de paridad independientes, con el sistema aumentado quedando también
de rango 21, así que es consistente y no contradictorio. Ese sistema módulo 2 por
sí solo retira un factor de unos dos millones del espacio de paridades de
rotación.
Los hechos de instancia que la ley confronta se reproducen también exactamente,
dígito por dígito frente al conjunto de piezas digitalizado por Brendan Owen: 196
piezas interiores, 56 piezas de borde, 4 esquinas; el color de borde gris en 64
medias aristas; cinco colores de marco que solo tocan piezas de borde, 24 medias
aristas cada uno; los colores interiores restantes repartiéndose en cinco a 48 y
doce a 50; y todo recuento de color par, que es exactamente lo que exige un
emparejamiento de aristas perfecto. Las cinco pistas oficiales son todas piezas
interiores. Nada de esto depende de confiar en una numeración de colores: el
verificador deriva el conjunto de colores de marco de los datos (los colores que
nunca aparecen en una pieza interior), de modo que una renumeración entre el kit
inicial y la lista fuente no puede engañarlo.
## De una ley a una comprobación de final
Una ley de conservación que debe cumplirse para el tablero entero restringe
también a cualquier tablero parcial, porque las piezas aún por colocar deben
llevar exactamente el flujo que a las piezas colocadas les falta. Durante una
búsqueda que llena la rejilla pieza a pieza, el flujo que deben las piezas
restantes queda fijado en el instante en que el conjunto colocado queda fijado. Si
ninguna asignación de rotaciones a las piezas restantes puede suministrar ese
flujo debido, el tablero parcial está muerto, y se puede parar sin buscar su
subárbol.
Reducido módulo 2 esto se vuelve un pequeño sistema lineal sobre las paridades de
rotación de las piezas restantes, decidido por eliminación de Gauss, y es un
certificado de final fiable. Fiable quiere decir que nunca rechaza un tablero que
sea de verdad completable: la ley es una condición necesaria, así que un parcial
real siempre pasa. Lo que sí puede hacer es atrapar un error. Probado sobre un
depósito de tableros 8 por 8 resueltos y enmarcados, con rotaciones implantadas,
inyectando una única rotación ilegal en el prefijo colocado, la comprobación no
rechazó ni una sola vez un parcial válido en 3 600 ensayos, y su probabilidad de
atrapar el error inyectado crecía con la fracción de llenado.
| Fracción de llenado | Parciales válidos rechazados | Error de rotación único atrapado |
|---|---|---|
| 0,50 | 0 de 900 | 0,6 % |
| 0,75 | 0 de 900 | 14,1 % |
| 0,90 | 0 de 900 | 88,3 % |
| 0,95 | 0 de 900 | 94,6 % |
El contenido reproducido aquí es el mecanismo y la forma de esa curva, no los
porcentajes exactos. La fuente reporta una curva más pronunciada (13 %, 50 %,
100 % en los llenados 0,50, 0,75, 0,90) sobre una familia implantada distinta; el
run de arriba usa un tablero 8 por 8 a 13 colores con una pieza inyectada elegida
uniformemente y un depósito de 30 tableros, 30 órdenes cada uno (900 por llenado), de
modo que las tasas de detección absolutas quedan más bajas. Lo que se cumple
exactamente, y ese es el punto, es que el certificado es fiable y que su
probabilidad de detección sube de forma monótona hacia el pleno a medida que el
tablero se llena. Ese es precisamente el comportamiento útil para una búsqueda: la
comprobación se afila justo donde la cola de ramificación del árbol es más costosa,
hacia el final, y cada captura es ortogonal al podado por color y por recuento, así
que se suma por encima en vez de duplicarlos.
## Qué es y qué no es
La ley de flujo es una obstrucción. Puede certificar un tablero parcial como
muerto; nunca puede certificar uno como completable. Ese es el papel correcto y
buscado para un invariante dentro de una búsqueda por ramificación y podado, y lo
comparten todos los resultados de esta familia. Dos advertencias más, dichas con
claridad. La ley restringe las rotaciones que el conjunto de piezas puede emplear,
no la celda donde cada pieza se coloca; solo el miembro de tablero de ajedrez se
acopla a la posición, y solo por la paridad de la celda, de modo que ningún
miembro fija una pieza a un lugar. Y la extensión no lineal natural, un producto
de palabra de borde no abeliano al estilo de la construcción original de Conway y
Lagarias, no sobrevive en dos dimensiones: una celda interior tiene cuatro aristas
compartidas pero solo dos vecinas adyacentes a ella en cualquier orden de lectura
lineal, de modo que al menos dos de sus aristas nunca podrán cancelarse, y la
construcción recae en la ley de flujo lineal. Todo invariante estrictamente más
fuerte que estos ha de ser no lineal y queda fuera de la familia de los grupos de
teselado.
## Dónde se ubica
Este es el recuento detallado de una ley de la
[revisión de teoremas](/es/research/why/theorem-sweep/), el arco que preguntó qué se
podía probar sobre la instancia en vez de qué score se podía alcanzar. Se ubica
junto a la [pureza del anillo](/es/research/why/ring-purity/), la otra ley exacta que
el borde cumple, y es el complemento algebraico de la
[lente del código de permutación](/es/research/why/permutation-code-wall/), que lee el
tablero entero como una palabra de código: la ley de flujo es un conjunto de
comprobaciones de paridad que las rotaciones deben satisfacer, la misma moneda en
la que esa lente está escrita. La
[página de teoría compleja](/es/research/why/complex-theory/) cuenta cuán ancha es la
búsqueda; esta página añade una manera barata y fiable de podar su final.
Cada número de arriba es recalculado por el verificador versionado en el topic de
reproducción enlazado bajo las fuentes: un único programa Rust determinista que
carga la instancia oficial, deriva los colores de marco de los datos, calcula los
tres rangos, verifica la sombra de ortogonalidad al censo y ejecuta el barrido de
final semilla a semilla, emitiendo un único archivo JSON (versionado como
`results/flux_invariants.json`) que contiene cada cifra citada aquí. Los hechos de
instancia y los rangos se reproducen byte por byte; el certificado reporta su
propia curva de capturas, fiable en cada llenado.
## Relacionado
- [La cosecha de teoremas: trece leyes estructurales](https://eternity2.dev/es/research/why/theorem-sweep/) — Un solo arco de investigación, trece familias de teoremas estructurales: pureza del anillo, el suelo de paridad en 479, el muro de 470 como frontera de fase, los invariantes de flujo, la ley de área entrópica, y los resultados de imposibilidad que ponen precio a cada atajo clásico. Esta página es el mapa.
- [Pureza del anillo: el borde es un subpuzle cerrado, sin holgura](https://eternity2.dev/es/research/why/ring-purity/) — Cinco de los 22 colores nunca tocan las 196 piezas interiores. La lista de piezas obliga a toda solución válida a gastar las 120 semiaristas de marco en el anillo del borde: un subpuzle autónomo con holgura exactamente nula (120 = 120), un circuito euleriano sobre cinco vértices, acoplado al interior solo por 56 aristas orientadas hacia dentro.
- [El tablero como palabra de código](https://eternity2.dev/es/research/why/permutation-code-wall/) — Lee un tablero completo como una palabra de código cuyas 480 junturas interiores son comprobaciones de tipo paridad, y el score de aristas emparejadas pasa a ser 480 menos el número de comprobaciones fallidas. Es una lente limpia que descansa sobre una sola identidad portante, y conviene ser preciso sobre lo que la vista de códigos correctores aporta y lo que solo renombra.
- [La teoría compleja: contar el árbol de búsqueda antes de recorrerlo](https://eternity2.dev/es/research/why/complex-theory/) — La teoría compleja de Brendan Owen estima la anchura del árbol de búsqueda a cada profundidad, e incluso cuántas soluciones existen en total. Muchos en la comunidad la consideran lo más importante que hay que entender sobre Eternity II.
---
# Patrones prohibidos
> Casi todo pequeño conjunto de piezas que podrías construir es imposible. Para un cuadrado 2×2, el 99,72 % de las formas de colocar cuatro piezas nunca podrá encajar.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/forbidden-patterns/
- Actualizado: 2026-07-01
- Temas: structure, search-space
- Reproducir: `just research-forbidden-patterns`
- Fuente: Patrones prohibidos: artículo, código fuente y resultados (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/forbidden-patterns
---
Eternity II tiene 256 piezas cuadradas, cada una con un color en sus cuatro
lados. 196 de ellas son piezas interiores, las que no tienen ninguna arista de
borde gris, así que son las únicas que llegan a situarse dentro del tablero.
Toma unas cuantas, colócalas en una pequeña forma y gíralas como quieras. La
mayoría de las veces, los colores simplemente no cuadrarán, hagas lo que hagas.
Cuanto más grande es la forma, peor se pone. Dos piezas una al lado de la otra
no encajan aproximadamente el 39 % de las veces. Añade una tercera en L y te
quedas atascado el 83 % de las veces. Cierra un cuadrado 2×2 y el 99,72 % de
todas las colocaciones nacen muertas: solo funciona alrededor de 1 de cada 358.
## Una que encaja, otra que no puede
> **[Figure]** interactive: BoardSvg. Rendered on the canonical page (link above); not shown in this markdown export.
> **[Figure]** interactive: BoardSvg. Rendered on the canonical page (link above); not shown in this markdown export.
## Pruébalo: saca cuatro piezas
> **[Figure]** Interactivo: pinta un conjunto y míralo prohibirse a sí mismo — interactive: ForbiddenPatchLab. Rendered on the canonical page (link above); not shown in this markdown export.
## De dónde sale el 99,72 %
Una estimación aproximada explica por qué el número es tan alto. Dos piezas
adyacentes comparten una arista. Cada pieza interior lleva colores de la paleta
interior de 17 colores, de modo que un par aleatorio de medias aristas encaja
con una probabilidad de aproximadamente
$$
\Pr[\text{one edge matches}] \;\approx\; \frac{1}{17} \;\approx\; 6\%.
$$
Un cuadrado 2×2 tiene cuatro aristas internas que satisfacer a la vez. Las
rotaciones dan cuatro oportunidades a cada pieza, pero las cuatro aristas están
acopladas, de modo que una estimación de independencia hecha a ojo sitúa la
probabilidad de que las cuatro encajen en, muy aproximadamente,
$$
\Pr[\text{2}\times\text{2 feasible}] \;\sim\; 1 - \left(1 - \tfrac{1}{17}\right)^{\!c} \ \text{per rotation budget} \;\Rightarrow\; \lesssim 1\%,
$$
lo cual ya está por debajo del uno por ciento. El recuento exhaustivo exacto
llega al 0,28 % de configuraciones factibles, es decir, el 99,72 % prohibidas
$(\,0.28\% = \tfrac{3{,}993{,}696}{1{,}431{,}033{,}240}\,)$. La estimación es
burda porque las aristas no son independientes y los colores no son uniformes,
pero acierta el orden de magnitud y muestra por qué cerrar un cuadrado es mucho
más difícil que colocar un solo par.
## Los recuentos exactos
Toda colocación de piezas distintas de cada forma, verificada exhaustivamente,
sin muestreo.
| Forma | Colocaciones | Prohibidas | % prohibidas |
| ---------------- | -------------: | ------------: | ----------: |
| Dos una al lado de otra | 38,220 | 14,890 | 38.96% |
| Dos apiladas | 38,220 | 14,890 | 38.96% |
| L de tres | 7,414,680 | 6,173,828 | 83.26% |
| Cuadrado 2×2 | 1,431,033,240 | 1,427,039,544 | 99.72% |
Calculado exactamente a partir del conjunto oficial; la ejecución se reproduce
de forma idéntica cada vez (unos veinte segundos). El
[artículo, el código fuente y los resultados están en GitHub](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/forbidden-patterns).
## Prohibido antes incluso de elegir una pieza
La escasez empieza un nivel por debajo de las piezas enteras, en los colores.
Una celda interior muestra dos de los 17 colores interiores en cualquier
esquina dada, las dos aristas que se encuentran allí, lo que da
$17 \times 17 = 289$ pares de colores ordenados posibles. No todos existen. Ya
en 2008 la comunidad notó que **20 de esos 289 pares son ausencias**: ninguna
pieza interior, en ninguna rotación, presenta ese par concreto de colores en
aristas adyacentes
([msg 5027](https://groups.io/g/eternity2/message/5027)). Así que un tablero
parcial que obliga a una celda a responder con uno de esos 20 pares de esquina
está muerto en el acto, antes de probar una sola pieza, y un solucionador rápido
puede rechazarlo con una única consulta de tabla. Es la misma lección que el
recuento 2×2, llevada hasta la unidad más pequeña que puede ser imposible: las
restricciones muerden tan pronto que categorías enteras de demanda local no
tienen ninguna respuesta legal en absoluto.
## Por qué importa
Un tablero terminado y correcto tiene cero conjuntos prohibidos: por
definición, todo encaja. Así que contar los conjuntos prohibidos de un tablero
indica aproximadamente a qué distancia está de una solución real, incluso
cuando dos tableros tienen el mismo número de aristas encajadas. Los tableros
débiles están llenos de cuadrados prohibidos; los mejores tableros jamás
encontrados solo conservan un par de docenas.
También muestra, desde otro ángulo, por qué el puzzle se sacude los arreglos
locales ingeniosos. Cuando el 99,72 % de los pequeños cuadrados son imposibles,
las piezas que sí encajan entre sí son raras y específicas. No hay casi margen
para reordenar las cosas sin romper algo. Los buenos arreglos son escasos y
rígidos.
## Un segundo eje de progreso
Contar los cuadrados prohibidos convierte la idea en una señal utilizable. Toma
un tablero récord real: el número de ventanas 2×2 prohibidas disminuye a medida
que sube la puntuación de aristas encajadas. Dos tableros con la misma
puntuación de aristas aún pueden diferir aquí: el que tiene menos cuadrados
prohibidos está estructuralmente más cerca de una solución, y por eso algunos
solucionadores siguen el recuento de conjuntos prohibidos como criterio de
desempate.
> **[Figure]** Interactivo: cuenta las colocaciones factibles frente a las prohibidas — interactive: ForbiddenCountLab. Rendered on the canonical page (link above); not shown in this markdown export.
## Relacionado
- [La entropía y la ley de área](https://eternity2.dev/es/research/why/entropy-area-law/) — Eternity II tiene dos reglas: los bordes deben coincidir y cada pieza se usa una sola vez. La primera es generosa. Toda la dificultad reside en la segunda.
- [KEYRING](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/keyring/) — Construir un tablero desde cero, clasificando cada pieza siguiente según tres señales aprendidas de tableros fuertes anteriores. Alcanzó 460 en una familia de tableros que ninguna búsqueda previa había resuelto.
- [La consistencia de arco, desde AC-3 en adelante](https://eternity2.dev/es/research/build/reduce/arc-consistency/) — El forward checking mira un movimiento por delante; la consistencia de arco obliga a la lista de candidatos de cada celda a defenderse frente a la de cada vecina, hasta un punto fijo. El AC-3 de Mackworth, los refinamientos óptimos que vinieron después, y lo que toda esa familia midió realmente en este puzzle, incluido dónde deja de ser correcta.
---
# El marco no es la cuenca: un borde distinto no abre un tablero más alto
> El anillo del borde es la parte más restringida del rompecabezas, así que un borde fuerte distinto debería fijar un interior alto distinto. No lo hace. Muchos bordes completamente emparejados y distintos, cada uno completado por un mismo productor de interior fijo, dan cimas casi máximamente distintas entre sí pero uniformemente bajas, ninguna cerca de la franja récord. El borde diversifica el tablero sin predecir su techo.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/frame-is-not-the-basin/
- Actualizado: 2026-07-22
- Temas: structure, search-space
- Reproducir: `just research-frame-is-not-the-basin`
- Fuente: El marco no es la cuenca: topic de reproducción con el artículo, el productor versionado y los dos archivos JSON de resultados (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/frame-is-not-the-basin
---
Hay un atajo tentador para Eternity II. El anillo del borde es la parte más
restringida del tablero: sesenta casillas sobre solo cinco colores de anillo,
llenadas por las cuatro esquinas y las cincuenta y seis piezas de borde (la
[página de pureza del anillo](/es/research/why/ring-purity/) muestra por qué esos
cinco colores nunca abandonan el reborde). Si un borde completamente emparejado
fija la cima del tablero, entonces un borde *distinto* debería fijar un interior
alto *distinto*, y construir varios bordes fuertes distintos abriría varias
cuencas altas distintas. La diversificación por el borde sería una palanca para
las puntuaciones.
Esta página es la medición que cierra esa puerta. Generar muchos bordes
completamente emparejados y estructuralmente distintos, y completar cada uno con
el mismo productor de interior fijo, da cimas casi máximamente distintas entre sí
y, sin embargo, todas alojadas en la misma banda baja, lejos de la franja récord.
El borde es un fuerte *diversificador* del tablero resultante y un *selector* de
calidad inútil. La identidad del marco no predice el techo del interior.
28
bordes completamente emparejados distintos, dos bases de semillas
~190 / 196
casillas interiores que difieren entre dos cimas cualesquiera
441
mejor tablero, estricto 5/5, aún a 14 de 455
Toda puntuación de esta página está bajo la convención estricta de cinco pistas
(las cinco pistas oficiales respetadas, adyacencias no grises emparejadas sobre
480); las cinco pistas están en casillas interiores, ninguna en el anillo, así
que cada completado aquí es un tablero estricto 5/5 legal y el borde queda libre
de restricción de pista. Para situar estos números frente a los récords
comunitarios y de cuaderno, véase la [página de récords](/es/research/records/).
## El marco es un objeto laxo
La razón para dudar del atajo es estructural. El anillo del borde es un problema
de emparejamiento de aristas cíclico y autónomo sobre cinco colores con
suministro equilibrado, así que los bordes completamente emparejados son
astronómicamente abundantes: el marco por sí solo admite, como se sabe desde hace
tiempo, más de $10^{15}$ disposiciones. Producir versiones estructuralmente
distintas es trivial, y se acoplan al interior por un único canal de baja
información: sesenta colores orientados hacia dentro, una palabra frontera que el
interior debe satisfacer, sobre un interior de 196 casillas y 22 colores. Ese
canal es demasiado delgado para determinar el interior. La esperanza de que un
borde distinto fije un interior alto distinto descansa, pues, sobre una
información que el marco no porta.
El experimento convierte ese argumento estructural en una prueba directa.
## Lo que se midió
Sobre el conjunto oficial de 256 piezas, con las cinco pistas oficiales fijadas:
1. generar N bordes completamente emparejados y estructuralmente distintos desde
cero (una colocación en profundidad aleatorizada sobre las sesenta casillas de
borde, gris hacia fuera, cada adyacencia de anillo emparejada, deduplicado por
igualdad exacta del anillo);
2. congelar cada borde y llenar sus 196 casillas interiores con **un** solo
productor fijo a presupuesto fijo: un haz tolerante a rupturas que llena el
interior fila por fila, puntuando cada candidato por aristas emparejadas menos
no emparejadas contra sus vecinos ya colocados (el borde congelado incluido) y
podando a un ancho fijo con un desempate por semilla;
3. reportar la banda de puntuación del tablero completo, la distancia de Hamming
por losetas entre los mejores completados, y si algún borde alcanza la franja
récord.
Dos preguntas, y solo dos: **¿son distintas las cimas?** y **¿son altas las
cimas?**
### La ejecución principal
Dieciséis bordes completamente emparejados estructuralmente distintos, haz de
interior de ancho 128, tres semillas por borde, se conserva la mejor:
| Cantidad | Resultado |
| --- | --- |
| Bordes completamente emparejados distintos generados | 16 (de 17 intentos en profundidad) |
| Banda de puntuación de las cimas (mín / mediana / máx) | 434 / 437 / 440 |
| Algún borde alcanza la franja récord (>= 455) | no |
| Brecha de la mejor cima por borde a 455 | 15 |
| Hamming por losetas interiores (sobre 196 casillas) | 188 a 191, media 190,4 (120 pares) |
| Mejor tablero, estricto 5/5, borde aún emparejado | sí y sí (440, 40 rupturas) |
Las dos filas portantes son la tercera y la penúltima. **Ningún borde alcanza la
franja récord**: el mejor de los dieciséis marca 440, aún a 15 de 455 y a unos
20 del máximo estricto 5/5 del cuaderno. Y los completados son **casi máximamente
distintos**: entre dos cualesquiera, 188 a 191 de las 196 casillas interiores
difieren. Los bordes diversifican el tablero casi por completo y no seleccionan
en absoluto su calidad; cada uno de los dieciséis se aloja en una ventana de seis
puntos, 434 a 440. El mejor tablero de la ejecución, un completado estricto 5/5
legal de un borde completamente emparejado, se puede visualizar desde el archivo
de resultados versionado del topic de reproducción.
### La pasada de robustez
Como el objetivo es precisamente que la identidad del marco no importa, el
resultado debe mostrar que no es un accidente de una sola base de semillas. Una
segunda pasada independiente (doce bordes, una base de semillas distinta)
concuerda: banda 434 a 441 (mediana 438), mejor 441 aún a 14 de 455, Hamming por
losetas interiores 187 a 191 (media 190,3), y el mejor tablero de nuevo un
completado estricto 5/5 de un borde completamente emparejado. Dos bases de
semillas independientes, 28 bordes distintos en total, y ninguno cruza 445, y
mucho menos la franja récord.
## Por qué un interior más fuerte solo lo afila
Una pasada de cuaderno anterior realizó esta misma prueba con un interior más
débil, de ajuste duro, que se estancaba en los 250 y nunca se acercaba a la
franja récord. Esta reproducción sustituye deliberadamente por un productor de
interior *más fuerte*, el haz tolerante a rupturas de arriba, que siempre llena
las 196 casillas. Su banda absoluta es por tanto más alta, mediados de 430 en
lugar de los 250. Eso no ablanda el hallazgo; lo afila. Incluso con un solucionador
de interior mucho mejor, ningún borde distinto alcanza la franja récord, y los
bordes siguen siendo casi máximamente distintos. Un interior más fuerte no puede
hacer informativo al borde, porque el borde es una cáscara aguas abajo, de baja
entropía, colgada del interior, y no lo que lo fija. La banda es una propiedad del
solucionador de interior; el hallazgo negativo es una propiedad del acoplamiento
marco-interior, y es independiente del productor.
## Qué cierra y qué no cierra
El resultado es un enunciado de rigidez sobre el borde. Cierra la diversificación
por el borde como ruta hacia mejores puntuaciones: un borde completamente
emparejado distinto da un tablero distinto, pero no uno más alto, así que no hay
gradiente que escalar recorriendo el espacio de los bordes. Donde vive realmente
la información de las puntuaciones altas es en el interior de las filas
superiores, y esa es exactamente la región que el
[muro de rigidez](/es/research/why/rigidity-wall/) describe como una isla congelada.
El marco no fija la cima; la cima se fija a sí misma, y el borde cuelga de ella.
La contabilidad de la costura que acopla ambos, el equilibrio exacto de colores a
través de la interfaz borde-interior, es el tema de la
[página de equilibrio del borde](/es/research/why/border-balance/).
Este es un hallazgo negativo de configuración única, acotado con franqueza. Se
establece puramente a partir de bordes generados desde cero y completados por un
solo productor fijo, la forma de robustez que el estudio original pedía. No
intenta el control más difícil de congelar el borde propio de un tablero récord y
completarlo, lo que requeriría un tablero que no forma parte del kit de inicio
público; el hallazgo se sostiene sin él. Y la banda absoluta es la del
solucionador de interior, no una afirmación sobre un dígito exacto: lo que porta
es la brecha a la franja récord, y se reproduce con margen.
Cada número de arriba lo recalcula el productor versionado del topic de
reproducción enlazado en las fuentes: un programa Rust que carga la instancia
oficial, genera sus propios bordes completamente emparejados, congela cada uno y
completa el interior con el único haz fijo tolerante a rupturas, y emite dos
archivos JSON (la ejecución principal y la pasada con semilla independiente) que
contienen cada cifra citada aquí.
## Relacionado
- [Pureza del anillo: el borde es un subpuzle cerrado, sin holgura](https://eternity2.dev/es/research/why/ring-purity/) — Cinco de los 22 colores nunca tocan las 196 piezas interiores. La lista de piezas obliga a toda solución válida a gastar las 120 semiaristas de marco en el anillo del borde: un subpuzle autónomo con holgura exactamente nula (120 = 120), un circuito euleriano sobre cinco vértices, acoplado al interior solo por 56 aristas orientadas hacia dentro.
- [El equilibrio del borde](https://eternity2.dev/es/research/why/border-balance/) — Un tablero resuelto esconde una sencilla ley contable: cada color que el borde entrega al interior, el interior se lo devuelve al instante. Rómpela y sabrás de inmediato que el tablero es incorrecto; respetarla, en cambio, no garantiza nada.
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [Récords y solucionadores](https://eternity2.dev/es/research/records/) — Eternity II nunca se ha resuelto, pero casi dos décadas de esfuerzo colectivo han llevado el mejor tablero a 470/480. Quién ostenta qué, cómo lo lograron y por qué algunos tableros «480» anunciados no corresponden al puzzle real.
---
# Dónde colocas las pistas importa más que cuántas
> En un puzzle de 16×16 construido como Eternity II, dieciocho pistas repartidas por el tablero lo resuelven en minutos, mientras que amontonarlas en filas contiguas necesita un centenar solo para bajar la búsqueda a decenas de miles de millones de colocaciones. La posición, no la cantidad, es la palanca, y apunta directamente a la fase final.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/hint-geometry/
- Actualizado: 2026-07-10
- Temas: structure, search-space, backtracking
- Reproducir: `just experiments hint-study-solve`
- Fuente: El estudio de densidad de pistas de Joe y la resolución con 18 pistas de Peter McGavin (hilo de groups.io «A method to prune E2 search space by 17-30%+», msg 11725) — https://groups.io/g/eternity2/message/11725
- Fuente: Peter McGavin: 18 pistas repartidas resuelven el puzzle 16×16 tipo E2 en menos de 15 minutos (groups.io msg 11746) — https://groups.io/g/eternity2/message/11746
- Fuente: Peter McGavin: el backtracker optimizado se remonta al mensaje de Mike de 2007 (groups.io msg 3098) — https://groups.io/g/eternity2/message/3098
---
Regala a un solucionador algunas piezas correctas y el puzzle se vuelve más
fácil. La pregunta obvia es cuántas necesitas. La mejor pregunta, resulta, es
*dónde* van. En un puzzle de 16×16 construido con la receta de colores exacta
de Eternity II, dieciocho pistas colocadas en los sitios adecuados lo resuelven
en minutos; amontonarlas en cambio en filas contiguas, una medición necesitó un
centenar (sesenta de borde más cuarenta interiores) solo para bajar la búsqueda
a decenas de miles de millones de colocaciones. Para fijar nosotros mismos el
punto de cruce, repetimos el mismo enfrentamiento en un tablero lo bastante
pequeño para resolverse por completo: igualar un retículo repartido de dieciséis
pistas exigió **cinco filas contiguas, cuarenta pistas**, unas dos veces y media
la cantidad, decidida por la sola geometría.
## Dos maneras de gastar las mismas dieciocho pistas
> **[Interactive: HintGeometryDiagram]** Rendered on the canonical page (link above); not shown in this markdown export.
El tablero de la izquierda es la disposición real que usó Peter McGavin:
dieciocho pistas en un retículo regular, cada tercera columna en unas pocas
filas sueltas. Su backtracker sencillo, de recorrido por filas, resolvió el
puzzle 16×16 tipo E2 de Joe (cinco colores de borde, diecisiete colores
interiores, la misma distribución que el puzzle oficial) en menos de quince
minutos en un solo núcleo, recorriendo un árbol de búsqueda de 41 160 067 167
colocaciones. Amontona en cambio las dieciocho pistas en las primeras
filas, tal como un recorrido de arriba abajo las acumula de forma natural, y no
compran casi nada: la parte difícil del tablero sigue completamente abierta.
Joe lo había abordado por el otro lado, sembrando filas contiguas enteras a
partir de una solución conocida, y necesitaba muchas más para bajar la búsqueda
a un tamaño manejable: un centenar de pistas (sesenta de borde más cuarenta
filas interiores) todavía dejaba un árbol de unos 47 mil millones de colocaciones
([msg 11725](https://groups.io/g/eternity2/message/11725)).
Ninguna de las dos cifras fija el cruce con exactitud, porque un tablero 16×16
nunca termina en segundos y el recuento en bruto queda enturbiado por las
coincidencias gratuitas que un bloque macizo te regala. Así que encogimos el
puzzle a un tamaño que sí termina, un 8×8 construido con la misma receta de
colores, y medimos la magnitud real: los nodos hasta una resolución completa,
sobre treinta instancias semilla por disposición. Allí, un retículo repartido de
dieciséis pistas resuelve cada instancia en unos pocos miles de nodos de
búsqueda. Las filas contiguas tienen que subir a cinco filas completas, cuarenta
pistas, antes de resolver cada instancia dentro del mismo presupuesto de nodos.
A *igual* cantidad, dieciséis pistas repartidas superan a dieciséis amontonadas
en dos filas por más de dos órdenes de magnitud en nodos de búsqueda, y el
bloque no logra resolver seis de las treinta. El retículo alcanza el final de la
partida; el bloque no lo alcanza hasta casi sepultarlo.
18
pistas repartidas, resuelto en minutos
2,5×
más pistas, en filas contiguas, para igualar un retículo repartido (medido hasta la resolución)
99%
del tiempo de búsqueda transcurre más allá de la profundidad 132
70%
del tiempo de búsqueda transcurre más allá de la profundidad 150
## Por qué gana la posición: las pistas tienen que llegar a la fase final
Los dos números de la derecha explican los de la izquierda. Joe instrumentó su
backtracker a lo largo de mil millones de iteraciones y descubrió que el trabajo
no está repartido por el tablero en absoluto: el 99 % ocurre después de la
profundidad 132 de 256, y el 70 % después de la profundidad 150. Casi todo el
sufrimiento está en la mitad final del relleno, y la mayor parte pasado el punto
de las tres quintas partes.
Un bloque de pistas contiguas arriba se gasta justo donde la búsqueda nunca iba
a costar. Acorta un comienzo fácil y deja intacta la cola cara. Las pistas
repartidas hacen lo contrario: salpicadas por el tablero, hasta bien dentro de
la región que la búsqueda alcanza en último lugar, se anticipan a las decisiones
que, de otro modo, estallarían en lo profundo del árbol. Este es el mismo hecho
que los tableros récord llevan en su superficie. Un tablero casi perfecto
concentra todos sus daños en la banda de filas en la que la búsqueda terminó,
porque
[las filas que rellenas en último lugar son donde el puzzle te hace pagar](/es/research/why/mismatch-geometry/).
Las pistas solo ayudan en la medida en que alcanzan esa banda antes que la
búsqueda.
También encaja con [por qué el interior no da jugadas forzadas](/es/research/why/no-forced-moves/):
con cada celda interior aún aceptando decenas de vecinas, el valor de una pista
no es la propagación local sino la restricción global, que corta subárboles
enteros que la búsqueda habría tenido que recorrer. Una pista lejos de la región
difícil corta subárboles que de todos modos eran baratos.
## Lo que dice y lo que no dice
Este es un resultado sobre un puzzle de 16×16 construido según la receta de
colores de Eternity II, no sobre el puzzle oficial, cuyas cinco pistas fijas son
un regalo distinto, mucho más pequeño, en sitios distintos. Lo que se transfiere
es la forma de la lección, y es la misma que el argumento de
[poda frente a velocidad](/es/research/why/prune-vs-speed/) formula desde el otro
lado: lo que importa es cambiar dónde gasta su esfuerzo la búsqueda, y el
esfuerzo vive en la fase final. Un puñado de pistas dirigidas a esa fase final
vale muchísimo más que otras tantas dirigidas a cualquier otro sitio.
> **Note**
>
> Los recuentos, el árbol de 41 mil millones de nodos y las estadísticas de profundidad son las mediciones de Joe y de Peter McGavin, publicadas en la lista de groups.io eternity2 en enero de 2026; la disposición repartida que se muestra está decodificada del tablero publicado por Peter (msg 11746). El backtracker optimizado que usó Peter se remonta al mensaje de Mike de 2007 (msg 3098). Estos son resultados de la comunidad sobre un puzzle tipo E2 concreto, registrados aquí con atribución en lugar de re-derivados. El umbral de cinco filas es nuestra propia medición, sobre nuestros propios tableros 8×8 generados y nuestro backtracker: el menor número de filas contiguas cuya tasa de resolución y mediana de nodos hasta la solución igualan ambas un retículo repartido de dieciséis pistas, sobre treinta instancias semilla por disposición. Reprodúcelo con `just experiments hint-study-solve`.
## Relacionado
- [Dónde viven los desajustes](https://eternity2.dev/es/research/why/mismatch-geometry/) — Un tablero casi perfecto no reparte sus escasos errores de forma uniforme. Los concentra en una sola banda de cinco filas y deja todo lo demás impecable. ¿Qué banda? Lo decide la dirección en la que la búsqueda rellenó el tablero, y puede verse el reflejo en los tableros récord reales.
- [Sin jugadas forzadas](https://eternity2.dev/es/research/why/no-forced-moves/) — La manera habitual de resolver un puzzle lógico es encontrar un lugar donde solo encaja una pieza, colocarla y repetir. Aquí ese recurso no existe: cada pieza interior tiene entre 73 y 137 vecinas posibles, y ninguna queda jamás fijada a una sola opción.
- [Por qué un ordenador más rápido no ayuda](https://eternity2.dev/es/research/why/prune-vs-speed/) — La idea más importante de la búsqueda combinatoria difícil: reducir el espacio que se explora vence, por un margen exponencial, a explorarlo más rápido. Eternity II está diseñado para que apenas puedas reducirlo.
---
# ¿Es NP-completa esta instancia y cómo la codifico?
> El emparejamiento de aristas es NP-completo como familia, pero eso no dice nada de un tablero 16×16 fijo: una instancia aislada es una constante, no un problema. Lo que sí es cierto es la dureza en el peor caso de la familia y la dureza empírica de esta instancia, y cómo escribir el puzzle para un solucionador SAT, de cobertura exacta o de PLE, con pequeños esbozos detallados. Una medición con tableros plantados pone cifras a la elección de la formulación: un acantilado de resolubilidad que un paradigma de búsqueda golpea y otro cruza, y que se mueve con el número de colores.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/how-hard-is-this-instance/
- Actualizado: 2026-07-22
- Temas: exact-methods
- Fuente: Demaine & Demaine 2007, "Jigsaw Puzzles, Edge Matching, and Polyomino Packing: Connections and Complexity" (Graphs and Combinatorics 23): el emparejamiento de aristas es NP-completo — https://doi.org/10.1007/s00373-007-0713-4
- Fuente: Ansótegui, Béjar, Fernàndez & Mateu, How Hard is a Commercial Puzzle: the Eternity II Challenge (CCIA 2008) — https://repositori.udl.cat/bitstreams/0b6533fe-54e5-4070-85fe-80f7d35837d8/download
- Fuente: Knuth, The Art of Computer Programming, Volume 4B: Algoritmo X y Algoritmo C (cobertura exacta con colores) — https://www-cs-faculty.stanford.edu/~knuth/taocp.html
- Fuente: Puzzle Eternity II (Wikipedia) — https://en.wikipedia.org/wiki/Eternity_II_puzzle
---
Esta página responde a una pregunta que reaparece una y otra vez en los Stack
Exchange de matemáticas e informática y que encabeza la lista de disputas en la
página de discusión de Wikipedia sobre el puzzle: el emparejamiento de aristas
es NP-completo en general, así que ¿nos dice eso algo sobre *este* tablero
16×16 fijo y, en concreto, cómo se le entregaría Eternity II a un solucionador?
Las respuestas breves son: no, no directamente, aquí van tres codificaciones, y
una medición al final muestra cuánto puede importar la elección entre ellas.
## Primero, el error de categoría
La NP-completitud es una propiedad de un *problema*, lo que en teoría de la
complejidad designa una familia infinita de instancias indexada por un parámetro
de tamaño $n$. Los «puzzles de emparejamiento de aristas» forman una familia de
ese tipo: dados $n$, un conjunto de piezas cuadradas y un alfabeto de colores,
decidir si las piezas embaldosan un marco $n \times n$ con todas las aristas
adyacentes en concordancia. Ese problema de decisión es NP-completo
([Demaine & Demaine 2007](https://doi.org/10.1007/s00373-007-0713-4)), lo que
significa tanto que una solución propuesta es verificable en tiempo polinómico
como que todo problema de NP se reduce a él.
Un único tablero fijo no es una familia. La instancia de Eternity II tiene una
respuesta bien definida, «sí, tiene solución» (los diseñadores la construyeron a
partir de una solución) o, en la forma de competición con 5 pistas, «sí, con
exactamente esta disposición». Esa respuesta cabe en un solo bit. Un solo bit es
una constante, y «¿es NP-completa esta constante?» no es una pregunta bien
formada: existe un algoritmo en tiempo constante que imprime la respuesta
(`return true`), sencillamente lleva la respuesta grabada dentro. Preguntar si
una instancia aislada es NP-completa incurre en el mismo error de categoría que
preguntar si el número 17 es de tiempo polinómico.
Así pues, la familia es dura y la instancia es una constante. ¿Qué hay,
entonces, de realmente cierto y útil que decir sobre la dificultad del tablero
que tienes sobre el escritorio?
## Lo que sí es cierto
Dos afirmaciones distintas, mantenidas por separado:
- **Dureza en el peor caso de la familia.** Como el problema general es
NP-completo, no se conoce ningún algoritmo que supere el tiempo exponencial en
el peor caso a medida que $n$ crece, y encontrar uno probaría
$\mathrm{P}=\mathrm{NP}$. Esto acota lo que puede prometer cualquier
solucionador de emparejamiento de aristas genérico. No dice nada sobre cómo se
comporta una entrada *específica*.
- **Dureza empírica de esta instancia.** Una dureza que se puede medir. El
tablero 16×16 tiene del orden de $1{,}115\times10^{557}$ disposiciones distintas
de piezas y rotaciones, y el puzzle parece admitir muy pocas soluciones (la
forma con 5 pistas está diseñada para tener esencialmente una; véase la
[teoría de la complejidad](/es/research/why/complex-theory/) para la estimación del
número esperado). Por tanto, una búsqueda con backtracking enhebra un espacio
astronómicamente amplio hacia un conjunto de soluciones casi vacío, y así pasa
casi todo su tiempo explorando callejones sin salida. Por eso el puzzle es
duro *en la práctica*, y es una afirmación sobre este tablero, no sobre la
familia.
El teorema del peor caso y la dificultad empírica apuntan aquí en la misma
dirección, pero son enunciados de naturaleza distinta y solo uno de ellos es un
teorema. Una familia puede ser NP-completa mientras que una instancia dada es
trivial (muchas lo son), y una instancia puede ser brutalmente difícil de
resolver en la práctica incluso dentro de una familia polinómica. Ansótegui et
al. plantearon exactamente ese caso empírico para Eternity II, construyendo a
partir de él bancos de pruebas para solucionadores y midiendo la dificultad
directamente en lugar de apelar al teorema general
([CCIA 2008](https://repositori.udl.cat/bitstreams/0b6533fe-54e5-4070-85fe-80f7d35837d8/download)).
> **La versión en una línea**
>
> «¿Es Eternity II NP-completo?» No: una instancia no tiene clase de complejidad. «¿Es NP-completo el problema de emparejamiento de aristas?» Sí. «¿Es difícil de resolver esta instancia?» Empíricamente sí, porque el espacio de búsqueda es de ~$10^{557}$ de ancho y el conjunto de soluciones está casi vacío, de modo que la búsqueda se ahoga en callejones sin salida.
## Codificarlo: el montaje
Lo demás es práctico: ¿cómo escribes el tablero para que un solucionador pueda
masticarlo? Las tres codificaciones de abajo comparten el mismo esqueleto.
Numera las celdas $c = 1 \dots 256$, las piezas $p = 1 \dots 256$ y las
rotaciones $r \in \{0, 1, 2, 3\}$. Una *colocación* es un triple $(c, p, r)$: la
pieza $p$ depositada en la celda $c$ girada $r$ cuartos de vuelta. Toda
codificación tiene que expresar tres cosas:
1. cada celda recibe exactamente una colocación,
2. cada pieza se usa exactamente una vez,
3. dondequiera que dos celdas se toquen, los colores de la arista compartida
concuerdan.
Las codificaciones solo se diferencian en cómo expresan la restricción 3, el
emparejamiento de colores, y esa diferencia es toda la historia. Los esbozos de
abajo usan un tablero 2×2 o 3×3 para que puedas ver todas las cláusulas; el
16×16 tiene la misma forma a mayor escala.
## SAT / FNC
Introduce una variable booleana $x_{c,p,r}$, verdadera cuando la pieza $p$ se
asienta en la celda $c$ en la rotación $r$. En el tablero completo eso son
$256 \times 256 \times 4 \approx 262{,}000$ variables antes de cualquier
restricción. Luego:
- **Exactamente una colocación por celda.** Para cada celda $c$, una cláusula de
«al menos una» sobre todas sus colocaciones, $\bigvee_{p,r} x_{c,p,r}$, más
cláusulas de «a lo sumo una» que prohíben cualquier par,
$\lnot x_{c,p,r} \lor \lnot x_{c,p',r'}$ para colocaciones distintas.
- **Exactamente una celda por pieza.** La imagen especular: para cada pieza $p$,
una cláusula de «al menos una» sobre las celdas que podría ocupar, más
cláusulas de «a lo sumo una» para que se coloque solo una vez.
- **Emparejamiento de aristas.** Para cada adyacencia interior y cada colocación
cuya arista expuesta muestra el color $k$, prohíbe toda colocación de la celda
vecina cuya arista enfrentada no sea $k$: una cláusula binaria
$\lnot x_{c,p,r} \lor \lnot x_{c',p',r'}$ por cada par en conflicto.
Un esbozo 2×2 concreta la tercera familia. Las celdas $A$ (arriba a la
izquierda) y $B$ (arriba a la derecha) comparten una arista vertical; la arista
este de $A$ debe ser igual a la arista oeste de $B$. Para cada colocación
$(A,p,r)$ que muestra el color este $k$, y cada colocación $(B,p',r')$ cuyo
color oeste no es $k$, añade $\lnot x_{A,p,r} \lor \lnot x_{B,p',r'}$. Haz lo
mismo para $A$/$C$ verticalmente y las otras dos adyacencias interiores. Eso es
todo lo que es la restricción 3: un gran montón de cláusulas binarias «estas dos
colocaciones no pueden ser ambas verdaderas».
El problema es que el montón es enorme. Las cláusulas de conflicto dominan, las
codificaciones de «a lo sumo una» añaden su propia explosión (el enfoque ingenuo
por pares es cuadrático; las codificaciones en escalera o por comandante lo
cambian por variables auxiliares), y el resultado es una fórmula con millones de
cláusulas cuya estructura le da casi nada que aprender a la búsqueda guiada por
conflictos. Esto se ha intentado desde 2008 y los solucionadores SAT completos
se atascan en el tablero completo; Blackwood, entre otros, informó de que SAT no
ayudaba. La codificación es limpia, el solucionador no es el cuello de botella,
lo es la *instancia*. Véase
[codificaciones SAT y CSP](/es/research/build/exact/sat-csp-encodings/) para el
historial de bancos de pruebas y dónde los veredictos SAT todavía se ganan su
sitio como pruebas de imposibilidad en regiones pequeñas.
## Cobertura exacta y enlaces danzantes
La visión por cobertura exacta es más pulcra, y esconde una trampa que hace
tropezar a casi todo el que recurre a los enlaces danzantes de Knuth.
Plantea 512 *ítems*: uno por celda («la celda $c$ está rellena») y uno por pieza
(«la pieza $p$ se usa»). Cada *opción* es una colocación $(c,p,r)$, y cubre
exactamente dos ítems: la celda $c$ y la pieza $p$. Un conjunto de opciones que
cubre cada ítem exactamente una vez es un tablero con cada celda rellena y cada
pieza usada una vez. Esa es una instancia de cobertura exacta limpia, y el
**Algoritmo X** de Knuth con enlaces danzantes resuelve la cobertura exacta a la
perfección.
Aquí está la trampa. Las restricciones 1 y 2 son condiciones de cubrir-una-vez,
que es exactamente lo que expresa la cobertura exacta. Pero la restricción 3, el
emparejamiento de colores, no es en absoluto una condición de cubrir-una-vez:
una arista compartida no se «usa una vez», se le «asigna un color en el que
ambos vecinos coinciden». El Algoritmo X sin más no tiene forma de decir esto.
La gente lo codifica, lo ejecuta y obtiene tableros con aristas discordantes, o
intenta injertar ítems adicionales y descubre que la semántica de cubrir-una-vez
se le resiste. Esta confusión concreta tiene su propia pregunta en el CS Stack
Exchange.
La solución es la propia extensión de Knuth, el **Algoritmo C**, para XCC, la
cobertura exacta con colores (TAOCP Volume 4B). Junto a los ítems *primarios*
(cubiertos exactamente una vez) añades ítems *secundarios* que pueden cubrirse
cualquier número de veces, *siempre que todas las opciones que cubren un ítem
secundario dado le asignen el mismo color*. Da a cada arista interior de la
cuadrícula un ítem secundario. Una colocación que expone el color $k$ en una
arista compartida asigna el color $k$ al ítem secundario de esa arista. Dos
colocaciones pueden entonces coexistir a ambos lados de la arista solo si la
colorean de forma idéntica, que es precisamente la restricción de emparejamiento
de aristas, ahora expresada de forma nativa.
Un esbozo 3×3: 9 ítems de celda y 9 ítems de pieza (primarios), más 12 ítems de
arista interior (secundarios, uno por cada unión horizontal o vertical). Las
colocaciones de la celda central tocan cada una cuatro ítems de arista
secundarios y deben concordar en color con los cuatro vecinos; las colocaciones
de una celda de esquina tocan dos. El Algoritmo C enhebra todo esto sin emitir
jamás un tablero discordante. Lo que los estudiantes pasan por alto:
**la cobertura exacta por DLX para Eternity II necesita el Algoritmo C, no el
Algoritmo X.** La página
[cobertura exacta y enlaces danzantes](/es/research/build/exact/exact-cover-dlx/)
recorre la construcción XCC completa y dónde el DLX brilla de verdad (tableros
pequeños, recuento exhaustivo de soluciones) frente a dónde se atasca en el
16×16.
## PLE y clique máxima, brevemente
Dos encuadres más, útiles sobre todo como indicadores:
- **Programación lineal entera.** Reutiliza las variables SAT como enteros 0/1
$x_{c,p,r}$. Las restricciones 1 y 2 se convierten en igualdades
$\sum_{p,r} x_{c,p,r} = 1$ por celda y $\sum_{c,r} x_{c,p,r} = 1$ por pieza. El
emparejamiento de aristas pasa a ser, para cada arista interior y cada color
$k$, una condición de enlace que ata las colocaciones de color $k$ de los dos
vecinos (una forma limpia: una nueva variable binaria de color de arista
$y_{e,k}$ con $\sum_k y_{e,k} = 1$, y las colocaciones de cada lado implicando
el $y$ correspondiente). Es una PLE de factibilidad, sin objetivo, y la
relajación lineal es débil, de modo que la ramificación y acotación se comporta
muy parecido a la búsqueda SAT. Véase
[relajaciones lineales](/es/research/build/exact/lp-relaxations/).
- **Clique máxima.** Construye un grafo cuyos vértices son las colocaciones
legales y cuyas aristas unen cualesquiera dos colocaciones mutuamente
compatibles (celdas distintas, piezas distintas y concordancia en cualquier
arista compartida). Un tablero completo es una clique de tamaño 256. Es
elegante sobre el papel, pero el grafo es inmenso y los solucionadores de
clique no salen mejor parados; vale la pena conocerlo como reducción, no como
ataque práctico.
## ¿Cuánto pesa la formulación? Un acantilado medido
Las secciones anteriores terminan con una nota desalentadora: la codificación
es limpia, la instancia es el muro. Esa afirmación merecía una cifra, y
ponérsela la afinó en una dirección inesperada. El banco de pruebas es una
familia de tableros *plantados*: instancias con marco y colores equilibrados,
construidas a partir de una solución conocida, con cinco celdas de la solución
fijadas como pistas, puntuadas con la convención de aristas emparejadas sin
contar el borde exterior (una resolución completa a tamaño $N$ vale
exactamente $2N(N-1)$ aristas emparejadas: 264 en 12×12, 480 en 16×16). Los
tableros plantados no son el Eternity II canónico; plausiblemente admiten
muchísimas soluciones donde el puzzle real está diseñado para tener en esencia
una. Lo que ofrecen es una escalera de instancias resolubles por construcción
que dos paradigmas de búsqueda distintos pueden atacar lado a lado.
En este banco, a 22 colores, una búsqueda en profundidad con reinicios que
solo coloca coincidencias exactas resuelve por completo cuatro de cinco
semillas 10×10 (la más rápida en 4 ms) y dos de cinco semillas 11×11, y luego
cero de cinco en 12×12 y cero en todos los tamaños superiores. El fallo no es
cuestión de presupuesto. La instancia 12×12 de semilla 1 puntúa 127 de 264
tras 20 segundos, tras 45 segundos y tras 120 segundos, mientras el número de
nodos visitados crece de 22 millones a 132 millones; una instancia 14×14
repta de 236 a 240 de 364 a lo largo del mismo estiramiento séxtuple del
presupuesto. La búsqueda no está convergiendo despacio; está clavada.
Entrega las instancias idénticas a CP-SAT con un modelo estructurado (una
variable entera por celda que recorre los identificadores de pieza bajo una
restricción AllDifferent, índices de pieza y rotación canalizados mediante
tablas Element hacia variables de color por lado, todo planteado como pregunta
de decisión) y el muro se mueve. Cuatro de las cinco instancias 12×12 caen en
31,7 a 88,1 segundos (la quinta agota el límite de 300 segundos), y una de las
dos instancias 13×13 probadas cae en 74 segundos, con cada tablero devuelto
reverificado de forma independiente: distinción de piezas, conformidad con las
pistas, recuento de aristas recalculado. Son resoluciones completas
verificadas de tableros que ninguna semilla de la DFS toca con ningún
presupuesto. El acantilado pertenece al paradigma de búsqueda, no a los
tableros.
La ronda original de esta medición corría sobre un generador que permitía 26
colores interiores, un ajuste que el banco empaquetado no puede producir (su
generador limita los colores interiores a 22, el recuento del puzzle real). A
26 colores el contraste era aún más nítido: CP-SAT resolvió por completo 25 de
25 instancias en los tamaños 10 a 14 con tiempos medianos de 0,10 a 0,84
segundos, medio segundo en 13×13, y terminó un 16×16 plantado en unos 15
segundos, mientras el acantilado de la DFS quedaba un peldaño más arriba, en
13×13. Esa misma ronda midió además la brecha de formulación en aislamiento:
sobre una instancia 12×12, un MIP genérico sobre binarias de colocación con
filas de suma uno, pasado por la ramificación y acotación de HiGHS, devolvió
11 de 264 aristas emparejadas tras 300 segundos; CP-SAT devolvió las 264
completas sobre la misma instancia en 0,42 segundos. Mismo problema, misma
máquina, unos tres órdenes de magnitud, y toda la diferencia está en cómo se
escribieron las restricciones.
Poner los dos ajustes lado a lado hace aflorar un segundo hallazgo: el
acantilado se mueve con el número de colores, para ambos paradigmas a la vez.
A 26 colores, la DFS muere en 13×13 y CP-SAT atraviesa un 16×16 plantado en
segundos. A 22 colores, la DFS muere un peldaño antes, en 12×12, y el propio
CP-SAT se ralentiza unos dos órdenes de magnitud entre 11×11 y 12×12 y
empieza a agotar sus límites desde 12×12 en adelante: las sondas 14×14 y
16×16 chocan ambas con un tope de 120 segundos. (Los peldaños grandes fueron
sondas de una sola semilla, y los tiempos de CP-SAT a 22 colores llevan algo
de inflación por un brazo DFS compartiendo la máquina, que ni de lejos
explica la brecha con las medianas por debajo del segundo a 26 colores.) Más
colores significa un tablero más restringido y una búsqueda más fácil para
todos; menos colores arrastra a ambos paradigmas hacia abajo a la vez, de
modo que las mediciones tomadas a 26 colores favorecen a todos los
solucionadores de la carrera. El 16×16 plantado en el que la sonda agotó su
tiempo merece verse, mostrado aquí como su solución construida:
[16×16 plantado, 480/480](https://eternity2.dev/viewer?puzzle=gen_16x16_c22_s1&puzzle_size=16&board_edges=aebaabgeabvbacvbadvcacrdadlcadodadidaeqdafneadgfacwdafscachfaabcbjcagmujvhpmvuohvtpurnttlrsnouvriphuqowpnluogqllwpqqsvgphkgvbackcgdauwsgpluwoqmlpjoqtikjsnnivvvnhmrvwhpmuuuhlutuqqkugguqgnhgcabndgdassrguihsmqkiokhqkjnknokjvkrormikpptmuroptrirkomruumohjsubaejdlearsulhqmskvpqhqkvnwpqknuwrlqnikrltjlkosnjiglsmoogmnjoslqneaclerdauhjrmiihpklikwlkprmwunprqnwnrgnnlgjgnvmglknvowskjkowqwpkcafwdjfajjgjiqqjlptqlnipmslnpowswjjonoljjttomsrtnwtssrowosmrpmisfafmfhdagvkhqjsvtinjitsilwntwjrwjvrjlkovtsvkrhqstquhojhqmkqjitrkfaftdufakstusuisnmvuslsmnrmlrsvrrhnsoomhvtloqvntutvvhkltqukkrmtufaemfhfatwhhirhwvtrrsjptmtujvtgtnvstmohvliionwhivqqwlomqkgpotljgeaflfqeahgqqhmngrprmpqhpuugqgiquslqihqrliimqhkjiqwwkmspwpqisjkjqfaekembaqipmnioirkwihvkkgntvqhhnqnshrwgnmvlwjgwvwqkgpwmqiliwjulleadububapssuohjswmuhkowmtnpohrtnspgrgnrplnvnwgpnkvvgmhlvihwhlnshdadnbkeasgtkjjigumvjwwwmpjgwtpojgujprvtuvruvptorvmmtlsomwigssopidafoegcatppgiltpvpwlwohpgiuoolhijroltigrujgiotljmkjtorkkgiirppmifabpcbaapeabtbaewcabhcacueacheaeocaegfacgcaflbacjfabkbafieabmdaebaad).
> **Un testigo, contado diez veces**
>
> La ronda a 26 colores también probó diez familias heurísticas sobre el acantilado, desde un rellenador ingenuo fila a fila hasta la propagación AC-3 y la poda por déficit de Hall: seis resolvieron por completo el 12×12 y ninguna resolvió el 13×13. Diez solucionadores de acuerdo parecían diez pruebas de que las instancias eran el muro. Era una sola. Los diez se comprometen cronológicamente y con avidez sobre información local, así que fallan juntos por la razón compartida, y el primer solucionador de un paradigma de verdad distinto tumbó la conclusión en medio segundo. El acuerdo de N solucionadores de la misma familia es un testigo con N voces.
## Dónde te deja esto
Si viniste a preguntar si la teoría de la NP-completitud vuelve a esta instancia
demostrablemente difícil, la respuesta es que no lo hace, ni puede: las clases de
complejidad describen familias, y este tablero es una entrada fija con una
respuesta fija. El problema general de emparejamiento de aristas es NP-completo,
lo que pone un techo a lo que puede prometer cualquier solucionador a medida que
$n$ crece, pero la dificultad que realmente sientes es empírica: un espacio de
$10^{557}$ de ancho sobre un conjunto de soluciones casi vacío. Cada
codificación de arriba captura fielmente el puzzle, y en el 16×16 completo
ninguna lo vuelve fácil; pero el acantilado de los tableros plantados muestra
que la elección del formalismo no tiene nada de neutral por debajo de esa
escala, donde el mismo tablero puede ser inalcanzable para un paradigma y una
resolución de un minuto para otro. Una
vez codificado el tablero, la palanca que queda es la
[consistencia de arco](/es/research/build/reduce/arc-consistency/) y un orden de
búsqueda inteligente, que es donde retoma el resto de esta sección.
## Relacionado
- [La teoría compleja: contar el árbol de búsqueda antes de recorrerlo](https://eternity2.dev/es/research/why/complex-theory/) — La teoría compleja de Brendan Owen estima la anchura del árbol de búsqueda a cada profundidad, e incluso cuántas soluciones existen en total. Muchos en la comunidad la consideran lo más importante que hay que entender sobre Eternity II.
- [Codificaciones SAT y CSP](https://eternity2.dev/es/research/build/exact/sat-csp-encodings/) — Escribir el puzzle como cláusulas y entregárselo a un solucionador industrial: el movimiento evidente, intentado desde 2008. Por qué los solucionadores completos se atascan en el tablero completo, y dónde sus veredictos siguen ganándose el sustento como pruebas de imposibilidad.
- [Cobertura exacta y enlaces danzantes](https://eternity2.dev/es/research/build/exact/exact-cover-dlx/) — Eternity II se formula limpiamente como un problema de cobertura exacta, y el algoritmo X de Knuth con enlaces danzantes es la máquina clásica para ellos. Dónde brilla de verdad (tableros pequeños, conteo exhaustivo) y las dos razones por las que no vence al 16×16: un árbol de búsqueda que nunca se reduce, y ningún crédito parcial.
- [La consistencia de arco, desde AC-3 en adelante](https://eternity2.dev/es/research/build/reduce/arc-consistency/) — El forward checking mira un movimiento por delante; la consistencia de arco obliga a la lista de candidatos de cada celda a defenderse frente a la de cada vecina, hasta un punto fijo. El AC-3 de Mackworth, los refinamientos óptimos que vinieron después, y lo que toda esa familia midió realmente en este puzzle, incluido dónde deja de ser correcta.
---
# La región difícil que no se puede diseñar de otro modo
> Rellena un tablero en cualquier orden fijo y los tres cuartos de arriba entran con soltura, mientras la dificultad se amontona en la banda que terminas al final. En cuarenta tableros generados, todo lo que sobra cae en la mitad inferior cada vez; baraja el orden de relleno y se dispersa, así que la región difícil la fabrica el barrido, no está escondida en el tablero.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/irreducible-hard-region/
- Actualizado: 2026-07-22
- Temas: structure, search-space
- Reproducir: `just research-irreducible-hard-region`
---
Dos cosas son ciertas en casi todo intento de resolver Eternity II partiendo el
tablero en piezas que se rellenan por turno. La primera pieza que rellenas entra
con facilidad. La última, no. Ya sean las piezas filas, bandas, franjas, bloques
o anillos concéntricos, la dificultad no se reparte entre ellas; se junta en la
región que la búsqueda alcanza en último lugar, y ahí se planta como un muro.
Esta página pone a prueba la versión más nítida de esa afirmación y la encuentra
verificada con claridad, con un matiz que la medición deja a la vista: la región
difícil no es un parche fijo del tablero esperando a que lo encuentren. La
fabrica el orden en que rellenas, y aterriza donde ese orden termina.
## La afirmación, y sus tres partes
La conjetura completa, en el cuaderno del proyecto, tiene tres partes. Primero,
**la dificultad se localiza**: rellena de forma secuencial y el sobrante, las
celdas que la búsqueda no logra colocar, se concentra en la última región.
Segundo, **esa región es demasiado grande para resolverse de forma exacta**:
supera la ventana de unas 112 celdas donde una completación exacta todavía vuelve
en un tiempo razonable. Tercero, **está demasiado acoplada globalmente para
terminarla con una heurística**: como cada pieza se usa una sola vez, gastar una
pieza escasa pronto en la parte fácil mata de hambre a la parte difícil después,
de modo que ninguna reparación local alcanza un tablero alto nuevo.
Solo la primera parte es un hecho nítido que se lee directamente en un tablero.
Las otras dos son techos ligados a un solucionador exacto concreto y a la escasez
propia del conjunto oficial de 22 colores, y el propio cuaderno las califica de
empíricas más que de demostradas. Por eso esta página reproduce la primera parte,
la localización, y lleva las otras dos como conjetura. La única lectura que añade
al cuaderno es que la localización se entiende mejor como una propiedad del orden
de barrido que del tablero, algo que el control de abajo vuelve inevitable.
## El instrumento, y por qué es leal
La medición parte de cero sobre tableros enmarcados, equilibrados en color y
**con solución plantada**, construidos por el generador con semilla del kit
inicial: una solución perfecta existe con seguridad, así que cualquier atasco
pertenece a la búsqueda y no a una instancia irresoluble. Para cada semilla del
generador, el verificador construye un tablero 16x16 sin pistas fijadas, y luego
ejecuta sobre él dos veces la misma búsqueda en profundidad con emparejamiento
exacto y reinicios, una vez en orden de celdas row-major y otra en un orden de
celdas aleatorio con semilla, y lee dos números del parcial más profundo que
alcanza cada rama:
- la **fracción de frontera**, la fila llena más profunda dividida por el lado del
tablero, que dice hasta dónde llegó la parte fácil; y
- la **fracción de sobrante en la mitad inferior**, entre las celdas aún vacías,
la porción que cae en las filas 8 a 15, que dice dónde aterrizó la dificultad.
Ambos números están definidos para cualquier orden de relleno, que es justo lo
que permite que la rama aleatoria sea un control justo frente a la rama
row-major. Los scores se dan aquí bajo la convención de aristas emparejadas (solo
junturas interiores; una solución 16x16 completa vale 480), aunque esta página no
reclama récord alguno; las estadísticas de frontera y sobrante son geometría de
celdas, no score de aristas. Para situar los tableros del proyecto frente a los
mejores de la comunidad, véase la [página de récords](/es/research/records/).
## Lo que hace el barrido
Ejecutado en Apple Silicon, un solo núcleo, cuarenta tableros por dos ramas en
unos tres minutos con el presupuesto por defecto de 1,5 millones de nodos. La
fuente del cuaderno es una síntesis de muchos experimentos de descomposición más
que una sola medición, así que no compromete ninguna tabla de cifras por semilla
para un tablero del kit; los números de abajo son la forma que predice la
conjetura, y el acuerdo es sobre esa forma y su signo.
Barrido de localización, cuarenta tableros 16x16 generados y enmarcados, 22
colores, desde cero:
| Cantidad | Forma que predice la conjetura | Medido, row-major | Medido, control aleatorio |
| --- | --- | ---: | ---: |
| Tableros resueltos por completo | ninguno esperado (esto no es un solucionador) | 0 / 40 | 0 / 40 |
| Fracción de frontera mediana en tableros atascados | las diez filas y más de arriba se rellenan con soltura (por encima de 0,6) | 0,75 (12 de 16 filas) | 0,0 (ninguna fila se rellena por completo) |
| Rango de la fracción de frontera | alto | 0,6875 a 0,75 | no aplica |
| Fracción de sobrante media en la mitad inferior | cerca de 1,0 (la región difícil es la última banda) | 1,000 | 0,503 |
| Tableros con todo el sobrante en la mitad inferior | todos | 40 / 40 | 0 / 40 |
La búsqueda row-major alcanza una frontera mediana de tres cuartos del tablero,
doce filas completas de dieciséis, antes de no poder colocar ya un emparejamiento
perfecto. Eso coincide con la imagen del cuaderno donde las diez filas y más de
arriba se rellenan casi con soltura. Y en cada uno de los cuarenta tableros, todo
el sobrante cae en la mitad inferior: la fracción de sobrante media en la mitad
inferior vale exactamente 1,000.
## El control es todo el asunto
Toma los mismos cuarenta tableros y rellena cada uno en un orden de celdas
uniformemente aleatorio en lugar de row-major. Ahora no hay última región, y el
sobrante se dispersa. La fracción de sobrante media en la mitad inferior vale
0,503, indistinguible de un reparto igual, y ninguno de los cuarenta tableros
concentra su sobrante abajo.
Así que la región difícil no está en algún sitio del tablero esperando a que la
encuentren. El mismo tablero tiene toda su dificultad abajo bajo un barrido
row-major y no la concentra en ningún sitio bajo un orden aleatorio. La dificultad
es real, pero la coloca la descomposición. Es la imagen especular de lo que
muestran directamente los tableros récord: sus
[pocos desajustes se amontonan en una banda](/es/research/why/mismatch-geometry/)
cuya posición fija la dirección en que la búsqueda rellenó el tablero. Aquí se
puede ver esa banda crearse y desplazarse sin cambiar nada más que el orden de
relleno.
## El atasco es un muro, no un arranque lento
Una última comprobación separa un muro de una búsqueda que sencillamente se quedó
sin nodos. Reejecuta ocho de los tableros a cuatro millones de nodos, unas 2,7
veces el presupuesto del barrido, y compara la frontera con las mismas semillas de
la serie principal.
| Cantidad | Barrido a 1,5 millones de nodos | Reejecución a 4 millones de nodos |
| --- | ---: | ---: |
| Fracción de frontera, semillas 1 a 8 | 0,6875 a 0,75 | 0,6875 a 0,75 |
| Fracción de sobrante media en la mitad inferior | 1,000 | 1,000 |
La frontera no sube con el presupuesto. Cuatro de los ocho tableros suben una
fila, uno baja una fila, y tres no se mueven en absoluto, todo dentro de una sola
fila de temblor, y el sobrante permanece por completo en la banda inferior. La
búsqueda no es lenta; está detenida, y está detenida en la última región que
intenta rellenar. Ese es el fallo insensible al presupuesto que predice la
conjetura, reproducido directamente.
## Qué zanja esto y qué no
Esto reproduce solo la mitad de localización de la conjetura. Las dos mitades
restantes se enuncian como conjetura y no se miden aquí, deliberadamente.
La mitad **demasiado grande para resolverse de forma exacta** es propia de la
máquina y del solucionador: la ventana exacta de unas 112 celdas es una propiedad
de una búsqueda de aristas estrictas concreta, y un solucionador exacto más
potente la desplazaría. Nuestra región difícil son las cuatro o cinco filas de
abajo, unas 64 a 80 celdas, que en realidad quedan por debajo de la ventana de
unas 112 celdas; es más pequeña que las cerca de 96 a 128 celdas que describe la
conjetura, porque estos tableros generados se rellenan más profundo que las
descomposiciones del conjunto oficial que el cuaderno sintetizó. Si una región
difícil llega alguna vez a superar la ventana en el conjunto oficial es la
afirmación aparte, no medida.
La mitad **demasiado acoplada globalmente** es un techo empírico ligado a la
escasez del conjunto oficial, el acoplamiento que permite que una pieza escasa
gastada arriba [mate de hambre a una celda muy abajo](/es/research/why/piece-theft/).
Nuestros tableros vienen del generador enmarcado del kit, con solución plantada y
que plausiblemente admite muchas soluciones, donde se cree que el puzzle real
admite esencialmente una. La localización vale para cualquier tablero resoluble
bajo un relleno secuencial, porque el sobrante tiene que vivir en algún sitio y un
barrido row-major lo pone abajo, de modo que la familia generada es una prueba
adecuada de la localización; no es una prueba de la afirmación de acoplamiento,
que exigiría el conjunto oficial. Esa brecha de familia de instancias explica por
qué esta reproducción es cualitativa y no exacta: no hay una tabla fuente que
reproducir al bit, solo un signo y una banda, y ambos se reproducen.
La lección más amplia aterriza donde aterrizan los demás muros estructurales. Una
descomposición no elimina la dificultad; la reubica. Es la misma forma que el
[muro de rigidez](/es/research/why/rigidity-wall/), donde un récord es una isla
localmente congelada, y por eso el [mapa de métodos](/es/research/why/walls-and-methods/)
muestra cada familia de descomposición deteniéndose contra un muro en un lugar
distinto del tablero en vez de escapar de uno.
## Relacionado
- [Dónde viven los desajustes](https://eternity2.dev/es/research/why/mismatch-geometry/) — Un tablero casi perfecto no reparte sus escasos errores de forma uniforme. Los concentra en una sola banda de cinco filas y deja todo lo demás impecable. ¿Qué banda? Lo decide la dirección en la que la búsqueda rellenó el tablero, y puede verse el reflejo en los tableros récord reales.
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [El robo de piezas, donde mueren los solucionadores](https://eternity2.dev/es/research/why/piece-theft/) — Un solucionador rellena unas pocas filas sin esfuerzo y luego choca contra un muro en mitad del tablero. He aquí el mecanismo: una pieza escasa gastada en el lugar equivocado, varias filas atrás.
- [Qué muro detiene a qué método](https://eternity2.dev/es/research/why/walls-and-methods/) — La sección de investigación tiene dos vertientes: los muros estructurales que hacen difícil a Eternity II, y los algoritmos concebidos para franquearlos. Esta página es el puente: cada método enfrentado al muro que realmente ataca, y la puntuación en la que ese muro lo detuvo.
- [Récords y solucionadores](https://eternity2.dev/es/research/records/) — Eternity II nunca se ha resuelto, pero casi dos décadas de esfuerzo colectivo han llevado el mejor tablero a 470/480. Quién ostenta qué, cómo lo lograron y por qué algunos tableros «480» anunciados no corresponden al puzzle real.
---
# Dónde viven los desajustes
> Un tablero casi perfecto no reparte sus escasos errores de forma uniforme. Los concentra en una sola banda de cinco filas y deja todo lo demás impecable. ¿Qué banda? Lo decide la dirección en la que la búsqueda rellenó el tablero, y puede verse el reflejo en los tableros récord reales.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/mismatch-geometry/
- Actualizado: 2026-07-22
- Temas: structure
- Fuente: Anuncio del récord 469 de Peter McGavin: el tablero cuyas once aristas no apareadas analiza esta página (groups.io msg 10045, septiembre de 2020) — https://groups.io/g/eternity2/message/10045
---
Puntúa un tablero récord arista por arista y aparece algo llamativo: los
desajustes no están repartidos. El 469 de McGavin tiene sus once aristas no
apareadas, todas ellas, en las cinco primeras filas (filas 0 a 4); las filas
5 a 15 son localmente perfectas.
El tablero es, en efecto, una losa impecable de 11 filas con todos los daños
barridos contra una sola arista.
Puntúa ahora de la misma manera los mejores tableros construidos desde cero de
este proyecto. Los daños vuelven a estar en una banda de cinco filas, pero
abajo. Los desajustes de KEYRING y de GAUNTLET se asientan en las filas 11 a
15, con las filas 0 a 10 perfectas. Es la misma imagen volteada de arriba
abajo.
## Verlo en los tableros reales
Elige un tablero. La banda sombreada es donde caen realmente sus desajustes,
calculada en vivo con la regla de puntuación propia del motor: los tableros de
la comunidad arriba, los de este proyecto abajo.
> **[Figure]** Interactivo: dónde se ven obligados a vivir los desajustes — interactive: MismatchGeometryLab. Rendered on the canonical page (link above); not shown in this markdown export.
## Alejar la vista: la banda es una ley del corpus
Dos tableros podrían ser una anécdota. Agreguemos entonces. Toma todos los
tableros de alta puntuación que este proyecto ha guardado, 1 964 tableros con
455 aristas apareadas o más (convención de aristas apareadas; la
[página de récords](/es/research/records/) sitúa estas cifras internas en su
contexto), y marca cada junta según la frecuencia con la que falla. La misma
imagen reaparece como ley de frecuencias. Las juntas que conectan las filas
11 a 14 con sus vecinas se rompen en aproximadamente el 38 a 49 % de todos
los tableros. La junta más frágil de todo el tablero está en la fila 12,
columna 2, rota en el 49,4 % de los casos; las cuatro siguientes (47,5 %,
47,3 %, 46,3 %, 46,0 %) también pertenecen a la fila 12, y las veinte juntas
más rotas se sitúan todas en las filas 11 a 13. Son recuentos exactos sobre
el corpus guardado, no muestras.
Una advertencia, que en realidad es el hallazgo mismo: cada uno de esos
1 964 tableros salió del propio pipeline de este proyecto, que rellena de
arriba hacia abajo. El mapa de calor no es una propiedad del puzzle; es la
firma del pipeline, escrita 1 964 veces. Un relleno descendente gasta su
presupuesto de conflictos por el camino, el conjunto de restricciones se
tensa primero en torno a la fila 12, y esa costura se parte en la mitad de
las ejecuciones. Un solucionador con otro orden de relleno movería la
costura, que es exactamente lo que muestran los tableros de la comunidad en
la figura de arriba.
## Por qué se voltea: el orden de recorrido
El vuelco no es una coincidencia; es la huella de cómo se construyó cada
tablero. Una búsqueda que rellena el tablero de abajo hacia arriba gasta pronto
sus colocaciones perfectas, abajo, y se ve obligada a absorber todo el conflicto
acumulado en las últimas filas que alcanza: arriba. Una búsqueda que rellena de
arriba hacia abajo hace exactamente lo contrario y amontona los daños abajo. Los
desajustes siempre acaban apiñados contra la arista donde el solucionador
terminó. Mismo puzzle, mismo tipo de tablero, orden de construcción opuesto.
Hay un matiz que la historia de los dos solucionadores esconde: el vuelco es
por ejecución, no por herramienta. Dentro de la propia producción de este
proyecto conviven dos familias de tableros casi récord con geometría
invertida. En una (mejor tablero con 458 aristas apareadas, una antigua
mejor marca interna; véase la [página de récords](/es/research/records/) para el
contexto), todos los desajustes interiores ocupan las cinco últimas filas
del interior y las nueve primeras filas interiores son perfectas. En la otra
(mejor con 457), los veinte desajustes interiores están todos en las filas 1
a 4, con las filas 5 a 14 perfectas. Los mejores tableros de ambas familias
solo comparten 7 de 256 colocaciones (2,7 %): son tableros casi disjuntos,
no dos arreglos de un mismo marco. Y ambos están localmente congelados; la
programación entera exacta, aplicada a cada racimo de daños de hasta unas
treinta celdas, no mejora ninguno de los dos en una sola arista. Son
familias que hemos muestreado, un puñado de tableros cada una: la partición
es una observación, no un censo. Pero matiza la historia: el orden de
recorrido es la fuerza dominante, y sin embargo lo que fija de verdad la
banda es la trayectoria de la ejecución individual, la cuenca en la que
cayó. Mismo pipeline, bandas opuestas.
## La misma banda, bajo un objetivo distinto
El patrón no es un artefacto de cómo puntuamos. Algunos solucionadores optimizan
algo completamente distinto: no las aristas apareadas en un tablero completo,
sino el mayor número de piezas que puedes colocar sin conflicto alguno, dejando
huecos en lugar de desajustes. Persigue ese objetivo y los huecos caen en el
mismo sitio. El tablero «Only seven holes» de Louis Verhaard coloca 249 de las
256 piezas sin conflicto, y los siete huecos se asientan todos en las filas 1 a
4, la banda de arriba una vez más. Laurent Zamofing, alcanzando un techo similar
en 2026 recombinando los tableros récord de la comunidad, observó lo mismo: «el
residuo sin resolver siempre cae en esa banda de arriba»
([msg 11901](https://groups.io/g/eternity2/message/11901)). Dos objetivos que no
comparten nada salvo el puzzle, y el daño sobrante se reúne contra la misma
arista. Es el orden de construcción, no la regla de puntuación, lo que decide
dónde termina alojándose la dificultad. (Más sobre esta variante en la
[página de variantes](/es/research/build/variants/).)
## La forma del daño
El daño tiene una forma constante, no solo un lugar constante. En todos los
tableros casi récord que hemos perfilado, el grafo de las aristas en
desajuste es un bosque: nunca cierra un bucle. Y a medida que los tableros
mejoran, el daño se fragmenta. Los tableros intermedios, entre 444 y 447
(aristas apareadas), llevan 24 a 26 desajustes repartidos en cinco a diez
racimos, el mayor de 13 a 15 celdas. Tres tableros con 458, hallados de
forma independiente, comparten una huella idéntica: 17 desajustes en solo
dos racimos, el mayor de 25 celdas; muy probablemente una misma cuenca
encontrada tres veces. Un tablero con 459 se divide en cuatro racimos
pequeños, el mayor de apenas 10 celdas. Los mejores tableros llevan un
residuo más pequeño y más disperso. Eso sugiere una conjetura, y nada más
que eso: la mejora podría funcionar fragmentando el daño hasta que cada
fragmento sea lo bastante pequeño para repararse localmente.
La concentración misma puede medirse. Comprime la densidad de desajustes por
celda con una transformada de Fourier bidimensional conservando el 1 % de
los coeficientes: un daño bien concentrado se reconstruye con poco error, un
daño disperso no. En esta escala, un tablero con 457 en particular está más
concentrado (error de reconstrucción 0,145) que los tres tableros con 458
(0,236 cada uno, idénticos: la misma cuenca otra vez) y prácticamente empata
con el 459 (0,148), mientras que los tableros intermedios se sitúan entre
0,32 y 0,34. El corpus es pequeño (una decena de tableros), pero dos medidas
estructurales independientes confirman el orden, y apunta a una hipótesis
que vale la pena retener: la calidad estructural podría ser un eje en parte
ortogonal a la puntuación bruta. Un 457 puede estar más cerca de la forma de
un récord que un 458.
## Nada cae en el borde
Reparte las 480 juntas de un tablero en tres clases: 60 juntas borde-borde a
lo largo del anillo, 56 juntas donde el anillo toca el interior, y 364
juntas interior-interior. Compara el 469 de McGavin con un tablero de este
proyecto que alcanzó 444 aristas apareadas sobre un borde equivalente: la
descomposición cuenta dos veces la misma historia. Ambos logran un 60 de 60
perfecto en el anillo y 55 de 56 en la costura. Toda la brecha de 25 aristas
es interior-interior, 354 de 364 frente a 329 de 364. (Solo dos tableros:
léelo como una ilustración de la descomposición, no como una ley del
corpus.) Los cinco colores exclusivos del marco forman un ciclo autónomo que
cualquier búsqueda competente satura; los diecisiete colores interiores son
donde muerde la escasez.
Una sonda más afilada sugiere que el borde ni siquiera lleva la información.
Congela solo el borde del mejor tablero de este proyecto y deja que un
relleno voraz complete el interior: alcanza apenas 204 a 209 aristas
apareadas, el mismo rango que da un borde válido aleatorio (202 a 214).
Congela en cambio las filas de arriba y el relleno sube de forma sostenida:
209 sin fijar nada, 258 con cuatro filas, 334 con ocho, 364 con diez, 406
con doce, 424 con trece, y la puntuación completa con las dieciséis. Se usó
una única política de compleción voraz; trátalo como una sonda, no como una
ley. Pero bajo ese relleno, la identidad de un gran tablero vive en el
esqueleto interior de su primera docena de filas, no en su marco.
## La banda del daño es la banda de la libertad
La banda de abajo no es solo donde se rompen los tableros de este proyecto;
es donde discrepan entre sí. Sobre 421 tableros completos con 455 aristas
apareadas o más (todos, de nuevo, de una misma familia de pipeline), cuenta
cuántos arreglos distintos exhibe cada fila a lo largo del corpus. Las filas
0 a 11 muestran 39 a 63 arreglos distintos cada una, aproximadamente el 9 a
15 % de los tableros únicos en esa fila. Las filas 12 a 15 saltan a 131 o
132 cada una, en torno al 31 %: el triple de diversidad. Las filas donde
viven los desajustes son también aquellas donde los tableros casi récord más
difieren unos de otros.
Acércate a cuatro tableros distintos que alcanzan todos 459 aristas
apareadas y la misma partición aparece celda a celda. Solo 3 de las 256
celdas son idénticas en los cuatro (las dos esquinas superiores más una
celda del anillo del borde); 212 celdas alternan entre exactamente dos
colocaciones; y las 24 celdas que difieren en los cuatro tableros se alojan
por completo en las filas 13 a 15 (nueve, diez y cinco celdas; ninguna en
las filas 0 a 12). En los cuatro tableros de igual puntuación que
comparamos, toda la variación genuina vive en la banda del daño. Un
contraste merece una frase: el reordenamiento que separa uno de esos
tableros del 469 de McGavin abarca todo el interior de forma más o menos
uniforme, cuatro a nueve celdas en cada fila de la 1 a la 14. Moverse entre
tableros de igual puntuación es un barajado de la banda de abajo; moverse a
un tablero realmente mejor exige reconstruir por todas partes (la
[página de los ciclos sigma](/es/research/why/sigma-cycles/) lo hace preciso).
El mecanismo detrás de la diversidad es el mismo que detrás del daño: las
últimas filas rellenadas absorben a la vez el conflicto acumulado y la
libertad acumulada. Todo lo anterior es esqueleto; la banda de abajo es
donde se ramifican las compleciones distintas de alta puntuación.
## Lo que nos dice
Esta es la forma visible de dos hechos más profundos. Primero, los grandes
tableros son de verdad casi completos: la distancia hasta 480 está concentrada,
no difusa, y por eso la programación entera los encuentra localmente congelados
en todas partes salvo en esa única banda (el muro de rigidez). Segundo, dice que
el final de partida es toda la partida: las filas que rellenas en último lugar
son donde el puzzle te hace pagar, de modo que el orden en el que buscas decide
dónde aterriza la dificultad. Es la misma lección que la carrera de caminos del
espacio de juego te hace sentir, aquí inscrita en la estructura de cada tablero
récord.
Dos sondas hacen concretos ambos hechos. La primera: una antigua mejor marca
de este proyecto, un tablero con 459 aristas apareadas, muestra el patrón en
su forma más limpia. Sus 21 desajustes están todos en las filas 12 a 15, las
192 celdas de las filas 0 a 11 son perfectas, y los defectos forman una
única región conexa a lo largo de las cuatro filas de abajo. El arreglo
obvio es fijar las doce filas perfectas y volver a buscar solo la parte de
abajo. Esa búsqueda muere en milisegundos, hacia la profundidad 211: dados
esos compromisos de arriba, 459 es el óptimo. (Un solo tablero, una sola
configuración de búsqueda; el agotamiento, eso sí, es exacto.) La región
perfecta no es holgura en espera. Está gastada: cada grado de libertad aguas
arriba se consumió para hacerla perfecta, y por eso la banda residual no
puede repararse en el sitio, y por eso mejorar ese tablero acabó exigiendo
movimientos de destrucción y reparación que cruzan todo el tablero.
La segunda sonda es la prueba espejo sobre el 469 de McGavin, cuyo daño se
esconde arriba. Fija sus 14 filas superiores y deja que una búsqueda de
destrucción y reparación rellene la parte de abajo: reconstruye el 469
completo. Fija sus 14 filas inferiores y rellena la parte de arriba: solo
llega a 462, sin umbral nítido por el camino (443, 453, 454, 462 a medida
que el bloque fijado crece de once a catorce filas). Y fijar quince filas de
abajo lo hace peor (460) que fijar catorce, porque congelar más tablero
elimina la holgura que la búsqueda necesitaba para absorber la parte de
arriba, la difícil. Fue una sonda rápida de configuración única (una
semilla, sesenta segundos de reparación por punto): toma los números exactos
con cautela; la dirección de la asimetría, en cambio, se predijo antes de la
ejecución y quedó confirmada por ella. La lectura: la banda donde viven los
desajustes es exactamente la parte del tablero que lo define, y el resto se
deriva de ella. Para esa familia de tableros, la brecha por encima de 469 se
lee como un problema de las cinco filas de arriba (una interpretación, no un
teorema). La banda que tu búsqueda deja para el final no es solo donde
pagas; es donde ocurre el trabajo insustituible.
> **Note**
>
> Los recuentos por fila y la banda resaltada se calculan en tu navegador a partir de las aristas reales del tablero (la misma regla de puntuación que usa el motor), no colocados a mano. El hallazgo subyacente y la explicación por el orden de recorrido están consignados en el cuaderno de laboratorio del proyecto.
## Relacionado
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [STAGED](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/staged/) — Construir todo el tablero desde cero, sin marco prefijado, por etapas, dejando que el borde emerja al final a partir de las piezas restantes.
- [Qué muro detiene a qué método](https://eternity2.dev/es/research/why/walls-and-methods/) — La sección de investigación tiene dos vertientes: los muros estructurales que hacen difícil a Eternity II, y los algoritmos concebidos para franquearlos. Esta página es el puente: cada método enfrentado al muro que realmente ataca, y la puntuación en la que ese muro lo detuvo.
- [Por qué el basin-hopping parece imposible](https://eternity2.dev/es/research/why/sigma-cycles/) — Si no puedes mejorar un tablero excelente puliéndolo, quizá puedas saltar a otro tablero excelente. En cada par de récords probado, no puedes, y vale la pena ver la razón estructural que lo explica.
- [Récords y solucionadores](https://eternity2.dev/es/research/records/) — Eternity II nunca se ha resuelto, pero casi dos décadas de esfuerzo colectivo han llevado el mejor tablero a 470/480. Quién ostenta qué, cómo lo lograron y por qué algunos tableros «480» anunciados no corresponden al puzzle real.
---
# Sin jugadas forzadas
> La manera habitual de resolver un puzzle lógico es encontrar un lugar donde solo encaja una pieza, colocarla y repetir. Aquí ese recurso no existe: cada pieza interior tiene entre 73 y 137 vecinas posibles, y ninguna queda jamás fijada a una sola opción.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/no-forced-moves/
- Actualizado: 2026-07-01
- Temas: structure, search-space
- Reproducir: `just research-no-forced-moves`
- Fuente: Sin jugadas forzadas: artículo, código y resultados (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/no-forced-moves
---
Bar,
BarChart,
CartesianGrid,
ResponsiveContainer,
Tooltip,
XAxis,
YAxis,
} from "recharts";
Cada una de las 196 piezas interiores tiene entre 73 y 137 otras piezas que
pueden situarse legalmente a su derecha (contando las parejas de la derecha,
como hace el gráfico anterior). La pieza típica dispone de más de un centenar de
opciones. Ni una sola pieza queda jamás fijada a una única elección.
Este es el reverso de los patrones prohibidos. Allí, casi toda combinación de
piezas es imposible. Cabría pensar que todas esas reglas acabarían acorralando a
las piezas en su sitio. No lo hacen: las restricciones descartan combinaciones
sin acorralar jamás a una pieza individual, de modo que un solucionador nunca
recibe una jugada libre y forzada sobre la que construir.
{data.forcedPieces}
piezas forzadas a una sola opción
{data.minPartners}–{data.maxPartners}
parejas por pieza (del mín. al máx.)
{data.meanPartners}
parejas en promedio
## Cuántas vecinas admite cada pieza
Las 196 piezas interiores, agrupadas según cuántas vecinas de la derecha acepta
cada una. La distribución entera se mantiene muy lejos de uno.
> **[Interactive: PartnerHistogram]** Rendered on the canonical page (link above); not shown in this markdown export.
## Verlo en un puzzle real
El motor rellena unas cuantas celdas; luego contamos, en vivo, cuántas piezas
encajan legalmente en la siguiente. Casi nunca baja a uno.
> **[Figure]** Interactivo: número de candidatas, celda a celda — interactive: ForcedMovesLab. Rendered on the canonical page (link above); not shown in this markdown export.
## Por qué importa
Coloca esto junto a los patrones prohibidos y aparece la verdadera forma de la
dificultad. A escala local el puzzle parece holgado: cualquier pieza encaja al
lado de muchas otras, así que no hay nada que propagar ni cadena de jugadas
forzadas que aprovechar. A escala global casi toda combinación es ilegal. La
dureza vive en esa brecha: mucha libertad local, casi ninguna coherencia global.
Un solucionador tiene que encadenar una larga sucesión de elecciones de
apariencia libre que solo resultan erróneas mucho más tarde.
## Relacionado
- [Por qué un ordenador más rápido no ayuda](https://eternity2.dev/es/research/why/prune-vs-speed/) — La idea más importante de la búsqueda combinatoria difícil: reducir el espacio que se explora vence, por un margen exponencial, a explorarlo más rápido. Eternity II está diseñado para que apenas puedas reducirlo.
- [El robo de piezas, donde mueren los solucionadores](https://eternity2.dev/es/research/why/piece-theft/) — Un solucionador rellena unas pocas filas sin esfuerzo y luego choca contra un muro en mitad del tablero. He aquí el mecanismo: una pieza escasa gastada en el lugar equivocado, varias filas atrás.
- [Calibrado en el pico de dificultad](https://eternity2.dev/es/research/why/phase-transition/) — Eternity II utiliza 22 colores, repartidos entre 17 colores interiores y 5 reservados al marco, y ese número de alrededor de 17 se sitúa cerca del punto donde este tipo de puzzle es más difícil de resolver (la transición es una banda, no un entero único).
- [La consistencia de arco, desde AC-3 en adelante](https://eternity2.dev/es/research/build/reduce/arc-consistency/) — El forward checking mira un movimiento por delante; la consistencia de arco obliga a la lista de candidatos de cada celda a defenderse frente a la de cada vecina, hasta un punto fijo. El AC-3 de Mackworth, los refinamientos óptimos que vinieron después, y lo que toda esa familia midió realmente en este puzzle, incluido dónde deja de ser correcta.
---
# El puzzle no tiene función de altura
> Toma el truco del físico que vuelve solubles los defectos cristalinos e intenta convertir un empalme mal casado en una dislocación con una carga conservada. Fracasa de tres maneras: una altura escalar es ciega a las roturas, el conjunto de roturas forma cadenas abiertas y no bucles cerrados, y la corriente orientada por color no se conserva. Solo sobrevive un bit de paridad sin signo.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/no-height-function/
- Actualizado: 2026-07-23
- Temas: structure, search-space
- Fuente: Verificador sin función de altura: artículo, código fuente Rust y tabla de resultados por tablero (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/no-height-function
---
Hay una idea prestada que, si se sostuviera, cambiaría cómo se ataca este puzzle.
En la física estadística de los cristales, un teselado lleva una **función de
altura**: un número que vive en las caras y sube o baja una cantidad fija al
cruzar cada arista. Cuando el teselado es perfecto, la altura es univaluada. Un
defecto es un punto donde recorrer un pequeño bucle sumando los pasos no te
devuelve al punto de partida; lo que sobra es una carga conservada (los físicos
la llaman **vector de Burgers**), y los defectos solo pueden crearse o destruirse
en pares que se cancelan. Ese último hecho es el premio. Es lo que permite el
**movimiento de gusano**: una reescritura extendida por la red pero simple en el
espacio de alturas, que desliza dos defectos uno hacia el otro hasta que se
cancelan.
Puntúa un tablero completo de Eternity II contando sus empalmes internos casados
sobre 480 (la convención de aristas casadas usada en todo este wiki; la
[página de récords](/es/research/records/) sitúa en contexto los números que siguen).
Un empalme mal casado es una **rotura**. Si las roturas fueran dislocaciones con
una carga orientada conservada, existiría un movimiento no local y fundamentado
que baja el número de roturas haciendo caminar un par de ellas una hacia la otra
para aniquilarlas, justo el tipo de movimiento que la búsqueda por simple
intercambio no puede ver. Esta página deja constancia de por qué esa esperanza no
sobrevive al contacto con un tablero real. El fracaso no es cuestión de gusto. Son
dos hechos concretos medibles en cualquier tablero, más un tercero que no
necesita tablero alguno, y el verificador del tema de reproducción mide los dos
primeros en los tableros récord registrados de este proyecto.
## La altura escalar es ciega desde el principio
Toma primero la versión más ingenua: coloca un solo número en cada celda y lee el
«paso» a través de un empalme como la diferencia de los dos números de las
celdas. Recorre las cuatro celdas alrededor de una esquina interior de la
cuadrícula y suma los cuatro pasos. El número de cada celda entra en el bucle una
vez con un más y una vez con un menos, así que la suma es **cero**, siempre, para
cualquier asignación de números y sin importar qué empalmes estén rotos. Una
rotura vive en un empalme; nunca cambia la suma de bucle de ninguna esquina. Por
tanto, una altura escalar por celda no puede detectar una rotura en absoluto. No
es que las detecte mal; es estructuralmente sorda a ellas. Esta parte es una
identidad de una línea, por lo que se enuncia aquí en vez de medirse.
## El conjunto de roturas son cadenas abiertas, no bucles cerrados
El arreglo del físico consiste en dejar de usar los valores de las celdas y poner
en cambio el paso en un empalme **exactamente cuando ese empalme está roto**.
Entonces la suma de bucle alrededor de una esquina de la cuadrícula cuenta los
empalmes rotos que tocan esa esquina, tomados módulo dos. La altura es univaluada
solo si cada esquina toca un número par de roturas, es decir, solo si las roturas
forman bucles cerrados sobre la cuadrícula de esquinas.
No lo hacen. En cada tablero medido, decenas de esquinas tocan un número **impar**
de roturas. En la imagen cristalina, esas esquinas impares son **núcleos** de
dislocación, los cabos sueltos de cadenas de roturas abiertas. Una altura no puede
cerrarse alrededor de un cabo suelto, así que no puede existir globalmente. El
recuento de estos núcleos es el primer número que informa el verificador, y sigue
siendo grande incluso en los mejores tableros:
| Tablero (este proyecto) | Aristas casadas | Roturas | Núcleos de grado impar | Colores con corriente desequilibrada |
| --- | ---: | ---: | ---: | ---: |
| mejor en aristas casadas, 463 | 463 | 17 | 22 | 10 |
| un tablero 460 | 460 | 20 | 22 | 9 |
| un tablero 458 | 458 | 22 | 34 | 15 |
| un tablero 460 anterior | 460 | 20 | 26 | 12 |
Los cuatro son scores en aristas casadas, revalidados por el verificador antes de
medir la topología; un tablero cuyo valor revalidado difiere del registrado se
rechaza de plano, de modo que los números de arriba describen siempre un tablero
de calidad conocida y verificada. El mejor de ellos queda a solo 17 roturas de una
hipotética solución y todavía lleva 22 núcleos de cadena abierta. La obstrucción
no se ablanda a medida que un tablero se acerca a una solución, y ese es todo el
punto: no existe ningún tablero cerca de la cima donde los bucles se cierren en
silencio.
## La corriente orientada no se conserva
Vale la pena descartar una última escapatoria. Quizá resolver las roturas color
por color rescate una carga conservada. Para un solo color, orienta cada empalme
medio roto (uno donde exactamente un lado muestra ese color, lo que es
necesariamente una rotura) como una flecha que apunta desde la celda portadora del
color hacia su vecina no casada, y suma las flechas en un vector por color sobre
todo el tablero. Una corriente realmente conservada sumaría **cero**. No lo hace.
En cada tablero, varios colores tienen un total distinto de cero, listado en la
última columna de arriba: entre 9 y 15 de los 22 colores llevan una corriente
desequilibrada, según el tablero.
La razón es estructural, y explica por qué ningún ingenio lo remedia. En una
solución real, cada arista de color está casada con una arista del mismo color,
así que no hay empalmes medio rotos y la corriente de cada color es trivialmente
cero. Un empalme medio roto es precisamente una media arista **no casada**, una
cuyo compañero falta, de modo que su flecha no tiene contra qué cancelarse. La
suma desequilibrada no es un desliz de contabilidad; es la firma del compañero que
falta.
Solo a modo de orientación, una ejecución anterior e independiente del cuaderno
midió los mismos recuentos de núcleos en tres tableros distintos (un tablero 451,
uno 463 y uno 458) y obtuvo **28, 22 y 32** núcleos impares; los cuatro tableros
aquí presentados quedan en **22, 22, 34 y 26**, exactamente en el mismo régimen,
coincidiendo el tablero 463 en 22 por ambos lados. Los colores y signos precisos
que salen desequilibrados son etiquetas ligadas a cómo se numeró un tablero
concreto y no tienen sentido propio; solo el recuento de colores desequilibrados,
y el hecho de que nunca sea cero, es el contenido reproducido. Son los propios
tableros de este proyecto, muy por debajo de los mejores de la comunidad, 470 bajo
la convención de la pista central y 464 con las cinco pistas colocadas (de nuevo,
la [página de récords](/es/research/records/) conserva ese contexto); se usan aquí
porque la obstrucción debe verificarse en un tablero real de alta puntuación de la
instancia oficial, no en un tablero pequeño generado donde sería o bien vacía o
bien fuera de instancia.
## Lo que sobrevive es un único bit
Reúne los tres fracasos. Una altura escalar es sorda a las roturas; el conjunto de
roturas son cadenas abiertas con decenas de cabos sueltos; la corriente orientada
por color no se equilibra. Toda ruta hacia una altura de vector de Burgers está
cerrada. Lo que queda es mucho más débil que una altura: el único invariante
conservado del conjunto de roturas es una **paridad por color sin signo**, un bit
por color (un elemento de un espacio de dimensión 22 sobre el cuerpo de dos
elementos). Un bit registra si el recuento de empalmes medio rotos de un color es
par o impar; no tiene dirección ni magnitud. Un bit no es la holonomía de ninguna
función de altura, y ningún movimiento de gusano puede construirse sobre él.
Ese es el resultado negativo, y vale la pena enunciarlo con claridad porque la
idea que mata es realmente atractiva: la imagen de dímeros y defectos queda
cerrada por el lado de las roturas, y con ella el sueño de un movimiento no local
limpio que camine los defectos hasta aniquilarlos. La intuición física que deja en
pie es más esperanzadora y vive en otra parte: la salida correcta de un tablero
localmente congelado (véase el [muro de rigidez](/es/research/why/rigidity-wall/)) es
un **movimiento de agrupamiento correlacionado**, varias fichas giradas juntas, en
vez de cualquier edición de un solo sitio. Ese relato compañero es un resultado
distinto y no se mide aquí.
También encaja con la forma del puzzle tal como se ve en los tableros mismos. Las
roturas no se dispersan; se [amontonan en una sola banda](/es/research/why/mismatch-geometry/)
y el grafo de las aristas mal casadas es siempre un bosque, sin cerrar nunca un
bucle, que es el mismo hecho de cadena abierta que esta página demuestra imposible
de cerrar. El bit de paridad superviviente es un primo de la ley de conteo detrás
de [por qué 479 es imposible](/es/research/why/parity-defect-floor/): ambos son lo que
se obtiene cuando un invariante orientado colapsa en uno sin signo sobre el cuerpo
de dos elementos. La dirección es exactamente lo que esta instancia se niega a
darte.
## Compruébalo tú mismo
El verificador carga cada tablero registrado a través del analizador de tableros
del kit de inicio, lo revalida con la regla canónica (y rechaza todo tablero cuyo
valor revalidado difiera de su score registrado), y luego hace una pasada lineal
para contar los núcleos de grado impar y las corrientes por color desequilibradas.
Es determinista, no usa aleatoriedad, corre en bastante menos de un segundo en un
solo núcleo, y su salida es estable al bit entre ejecuciones. El
[artículo, el código fuente Rust y la tabla de resultados están en GitHub](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/no-height-function),
y el bloque de reproducción de esta página apunta al mismo tema. Dos reservas de
alcance, que el hallazgo enuncia con claridad sobre sí mismo: esta es una
reproducción **cualitativa**. Los recuentos exactos de núcleos y las sumas de
corriente son funciones del tablero concreto, así que se leen como «en el mismo
régimen que», nunca como una coincidencia al bit con una tabla anterior; y la
obstrucción de la altura escalar de la primera sección es una identidad demostrada,
afirmada en vez de recalculada.
## Relacionado
- [Dónde viven los desajustes](https://eternity2.dev/es/research/why/mismatch-geometry/) — Un tablero casi perfecto no reparte sus escasos errores de forma uniforme. Los concentra en una sola banda de cinco filas y deja todo lo demás impecable. ¿Qué banda? Lo decide la dirección en la que la búsqueda rellenó el tablero, y puede verse el reflejo en los tableros récord reales.
- [Por qué el basin-hopping parece imposible](https://eternity2.dev/es/research/why/sigma-cycles/) — Si no puedes mejorar un tablero excelente puliéndolo, quizá puedas saltar a otro tablero excelente. En cada par de récords probado, no puedes, y vale la pena ver la razón estructural que lo explica.
- [Por qué 479 es imposible](https://eternity2.dev/es/research/why/parity-defect-floor/) — Un argumento de conteo sobre el juego de piezas oficial prohíbe una puntuación de exactamente 479/480: las semiaristas de cada color vienen en cantidades pares, y una sola unión rota dejaría dos cuentas impares. El suelo bajo lo perfecto es 478, y a lo sumo 76 cuasi-soluciones a un movimiento pueden rodear una solución.
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [Récords y solucionadores](https://eternity2.dev/es/research/records/) — Eternity II nunca se ha resuelto, pero casi dos décadas de esfuerzo colectivo han llevado el mejor tablero a 470/480. Quién ostenta qué, cómo lo lograron y por qué algunos tableros «480» anunciados no corresponden al puzzle real.
---
# Por qué 479 es imposible
> Un argumento de conteo sobre el juego de piezas oficial prohíbe una puntuación de exactamente 479/480: las semiaristas de cada color vienen en cantidades pares, y una sola unión rota dejaría dos cuentas impares. El suelo bajo lo perfecto es 478, y a lo sumo 76 cuasi-soluciones a un movimiento pueden rodear una solución.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/parity-defect-floor/
- Actualizado: 2026-07-22
- Temas: structure, search-space
- Fuente: David Eddy abre el hilo Parity: el número de aristas de cada tipo es par, y la consecuencia sobre la última pieza (msg 332, junio de 2007) — https://groups.io/g/eternity2/message/332
- Fuente: El ejemplo detallado de Christophe Weibel de una última pieza que no encaja en su hueco (msg 335) — https://groups.io/g/eternity2/message/335
- Fuente: El veredicto de Brendan Owen sobre la paridad en E2: correcta por construcción, útil solo cerca del final de una búsqueda (msg 346) — https://groups.io/g/eternity2/message/346
- Fuente: Suelo de defecto por paridad: artículo, código del verificador y resultados del censo (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/parity-defect-floor
---
Ordene los tableros completos por puntuación, contando las uniones internas
emparejadas sobre 480 (la convención de aristas emparejadas usada en todo
este wiki), y la escalera parece continua: peldaño tras peldaño, cada uno
ocupado por algún tablero que alguien ha construido. Tiene exactamente un
hueco. Ninguna colocación completa legal de las 256 piezas puntúa 479. Es un
teorema sobre el juego de piezas publicado, demostrable solo con contar, y
esta página recorre el argumento entero: la paridad que lo fuerza, el suelo
de defecto de 2 que se sigue, y el censo que acota cuántas cuasi-soluciones
a un movimiento pueden rodear una solución. Es también una entrada de
[el barrido de teoremas](/es/research/why/theorem-sweep/), el repaso de lo que
puede demostrarse a partir de la bolsa antes de lanzar búsqueda alguna.
## Contar las semiaristas
256 fichas con cuatro bordes cada una llevan 1024 semiaristas. El gris del
marco ocupa 64, exactamente el número de posiciones orientadas hacia fuera
en el borde (16 por lado). Las 960 restantes llevan los 22 colores, y el
censo es llamativamente par:
| Grupo de colores | Semiaristas |
| ----------------------------------------- | ----------: |
| Borde gris del marco | 64 |
| Cinco colores de unión del marco (1 a 5) | 24 cada uno |
| Cinco colores interiores (6 a 10) | 48 cada uno |
| Doce colores interiores (11 a 22) | 50 cada uno |
Cada cuenta de color es par. El total coloreado, 960, es exactamente el
doble del número de uniones internas ($2 \times 16 \times 15 = 480$): en una
colocación completa con marco legal, donde las 64 semiaristas grises miran
hacia fuera, las semiaristas coloreadas llenan exactamente las 960 plazas de
las uniones internas, sin sobrar nada. Nada de esto depende de dónde vayan
las piezas. Son propiedades de la bolsa.
Aquí se esconde un atajo agradable: la paridad podía predecirse sin examinar
una sola pieza. Los diseñadores garantizan que existe una solución, y un
tablero resuelto empareja cada semiarista coloreada con una compañera del
mismo color, así que la cuenta de cada color es el doble de su número de
uniones, par por definición. El censo solo confirma sobre el juego real lo
que la resolubilidad ya prometía.
## El argumento, en cuatro líneas
Fije cualquier colocación completa con marco legal (todo borde orientado
hacia fuera es gris) y fije un color $c$. Cada una de las 480 uniones
internas muestra dos semiaristas. Algunas uniones muestran $c$ por ambos
lados, otras por uno solo. Contando las semiaristas de $c$:
$$h(c) = 2 \cdot \#\{\text{uniones que muestran } c \text{ dos veces}\} + \#\{\text{uniones que muestran } c \text{ una vez}\}.$$
Como $h(c)$ es par, el número de uniones que muestran $c$ exactamente una
vez también es par. Esto vale para todos los colores a la vez, en toda
colocación completa, resuelta o rota.
Suponga ahora una colocación con 479. Tiene exactamente una unión rota, y
una unión rota muestra dos colores distintos, digamos $a$ y $b$ (si ambos
lados coincidieran sería un emparejamiento; el gris queda excluido, pues sus
64 semiaristas miran hacia fuera). Toda otra unión está emparejada y muestra
su color dos veces. Así que exactamente una unión muestra $a$ exactamente
una vez. Uno es impar. Eso contradice la paridad de $h(a)$, y la colocación
no puede existir.
## El suelo bajo lo perfecto es 478
Escriba el defecto de un tablero como $480$ menos su puntuación. La paridad
prohíbe el defecto 1 y no prohíbe nada más: en el defecto 2 las cuentas
impares pueden absorberse por parejas, y el argumento calla. Toda colocación
completa legal es, por tanto, o una solución o falla al menos dos uniones.
Un último hecho censado cierra la escapatoria restante: ninguna ficha de
Eternity II queda fija bajo rotación alguna (0 de 256), así que un tablero
no puede puntuar 480 difiriendo de una solución solo por una ficha girada en
su sitio. Puntuación 480 significa solución. Cualquier otra cosa significa
478 o menos.
Para los marcadores de hoy el peldaño ausente es académico: los mejores
tableros completos de la comunidad están en 470 bajo la convención de solo
la pista central y en 464 con las cinco pistas colocadas
([la página de récords](/es/research/records/) mantiene la escalera completa).
Pero cambia lo que «casi resuelto» puede llegar a significar. No hay un
479 por el que pasar de camino a 480. El último paso de la subida va de 478
a 480, dos uniones a la vez, y todo método que mejore tableros una unión
cada vez es estructuralmente incapaz de darlo.
## La cáscara de los 478 es dispersa
Una solución existe; el rompecabezas se construyó a partir de una. ¿Qué hay
justo al lado, en 478? Un tablero a un movimiento de una solución debe venir
de un movimiento que rompa exactamente dos uniones, y solo dos clases de
movimiento único pueden hacerlo. Ambas se cuentan en la bolsa:
- **Intercambios de gemelas.** Dos fichas interiores que coinciden, en
ciertas orientaciones, en tres de sus cuatro bordes. Colocadas de modo que
los bordes coincidentes queden alineados, intercambiarlas perturba un
borde de cada una: dos uniones. El juego contiene exactamente **50** de
estas parejas cuasi-gemelas.
- **Giros en el sitio.** Una ficha cuyos colores repetidos permiten que un
medio giro o un cuarto de giro conserve dos de sus cuatro colores de borde
en posición, de modo que girarla donde está rompe exactamente las otras
dos uniones. El juego contiene **23** fichas de medio giro y **3** fichas
de cuarto de giro de este tipo.
Sumándolos, cualquier solución tiene a lo sumo $50 + 23 + 3 = 76$ vecinos de
defecto 2 alcanzables con un solo intercambio o giro. Es una cota superior
salida de la bolsa: que una pareja de gemelas dada quede realmente alineada
dentro de una solución concreta depende de esa solución, así que la cuenta
realizada para la solución de los diseñadores sigue abierta. El techo se
mantiene de todos modos. Alrededor de la cima de la escalera, las
cuasi-soluciones son dispersas, unas pocas decenas de tableros a lo sumo,
mientras que los peldaños más abajo están poblados astronómicamente. Es la
misma escasez que
[los patrones prohibidos](/es/research/why/forbidden-patterns/) muestran a
escala 2×2, leída en la cumbre.
## El marco paga su factura por adelantado
El censo tiene una segunda historia que contar. Los colores 1 a 5 no
aparecen en ninguna ficha interior; sus $5 \times 24 = 120$ semiaristas
viven por completo en los bordes laterales de las 60 fichas del contorno. El
anillo del contorno tiene exactamente 60 uniones, así que en toda solución
los cinco colores de unión del marco las saturan exactamente, 12 uniones por
color, sin holgura alguna. Y como la orientación de una ficha del contorno
está forzada (gris hacia fuera), cada una de las 56 fichas de borde muestra
un color fijo hacia el interior caiga donde caiga. Sumado sobre la bolsa, el
interior recibe un vector de demanda fijo sobre los colores 6 a 22, a saber
(4, 5, 3, 3, 1, 1, 2, 3, 4, 6, 4, 2, 3, 6, 4, 3, 2), 56 bordes orientados
hacia dentro en total. Sea cual sea el marco que se construya, la factura de
frontera del interior son esos mismos 17 números, conocidos antes de empezar
búsqueda alguna.
## Lo que la comunidad vio en junio de 2007
La paridad se detectó antes incluso de que el rompecabezas saliera a la
venta. En junio de 2007, David Eddy abre un hilo de la lista de correo
titulado Parity con la observación de que «el número de aristas de cada
tipo es par», y extrae la consecuencia sobre la última pieza: si la pieza
final tiene cuatro bordes distintos, el hueco final debe mostrar los mismos
cuatro colores en algún orden, lo que él estima en una probabilidad de 1
entre 6 de encajar
([msg 332](https://groups.io/g/eternity2/message/332)). Christophe Weibel
aporta el ejemplo detallado de que la última pieza realmente puede no
encajar en su hueco
([msg 335](https://groups.io/g/eternity2/message/335)), y Brendan Owen, que
había estudiado el diseño, cierra el hilo con el veredicto práctico: la
paridad es correcta para E2 por construcción, y en una búsqueda solo ayuda
muy cerca del final
([msg 346](https://groups.io/g/eternity2/message/346)).
Todo eso es cierto, y el hilo se detuvo ahí. Empujada un paso más allá, la
misma observación contiene el teorema de arriba: la paridad hace más que
volver azarosa la última pieza, borra el peldaño 479 de raíz, fija el suelo
de defecto en 2, y limita a 76 la cáscara a un movimiento alrededor de cada
solución.
## Compruébelo usted mismo
Cada número de esta página se reduce a un censo en una pasada del juego
oficial: las cuentas de semiaristas y su paridad, la identidad de ajuste
exacto 960, el cero fichas simétricas por rotación, la partición 4/56/196 en
esquinas/bordes/interior, los generadores de defecto 2 en 50/23/3, la
saturación del marco y el vector de demanda hacia el interior. El
verificador recalcula cada valor junto a su valor esperado y emite una
bandera de éxito por afirmación; las 16 comprobaciones pasan y la salida es
idéntica byte a byte entre ejecuciones.
[El artículo, el código del verificador y los resultados están en GitHub](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/parity-defect-floor),
y el bloque de reproducción de esta página apunta al mismo tema. Una
salvedad de alcance: el argumento de paridad cubre colocaciones completas de
las 256 piezas con un marco gris legal. Los tableros parciales, y los que
rompen la regla del marco, quedan fuera de él.
## Relacionado
- [La cosecha de teoremas: trece leyes estructurales](https://eternity2.dev/es/research/why/theorem-sweep/) — Un solo arco de investigación, trece familias de teoremas estructurales: pureza del anillo, el suelo de paridad en 479, el muro de 470 como frontera de fase, los invariantes de flujo, la ley de área entrópica, y los resultados de imposibilidad que ponen precio a cada atajo clásico. Esta página es el mapa.
- [Patrones prohibidos](https://eternity2.dev/es/research/why/forbidden-patterns/) — Casi todo pequeño conjunto de piezas que podrías construir es imposible. Para un cuadrado 2×2, el 99,72 % de las formas de colocar cuatro piezas nunca podrá encajar.
- [Diseñado para ser irresoluble: la receta](https://eternity2.dev/es/research/why/design-recipe/) — Eternity II sigue una receta para lograr el puzzle de emparejamiento de aristas más difícil posible: forma compacta, sin piezas simétricas ni duplicadas, paletas separadas, frecuencias planas, una sola solución esperada. La comunidad aplicó ingeniería inversa a cada ingrediente en el año del lanzamiento.
- [Dónde viven los desajustes](https://eternity2.dev/es/research/why/mismatch-geometry/) — Un tablero casi perfecto no reparte sus escasos errores de forma uniforme. Los concentra en una sola banda de cinco filas y deja todo lo demás impecable. ¿Qué banda? Lo decide la dirección en la que la búsqueda rellenó el tablero, y puede verse el reflejo en los tableros récord reales.
---
# El tablero como palabra de código
> Lee un tablero completo como una palabra de código cuyas 480 junturas interiores son comprobaciones de tipo paridad, y el score de aristas emparejadas pasa a ser 480 menos el número de comprobaciones fallidas. Es una lente limpia que descansa sobre una sola identidad portante, y conviene ser preciso sobre lo que la vista de códigos correctores aporta y lo que solo renombra.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/permutation-code-wall/
- Actualizado: 2026-07-22
- Temas: structure
- Reproducir: `cd research/topics/permutation-code-wall/compute && cargo run --release > ../results/permutation_code_wall.json`
- Fuente: El juego de piezas de Eternity II y el visor interactivo de tablero (bucas.name) — https://e2.bucas.name/
- Fuente: La lente tablero-como-palabra-de-código: artículo, código del verificador y resultados JSON (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/permutation-code-wall
---
Hay una manera de mirar un tablero terminado que toma todo su vocabulario de los
códigos correctores de errores, y resulta realmente esclarecedora en cuanto uno
sabe qué afirma exactamente. Extiende la rejilla de 16 por 16, trata cada ficha
como un símbolo, y trata cada lugar donde dos fichas vecinas se encuentran como
una *comprobación* que pasa (las dos aristas enfrentadas son del mismo color) o
falla. Hay 480 de esas junturas interiores. La lista de comprobaciones que
fallan es un *síndrome*, y una solución completa es el único tablero cuyo
síndrome está vacío. Puntúa un tablero según la
[convención de aristas emparejadas](/es/research/records/) usada en toda esta wiki
(cuenta las junturas interiores que emparejan, de 480), y la aritmética sale
sola: el score es 480 menos el número de comprobaciones fallidas.
Esa sola línea, score igual a 480 menos el peso del síndrome, es todo el motor
de la lente de códigos. Todo lo demás que dice sobre el puzzle (distancia
mínima, decodificadores, conjuntos de parada) se construye encima. Así que
conviene fijar qué es realmente esa identidad, y separar la parte de este cuadro
que es un hecho real y contable sobre el juego oficial de la parte que es solo
un cambio de ropa.
## Qué renombra la lente y qué mide
El reparto claro, enunciado sin rodeos porque en eso está la cuestión.
La identidad misma renombra en vez de revelar. El «peso del síndrome» es el
recuento de aristas interiores no emparejadas; el puntuador ya llama a ese
recuento *roturas* y ya lo define como el score máximo menos el score alcanzado.
Así que «score igual a 480 menos el peso del síndrome» no es un descubrimiento
sobre Eternity II. Es la definición del score escrita en lenguaje de códigos. No
es una crítica: un buen renombre puede volver legible una estructura. Solo
significa que la identidad te da un punto de vista, no un número.
Bajo el vocabulario, en cambio, hay tres hechos que son propiedades reales del
diseño publicado de 256 piezas, cada uno exactamente contable, cada uno
comprobable frente a la instancia oficial:
- **480 comprobaciones.** Una rejilla de 16 por 16 tiene exactamente 480
junturas interiores. Es $2WH - W - H$ con $W = H = 16$, es la longitud de la
propia lista de adyacencias del puntuador, y es el score máximo del kit. Tres
rutas independientes al mismo 480.
- **Un código de permutación.** Las 256 fichas son todas distintas salvo
rotación, de modo que un tablero legal usa cada una de las 256 piezas
exactamente una vez. En términos de códigos, la palabra de código no es una
cadena libre de símbolos; es una permutación, y esa restricción es mucho más
fuerte que las comprobaciones de juntura por sí solas.
- **Un código de borde.** Exactamente cinco colores (etiquetados del 1 al 5)
aparecen solo en el marco, nunca en una ficha interior, y el color de marco
gris se apoya en cero medias aristas interiores. El reborde es un pequeño
código aparte apilado sobre las junturas.
Eso es lo que da a la lente algo concreto sobre lo que apoyarse. El
[teorema de paridad](/es/research/why/parity-defect-floor/), leído en este lenguaje,
es un enunciado de que este código no tiene síndrome de peso uno: no se puede
hacer fallar exactamente una comprobación en un tablero completo legal, de modo
que 479 es un peldaño vacío y el suelo de defecto es 2. La
[ley de área](/es/research/why/entropy-area-law/) y el
[robo de pieza](/es/research/why/piece-theft/) son, en este lenguaje, enunciados
sobre el código de permutación: es la regla «cada pieza una sola vez», y no el
emparejamiento de colores, la que carga con la dificultad.
## La identidad, comprobada bit a bit
Como la identidad es portante, la reproducción la confirma directamente a través
del puntuador canónico del kit, el mismo puntuador que excluye el reborde que el
sitio y cada motor usan, de modo que una comprobación fallida aquí significa lo
mismo que una rotura en cualquier otra parte de esta wiki.
La comprobación parte de una solución verdadera: un tablero de 16 por 16 generado
y resuelto que puntúa 480 sobre 480 con síndrome vacío. Luego inyecta un número
exactamente conocido de comprobaciones rotas corrompiendo una media arista
enfrentada por vez a un color que ninguna pieza lleva, aceptando una corrupción
solo cuando baja el score en exactamente uno. Ese resguardo paso a paso es lo que
hace que el recuento inyectado sea una cantidad conocida y no inferida: $k$
roturas significa exactamente $k$ comprobaciones fallidas, cada una verificada
por separado. Después vuelve a leer el score, el número de roturas y un recuento
independiente del síndrome, y confirma que los tres coinciden.
Ejecutado sobre cinco tableros resueltos y ocho números de roturas (cuarenta
filas en total, sobre la convención de aristas emparejadas, de 480), cada fila
obedece la identidad:
| Roturas inyectadas $k$ | Score | Roturas | Recuento independiente del síndrome | 480 menos $k$ |
| ---------------------: | ----: | ------: | ----------------------------------: | ------------: |
| 0 | 480 | 0 | 0 | 480 |
| 1 | 479 | 1 | 1 | 479 |
| 2 | 478 | 2 | 2 | 478 |
| 5 | 475 | 5 | 5 | 475 |
| 10 | 470 | 10 | 10 | 470 |
| 29 | 451 | 29 | 29 | 451 |
| 60 | 420 | 60 | 60 | 420 |
| 120 | 360 | 120 | 120 | 360 |
Cada fila satisface score igual a 480 menos $k$, roturas igual a $k$, y el
recuento independiente del síndrome igual a $k$, en las cinco semillas. La
ejecución es determinista y termina en menos de un segundo sobre Apple Silicon;
el JSON de resultados archivado es estable byte a byte al reejecutar. La fila en
$k$ igual a 29 está ahí a propósito: muestra el score 451, que es exactamente el
par score-y-roturas que lleva el tablero campeón de banda inferior construido desde
cero del artículo (29 roturas, 451 aristas emparejadas). La identidad 480
menos 29 igual a 451 se sostiene frente al par score-y-roturas que el artículo
reporta para ese tablero campeón. (Ese
451 es una cifra de cuaderno obtenida desde cero, muy por debajo de los mejores
tableros completos de la comunidad, en 470 y 464, en la
[página de récords](/es/research/records/); aquí lo único que importa es que la
aritmética de códigos cae sobre él.)
## Los hechos estructurales, sobre la instancia oficial
| Hecho | Esperado | Medido |
| --- | --- | --- |
| Número de comprobaciones | 480 | 480 de tres formas: fórmula $2WH - W - H$, lista de adyacencias enumerada, score máximo del kit |
| Código de permutación | 256 fichas, cada una una vez | 256 piezas, todas distintas salvo rotación |
| Código de borde, colores de marco | cinco, confinados al reborde | 5 colores de marco (del 1 al 5), 17 colores interiores |
| Código de borde, gris | solo reborde exterior | 0 medias aristas grises en cualquier pieza interior |
Los cuatro se recalculan a partir de los datos de la instancia en vez de
suponerse, y los cuatro coinciden.
## Qué aporta y qué no aporta la vista de códigos correctores
Lo que aporta es un modelo mental limpio y un lugar donde alojar las dos
restricciones duras. Las comprobaciones de juntura forman por sí solas un código
débil: localmente, un tablero casi perfecto tiene abundantes patrones de color de
bajo desacuerdo cerca, y por eso los
[desacuerdos se agrupan](/es/research/why/mismatch-geometry/) en una sola banda en
lugar de esparcirse. La fuerza vive en el código de permutación superpuesto
encima, la exigencia de que los símbolos sean un reordenamiento genuino de las
256 piezas completas. Nombrar esa capa, y separarla de las comprobaciones de
color, es una forma útil de decir dónde está la dificultad: no en emparejar
colores, sino en emparejarlos mientras cada pieza se gasta exactamente una vez.
Lo que no aporta es un número nuevo. La identidad central es la propia definición
del score en otro alfabeto, y el vocabulario de decodificadores y distancia
mínima describe el mismo paisaje que las páginas de
[rigidez](/es/research/why/rigidity-wall/) y
[ley de área](/es/research/why/entropy-area-law/) miden directamente, sin añadir una
medida propia. La afirmación más fuerte que una lectura de códigos querría hacer,
que la distancia mínima del código de permutación es lo que fija en su lugar un
tablero récord concreto, es una medida propia de un tablero que vive sobre un
único tablero campeón privado que el kit público no entrega, de modo que aquí no
queda ni confirmada ni refutada. Lo que se reproduce exactamente es el andamiaje:
480 comprobaciones, un código de permutación de 256 piezas, un código de borde de
cinco colores, y la única identidad que sostiene todo el cuadro.
## Relacionado
- [Por qué 479 es imposible](https://eternity2.dev/es/research/why/parity-defect-floor/) — Un argumento de conteo sobre el juego de piezas oficial prohíbe una puntuación de exactamente 479/480: las semiaristas de cada color vienen en cantidades pares, y una sola unión rota dejaría dos cuentas impares. El suelo bajo lo perfecto es 478, y a lo sumo 76 cuasi-soluciones a un movimiento pueden rodear una solución.
- [Dónde viven los desajustes](https://eternity2.dev/es/research/why/mismatch-geometry/) — Un tablero casi perfecto no reparte sus escasos errores de forma uniforme. Los concentra en una sola banda de cinco filas y deja todo lo demás impecable. ¿Qué banda? Lo decide la dirección en la que la búsqueda rellenó el tablero, y puede verse el reflejo en los tableros récord reales.
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [La entropía y la ley de área](https://eternity2.dev/es/research/why/entropy-area-law/) — Eternity II tiene dos reglas: los bordes deben coincidir y cada pieza se usa una sola vez. La primera es generosa. Toda la dificultad reside en la segunda.
- [El robo de piezas, donde mueren los solucionadores](https://eternity2.dev/es/research/why/piece-theft/) — Un solucionador rellena unas pocas filas sin esfuerzo y luego choca contra un muro en mitad del tablero. He aquí el mecanismo: una pieza escasa gastada en el lugar equivocado, varias filas atrás.
- [Récords y solucionadores](https://eternity2.dev/es/research/records/) — Eternity II nunca se ha resuelto, pero casi dos décadas de esfuerzo colectivo han llevado el mejor tablero a 470/480. Quién ostenta qué, cómo lo lograron y por qué algunos tableros «480» anunciados no corresponden al puzzle real.
---
# Calibrado en el pico de dificultad
> Eternity II utiliza 22 colores, repartidos entre 17 colores interiores y 5 reservados al marco, y ese número de alrededor de 17 se sitúa cerca del punto donde este tipo de puzzle es más difícil de resolver (la transición es una banda, no un entero único).
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/phase-transition/
- Actualizado: 2026-07-02
- Temas: structure
- Reproducir: `just research-phase-transition`
- Fuente: Brendan Owen, Diseñar el puzzle más difícil: la derivación 17+5 (lista de correo eternity2, agosto de 2007) — https://groups.io/g/eternity2/message/1947
- Fuente: Ansótegui, Béjar, Fernández & Mateu, On the hardness of solving edge matching puzzles as SAT or CSP problems (Constraints, Springer 2013) — https://link.springer.com/article/10.1007/s10601-012-9128-9
- Fuente: Ansótegui, Béjar, Fernández & Mateu, How Hard is a Commercial Puzzle: the Eternity II Challenge — https://repositori.udl.cat/server/api/core/bitstreams/0b6533fe-54e5-4070-85fe-80f7d35837d8/content
---
Los problemas de búsqueda difíciles tienen una perilla de dificultad. Aflójela
y habrá muchas soluciones, de modo que una búsqueda tropieza con alguna
enseguida. Apriétela y no habrá ninguna, algo que a menudo es fácil de probar.
En medio se sitúa una banda estrecha donde las soluciones son escasas pero
reales, y ahí es donde la búsqueda estalla. Se le llama transición de fase,
como el agua al congelarse.
En los puzzles de emparejamiento de aristas, esa perilla es el número de
colores. Demasiado pocos y las piezas encajan de innumerables maneras;
demasiados y apenas encajan. El
[análisis publicado](https://link.springer.com/article/10.1007/s10601-012-9128-9)
sitúa el pico en torno a 17 colores interiores, el ajuste con el que un puzzle
de este tamaño tiene aproximadamente una única solución. Eternity II utiliza 17.
La comunidad ya disponía de ese número pocas semanas después del lanzamiento:
en agosto de 2007, Brendan Owen dedujo $I = (196! \cdot 4^{196})^{1/392} \approx 17.14$
colores interiores a partir del criterio de «aproximadamente una solución
esperada», exactamente los parámetros publicados, años antes de los análisis
académicos
([Diseñar el puzzle más difícil, msg 1947](https://groups.io/g/eternity2/message/1947)).
Lo medimos aquí. El criterio de Owen solo se enunció para el tablero completo,
así que lo llevamos a un segundo tamaño para ver si se sostiene. La misma fórmula
predice $(36! \cdot 4^{36})^{1/72} \approx 7.56$ colores interiores para un
tablero 8x8, y un 8x8 es lo bastante pequeño como para que un backtracker común
resuelva de verdad instancias aleatorias: su curva de dificultad se puede barrer
directamente. Al medir el esfuerzo del solucionador frente al número de colores
interiores sobre tableros 8x8 generados (el generador y el DFS del sitio), la
banda dura, donde la búsqueda deja de encontrar solución dentro del presupuesto,
cae justo donde lo predice el criterio a tamaño 8. El barrido 16x16 completo es
la otra mitad del cuadro: un backtracker común no lo termina con ningún número de
colores, y la profundidad que alcanza decrece de forma sostenida al aumentar los
colores, de modo que el tablero real queda más allá del punto donde la curva ya
se ha vuelto vertical. El
[experimento hardness-peak](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/hardness-peak)
contiene el código, ambos barridos y el criterio recalculado en el repositorio
(reproduce el 17,14 de Owen a tamaño 16).
## El muro de la dificultad
> **[Figure]** Interactivo: el pico de dificultad según el número de colores — interactive: PhaseTransitionLab. Rendered on the canonical page (link above); not shown in this markdown export.
## O mídelo tú mismo
El gráfico anterior está precalculado. Este no lo está: el motor resuelve en
vivo puzzles inéditos, uno por cada número de colores, y traza el pico a partir
de ejecuciones reales en tu navegador.
> **[Figure]** Interactivo: resolver en vivo a lo largo del pico de dificultad — interactive: PhaseTransitionLiveLab. Rendered on the canonical page (link above); not shown in this markdown export.
## La transición, medida sobre piezas reales
El argumento basado en el número de colores indica *dónde* está el pico. En
marzo de 2008, Brendan Owen fue a observar una transición de fase directamente,
sobre las piezas reales. Tomó un fino rectángulo interior de 2 por L y lo cubrió
con conjuntos aleatorios de piezas interiores de E2, cuatrocientos conjuntos
aleatorios por cada longitud, y anotó cuántos podían completarse sin ninguna
discordancia
([msg 4909](https://groups.io/g/eternity2/message/4909)).
> **[Interactive: RectangleTransitionChart]** Rendered on the canonical page (link above); not shown in this markdown export.
La forma resultante es la transición de fase en miniatura. Una tira de 2 por 1
o 2 por 2 es tan corta que las piezas aleatorias a menudo simplemente encajan:
58 % de casos resolubles en la longitud 1. Luego se apaga por completo. De la
longitud 4 a la 15, ni un solo conjunto aleatorio de cuatrocientos cubre el
rectángulo en ninguna longitud: las soluciones son tan escasas que
prácticamente no existen. Y entonces reaparecen. En la longitud 16, un conjunto
de cuatrocientos funciona; en 19 es el 8,5 %; en 21 es el 57 %; y en 22, casi
nueve de cada diez. La región donde las soluciones son extremadamente raras
pero aún no imposibles es precisamente la banda difícil, y aquí no es ni un
relato ni un modelo: es un recuento. También es la razón por la que un interior
de 14 celdas de ancho resulta tan implacable: se sitúa en la parte empinada de
esa subida, donde una solución existe pero casi ningún arreglo aleatorio lo es.
## La división, leída directamente en las piezas
Ordenar los colores del conjunto oficial según dónde aparecen deja el diseño a
la vista.
5 colores reservados al marco
{data.frameOnlyColors.map((c) => (
> **[Interactive: MotifSwatch]** Rendered on the canonical page (link above); not shown in this markdown export.
'{colorToLetter(c)}'
))}
Solo aparecen en las piezas de borde y de esquina, nunca en el interior.
Son los colores raros, confinados al perímetro.
17 colores interiores
{data.interiorColors.map((c) => (
> **[Interactive: MotifSwatch]** Rendered on the canonical page (link above); not shown in this markdown export.
'{colorToLetter(c)}'
))}
La paleta del interior del tablero, donde ocurre casi todo el
emparejamiento.
## El conjunto en cifras
| | Cantidad |
| ------------------- | -------: |
| Piezas de esquina | 4 |
| Piezas de borde | 56 |
| Piezas interiores | 196 |
| Colores interiores | 17 |
| Colores del marco | 5 |
## Por qué importa
Es la señal individual más clara de que Eternity II se hizo difícil a
propósito. El tamaño del tablero, el número de piezas y la división de colores
apuntan todos al mismo objetivo: un puzzle con aproximadamente una única
solución, colocado en el peor lugar posible para que cualquier búsqueda la
encuentre. La dificultad fue elegida, igual que un buen examen no es ni trivial
ni imposible.
¿Cómo sabemos que el pico es real y no un mero relato? Aquí confluyen dos vías.
El análisis publicado lo
[deriva](https://repositori.udl.cat/server/api/core/bitstreams/0b6533fe-54e5-4070-85fe-80f7d35837d8/content):
para los puzzles de emparejamiento de aristas con marco, el número de colores
con el que se esperaría aproximadamente una solución cae cerca de 17, y ese es
el ajuste más difícil de explorar. Y tú mismo puedes observar una parte de
ello en la demostración anterior: construye puzzles reales, cuenta el trabajo, y
velo explotar cuando los colores escasean. El impacto es concreto. Significa
que la distancia hasta una solución no es un problema de ajuste que se pueda
limar con una máquina más rápida; el puzzle se colocó donde la búsqueda es peor
a propósito, de modo que vencerlo exige una idea genuinamente mejor, no
simplemente más esfuerzo.
Ve la dificultad medida en vivo en la [página de Algoritmos](/algorithms/).
## Relacionado
- [Diseñado para ser irresoluble: la receta](https://eternity2.dev/es/research/why/design-recipe/) — Eternity II sigue una receta para lograr el puzzle de emparejamiento de aristas más difícil posible: forma compacta, sin piezas simétricas ni duplicadas, paletas separadas, frecuencias planas, una sola solución esperada. La comunidad aplicó ingeniería inversa a cada ingrediente en el año del lanzamiento.
- [Por qué un ordenador más rápido no ayuda](https://eternity2.dev/es/research/why/prune-vs-speed/) — La idea más importante de la búsqueda combinatoria difícil: reducir el espacio que se explora vence, por un margen exponencial, a explorarlo más rápido. Eternity II está diseñado para que apenas puedas reducirlo.
- [La entropía y la ley de área](https://eternity2.dev/es/research/why/entropy-area-law/) — Eternity II tiene dos reglas: los bordes deben coincidir y cada pieza se usa una sola vez. La primera es generosa. Toda la dificultad reside en la segunda.
- [Sin jugadas forzadas](https://eternity2.dev/es/research/why/no-forced-moves/) — La manera habitual de resolver un puzzle lógico es encontrar un lugar donde solo encaja una pieza, colocarla y repetir. Aquí ese recurso no existe: cada pieza interior tiene entre 73 y 137 vecinas posibles, y ninguna queda jamás fijada a una sola opción.
---
# El robo de piezas, donde mueren los solucionadores
> Un solucionador rellena unas pocas filas sin esfuerzo y luego choca contra un muro en mitad del tablero. He aquí el mecanismo: una pieza escasa gastada en el lugar equivocado, varias filas atrás.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/piece-theft/
- Actualizado: 2026-07-01
- Temas: structure, search-space
- Reproducir: `just research-piece-theft`
- Fuente: Régin 1994, «A Filtering Algorithm for Constraints of Difference in CSPs» (AAAI-94): el argumento all-different/conjunto de Hall que motiva el recuento de demandas escasas de esta página — https://cdn.aaai.org/AAAI/1994/AAAI94-055.pdf
---
Bar,
BarChart,
CartesianGrid,
ResponsiveContainer,
Tooltip,
XAxis,
YAxis,
} from "recharts";
Rellena el tablero de la esquina superior izquierda hacia la inferior derecha y
cada celda nueva ya conoce dos de sus colores: el color norte proviene de la
pieza de arriba, el color oeste de la pieza de la izquierda. La celda necesita
una pieza sin usar capaz de mostrar exactamente ese par. Esas demandas son
escasas, con solo unas tres piezas posibles en promedio, y 47 de ellas tienen
una sola.
Así, un tablero que parece sano, con la mayoría de las piezas todavía en la
caja, puede estar ya condenado. En algún punto más arriba del tablero, la única
pieza que jamás podría satisfacer una celda futura se empleó en otra cosa.
Cuando el solucionador alcanza por fin esa celda, no hay nada que colocar.
## Cómo muere una celda
> **[Interactive: PieceTheftDiagram]** Rendered on the canonical page (link above); not shown in this markdown export.
## Cuántas piezas pueden satisfacer una demanda
{data.uniqueServerDemands}
demandas satisfechas por una sola pieza
{data.meanServers}
piezas por demanda, en promedio
{data.occurringDemands}
demandas distintas que aparecen
> **[Figure]** interactive: ServersChart. Rendered on the canonical page (link above); not shown in this markdown export.
## Deja morir de hambre a una celda tú mismo
El motor rellena un tablero hasta una celda con un único proveedor legal; roba
esa pieza y observa cómo la celda muere con la caja todavía llena.
> **[Figure]** Interactivo: dónde mueren los solucionadores por el robo de piezas — interactive: PieceTheftLab. Rendered on the canonical page (link above); not shown in this markdown export.
## Por qué importa
Un arreglo tentador es una comprobación global: ¿siguen las piezas restantes
cubriendo las celdas restantes? No sirve de nada. A nivel global la oferta es
suficiente; el fallo es una sola pieza escasa mal asignada, no una carencia.
Por eso una anticipación global no ve nada anormal hasta el momento en que la
celda resulta no tener proveedor, lo que explica por qué una comprobación global
ingenua no lo detecta.
Ponlo junto a la [ausencia de jugadas forzadas](/es/research/why/no-forced-moves/) y
la trampa queda completa. Cada pieza tiene decenas de lugares donde podría ir,
de modo que al solucionador nunca se le indica dónde debe reservarse una pieza
escasa, y sin embargo cada pieza escasa tiene exactamente una demanda para la
que debe preservarse. Libertad para colocar, ninguna guía sobre qué guardar.
## Relacionado
- [Sin jugadas forzadas](https://eternity2.dev/es/research/why/no-forced-moves/) — La manera habitual de resolver un puzzle lógico es encontrar un lugar donde solo encaja una pieza, colocarla y repetir. Aquí ese recurso no existe: cada pieza interior tiene entre 73 y 137 vecinas posibles, y ninguna queda jamás fijada a una sola opción.
- [La entropía y la ley de área](https://eternity2.dev/es/research/why/entropy-area-law/) — Eternity II tiene dos reglas: los bordes deben coincidir y cada pieza se usa una sola vez. La primera es generosa. Toda la dificultad reside en la segunda.
- [All-different, el filtro por matching de Régin](https://eternity2.dev/es/research/build/reduce/alldiff-regin/) — Ninguna pieza puede usarse dos veces: una sola restricción all-different global sobre 256 celdas. Jean-Charles Régin mostró en 1994 cómo un matching bipartito la filtra por completo en tiempo polinómico; su variante por color es el propagador más potente jamás medido sobre el edge matching, con una reserva clara sobre las búsquedas tolerantes a desajustes.
- [PRIOR](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/prior/) — Construir un tablero desde cero, resolviendo los empates según la posición habitual de las piezas en los buenos tableros ya conocidos. Alcanza una puntuación alta sin ningún tablero de partida que copiar.
---
# Por qué un ordenador más rápido no ayuda
> La idea más importante de la búsqueda combinatoria difícil: reducir el espacio que se explora vence, por un margen exponencial, a explorarlo más rápido. Eternity II está diseñado para que apenas puedas reducirlo.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/prune-vs-speed/
- Actualizado: 2026-07-01
- Temas: speed, search-space, backtracking
- Reproducir: `just research-prune-vs-speed`
- Fuente: Artículo, código y resultados en GitHub (research/topics/prune-vs-speed) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/prune-vs-speed
- Fuente: Peter McGavin: la poda por detección temprana de callejones sin salida suele ser demasiado costosa para que merezca la pena (groups.io msg 11848) — https://groups.io/g/eternity2/message/11848
- Fuente: @95A31: toda una batería de comprobaciones de factibilidad resultó inútil en una búsqueda 8×8 (groups.io msg 11856) — https://groups.io/g/eternity2/message/11856
---
Imagina la búsqueda como un árbol. Desde el tablero vacío eliges una pieza para
la primera celda; a partir de ahí una pieza para la segunda; y así
sucesivamente, hasta 256 celdas de profundidad. El número de hojas en la base
es el factor de ramificación elevado a la profundidad, un número
astronómicamente grande. Para demostrar que una región no tiene solución, una
búsqueda tiene que recorrer ese árbol.
Ahora bien, hay dos maneras de hacer menos trabajo. Puedes ir más **rápido**: un
motor mejor, más núcleos, bucles internos afinados a mano. O puedes hacer el
árbol más **pequeño**, podando las ramas que no pueden llevar a ninguna
solución, de modo que el factor de ramificación efectivo disminuya. Suenan
parecidas. Ni siquiera se acercan.
## Constante frente a exponencial
Una aceleración es un divisor constante. Haz la máquina 1000× más rápida y
esperarás 1000× menos, lo mismo tanto si el árbol tiene diez niveles de
profundidad como si tiene diez mil. Te compra un múltiplo fijo, punto.
Una poda, en cambio, se compone. Recorta aunque sea un pequeño porcentaje del
factor de ramificación y ahorrarás esa fracción en cada uno de los niveles. A lo
largo de 256 niveles, los ahorros se multiplican entre sí: reducir el factor de
ramificación de $b$ a $b'$ divide el trabajo por $(b/b')^{256}$. Un recorte del
5 %, aplicado hasta el fondo, vale $(1/0.95)^{256} \approx 5\times10^{5}$, el
equivalente a una aceleración de quinientas mil veces, a partir de una sola idea
estructural barata. Eso vence a casi cualquier aceleración que una máquina real
pueda ofrecer.
## Siente la diferencia
Pon una aceleración bruta en la balanza frente a una pequeña poda por nivel y
observa cómo la poda gana por varios órdenes de magnitud.
> **[Figure]** Interactivo: poder de la poda frente a velocidad bruta — interactive: PruneVsSpeedLab. Rendered on the canonical page (link above); not shown in this markdown export.
## Por qué esto es exactamente la maldición de E2
Si la poda es la palanca que importa, los puzzles difíciles son aquellos que no
se pueden podar. Eternity II fue calibrado para ser precisamente eso. Cuatro de
sus muros dicen, en el fondo, lo mismo: no hay nada local que podar.
- **[Sin jugadas forzadas](/es/research/why/no-forced-moves/)**: cada celda interior
aún tiene de 73 a 137 vecinos legales, así que la propagación casi nunca reduce
una celda a una sola opción. El factor de ramificación se mantiene
obstinadamente alto.
- **[En el pico de dificultad](/es/research/why/phase-transition/)**: los recuentos
de piezas y colores se sitúan donde se espera alrededor de una solución, sin
dejar ninguna región densa en soluciones a la que apuntar un atajo
estadístico, el truco que hizo caer Eternity I.
- **[La ley de área](/es/research/why/entropy-area-law/)**: el recuento de tableros
parciales genuinamente distintos se desploma a medida que crece el área rellenada, pero
ninguna señal de puntuación local puede ver ese colapso global, así que no
puedes podar hacia él de forma barata.
- **[La rigidez](/es/research/why/rigidity-wall/)**: incluso a partir de un tablero
récord, el salto a uno mejor es enorme e indivisible, sin gradiente que seguir
ni nada cercano que podar.
## Lo que significa para todo lo demás aquí
Esta es la lente para toda la sección de investigación. Un motor mucho más
rápido hace la misma búsqueda más barata, no más pequeña, y no mueve el récord.
Cada experimento que sí movió la aguja cambió en su lugar la forma de la
búsqueda: un orden de recorrido distinto, un a priori aprendido sobre dónde se
sitúan las piezas, una región confinada para los desajustes. Y cada callejón sin
salida es, en el fondo, una poda que la estructura global del puzzle se niega a
honrar. La velocidad al principio da sensación de productividad; casi nunca es
ahí donde se esconde la distancia hasta 480.
## La comunidad también llegó aquí, por las malas
La mitad contraintuitiva de esto es que incluso la poda *legal* a menudo pierde.
Una comprobación que detecta un tablero parcial condenado y retrocede pronto
suena como una victoria gratis, pero si la comprobación cuesta más que el
subárbol que ahorra, un backtracker simple que sigue avanzando sin más es más
rápido. Peter McGavin expuso sin rodeos la opinión asentada en la lista de
groups.io: los métodos que intentan detectar una colocación parcial condenada y
retroceder pronto "generalmente se consideran demasiado costosos para que
merezcan la pena". Un recién llegado que ejecutaba un solucionador de diagramas
de decisión, @95A31, lo confirmó después desde cero: tras construir toda una
batería de comprobaciones de factibilidad, informó de que "todas las
comprobaciones de factibilidad que implementé resultaron inútiles", con una
búsqueda 8×8 completa todavía abriéndose paso a través de 953 mil millones de
nodos durante 17 horas. La lección no es que la poda sea mala, sino que una poda
solo compensa si es *más barata que la búsqueda que elimina*, y en este puzzle
casi nada local supera ese listón.
> **Note**
>
> Los números del árbol en la demo son ilustrativos: un factor de ramificación y una profundidad elegidos para ser parecidos a E2 y legibles, no la medición de un solucionador concreto. La curva de dificultad y los recuentos de nodos, en cambio, son mediciones reales de motor sobre puzzles pequeños, deterministas y reproducibles con `just research-prune-vs-speed`. El principio en sí, divisor constante frente a divisor exponencial, es exacto.
## Relacionado
- [Qué muro detiene a qué método](https://eternity2.dev/es/research/why/walls-and-methods/) — La sección de investigación tiene dos vertientes: los muros estructurales que hacen difícil a Eternity II, y los algoritmos concebidos para franquearlos. Esta página es el puente: cada método enfrentado al muro que realmente ataca, y la puntuación en la que ese muro lo detuvo.
- [La teoría compleja: contar el árbol de búsqueda antes de recorrerlo](https://eternity2.dev/es/research/why/complex-theory/) — La teoría compleja de Brendan Owen estima la anchura del árbol de búsqueda a cada profundidad, e incluso cuántas soluciones existen en total. Muchos en la comunidad la consideran lo más importante que hay que entender sobre Eternity II.
- [Sin jugadas forzadas](https://eternity2.dev/es/research/why/no-forced-moves/) — La manera habitual de resolver un puzzle lógico es encontrar un lugar donde solo encaja una pieza, colocarla y repetir. Aquí ese recurso no existe: cada pieza interior tiene entre 73 y 137 vecinas posibles, y ninguna queda jamás fijada a una sola opción.
- [Calibrado en el pico de dificultad](https://eternity2.dev/es/research/why/phase-transition/) — Eternity II utiliza 22 colores, repartidos entre 17 colores interiores y 5 reservados al marco, y ese número de alrededor de 17 se sitúa cerca del punto donde este tipo de puzzle es más difícil de resolver (la transición es una banda, no un entero único).
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [La consistencia de arco, desde AC-3 en adelante](https://eternity2.dev/es/research/build/reduce/arc-consistency/) — El forward checking mira un movimiento por delante; la consistencia de arco obliga a la lista de candidatos de cada celda a defenderse frente a la de cada vecina, hasta un punto fijo. El AC-3 de Mackworth, los refinamientos óptimos que vinieron después, y lo que toda esa familia midió realmente en este puzzle, incluido dónde deja de ser correcta.
---
# Los colores raros viven en el marco
> Cinco de los 22 colores de Eternity II aparecen solo a lo largo del anillo de borde, cada uno en exactamente 24 aristas, nunca una sola vez en el interior. Una separación estructural que moldea la forma en que cada solucionador trata el marco.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/rare-color-geography/
- Actualizado: 2026-07-01
- Temas: structure
- Reproducir: `just research-rare-color-geography`
- Fuente: Brendan Owen deriva el diseño de 17+5 colores como el puzzle más difícil posible (mensaje groups.io 1947) — https://groups.io/g/eternity2/message/1947
---
Bar,
BarChart,
CartesianGrid,
Legend,
ResponsiveContainer,
Tooltip,
XAxis,
YAxis,
} from "recharts";
Los 22 colores no juegan roles equivalentes. Ordénalos según dónde se sitúan sus
aristas y se dividen en dos clases nítidas: cinco colores raros confinados al
borde, y diecisiete colores comunes que hacen casi todo su trabajo dentro del
tablero.
## Dónde se permiten los colores raros
Elige uno de los cinco colores raros y observa el tablero: sus 24 aristas se
encienden todo alrededor del anillo del marco, y el interior de 14×14 permanece
completamente en blanco. Cambia a un color común y en cambio se llena el
interior. Ese centro vacío, para cada color raro, es todo el resultado.
> **[Figure]** interactive: RareColorRing. Rendered on the canonical page (link above); not shown in this markdown export.
## Los cinco colores raros
> **[Interactive: RareSwatches]** Rendered on the canonical page (link above); not shown in this markdown export.
{data.edgesPerRareColor}
aristas cada uno
{data.rareEdgesTotal}
aristas raras, todas en el marco
0
aristas raras en el interior
## Marco frente a interior, color por color
> **[Figure]** interactive: FrameInteriorChart. Rendered on the canonical page (link above); not shown in this markdown export.
> **[Figure]** Interactivo: la geografía de borde de los colores raros — interactive: RareColorLab. Rendered on the canonical page (link above); not shown in this markdown export.
## Por qué importa
La separación en sí misma es estructural, no es un truco defensivo. Como el
reborde exterior es de un gris uniforme, cada pieza de borde mantiene su arista
gris orientada hacia afuera, de modo que sus aristas coloreadas solo llegan a
encontrarse con otras aristas de borde o con el interior: los colores de borde
y de interior viven en reservas separadas, pase lo que pase. Los cinco colores
de borde se leen como "raros" simplemente porque hay muchas menos aristas de
borde que colorear, y podrían reetiquetarse con cualesquiera cinco valores
(incluso reutilizando los del interior) sin cambiar en nada el puzzle. (Consulta
la [nota de diseño sobre el porqué](/es/research/why/#diseñado-para-resistir-el-ingenio),
con nuestro agradecimiento a Vasily V. en la lista groups.io por la corrección.)
Lo que sí es real, y lo que importa para resolver, es la consecuencia: el
interior de 14×14 queda a merced de diecisiete colores comunes sin ninguna señal
rara, fuertemente restrictiva, en ninguna parte de él, lo que explica en gran
medida por qué la búsqueda en el interior tiene tan poco a lo que aferrarse. El
borde, donde la reserva de colores es pequeña y las coincidencias son ajustadas,
es en consecuencia la parte que todo tablero sólido logra prácticamente perfecta.
Los conteos de colores de Eternity II se equilibraron para eliminar los apoyos
estadísticos que hundieron a Eternity I; esta geografía es donde se siente el
resultado.
Consulta [por qué el interior no ofrece movimientos forzados](/es/research/why/no-forced-moves/).
## Relacionado
- [Diseñado para ser irresoluble: la receta](https://eternity2.dev/es/research/why/design-recipe/) — Eternity II sigue una receta para lograr el puzzle de emparejamiento de aristas más difícil posible: forma compacta, sin piezas simétricas ni duplicadas, paletas separadas, frecuencias planas, una sola solución esperada. La comunidad aplicó ingeniería inversa a cada ingrediente en el año del lanzamiento.
- [Patrones prohibidos](https://eternity2.dev/es/research/why/forbidden-patterns/) — Casi todo pequeño conjunto de piezas que podrías construir es imposible. Para un cuadrado 2×2, el 99,72 % de las formas de colocar cuatro piezas nunca podrá encajar.
- [El equilibrio del borde](https://eternity2.dev/es/research/why/border-balance/) — Un tablero resuelto esconde una sencilla ley contable: cada color que el borde entrega al interior, el interior se lo devuelve al instante. Rómpela y sabrás de inmediato que el tablero es incorrecto; respetarla, en cambio, no garantiza nada.
- [CLOISTER](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/cloister/) — Fijar un borde perfecto y luego explorar el interior tratando las aristas del borde como restricciones duras desde la primera celda.
---
# El muro de rigidez
> Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/rigidity-wall/
- Actualizado: 2026-07-22
- Temas: structure, local-search, exact-methods
- Fuente: Teorema de rigidez local (artículo del proyecto, 2026-05-16): ≥13 pruebas MIP de optimalidad de halo en 3 a 4 cuencas, hasta el halo-4 — https://github.com/raphael-anjou/eternity2/tree/main/research
- Fuente: Land & Doig 1960, ramificación y acotación, el método exacto detrás de cada resolución de región — https://doi.org/10.2307/1910129
- Fuente: benj39100: el recocido en GPU aplicado al tablero estricto de 5 pistas topa con el mismo núcleo congelado; la mejor puntuación crece con la distancia al titular (mensaje groups.io 11902) — https://groups.io/g/eternity2/message/11902
- Fuente: Pruebas independientes de residuo SAT sobre halo y de congelación de réplicas de William Millilaw, reproducidas aquí sobre cinco tableros públicos (cada resolución terminada UNSAT, hasta un halo de radio 4 en el sentido de Chebyshev) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/rigidity-sat-halo
- Fuente: kissat, el solucionador SAT detrás de las pruebas UNSAT de anillos de borde e interior completo — https://github.com/arminbiere/kissat
- Fuente: Google OR-Tools CP-SAT, el solucionador certificador detrás de los movimientos de racimo y las re-resoluciones de ventanas — https://developers.google.com/optimization
- Fuente: Diaconis & Sturmfels 1998, bases de Markov: el marco de álgebra de movimientos detrás de la teoría del radio de conectividad — https://doi.org/10.1214/aos/1030563990
- Fuente: Graver 1975, conectividad de fibras acotadas: el mismo círculo de ideas — https://doi.org/10.1007/BF01584976
- Fuente: Wolff 1989, la clase de movimientos de racimo correlacionados de la física estadística que inspiró el censo de permutaciones — https://doi.org/10.1103/PhysRevLett.62.361
---
Esta es la intuición con la que casi todo el mundo empieza: acercarse y luego
arreglar las últimas discordancias. Intercambiar un par de piezas, rotar unas
cuantas, y seguro que la puntuación sube poco a poco hasta 480.
Pues no. En cada tablero de cabeza que hemos probado, las últimas discordancias
están bloqueadas. Mueve cualquier cosa en el entorno y la puntuación se mantiene
igual o baja. Los buenos tableros no son casi-soluciones a la espera de un
pulido; son puntos aislados sin ningún sitio mejor al que ir al lado.
## Observa cómo crece la región
> **[Interactive: RigidityHalo]** Rendered on the canonical page (link above); not shown in this markdown export.
## Inténtalo tú mismo
Un tablero pequeño de verdad, perfecto. Intercambia cualquier par de piezas, o
deja que el motor pruebe todos los intercambios. Nada lo supera; eso es la
rigidez, en directo.
> **[Figure]** Interactivo: intercambia piezas y observa cómo la puntuación se niega a subir — interactive: RigidityLab. Rendered on the canonical page (link above); not shown in this markdown export.
## Empieza por los movimientos más pequeños
Antes de convocar a ningún solucionador, las comprobaciones más baratas se
hacen por fuerza bruta: probar cada pequeño movimiento que existe, y contar.
Aquí va una versión de bolsillo que cabe en la cabeza. El tablero 469 de la
comunidad y un tablero 466 conocido difieren en exactamente cuatro celdas:
las mismas cuatro piezas, cicladas una posición a lo largo de una franja de
la fila inferior. Enumera las 6.144 disposiciones de esas cuatro piezas en
esas cuatro celdas (24 permutaciones por 256 combinaciones de rotaciones): el
máximo es 469, alcanzado únicamente por la disposición del propio titular. El
tablero 466 es una de las 6.143 disposiciones peores. Dos buenos tableros
pueden estar a cuatro celdas de distancia sin ningún camino entre ellos, ni
por encima de ellos, a través de esas celdas.
Sube la escala. En uno de nuestros tableros de 459 (convención estricta de
cinco pistas; nuestras cifras quedan por debajo de las mejores de la
comunidad, mira [la página de récords](/es/research/records/) para el contexto),
se probó cada rotación no trivial de cada pieza: 768 rotaciones, cero
mejoras; cada rotación real baja estrictamente la puntuación. Los 32.640
intercambios de pares de piezas: cero mejoras. Las combinaciones de
intercambio más rotación: 47.164 de ellas, extraídas de una muestra de 5.000
pares sobre los 522.240 posibles, cero de nuevo; esa es una muestra grande,
no una enumeración completa. Hay además una razón analítica por la que una
rotación no puede ni siquiera ser neutra: una rotación de 180 grados deja el
recuento local de coincidencias sin cambios en todos los vecindarios posibles
solo si los colores superior e inferior de la pieza coinciden, y también sus
colores izquierdo y derecho, y cero de las 256 piezas tienen esa simetría
(ninguna es tampoco totalmente simétrica por rotación). Ninguna rotación sale
gratis jamás. La misma sonda barata, pasada por once de nuestros tableros
altos, puntuaciones de 454 a 459, da 8.448 pruebas de rotación simple y ni
una sola mejora.
En un tablero de 457 (convención de aristas concordantes), la enumeración se
llevó a todo movimiento que toque hasta cinco piezas: 1.024 giros de rotación
simple, 6.720 rotaciones de pares adyacentes, 20.240 transposiciones no
adyacentes, 32.796 3-ciclos sobre las 38 celdas adyacentes a discordancias,
982.200 4-ciclos y 28.480.440 5-ciclos. Unos 29,5 millones de movimientos,
cero mejoras, más dos barridos de ramificación y acotación (una búsqueda de
permutaciones sobre 38 celdas y un halo de radio 1 sobre 82 celdas) que
tampoco encontraron nada. Ese mismo tablero de 457 fue alcanzado 11 veces de
forma independiente por una búsqueda de reinicios calientes, idéntico byte a
byte cada vez: la búsqueda no orbita cerca de un buen tablero, colapsa sobre
un punto exacto y se queda ahí.
Hasta los movimientos diseñados para parecer gratis fracasan. Algunos pares
de piezas comparten tres de sus cuatro colores de arista, así que
intercambiarlas parece casi neutro. En el 469 de la comunidad se probaron los
114 intercambios simples de ese tipo: exactamente uno mantiene la puntuación
en 469 (y produce el único tablero gemelo conocido), 2 dan 468 y 111 dan
467. Los 6.441 intercambios dobles: ninguno alcanza 470, el mejor da 468. En
6.555 perturbaciones construidas precisamente para ser casi neutras en
puntuación, el conjunto de nivel 469 contiene exactamente dos tableros.
Los números se explican solos. A una puntuación de 459, una celda aporta de
media unas 3,6 aristas concordantes, mientras que una pieza aleatoria soltada
en un vecindario fijo espera solo unas 0,18 (aproximadamente cuatro aristas
por una probabilidad de uno entre 22 colores); un intercambio aleatorio
espera por tanto perder unas 6,8 aristas. Una cota probabilística holgada
limita la probabilidad de un intercambio de mejora a alrededor del 5 por
ciento; la frecuencia medida está por debajo de $3\times10^{-5}$. Cada
colocación de un tablero de cabeza está coadaptada a sus vecinas mucho más
allá de lo que el azar por sí solo predeciría. Una nota de alcance: cada
censo aquí es exhaustivo dentro de su clase de movimientos pero corre sobre
un solo tablero (los censos de rotaciones e intercambios sobre un 459, la
enumeración de cinco piezas sobre un 457, el censo de casi gemelas sobre el
469); son las pruebas exactas de abajo las que los generalizan.
## Cómo se sabe esto
El resultado no se apoya en probar muchos intercambios y darse por vencido.
Proviene de una pregunta exacta planteada a un solucionador de programación
entera: tomar una región del tablero, liberar cada pieza que hay dentro y
encontrar la única mejor manera de rellenarla de nuevo. El solucionador explora
todo ese espacio local de forma exacta, no por muestreo.
La respuesta vuelve siempre igual: la mejor disposición es la que ya está ahí.
Lo demostramos región tras región, tablero tras tablero, y hasta un radio de
cuatro celdas; la región más grande cerrada con certificado tiene 79 celdas,
casi un tercio del tablero. Cada vez, no existe mejora alguna.
Una cautela aprendida por el camino: una re-resolución exacta en frío de una
región grande puede rendir de menos sin avisar. Al pedirle reconstruir desde
cero las tres últimas filas de un tablero fuerte (48 celdas), el solucionador
ni siquiera redescubrió la propia cola del tablero en el tiempo dado,
llegando a 68 aristas concordantes frente a las 72 del titular tras 201 s
(una sola ejecución). En ventanas grandes, "no se encontró nada mejor" puede
ser mera dificultad del solucionador, no una prueba. Un veredicto de rigidez
solo se acepta aquí cuando el solucionador parte del titular, de modo que
cualquier cosa mejor es estrictamente más fácil de encontrar, y aun así
certifica una brecha cero.
## Método: la prueba MIP
La pregunta exacta, enunciada con precisión. Alrededor de cada celda defectuosa
tomamos la región *halo-$r$*: toda celda a menos de $r$ pasos. Liberamos todas
las piezas que contiene, mantenemos el resto del tablero fijo como frontera y
resolvemos un programa entero para el mejor relleno legal. Variables binarias
$x_{c,p,\theta} \in \{0,1\}$ colocan la pieza $p$ con rotación $\theta$ en la
celda $c$; restricciones de una-pieza-por-celda y una-celda-por-pieza lo
convierten en un problema de asignación; el objetivo maximiza las aristas
concordantes, contando la frontera fija. Una región de 64 celdas representa unas
18.700 variables binarias. La ramificación y acotación encuentra entonces o bien
un relleno estrictamente mejor, o bien prueba, con una cota dual, que no existe
ninguno. La definición que conviene retener: un tablero es *localmente rígido
en radio $r$* si, para cada componente conexa de sus celdas adyacentes a
discordancias, liberar todas las celdas a distancia como mucho $r$ de ella y
resolver de forma exacta no aporta mejora alguna.
Nunca encuentra ninguno. Las pruebas, región por región. Estas ejecuciones MIP
provienen del cuaderno de investigación del proyecto (el artículo del 2026-05-16
citado en las fuentes); la tabla de abajo aún no se reejecuta bajo la cadena de
resultados validados de este sitio, de modo que sus tiempos de solucionador y sus
cotas duales no son verificables de forma independiente desde este repositorio,
a diferencia del resultado SAT sobre halo más abajo. La misma nota de
procedencia cubre cada censo, enumeración y escalada SAT añadidos a esta
página; la reproducción SAT de radio 4 es el único resultado consignado en
este repositorio:
| Región | Tablero | Celdas | Tiempo del solucionador | Resultado |
|---|---|---:|---:|---|
| halo-2, por componente (×8) | 3 cuencas (469, 459, 458) | 2–34 | segundos cada una | todos Δ = +0, **probado** |
| halo-1 conjunto | McGavin 469 | 37 | 895 s | Δ = +0, **probado** |
| halo-1 conjunto | Local 459 | 59 | 1800 s | Δ = +0, **probado** |
| halo-1 conjunto | tres 458 distintos | 57, 62, 64 | 180 s cada uno | Δ = +0, **probado** |
| halo-1 por componente | un segundo 459, disjunto | 52 + 4 | ~60 s | Δ = +0, **probado** |
| 3 filas superiores (una banda, no un halo) | McGavin 469 | 48 | 70 s | Δ = +0, **probado** |
| halo-3, por componente | McGavin 469 | 42 + 47 | 929 s | Δ = +0, **probado** |
| halo-3, racimo más denso | un 458 | 79 + 19 | 1200 s + 0,2 s | Δ = +0, **probado** |
| halo-4, componente 0 | McGavin 469 | 57 | 1200 s | Δ = +0, **probado** |
En al menos seis tableros distintos y más de veinte regiones la respuesta es
invariante: el tablero titular es localmente MIP-óptimo, hasta el halo-4 para
el 469 de McGavin. Dos filas merecen comentario. La fila de las tres filas
superiores es una banda geométrica completa, no un halo: libera celdas
limpias junto a las rotas, así que descarta además los movimientos que
intercambiarían piezas entre celdas rotas y limpias dentro de la banda. Y la
región de 79 celdas, la más grande jamás cerrada aquí, está en un 458 y no en
el 469 porque la resolubilidad seguía la *densidad de defectos*, no el tamaño
bruto de la región: las regiones densas en defectos se cierran, las mayores
pero dispersas agotan el tiempo.
La única región que queda con una brecha, las cuatro filas superiores, 64
celdas, sigue dando un resultado *sólido*: una cota dual de 123 frente a los
116 del titular, de modo que ni siquiera el caso no cerrado puede superar el muro
por mucho (implica una cota a escala de tablero de ≤ 476).
No todas las resoluciones terminaron, y el registro conserva también esas. La
resolución conjunta halo-2 de 54 celdas sobre el 469 se quedó atascada en su
relajación raíz durante 55 minutos y fue detenida; la banda de las 5 filas
superiores (80 celdas) agotó el tiempo; en los tres 458, las dos componentes
grandes de halo-2 toparon con un límite de 120 s reportando +0 *sin*
certificado, lo que cuenta como "no se encontró mejora", no como probado. Una
fila inacabada más amplía la evidencia a otra convención de puntuación: a un
tablero de 460 jugado *sin* la restricción de pistas se le dio una resolución
conjunta halo-1 (42 celdas libres, libertad total de piezas) y una ejecución
de 900 segundos no encontró mejora pero dejó abierta una brecha dual del 9,5
por ciento; esa fila también es "nada encontrado dentro del presupuesto", no
"probado óptimo". Un solo tablero, una sola ejecución.
Tampoco es un tablero desafortunado aislado. Un segundo tablero de 459,
hallado por un camino de construcción completamente distinto, coincide con el
primero en solo 3 de 256 celdas, esencialmente las celdas de las pistas; los
dos tableros son estructuralmente disjuntos, y el segundo está *también*
probado rígido en halo-1 (dos componentes, 52 y 4 celdas, +0 probado en
alrededor de un minuto). En halo-2 su componente pequeña (7 celdas) se probó
+0 en 18 s; su componente grande (67 celdas) quedó sin decidir tras unos 13
minutos y sigue abierta. La conjetura que esto respalda, enunciada como tal:
el conjunto de nivel 459 es una unión disjunta de muchos puntos rígidos, y
superarlo exige una reorganización a escala de tablero o un punto de partida
distinto, nunca un arreglo local.
La insignia dice *probado* en lugar de *conjeturado* para las regiones
efectivamente cerradas; el enunciado general sobre *todos* los tableros sigue
siendo una conjetura, respaldada por cada región probada hasta la fecha.
## Tampoco existe ningún intercambio ingenioso
El MIP libera una región y la rellena desde el conjunto completo de piezas.
Hay una clase de movimientos complementaria que no cubre: elegir $k$ celdas y
probar todas las formas de permutar y re-rotar las piezas *que ya están
ahí*, con el resto del tablero congelado. Un álgebra de movimientos
distinta, y la misma respuesta.
En un tablero nuestro de 452 (convención estricta de cinco pistas, 2026-07):
$k=1$, exhaustivo sobre las 251 celdas libres, cero movimientos de mejora.
$k=2$, exhaustivo sobre los 31.375 pares fuera de pistas, cero. $k=3$ a $6$,
unos 29.000 racimos muestreados (junto a defectos, por todo el tablero,
conexos y no conexos), cero; ese nivel es una muestra grande, no una
enumeración. Para $k=7$ y $8$ el muestreo se ascendió a enumeración
verdadera: cada subconjunto conexo de 7 y 8 celdas de las celdas que tocan un
defecto, en dos tableros independientes, 849 subconjuntos en total (231 en el
452, 618 en un 451 estructuralmente ajeno que difiere de él en 249 de las 256
celdas), todos resueltos hasta el final, cero de mejora, cero tiempos
agotados; más los 7.845 subconjuntos conexos de 7 celdas a un paso de una
arista defectuosa, cero otra vez. Unos 60.000 movimientos de racimo
evaluados, y el mejor delta encontrado en cualquier parte es exactamente
cero.
Ese cero no es un detector roto. Como control positivo, un sabotaje
deliberado de dos piezas (452 rebajado a 447) fue reparado por la misma
maquinaria en un solo movimiento de 4 celdas, directo de vuelta a 452. Y la
búsqueda local voraz sobre esta clase de movimientos, lanzada desde tres
tableros de orígenes independientes (el 452, un gemelo de igual puntuación
que difiere en exactamente 2 celdas, y el 451 ajeno), tocó un punto fijo
inmediato en las 20 ejecuciones sembradas: mínimo, mediana y máximo
idénticos, cero escapes.
El detalle que escuece: el propio 452 *nació* de esta clase de movimientos.
Una co-rotación de dos piezas elevó un 451 que era rígido bajo todo
movimiento de pieza única. Existió un genuino movimiento correlacionado de
dos cuerpos; una vez tomado, no queda ningún movimiento correlacionado de
tamaño hasta 8 cerca de los defectos. El radio de rigidez crece a medida que
el tablero mejora.
Cambiar la geometría del conjunto liberado tampoco ayuda. Libera franjas de
filas contiguas en vez de manchas: 54 de 54 franjas de una fila a través de
las bandas de defectos de los dos tableros (anchos de 8 a 14, hasta 15 celdas
liberadas) certifican exactamente la puntuación del propio tablero en menos
de un segundo cada una, y 18 de 18 franjas de dos filas fuera de la peor
banda certifican la rigidez hasta 26 celdas. En la banda de defectos más
densa de cada tablero, las franjas más anchas (16 a 26 celdas) se vuelven
difíciles de *certificar*: tras escalar a 300 s y 3 semillas, 6 de 10 siguen
abiertas con brechas de cota de 2 a 6 aristas. Pero en las 30 ejecuciones de
escalada el solucionador nunca encontró disposición alguna mejor que la del
propio tablero. Eso es una brecha de certificación, no evidencia de una
mejora, y las franjas abiertas se registran como abiertas, no como probadas.
Las ventanas rectangulares cuentan la misma historia. En el 452, cuyas 28
aristas rotas se reparten en 22 concentradas en la banda inferior y 6
dispersas, cada ventana de hasta 18 celdas alrededor de cada racimo de
defectos (cuatro ventanas, de 9 a 18 celdas) se re-resuelve a un óptimo
certificado exactamente en el valor del propio tablero. Cada defecto está
forzado por piezas comprometidas *en otra parte*; ninguna ventana que
simplemente contenga el defecto puede arreglarlo.
Ni siquiera dejar que las piezas comercien a través de la frontera
bueno/malo mueve nada. En un tablero nuestro de 459 (estricto de cinco
pistas), las dos filas inferiores (32 celdas) certifican la optimalidad en
49 s. Una ventana de 46 celdas, y ventanas de 52 y 72 celdas que además
liberan de 6 a 10 celdas donantes *dentro de la región perfecta*, para que las
piezas puedan intercambiarse entre las partes limpias y las rotas, devuelven
todas el tablero idéntico: cero celdas movidas, ni siquiera un reacomodo lateral de
igual puntuación (150 a 180 s cada una, semilla única, así que estas ventanas
mayores cuentan como "ninguna mejora y ningún movimiento encontrados", no
como certificados). El mismo operador aplicado a un tablero más débil de 455
lo eleva en 2 hasta 457: demostrablemente mejora tableros que aún no están en
su punto fijo; el 459 ya lo está. Dentro de cada ventana, la relajación
lineal cree que hay unas 17 coincidencias más disponibles; la restricción de
cada-pieza-una-sola-vez las prohíbe todas. La restricción que muerde es qué
piezas deja libres el resto del tablero, nunca el tamaño de la ventana. La
dificultad es la distinción global, no la concordancia local.
## Rígido fila entera a fila entera
Halos y ventanas son manchas. Prueba una geometría que cruce el tablero:
libera una fila entera de 16 celdas, restríngela a piezas no usadas en otra
parte del tablero y enumera los rellenos alternativos por programación
dinámica. En un tablero de 460 (discordancias todas en las filas 11 a 14) y
en el 469 de la comunidad (discordancias en las filas 0 a 4), el relleno
actual de cada fila es el mejor disponible, y varias filas no admiten
*ninguna alternativa legal en absoluto*: la cadena colocada es la única
manera de enhebrar esa fila a través del resto del tablero.
Los números. En el 460: las filas 1 a 10 son perfectas y admiten exactamente
una cadena cada una, la colocada; las filas 12 y 14 tienen cero cadenas
alternativas; la fila 13 tiene 176 alternativas, todas peores, la mejor de
ellas 10 aristas por debajo. En el 469: la fila 3 tiene cero alternativas;
las filas 2 y 4 tienen sus mejores alternativas 20 aristas por debajo; las
filas 5 a 14 son perfectas, con la original entre hasta unas 17.857 cadenas
legales y ninguna mejor. Liberando dos filas conjuntamente (32 celdas,
costura interna sin restricción): los pares (11,12), (12,13) y (13,14) del
460 dan de 0 a 4 cadenas alternativas en total, todas peores (12 a 16
aristas por debajo) o infactibles. Tres filas conjuntas (48 celdas): las
filas (11,12,13) y (12,13,14) dan cero cadenas alternativas. Estas filas no
son solo óptimas; a menudo están *forzadas*. Unicidad, no mera optimalidad.
Alcance: la enumeración es programación dinámica de haz (ancho de haz de
100.000 para una fila, de 5.000 a 50.000 para dos y tres filas), exhaustiva
en la práctica pero no certificada como las filas MIP; llamémosla
haz-exhaustiva. Dos tableros.
Un acompañante exacto sobre bandas: vacía por completo las 2 filas
inferiores (32 celdas) de un tablero de 460 y deja que una búsqueda exacta
por restricciones enumere cada relleno legal con las piezas liberadas.
Existen exactamente 32 rellenos alternativos, todos con 460 o menos. Vacía
las 4 filas inferiores (64 celdas): la única compleción que la búsqueda
exacta alcanza es el propio tablero original. Un solo tablero, solo estos dos
tamaños de banda; pero en cada banda que pudo cerrarse de forma exacta, la
puntuación actual es el techo verdadero.
## Dónde viven las últimas discordancias, y por qué están atascadas
En un tablero nuestro de 458, la anatomía del fallo está notablemente
concentrada. El anillo del borde es perfecto (60 de 60), las nueve filas
interiores superiores son perfectas, y las 22 discordancias (4
borde-interior, 18 interior-interior) viven todas en las cinco filas
inferiores, agrupadas en 10 minúsculos racimos disjuntos de 2,8 celdas de
media, el mayor de solo 5. Cada racimo parece trivialmente arreglable. Las
resoluciones exactas dicen lo contrario: rellenos por racimo, delta cero;
ampliaciones halo-1 y halo-2 hasta 16 celdas, delta cero; y la unión de las
28 celdas que tocan un defecto, resuelta conjuntamente a optimalidad probada
en 1,74 s, delta cero.
Este es el mecanismo de todo el muro en miniatura: la región de defectos
está en su óptimo exacto *dadas las piezas que le dejaron*. La parte superior
perfecta del tablero ha consumido un conjunto de piezas concreto, y ese
compromiso es lo que limita la parte inferior. Arreglar las últimas
discordancias exigiría descomprometer piezas de la región ya perfecta, un
gran movimiento entre regiones, no una reparación local. (Una relajación
lineal lee un techo de 478 para este borde; es un techo de relajación para
este borde en particular, no una afirmación sobre el óptimo verdadero.) Un
solo tablero, pero el patrón, defectos apretados en unos pocos racimos
minúsculos que los rellenos exactos no pueden arreglar, es exactamente lo que
la tabla de halos de arriba sigue encontrando en las demás cuencas.
## Por qué nadie puede certificar el muro desde arriba
Dos hechos coexisten en el tablero de 452 (estricto de cinco pistas), y su
tensión es el estado del arte actual. Hecho A: ningún movimiento local de
ningún tipo probado lo supera, y cuatro marcos independientes concuerdan
(movimientos de racimo, re-resoluciones de ventanas, un certificado exacto de
brecha cero de que el lote de piezas sobre sus celdas que tocan defectos está
colocado de forma óptima, y una sonda termodinámica que o bien se congela en
el titular o bien se funde hacia lo aleatorio, sin escape suave entre
medias). Hecho B: todo intento de acotar una región *grande* desde arriba
fracasa; las cotas son holgadas y no convergen. En la cola de tres filas del
tablero, 8 semillas de 20 minutos cada una devolvieron todas exactamente el
titular, ninguna encontró nunca nada mejor, mientras la cota superior del
solucionador *subía* de 79 (a 300 s) a 89 (a 1200 s), alejándose de los 72
del titular en vez de acercarse. Una cota de programación lineal sobre el
interior lee 478,5 de 480: vacía.
Dentro hay un cuento con moraleja. Una primera lectura de la ejecución de
300 s fue "una brecha de 7, margen hacia una puntuación mayor". La cacería de
8 semillas mostró que la brecha era un artefacto de una relajación no
convergente, no evidencia de un tablero mejor alcanzable. La razón por la que
las cotas siguen holgadas: la escasez que hace difícil este puzle es de
segundo orden, cuestión de qué *pares* de colores son conjuntamente escasos,
y las relajaciones de concordancia de primer orden, sobre las que se
construyen las cotas LP y de propagación, no pueden verla, por mucho tiempo
que corran.
Así que la rigidez local (probada) y la brecha global abierta no están en
tensión. El titular es un óptimo local profundo, *y* puede existir una
disposición mejor desconectada que ningún movimiento local alcanza; hoy
ninguna cota la descarta y ninguna búsqueda la encuentra. Cerrar cualquiera
de las dos direcciones de una sola brecha de región grande sería una
primicia: un relleno mejor sería un nuevo mejor tablero, y una cota empujada
hasta el titular sería el primer techo de puntuación local probado. La cota
dual de las cuatro filas superiores de arriba (123 frente a 116) es lo más
parecido a un progreso desde arriba, y sigue holgada por 7 aristas. Alcance:
el hecho A está probado en un tablero mediante varias lentes; el hecho B
lleva una dispersión de 8 semillas en su ejecución decisiva.
## Ni siquiera se pueden recombinar los buenos tableros
La rigidez sobrevive incluso cuando el conjunto de movimientos es "tomar
prestado de cada buen tablero jamás encontrado". Construye una optimización
en la que cada celda pueda tomar la pieza y rotación que *cualquiera* de 25 a
30 tableros distintos de alta puntuación coloca ahí, con
cada-pieza-una-sola-vez impuesto, y libera el tablero entero, las 256
celdas. El óptimo es exactamente el mejor tablero ya presente en el corpus,
nunca una mezcla que lo supere: 457 con las cinco pistas fijadas (convención
estricta; corpus de 25 tableros, resuelto en 24 s), y 459 sin imponer las
pistas (convención de aristas concordantes). Las versiones por región con
radios crecientes, 77, 127, 191 y 252 celdas libres, dan todas delta cero en
segundos hasta unos 30 s. Estos óptimos son certificados, por corpus; el
corpus es de 2026-05, cuando nuestros mejores eran 457 estricto y 459 en
aristas concordantes, ambos por debajo de las cifras de la comunidad entonces
y ahora ([página de récords](/es/research/records/)).
El corpus no anda escaso de opciones. Cada una de las 256 celdas tiene al
menos 2 opciones distintas entre los tableros, y una pieza típica aparece en
de 6 a 19 posiciones distintas por el corpus. La diversidad es rica; la
unicidad de las piezas la fragmenta. Los tableros de familias de esquinas
distintas no pueden mezclarse en absoluto, y añadir el 469 de la comunidad al
corpus hace que el optimizador simplemente elija ese tablero en bloque, a
469, en vez de mezclarlo con nada.
La lectura: la brecha por encima de los mejores tableros conocidos es una
brecha de *descubrimiento*, no de recombinación. La mejora no se esconde en
ninguna combinación de lo ya conocido; exige tableros fuera de todo el corpus
conocido.
## Por qué importa
Esto replantea toda la brecha hasta 480. La distancia entre el mejor tablero
conocido y una solución no es un montón de pequeñas correcciones a la espera de
ser encontradas. Si lo fuera, este tipo de búsqueda local las habría encontrado.
El obstáculo es que los buenos tableros se asientan en el fondo de sus propios
pequeños valles, y las paredes de esos valles son exactas, no aproximadas.
También indica lo que no va a funcionar. El pulido, la ascensión de colina y la
mayoría de las heurísticas de reparación local intentan subir la pendiente desde
un punto congelado. No hay pendiente que subir. Alcanzar una solución exige un
movimiento que reorganice una región grande de una sola vez, o un punto de
partida enteramente distinto, no un mejor pulido. Las pruebas conjuntas de
halo-1 lo hacen cuantitativo: cualquier operador de destrucción y reparación
cuyo alcance sea como mucho el halo, ventanas de hasta unas 30 celdas
alrededor de los defectos, está matemáticamente agotado en estos tableros. La
congelación no es "nuestra heurística es débil"; esa clase entera de
operadores está terminada.
Ni siquiera el mayor movimiento único que sabemos hacer escapa. En nuestro
tablero de 461 (estricto de cinco pistas; para situar esa cifra frente a los
récords de la comunidad, mira [la página de récords](/es/research/records/)), los
movimientos de ciclos enteros indescomponibles descritos en la [página de los
sigma-ciclos](/es/research/why/sigma-cycles/) se aplicaron *atómicamente*, cada
uno seguido de una re-resolución de ventana local para reparar las celdas
alteradas. Unos 4.000 movimientos de ese tipo: cero escapes, y la salida no
local más barata sigue perdiendo al menos un punto (mejor resultado 460, dos
celdas de diferencia). Esto solo descarta la variante de limpieza local; una
re-resolución compensatoria global no se probó. Pero un movimiento grande no
basta si su limpieza es local.
Una cosa más que la rigidez *no* significa: difícil de reconstruir. Fija las
primeras catorce filas del 469 de la comunidad y deja que una búsqueda de
reparación reconstruya el resto: 3 de 4 semillas vuelven a 469 (la cuarta se
queda en 454). Haz lo mismo con los prefijos de nuestros propios tableros
récord: ninguna semilla supera jamás 460. Una sonda pequeña (4 semillas,
reparaciones de 30 segundos por tablero), pero la forma es clara. El muro no
mide lo difícil que es reconstruir un tablero; dice *a qué valle pertenece el
esqueleto del tablero*. Un prefijo o admite una gran compleción o no la
admite, y ninguna suerte de semillas cambia cuál.
### El final de la partida se decide pronto
Fija las $N$ filas superiores del tablero 469 de la comunidad y deja que la
búsqueda local complete el resto. La puntuación de compleción no es gradual
en $N$; es un acantilado con señuelos: $N=1$ da 400, $N=2$ da 382, $N=4$ da
401, $N=8$ da 418, $N=12$ da 450, $N=13$ da 455, y $N=14$ da 469, una
reconstrucción *exacta*, cero celdas de diferencia, con $N=15$ igual. Con 13
filas fijadas existe una compleción alternativa de las tres últimas filas,
con las mismas piezas de otra manera, que puntúa solo 455 y es en sí misma
una trampa: la concordancia local de colores admite varias compleciones y la
búsqueda no puede saber cuál se extiende. Acertar el 87 por ciento de un
récord no es "estar casi ahí". Son ejecuciones de compleción únicas por
punto, con presupuestos del orden de minutos, sin dispersión de semillas; lee
el umbral, no las puntuaciones individuales.
Dos notas completan el cuadro. El barrido prueba que la maquinaria de
compleción es capaz de *alcanzar* 469; el muro está en encontrar las
primeras aproximadamente 224 piezas de la estructura, no en debilidad alguna
del paso de pulido. Y la influencia no fluye en sentido contrario: una fila
superior sola, una entre al menos $5\times10^{8}$ filas superiores legales,
no determina casi nada. Cuatro preajustes de operadores de nuestra familia de
búsqueda local, crecidos desde una fila superior fijada, se atascan todos
entre 378 y 400; otras familias de búsqueda quedan sin probar, así que ese
negativo está acotado a nuestro buscador. Entretanto, 363 de nuestros
tableros de 455 o más usaron solo 47 filas superiores distintas: los buenos
tableros se agrupan por arriba mucho antes de que la parte de abajo quede
decidida.
## Alguien topó con el mismo muro desde el lado del recocido
La prueba MIP aborda el muro de forma analítica. En junio de 2026, otro
investigador se estrelló contra él de manera empírica. Trabajando el tablero
estricto de cinco pistas con un solucionador de recocido simulado en GPU (4096
réplicas en paralelo), benj39100 reportó dos cosas que se leen como una
reformulación de esta página. Primero, la mejor puntuación que una ejecución
podía alcanzar *aumentaba con la distancia al mejor tablero actual*: para subir
de 429 hacia 432, las perturbaciones ganadoras tenían que migrar cada vez más
lejos, porque cerca del titular no había ningún movimiento de mejora que
encontrar. Segundo, a lo largo de todos sus mejores tableros, las mismas unas
cuarenta y dos aristas rotas formaban un «núcleo duro» congelado que la búsqueda
local nunca tocaba, de modo que tuvieron que añadir un término explícito que
*recompensaba* forzar la apertura de ese núcleo. Un titular localmente congelado
sin gradiente cercano, y un pequeño conjunto bloqueado de defectos que nada local
va a mover: ese es el muro de rigidez, visto desde un método completamente
distinto.
## Y de nuevo, desde un solucionador SAT
Un tercer investigador llegó a la misma conclusión con una tercera herramienta.
William Millilaw, trabajando el techo de forma independiente, realizó dos
pruebas. La primera fue una prueba de congelación: perturbar la raíz de un
tablero de cabeza, reoptimizar y ver qué celdas vuelven. En sus mejores tableros,
del 93 al 100 por ciento de las celdas regresaban exactamente a su sitio, un
núcleo congelado que la búsqueda no podía mover. La segunda fue una pregunta de
decisión para un solucionador SAT. Liberar las celdas alrededor de las
discordancias, exigir que cada arista liberada concuerde y preguntar si alguna
disposición de esas piezas la satisface. Su solucionador respondió UNSAT.
Nosotros [reprodujimos esa prueba SAT](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/rigidity-sat-halo)
sobre cinco tableros públicos, con nuestro propio codificador y un control
positivo para asegurarnos de que una región concordante vuelve satisfacible. En
los cuatro tableros récord de la comunidad, desde el 467 de Verhaard hasta el 470
de Blackwood, y el 464 de Riotte (el récord estricto de cinco pistas), cada
resolución que termina es UNSAT hasta un halo de radio 4 en el sentido de
Chebyshev (esta reproducción mide la región liberada por radio de Chebyshev,
mientras que las escaleras SAT del cuaderno más abajo cuentan pasos de
Manhattan, así que las dos escalas de halo no son la misma métrica): ningún
reordenamiento local de las propias piezas de un tablero récord cierra una sola
discordancia, incluso cuando la región liberada supera el centenar de celdas. Las
instancias de radio 4 son lo bastante grandes como para que algunas no terminen
dentro del límite de tiempo del solucionador; esas se registran como tiempos
agotados y se dejan abiertas, no se cuentan como probadas, de modo que la tabla
validada enuncia exactamente lo que se decidió. La programación entera optimiza y
acota; el recocido choca con el muro a mano; SAT decide y devuelve una
refutación. Tres métodos, una sola respuesta.
Una cuarta herramienta está de acuerdo. Un optimizador MaxSAT, una variante
de SAT que devuelve a la vez el mejor relleno y una prueba de su optimalidad,
se apuntó a subregiones de un tablero nuestro anterior de 454: fijar todo lo
que queda fuera de una región, liberar la región, pedir el mejor relleno
demostrable. Cada ventana $k\times k$ hasta 5×5 se probó óptima dentro de su
presupuesto de 60 s (las ventanas de 6×6 excedieron el presupuesto y quedan
registradas como no cerradas, no como probadas), y la zona de defectos entera
del tablero, 45 celdas que contienen sus 26 discordancias interiores, se
probó óptima en 83 s: esas 26 discordancias son lo mejor que esa región puede
hacer dado el resto del tablero. Ese 454 fue a su vez alcanzado byte a byte
desde 4 semillas aleatorias distintas, el mismo colapso sobre un único punto
que el 457 del censo de arriba: las ejecuciones independientes no solo llegan
a la misma puntuación, llegan exactamente al mismo tablero.
Empuja la pregunta SAT más lejos y la respuesta se vuelve más dramática.
Toma uno de nuestros tableros de 459 (cinco pistas impuestas), libera cada
celda a distancia como mucho 10 de sus discordancias, 218 de las 256 celdas
libres y solo 38 fijadas, y pregunta si *alguna* compleción alcanza un 480
completo. UNSAT, en 0,31 s. La escalera por el camino: los halos 0 a 5 todos
UNSAT en menos de 2 s cada uno; el halo 7, 173 libres y 83 fijadas, UNSAT en
0,17 s. Las 38 celdas aún fijadas en el halo 10 son esencialmente las dos
filas superiores más 3 de las 5 pistas. Así que las dos filas superiores de
este tablero son, por sí solas, demostrablemente incompatibles con cualquier
solución perfecta: todo 480 debe diferir de este tablero en algún punto de
esas 38 celdas. La rigidez la porta un fino esqueleto de la parte alta del
tablero, no los vecindarios de los defectos. En radio 15, con solo 4 celdas
fijadas, el solucionador agotó los 600 s; ese caso queda abierto. Un tablero
concreto; no se sabe si otros tableros de 459 comparten la misma rigidez de
la parte alta fijada.
Sus trabajos anteriores sobre la serpiente y la búsqueda local pusieron un número
al porqué. El mayor parche que cualquiera de sus operadores de reparación podía
reescribir en un movimiento era de unas 48 celdas, mientras que dos de los buenos
tableros conocidos, ambos cerca del techo, difieren en unas 225 celdas. Un
movimiento que solo puede tocar 48 celdas no puede cruzar una brecha de 225
celdas, así que ninguna secuencia de ellos alcanza una cuenca distinta. Buscó una
cadena de pequeños movimientos de mejora que abriera un túnel hacia la salida y no
encontró ninguna: cero mejoras a lo largo de veintiocho millones de combinaciones
de cuatro y cinco movimientos en la meseta. Es el mismo muro, enunciado como un
presupuesto. La reparación local reescribe demasiado poco a la vez para
abandonar el valle, y por eso escapar exige un movimiento que reorganice una
región grande de una sola vez, exactamente como concluye la sección de prueba de
arriba.
## El muro llega hasta el mismísimo 480
Todo lo anterior pregunta si un reordenamiento local puede cerrar una
discordancia. Hay una pregunta mucho mayor: conservando solo el anillo del
borde de un tablero, ¿alcanza *alguna* disposición de las 196 piezas
restantes un 480 perfecto? En nuestro tablero de 459 (convención de aristas
concordantes, pistas canónicas) la respuesta es una prueba de que no, a
todas las escalas. Liberar las 32 celdas en discordancia: UNSAT en 0,09 s
(14.000 variables, 81.000 cláusulas). Liberar todo lo que está a 5 pasos de
una discordancia, 140 celdas, más de la mitad del tablero: UNSAT en 1,56 s.
Liberar el *interior entero*, las 191 celdas interiores fuera de pistas,
conservando solo el anillo del borde de 60 piezas: UNSAT en 1,37 s (160.000
variables, 5,4 millones de cláusulas). Los peldaños intermedios, halo-1 con
70 celdas (0,33 s), halo-2 con 93 celdas (0,89 s), halo-3 con 109 celdas
(0,80 s), son todos UNSAT también. El solucionador es kissat, citado en las
fuentes.
Y no es la mala suerte de un solo tablero. Se probaron nueve configuraciones
distintas de anillo de borde, abarcando cuatro disposiciones de esquinas
diferentes: el borde del 469 de la comunidad, nuestros bordes récord de 459 y
458, un tablero de 435 derivado de propagación de creencias, y cinco bordes
parciales enumerados sistemáticamente. Cada una, sin excepción, es UNSAT para
480, en menos de 2 segundos cada vez. Lo más notable: el borde del 469 de la
comunidad, a 11 discordancias de la perfección, demostrablemente no puede
alojar ningún interior de 480: UNSAT en menos de 0,01 s. El codificador se
validó de ida y vuelta sobre pequeños puzles resolubles, donde resoluciones
frescas se decodifican en tableros perfectos verificados y fijar un borde
correcto devuelve SAT, la misma disciplina de control positivo que la
reproducción de arriba; los veredictos UNSAT son reales, no artefactos.
El borde abierto de este resultado es su mejor resumen. Solo existen nueve
configuraciones de borde en nuestro corpus, y un borde compatible con 480
existe con certeza: el puzle se construyó a partir de una solución.
Simplemente no es ninguno de los bordes que una búsqueda de clase récord haya
producido jamás. Pulir cerca de un récord no es solo lento; bajo el propio
borde de ese récord, llegar a 480 es demostrablemente imposible. Una solución
exige un borde distinto.
## Por qué existe el muro
La página hasta aquí prueba el muro; esto es lo más parecido que tenemos a
una razón. Modela el conjunto de tableros con puntuación fija como un grafo
cuyas aristas son movimientos que tocan como mucho $k$ celdas, y pregunta por
el menor $k$ que lo conecta: el radio de conectividad. En instancias pequeñas
de emparejamiento de aristas donde cada tablero puede enumerarse de forma
exacta, emergen dos leyes. Primera, el radio es pequeño en el grueso del
espectro de puntuaciones y salta al tablero entero exactamente en la
puntuación máxima: en una instancia de 6 celdas, $k$ vale de 2 a 4 celdas en
las puntuaciones interiores y 6, el tablero entero, en el máximo; en una
instancia de 9 celdas la razón $k/N$ ronda de 0,22 a 0,44 en el interior y
0,78 en la cima. Segunda, la rigidez se enciende con la riqueza de colores:
barriendo la paleta en las instancias de 9 celdas, el soporte medio del
movimiento mínimo sube de 1,4 a 7,6 celdas cuando los colores pasan de 2 a
8, y la fracción de instancias cuyas soluciones perfectas necesitan un
movimiento de tablero completo para interconectarse sube de 0 al 70 por
ciento.
A escala de juguete hay un teorema, probado con un argumento de forzado y
verificado por enumeración exhaustiva: si el diseño de colores es lo bastante
rico como para que cada color de arista expuesto admita como mucho una ficha
legal durante un relleno, entonces dos soluciones perfectas distintas no
comparten *ninguna celda*, así que cualquier movimiento entre ellas debe
tocar cada celda. A una riqueza de colores comparable a la del puzle real,
cada instancia probada resultó rígida exactamente en ese sentido: cero celdas
compartidas entre cada par de soluciones perfectas.
Para el propio Eternity II esto es una conjetura, y la etiquetamos como tal.
Con 22 colores interiores, cada uno reutilizado entre unas 24 y 50 veces a
lo largo de 480 adyacencias interiores, el puzle real se asienta bien adentro
del régimen rígido, de modo que tableros casi perfectos distintos deberían
ser casi ortogonales (lo que encaja con la diferencia de 225 celdas
observada arriba entre buenos tableros) y ningún movimiento de tamaño
acotado debería conectar óptimos distintos. La condición de "como mucho una
ficha" no es estrictamente cierta en E2, así que la afirmación defendible es
"una gran fracción del tablero", no "demostrablemente las 256 celdas".
El corolario es la parte satisfactoria: la búsqueda local se congela
*precisamente en las puntuaciones altas* porque ahí es donde el grafo de
movimientos se desconecta. El interior del rango de puntuaciones se recorre
con facilidad, por eso llegar a los 450 y 460 es rutina; la cima es un
conjunto de puntos aislados, por eso el pulido muere ahí. Una teoría, las
dos mitades de la historia de esta página. (Las matemáticas son el círculo
de ideas de las bases de Markov y de Graver de la estadística algebraica;
mira las fuentes. Los únicos movimientos de cima baratos que la teoría
permitiría son simetrías globales, y este juego de piezas no tiene
esencialmente ninguna.)
> **La siguiente pieza del cuadro**
>
> Si no puedes mejorar un tablero localmente, quizá puedas saltar de un buen tablero a otro. Eso también fracasa, por una razón afín: [ve por qué el salto entre cuencas es imposible](/es/research/why/sigma-cycles/).
*Las pruebas usan programación entera sobre regiones de cada tablero; corren
varios minutos por región en un solucionador, así que no se reproducen en directo
aquí. Los tableros en sí van incluidos y son verificables en el visor.*
## Relacionado
- [Récords y solucionadores](https://eternity2.dev/es/research/records/) — Eternity II nunca se ha resuelto, pero casi dos décadas de esfuerzo colectivo han llevado el mejor tablero a 470/480. Quién ostenta qué, cómo lo lograron y por qué algunos tableros «480» anunciados no corresponden al puzzle real.
- [Por qué el basin-hopping parece imposible](https://eternity2.dev/es/research/why/sigma-cycles/) — Si no puedes mejorar un tablero excelente puliéndolo, quizá puedas saltar a otro tablero excelente. En cada par de récords probado, no puedes, y vale la pena ver la razón estructural que lo explica.
- [Qué muro detiene a qué método](https://eternity2.dev/es/research/why/walls-and-methods/) — La sección de investigación tiene dos vertientes: los muros estructurales que hacen difícil a Eternity II, y los algoritmos concebidos para franquearlos. Esta página es el puente: cada método enfrentado al muro que realmente ataca, y la puntuación en la que ese muro lo detuvo.
- [Por qué un ordenador más rápido no ayuda](https://eternity2.dev/es/research/why/prune-vs-speed/) — La idea más importante de la búsqueda combinatoria difícil: reducir el espacio que se explora vence, por un margen exponencial, a explorarlo más rápido. Eternity II está diseñado para que apenas puedas reducirlo.
- [PALIMPSEST](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/palimpsest/) — Leer cada tablero fuerte para detectar los hábitos que, en silencio, limitan un tablero, y luego romperlos. Este experimento produjo el mejor tablero del proyecto: 463 de 480.
- [MIDDEN](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/pipelines/midden/) — Decidir de antemano no cuándo puede romperse un tablero, sino dónde: confinar cada desajuste a una forma de celdas elegida, y buscar la mejor forma.
- [Relajaciones LP y PLE: media pieza en todas partes](https://eternity2.dev/es/research/build/exact/lp-relaxations/) — Escribe Eternity II como un programa entero, abandona la integralidad, y un solucionador lineal alcanza error cero en segundos, con un 30 % de una pieza y un 20 % de otra compartiendo una esquina. Dieciocho años de campañas comunitarias midieron dónde termina la comodidad fraccionaria: una meseta de 420–440 aristas en cuanto las piezas deben ser enteras, un muro PLE ya en el 8×8, y un récord académico de 461 en una hora. Lo que enseña el camino del optimizador, y dónde el LP sigue ganándose su lugar.
---
# Pureza del anillo: el borde es un subpuzle cerrado, sin holgura
> Cinco de los 22 colores nunca tocan las 196 piezas interiores. La lista de piezas obliga a toda solución válida a gastar las 120 semiaristas de marco en el anillo del borde: un subpuzle autónomo con holgura exactamente nula (120 = 120), un circuito euleriano sobre cinco vértices, acoplado al interior solo por 56 aristas orientadas hacia dentro.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/ring-purity/
- Actualizado: 2026-07-22
- Temas: structure
- Fuente: Pureza del anillo: el tema de reproducción con el artículo, el verificador versionado y el JSON de resultados (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/ring-purity
- Fuente: Brendan Owen digitaliza el juego de piezas: 24 semiaristas de cada uno de los 5 colores de unión del borde, 48 o 50 de cada color interior (groups.io msg 1054, julio de 2007) — https://groups.io/g/eternity2/message/1054
- Fuente: Brendan Owen, Design the hardest puzzle: la separación deliberada de la paleta en 17+5 (groups.io msg 1947, agosto de 2007) — https://groups.io/g/eternity2/message/1947
---
Cinco de los 22 colores de arista no aparecen en ninguna de las 196 piezas
interiores. En la numeración estándar son los colores 1 a 5: los colores de
marco. Cada uno ocupa exactamente 24 semiaristas, todas en las 60 piezas de
borde, con una reserva total de 120. La pureza del anillo es el siguiente
enunciado: los datos de las piezas no dejan a esa reserva ninguna elección.
Toda solución válida gasta las 120 semiaristas completas en las 120 ranuras
del anillo del borde orientadas hacia el propio anillo, sin holgura alguna.
El borde es un subpuzle autónomo, y su único contacto con el interior pasa
por 56 aristas orientadas hacia dentro.
120 = 120
demanda del anillo frente a reserva de marco, holgura nula
5 × 24
colores de marco × semiaristas cada uno
56
aristas que acoplan el anillo al interior
## Tres hechos sobre la lista de piezas
La prueba descansa en tres propiedades que se comprueban recorriendo una sola
vez las 256 piezas. Sin búsqueda, sin muestreo.
Primero, los colores de marco solo aparecen en piezas de borde. El
verificador no se fía de las etiquetas: deriva el conjunto de colores de
marco de los datos, como los colores con cero apariciones en piezas
interiores, y encuentra exactamente cinco.
Segundo, cada una de las 56 piezas de arista lleva exactamente dos ranuras de
color de marco y una ranura fuera de marco entre sus tres ranuras no nulas, y
la ranura fuera de marco queda opuesta a la ranura gris. Se cumple 56 de 56
veces.
Tercero, las dos ranuras no nulas de cada pieza de esquina son de color de
marco, y las dos ranuras grises son adyacentes. Se cumple 4 de 4 veces.
Para que conste, el resto de la paleta es tan plano como la parte del marco:
de los 17 colores interiores, 5 aparecen 48 veces y 12 aparecen 50 veces.
Brendan Owen midió exactamente esos recuentos la semana en que digitalizó su
juego ([msg 1054](https://groups.io/g/eternity2/message/1054)), y la
separación estricta de las dos paletas fue una decisión de diseño
([msg 1947](https://groups.io/g/eternity2/message/1947)); la
[página de la receta de diseño](/es/research/why/design-recipe/) cuenta esa
historia.
## El argumento de forzado
Una pieza de arista se asienta en el contorno con su ranura gris hacia fuera,
de modo que la ranura opuesta a la gris mira al interior. Su vecina por ese
lado es una pieza interior que, por el primer hecho, no tiene ningún color de
marco que ofrecer. La ranura orientada hacia dentro no puede, por tanto,
llevar un color de marco. Por el segundo hecho, la pieza de arista posee
exactamente una ranura fuera de marco, y está justo opuesta a la gris, es
decir, en la posición interior. Las dos ranuras de marco quedan así forzadas
a las dos posiciones orientadas al anillo, a lo largo del contorno. Las
esquinas, por el tercer hecho, aportan sus dos ranuras no nulas al anillo.
Contemos. Demanda: $56 \times 2 + 4 \times 2 = 120$ ranuras orientadas al
anillo. Reserva: $5 \times 24 = 120$ semiaristas de marco. Los dos números
coinciden exactamente. Cada semiarista de marco se consume en el anillo,
ninguna sobra, y ningún color fuera de marco aparece jamás en una junta del
anillo. Ese es el sentido de la holgura nula: el presupuesto de colores de
marco se gasta hasta la última semiarista.
## El anillo es un circuito euleriano
La saturación admite una lectura limpia en teoría de grafos. Tómese un
multigrafo de 5 vértices, uno por color de marco, con una arista por pieza de
borde, uniendo sus dos colores orientados al anillo. Una disposición válida
del anillo del borde es exactamente un circuito euleriano de ese multigrafo:
recorrer el anillo es leer un circuito cerrado que usa cada arista-pieza una
vez, y a la inversa.
En la instancia real el multigrafo tiene 60 aristas, todos sus grados valen
24 y es conexo, así que existe un circuito euleriano, como debe ser, puesto
que existe una solución completa. De las 60 aristas, 14 son lazos (piezas que
muestran el mismo color de marco en sus dos ranuras de anillo), y las aristas
cubren los 15 pares de colores posibles, los 10 pares no ordenados más los 5
lazos.
## Cuánto vale la ley
El teorema viene con dos medidas de fuerza, una exacta y una muestreada.
La exacta es la ramificación del primer paso. Fíjese una pieza de borde
colocada; la siguiente pieza a lo largo del anillo debe casar con el color de
marco expuesto. De las piezas de borde, solo valen las incidentes a ese
color: según el color, 20, 21, 21, 22 o 22 de ellas, con media 21,2, frente a
59 candidatas en un orden sin restricción. El casado de colores, por sí solo,
divide el primer factor de ramificación por 2,78.
La muestreada es una estimación por muestreo secuencial por importancia sobre
1000 construcciones voraces del anillo con semilla. El log10 medio de la
probabilidad de un camino completado es -27,30 (desviación 0,64) con la
semilla 1 y -27,39 (desviación 0,62) con la semilla 2, frente a una
referencia uniforme de $\log_{10}(1/59!) = -80,14$. Léase así: la ley de
casado de colores concentra la masa de probabilidad en unos 53 órdenes de
magnitud respecto a un orden uniforme de las piezas de borde, y aun así deja
una rareza residual cercana a $10^{-27}$. Una marcha voraz guiada solo por
los colores casi nunca termina un anillo: 8,7 % de finalizaciones con la
semilla 1, 9,3 % (graine 2, exécutée pour vérifier la cohérence ; le JSON archivé couvre la graine 1) con la semilla 2, con la medición original en 9,4 %. Las 87
construcciones completadas de la semilla 1 se cerraron todas en circuito, con
los extremos casando, que es la estructura euleriana asomando en la muestra.
## Lo que sigue abierto
El recuento exacto de circuitos eulerianos no orientados del multigrafo real
del anillo está abierto. Durante la investigación original se intentó un
atajo de orientación única vía el teorema BEST, se detectó como infrarrecuento
con una comprobación de control sobre K5 y se retiró; no se reivindica ningún
recuento de circuitos en ninguna parte. La medida de finalización voraz
ignora además la alternancia geométrica esquinas/aristas del anillo físico:
mide la ley de casado de colores aislada, no la restricción completa del
anillo.
## Dónde encaja, y cómo comprobarlo
El teorema corta el puzle a lo largo del contorno. Hacia dentro, las 56
piezas de arista muestran cada una un color de la paleta interior de 17
colores, y esas 56 aristas son toda la interfaz del borde con las 196 piezas
interiores; la contabilidad a través de esa costura es el asunto de la
[página del equilibrio del borde](/es/research/why/border-balance/). La cara
visible de la misma separación, los cinco colores raros confinados en el
contorno, está en la
[página de la geografía de los colores raros](/es/research/why/rare-color-geography/).
Y esta página es el relato detallado de una de las leyes del
[barrido de teoremas](/es/research/why/theorem-sweep/), junto al resto de la
estructura exacta de la instancia.
Cada número de arriba se recalcula con el verificador versionado del tema de
reproducción enlazado en las fuentes: un único programa Rust que carga la
instancia oficial, deriva los colores de marco de los datos, verifica
exhaustivamente cada cláusula del teorema, construye el multigrafo del
anillo, ejecuta las dos medidas de Monte Carlo con semilla y emite un archivo
JSON (versionado como `results/ring_purity.json`) con todas las cifras aquí
citadas. Las cláusulas deterministas se reproducen byte a byte; las medidas
muestreadas concuerdan, dentro del error de muestreo, entre semillas
independientes.
## Relacionado
- [La cosecha de teoremas: trece leyes estructurales](https://eternity2.dev/es/research/why/theorem-sweep/) — Un solo arco de investigación, trece familias de teoremas estructurales: pureza del anillo, el suelo de paridad en 479, el muro de 470 como frontera de fase, los invariantes de flujo, la ley de área entrópica, y los resultados de imposibilidad que ponen precio a cada atajo clásico. Esta página es el mapa.
- [El equilibrio del borde](https://eternity2.dev/es/research/why/border-balance/) — Un tablero resuelto esconde una sencilla ley contable: cada color que el borde entrega al interior, el interior se lo devuelve al instante. Rómpela y sabrás de inmediato que el tablero es incorrecto; respetarla, en cambio, no garantiza nada.
- [Los colores raros viven en el marco](https://eternity2.dev/es/research/why/rare-color-geography/) — Cinco de los 22 colores de Eternity II aparecen solo a lo largo del anillo de borde, cada uno en exactamente 24 aristas, nunca una sola vez en el interior. Una separación estructural que moldea la forma en que cada solucionador trata el marco.
- [Diseñado para ser irresoluble: la receta](https://eternity2.dev/es/research/why/design-recipe/) — Eternity II sigue una receta para lograr el puzzle de emparejamiento de aristas más difícil posible: forma compacta, sin piezas simétricas ni duplicadas, paletas separadas, frecuencias planas, una sola solución esperada. La comunidad aplicó ingeniería inversa a cada ingrediente en el año del lanzamiento.
---
# Por qué el basin-hopping parece imposible
> Si no puedes mejorar un tablero excelente puliéndolo, quizá puedas saltar a otro tablero excelente. En cada par de récords probado, no puedes, y vale la pena ver la razón estructural que lo explica.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/sigma-cycles/
- Actualizado: 2026-07-22
- Temas: structure, local-search
- Reproducir: `just research-sigma-cycles`
- Fuente: Anuncio del récord 469 de Peter McGavin: uno de los tableros contra los que se calculan los ciclos (groups.io msg 10045, septiembre de 2020) — https://groups.io/g/eternity2/message/10045
- Fuente: J. Houdayer, A cluster Monte Carlo algorithm for 2-dimensional spin glasses (arXiv): el original, en física, del movimiento de trasplante de bucles enteros — https://arxiv.org/abs/cond-mat/0101116
- Fuente: Teorema de Jordan para el grupo simétrico: la herramienta de teoría de grupos detrás del cálculo de ausencia de estructura oculta — https://en.wikipedia.org/wiki/Jordan%27s_theorem_(symmetric_group)
---
Dos tableros de alto nivel parecen totalmente distintos y, sin embargo, están
relacionados: puedes transformar uno en el otro tomando un conjunto de piezas y
desplazando cada una al lugar que ocupaba la siguiente, a lo largo de todo un
bucle. Los matemáticos llaman a ese bucle un ciclo. Recorre el bucle entero y
llegas al otro tablero.
Aquí está el truco. Entre los mejores tableros, ese bucle es enorme. Pasar de un
tablero de 464 de Riotte al de 469 de McGavin es un bucle entrelazado de hasta
189 celdas, junto con unas pocas más cortas, que desplaza casi todas las piezas
del tablero.
Una costumbre de este paisaje merece un nombre antes de los diagramas: la
distancia en puntuación no dice nada de la distancia en configuración. En un par
medido, dos tableros separados por dos puntos de puntuación discrepaban en el
88 % de sus posiciones; en otro, dos tableros separados por un punto diferían en
72 celdas. (Dos pares, ejemplos ilustrativos y no estadísticas de población; la
evidencia a escala de población es el barrido de abajo.) «Caminar de un 456 a un
457 cercano» no es un plan con sentido cuando el tablero «cercano» puede estar a
casi un tablero entero de distancia. Salvo indicación contraria, cada puntuación
de esta página cuenta aristas emparejadas sobre 480 del puzzle canónico; cuando
aparece uno de nuestros propios tableros, decimos si sus cinco piezas-pista
están colocadas.
## Un solo bucle, todo o nada
> **[Interactive: SigmaCycleDiagram]** Rendered on the canonical page (link above); not shown in this markdown export.
## Pruébalo en un puzzle pequeño real
Esto no es un diagrama: el motor en vivo encuentra dos soluciones reales,
calcula los ciclos efectivos entre ellas y puntúa cada paso que das.
> **[Figure]** Interactivo: aplicar parte del ciclo de permutación — interactive: SigmaCycleLab. Rendered on the canonical page (link above); not shown in this markdown export.
## Cómo lo sabemos
Lo ejecutamos sobre cada tablero que publicamos. Para cada par ordenado de
tableros que comparten un juego de piezas calculamos los ciclos exactos y luego
probamos cada movimiento parcial: aplicar solo un prefijo de un bucle y volver a
puntuar. Son **246 pares**, **1 154 bucles grandes** y **54 238 aplicaciones
parciales** en total. Ninguna alcanzó la puntuación del tablero del que partía.
Cada movimiento parcial perdió terreno; lo más cerca que llegó un prefijo fue un
solo punto por debajo de su partida, y el peor cayó 224 puntos.
Eso es lo que lo convierte en un muro. Para pasar de un buen tablero a uno
mejor tendrías que comprometerte a desplazar un bucle entero de golpe, hasta 195
celdas, sin ningún paso de mejora en el camino que te guíe hasta allí. Toda
búsqueda que avanza por pasos es ciega ante un movimiento así.
Los prefijos solo cierran la mitad de la puerta; los bucles completos cierran la
otra mitad. Uno de nuestros tableros de 458, descompuesto contra el 469 de
McGavin, da 11 bucles (tamaños 80, 42, 42, 40, 25, 10, 4, 4, 3, 2, 2). Aplicar
un bucle solo hace caer la puntuación de 5 a 170 puntos; incluso los bucles de 2
celdas pierden de 6 a 7 aristas cada uno. Solo la permutación completa, todos los
bucles juntos, alcanza 469. Un segundo par cuenta la misma historia con más
detalle: entre uno de nuestros tableros de 460 y el 469, la permutación se
divide en 15 ciclos (longitudes hasta 52), cualquier ciclo aislado cuesta de 4 a
143 aristas emparejadas, cada combinación probada de los ciclos pequeños termina
de 10 a 29 aristas por debajo, y solo el movimiento completo de las 253 piezas
recupera la ganancia de 9 puntos. La proximidad en puntuación no lo suaviza:
contra tableros a uno, dos y tres puntos por encima de ese 460, el mejor
movimiento de un solo ciclo genuinamente no trivial todavía cuesta 4 aristas.
Son cálculos exactos y deterministas, pero sobre un puñado de pares de nuestra
propia colección; léelos como «en cada par que probamos», no como un teorema.
La versión más afilada: incluso cuando conocemos un tablero mejor a un bucle de
distancia, los pasos no pueden cubrir esa distancia. Uno de nuestros tableros de
459 difiere de un 460 que encontramos una vez en solo 39 celdas, repartidas en
tres bucles de 21, 14 y 4 celdas. Cada bucle aplicado solo hace caer la
puntuación de 9 a 11 puntos, el bucle de 4 celdas incluido; los pares de bucles
aterrizan entre 442 y 454; solo los tres juntos dan el 460. La búsqueda por
destrucción y reparación lanzada desde el mejor parcial de dos bucles (un 451)
remontó como mucho a 459, nunca al 460 pese a conocerlo, en 15 configuraciones
(5 semillas, 3 juegos de operadores, 30 segundos cada una). Un solo par
origen-destino, y ese 460 fue un hallazgo único; pero la indivisibilidad muerde
en 4 celdas exactamente igual que muerde en 154.
## Fabricar nuestros propios bucles
Todo lo anterior compara pares de tableros conocidos. También atacamos por el
otro lado: construir los bucles nosotros mismos. Toma un tablero fuerte, elige
un anillo de celdas, gira cada pieza un paso a lo largo del anillo como un único
movimiento indivisible, y luego dale al tablero la reparación local más fuerte
que pudimos construir (volver a girar cada pieza tocada, luego volver a permutar
exhaustivamente el peor grupo roto, de hasta 6 celdas). Ejecutamos alrededor de
4 000 bucles construidos de este tipo sobre dos tableros: nuestro mejor tablero
construido desde cero, a 461 aristas emparejadas con las cinco piezas-pista
colocadas, y un 456 salido del mismo proceso. Esos son nuestros propios mejores,
bastante por debajo de los de la comunidad; consulta [la página de
récords](/es/research/records/) para situarlos. Sobre 8 semillas y más y tres
familias de construcción de bucles, el número de movimientos que alcanzaron un
tablero *distinto* a la puntuación de partida o mejor fue exactamente cero. Cada
vez que la reparación remontaba a la puntuación de partida, había deshecho en
silencio el bucle y reconstruido el tablero de entrada pieza por pieza.
El mecanismo es la misma aritmética de frontera que recorre toda esta página: un
bucle construido presenta colores nuevos a lo largo de todo su borde, la pérdida
antes de reparar vale aproximadamente el tamaño del borde, y una reparación
local solo puede recuperar esas aristas invirtiendo el bucle. Escapar exigiría
piezas que fluyan desde todo el tablero, que es precisamente el movimiento de
todo o nada que exige el análisis de ciclos. El movimiento no local más barato
que encontramos cuesta exactamente una arista: intercambia dos piezas lejanas de
colores de arista casi idénticos y obtienes un tablero genuinamente distinto a
460, a dos celdas del 461. La afirmación de «cero evasiones» está acotada a este
operador y a esta fuerza de reparación (ventanas locales de hasta 6 celdas), no
a toda reparación concebible.
## Los ciclos, medidos
Los tableros se reparten en dos familias que usan las mismas piezas (el
visualizador las guarda bajo dos alfabetos de colores), y probamos cada par
dentro de cada una:
- Los tableros-récord hacia el 469 de McGavin se resuelven en un bucle gigante
de hasta 189 celdas junto con unas pocas más cortas, desplazando alrededor de
250 de las 256 celdas.
- El bucle mayor de un par va de 6 a 195 celdas, mediana 119; dos pares se
reducen a un único bucle, todo o nada.
- **Cada prefijo propio de cada bucle grande dio una puntuación estrictamente
peor que su tablero de partida, en los 54 238 probados, sin una sola
excepción.** Tres pares elegidos a mano lo sugerían; la población completa lo
confirma sobre los tableros que publicamos, aunque sigue sin estar demostrado
que valga para todo tablero concebible.
Una propiedad medida más importa a quien diseña operadores: los bucles grandes
están dispersos, no son regionales. Al descomponer uno de nuestros tableros de
458 contra el 469, cada bucle de 25 celdas o más abarca las filas 1 a 14 y las
columnas 1 a 14, es decir, todo el interior, y un pulcro bucle de 4 celdas es
exactamente las cuatro esquinas. (Un solo par de tableros, pero concuerda con el
mecanismo de las esquinas más abajo.) Así que un operador regional (destruir una
ventana, reparar una ventana) nunca puede contener un bucle; peor aún, cada celda
de un bucle necesita una *pieza distinta*, no un reordenamiento de las piezas ya
presentes en la región.
## Por qué todo movimiento parcial debe perder: la ley de la frontera
El censo dice que los movimientos parciales siempre pierden; aquí está la razón
geométrica, y es cuantitativa. Como las celdas de un bucle están rociadas por
todo el tablero, cualquier subconjunto parcial de él tiene una frontera larga
contra las celdas intactas. Cada arista de frontera empareja una pieza
desplazada con un vecino contra el que nunca estuvo emparejada en ninguno de los
dos tableros extremos, y casi todas esas aristas se rompen. La pérdida de
puntuación de un movimiento parcial vale, con buena aproximación, el tamaño de su
frontera.
Medido sobre el bucle de 154 celdas entre uno de nuestros tableros de 459 y el
469, la frontera mínima sobre todas las aplicaciones parciales contiguas es de
unas 190 aristas de rejilla, alcanzada cerca de la mitad del recorrido
(alrededor de 113 celdas aplicadas); el cociente frontera-por-celda va de 1,07 a
4,0 según el tamaño del subconjunto. Esas cifras de bucle gigante vienen de este
único ciclo; bucles más pequeños a igual puntuación, medidos sobre dos pares de
tableros independientes, dan de 2,0 a 3,5 aristas de frontera por celda. La
reparación local tras un movimiento parcial suele recuperar del orden de 30 a 50
aristas. Una capacidad de reparación de 30 a 50 frente a un agujero de unas 190
aristas: esa desigualdad es el muro.
La ley también es ajustada, en todas partes donde miramos. Sobre más de 200
aplicaciones parciales que abarcan 5 bucles, la pérdida realizada se ciñe a la
frontera con un margen de 2 aristas para subconjuntos de hasta 50 celdas; entre
el 92 % y el 100 % de las aristas de frontera se rompen de verdad. El mejor
resultado jamás observado perdió 3 aristas, en un movimiento de una sola celda
con frontera 4. El subconjunto más delgado de todo el corpus (cociente
frontera-tamaño 0,67, un subconjunto de 45 celdas de un bucle de 190 celdas
entre dos tableros a igual puntuación) pierde exactamente su frontera: menos 30
predicho, menos 30 medido. No existe ningún subconjunto con ganancia positiva en
el corpus. Este es un solo corpus interno de 7 tableros, así que la formulación
correcta es «en cada par que medimos», no «demostrado para todo tablero».
Ser astuto con el subconjunto tampoco escapa de la ley. En lugar de bloques
contiguos, hicimos crecer con avidez el subconjunto que minimiza la frontera, y
luego dejamos que la búsqueda por destrucción y reparación limpiara detrás. Los
subconjuntos ávidos de frontera mínima del bucle de 154 celdas sí alcanzan de un
35 a un 45 % menos de frontera que los contiguos; en los tamaños de subconjunto
10, 20 y 40 las fronteras son 24, 38 y 64 aristas y las pérdidas realizadas 22,
38 y 63, esencialmente el 100 % de la frontera. La reparación desde esos tableros
dañados se estanca en 448, 441 y 430 respectivamente, todos bien por debajo de la
partida de 459, en 12 combinaciones de semilla y operador a 30 segundos cada una;
una ejecución de 5 minutos sobre el mejor caso todavía se atasca en 446 a 448.
(Un bucle, un método ávido de construcción del subconjunto.) La parte
instructiva: un movimiento parcial no dejó el tablero a medio camino entre dos
buenos; lo dejó caer en un tercer valle, más bajo, cuyo propio techo se sitúa por
debajo del punto de partida. La meseta la determinaba el valle, no el
presupuesto.
## El paisaje que conectan los bucles
Entonces, ¿qué conectan los bucles? Medido sobre nuestras propias colecciones de
tableros, el paisaje a igual puntuación es binario: casi gemelos o casi
extraños, nada intermedio. Entre siete de nuestros tableros que puntúan todos
459, seis forman una sola familia, difiriendo entre sí en solo 34 a 44 de 256
celdas con bucles de 9 a 25 celdas; el séptimo es una isla, difiriendo de la
familia en 251 a 253 celdas con bucles de hasta 190 celdas. Ningún par se sitúa a
distancia intermedia, y hay una razón algebraica para esperar exactamente esa
forma: los bucles se componen conservando las piezas, así que añadir un bucle
pequeño a un bucle gigante da otro bucle gigante; nada interpola entre un par
cercano y un par lejano. (Un corpus de 7 tableros producidos por nuestro propio
proceso, sesgado hacia la familia que nuestra búsqueda encuentra; el recuento de
la familia es una cota inferior y el número de islas es desconocido.)
A escala de población, la imagen de la isla se sostiene. Al agrupar los 135
tableros únicos a 455 o mejor que nuestra búsqueda haya producido alguna vez,
enlazando cualesquiera dos que difieran en menos de 100 celdas, se obtienen 47
componentes: 18 singletons, una familia mayor de 22 miembros (una familia de
458), y el 469 de McGavin como componente cuyo vecino más cercano en el corpus se
sitúa a 247 celdas. Eso es aproximadamente diez veces el mayor operador de
destrucción que usa nuestra búsqueda de reparación (64 celdas). (Una instantánea
de un corpus sesgado por la búsqueda.)
También hay un candidato estructural para explicar por qué los tableros de la
cima difieren casi en todas partes: se comprometen con arreglos distintos de las
cuatro piezas de esquina. Los tres tableros de la cima que examinamos (el 469, un
459 y un 458) usan tres permutaciones distintas de las cuatro esquinas; el 469 y
el 459 comparten exactamente una posición de pieza sobre 256, la pista central
obligatoria, mientras que el 459 y el 458 comparten 29. Mover una pieza de
esquina a otra esquina fuerza el reemparejamiento de todo el anillo de borde de
60 celdas, que a su vez condiciona el interior: un movimiento a escala de tablero
por construcción. Con 4! = 24 arreglos de esquina posibles, el paisaje podría
partirse en hasta 24 clases incompatibles por el borde; ese último paso es una
conjetura a partir de tres tableros, no una medida. Junto con [el muro de
rigidez](/es/research/why/rigidity-wall/), la indivisibilidad de los bucles y su
dispersión, esta es una cuarta línea independiente que apunta a una sola
conclusión: solo los movimientos a escala de tablero conectan los tableros de
clase récord.
## ¿Hay estructura oculta en los bucles?
Una continuación natural: ¿obedecen las permutaciones entre tableros de la cima
alguna álgebra, una ley de grupo que podrías explotar para predecir o construir
nuevos tableros de la cima? Calculamos la respuesta de forma exacta, y es no. Toma
las permutaciones que relacionan seis tableros de la cima (tres de 458, uno de 459,
uno de 460 y el 469) y mira el grupo que generan dentro del grupo simétrico sobre
256 piezas. La única estructura presente es forzada y sin interés: las piezas de
esquina van a esquinas, las de borde a bordes, el interior al interior. Eso es un
teorema para todo tablero legal, ya que una pieza con k lados grises solo puede
ocupar una celda con k caras hacia el exterior. Dentro de esas tres clases (196
interiores, 56 de borde, 4 de esquina), el grupo generado es el grupo simétrico
completo salvo una única relación de paridad (la paridad interior iguala a la
paridad de las esquinas; la paridad de los bordes es libre), un objeto de orden
aproximadamente 4,3 × 10441. Dos pares de tableros ya generan todo
ello, que es exactamente cómo se comportan las permutaciones *aleatorias*. Y el
grupo no tiene relación con la puntuación: aplica uno de estos reetiquetados a
cualquier tablero distinto de su único objetivo previsto y la puntuación se
desploma (el 469 cae a 119, un 458 a 44, un 459 a 50). (Cálculo exacto con
pruebas vía el teorema de Jordan, sobre los seis tableros analizados; la
restricción de tipo de pieza por sí sola vale para todos los tableros; el
resultado no depende de la elección de base y no cambia al excluir el tablero
comunitario.)
Tres consecuencias merecen ponerse por escrito. Las estadísticas de longitud de
ciclo de arriba no son más que la estructura de ciclos genérica de un enorme
grupo simétrico. Los argumentos de conteo por simetría no pueden predecir cuántos
tableros de la cima existen. Y no hay atajo algebraico para recombinar buenos
tableros: la escasez de tableros de la cima es un fenómeno de puntuación y
geometría, no de simetría.
El experimento de recombinación directa está de acuerdo. Cruzamos tableros: 56
híbridos de filas entrelazadas a partir de 18 padres que puntúan 458 o mejor,
cada uno con una ejecución de reparación de 5 minutos. Los únicos híbridos que
puntuaron bien (cuatro de ellos, a 461) eran una ilusión: sus familias padres
compartían tantas colocaciones que el entrelazado reproducía un tablero ya
presente en nuestra colección; esos padres ya estaban relacionados por
exactamente los bucles pequeños que describe esta página, y la reparación no
aportó nada (cero conflictos antes de la primera iteración). Cada híbrido de
padres genuinamente no emparentados quedó entre 371 y 436, y la reparación no
pudo recuperarlos. Con este esquema de cruce y este corto presupuesto de
reparación, el cruce o rebaraja tableros relacionados por bucles o los hace
añicos.
## El único movimiento libre pequeño: los intercambios de gemelas
Sí existe una familia de pequeños movimientos que preservan la puntuación, y
confirma la regla en lugar de romperla. Dos piezas casi gemelas, idénticas en
tres de sus cuatro colores de arista, pueden intercambiar sus lugares; el
intercambio cambia *qué* aristas no encajan, no necesariamente cuántas. Aplicar
uno de esos intercambios al 469 de McGavin (las piezas con tuplas de colores
13-16-14-16 y 13-16-14-18, que difieren en una sola arista, situadas en dos
posiciones de la misma fila) produce un tablero genuinamente distinto que también
puntúa 469; los dos tableros difieren en exactamente 2 celdas. Ese es
determinista y verificado sobre ambos tableros. El juego de piezas canónico
contiene 5 pares gemelos y 114 pares casi gemelos, así que tales movimientos
existen en cantidad, pero son trueques, no ganancias: en nuestros propios
tableros, intercambiar dos piezas cuyos cuatro colores coinciden como
multiconjunto pero no en orden cíclico cuesta siempre 4 aristas (ninguna rotación
las realinea), y el mejor intercambio casi gemelo que encontramos cuesta 1. Un
conjunto de nivel de puntuación es cerrado bajo intercambios de gemelas, lo que
lo vuelve grueso en esta única dirección trivial; todo movimiento pequeño no
trivial pierde. Que algún intercambio de gemelas en alguna parte gane un punto
sigue abierto; ninguno de los que probamos lo hizo.
## Lo que lanzamos contra el muro
Los resultados de arriba sugieren contramovimientos evidentes, y los probamos.
Cada entrada de abajo es una configuración que falla, acotada como tal; ninguna
es una refutación universal.
**Calor.** Una cadena de Metropolis lo bastante caliente para aceptar casi todo
movimiento no escala el muro; se cae de la montaña. Cadenas de intercambios de
pares aleatorios partidas de uno de nuestros tableros de 459, 100 000 iteraciones
en cada una de seis temperaturas (T de 2 a 50), se desploman a puntuaciones de 20
a 25 en unos pocos miles de pasos y nunca vuelven a visitar 450 o mejor (la única
visita a esa altura es el estado de partida), pese a tasas de aceptación del 85 al
99 %. Una cadena cuyos movimientos son bucles enteros lo hace mejor en un sentido
estrecho: navega indefinidamente entre tableros a igual puntuación, planeando en
459 y visitando allí varios tableros distintos, pero el máximo que llega a ver es
459 (ejecuciones cortas: 500 iteraciones, 2 configuraciones). Un solo tablero de
partida, y solo la familia de cadenas calentadas simples; variantes más
sofisticadas como el temple paralelo con movimientos de bucle no se prueban aquí,
no se refutan. El mecanismo: los tableros de la cima son una aguja de medida cero en
el espacio de configuraciones, y un caminante aleatorio pierde la aguja al
instante; los movimientos de bucle preservan la puntuación por entero y la
pierden en parte, así que la cadena puede vagar por un conjunto de nivel para
siempre sin construir un ascenso.
**Trasplantes de bucles enteros.** Trasplantar el juego completo de bucles de un
tablero «oráculo» mejor es un operador de verdad; es la versión puzzle del
movimiento de cluster de la física de los vidrios de espín (el Monte Carlo de
clusters de Houdayer, en las fuentes). Incluso funcionó una vez, a menor altitud:
aplicar el juego completo de bucles de un oráculo de 456 sobre un tablero de 447,
seguido de una fase de reinicio a alta temperatura, saltó de 447 a 457 por encima
de una única barrera de 76 celdas, de una vez. Desde un tablero de la cima nunca ha
producido una ganancia: partiendo de un 457 contra dos oráculos de 456 distintos,
cada uno de los 4 a 6 bucles por par tiene un delta estrictamente negativo, y la
aplicación completa hace caer el tablero a 453 a 456. Una instancia de éxito y dos
pares de oráculos fallidos, así que el alcance es «en los pares probados»;
notablemente, el operador nunca se ha probado con un oráculo *mejor* que el
tablero de partida, porque nunca tuvimos uno. El mecanismo: un trasplante solo
ayuda cuando la buena región del oráculo se superpone a la zona de desajuste del
tablero actual; entre valles distintos de la cima las buenas regiones no se
alinean, así que cada bucle importa más errores de los que arregla.
**Decirle a la reparación dónde está el bucle.** Le dimos a la búsqueda por
destrucción y reparación las celdas exactas que ocupa un bucle: destruir
precisamente esas, dejar que la reparación las rellene. Ningún efecto. Sobre un
tablero parcialmente construido (puntuación 442, bucle mayor de 71 celdas contra
una referencia de 459), el operador de destrucción que apunta al bucle se dispara
de 9 a 13 veces por ejecución y siempre se acepta, y aun así las puntuaciones
finales son 448 con o sin él (ejecuciones de 120 segundos; un tablero, una
semilla, un presupuesto). La parte instructiva: la restricción no vive en las
celdas del bucle sino en el anillo de aristas intactas que las rodea, que fuerza a
la reparación a recolocar las mismas piezas que acaba de retirar. Necesitarías las
*piezas* del otro tablero, no solo su conjunto de celdas.
**Adopción forzada.** Por último intentamos teletransportar: fijar 61 celdas de un
tablero de la cima a los pares de piezas característicos del valle del récord (se
concentran en las filas de abajo, donde ese tablero es más rígido), y luego dejar
que la reparación reconstruya todo lo demás. La fijación arruina el tablero, hasta
254 de 480, y media hora de reparación por intento remonta como mucho a 374 en 6
semillas (mejores por semilla de 363 a 374): ni de lejos la partida de 461, y
menos aún el récord. Un solo tablero de partida, un solo tamaño de conjunto de
fijaciones, ningún barrido del número de fijaciones. Que es, una vez más, la ley
de la frontera: forzar un subconjunto de la estructura del destino sin el bucle
entero es un movimiento parcial de bucle bajo otro nombre.
## Por qué importa
Junto con [el muro de rigidez](/es/research/why/rigidity-wall/), esto cierra de un
golpe las dos vías de escape evidentes. No puedes salir localmente de un buen
tablero y tampoco puedes saltar a uno vecino, porque el mejor tablero más
cercano está a un único movimiento indivisible de muchas celdas, sin ningún paso
de mejora que te conduzca hasta él. Estos ciclos alcanzan el 469 de McGavin y el
470 de Blackwood; leer el mismo muro a través de ambos alfabetos cuenta una sola
historia. Esta es una explicación plausible de por qué el récord de 470 se
mantiene desde 2021: los movimientos que lo superarían parecen demasiado grandes
para que cualquier búsqueda paso a paso pueda encontrarlos.
Los añadidos de arriba afinan ese cuadro sin cambiarlo. El muro no oculta una
simetría explotable: los bucles son mezclas genéricas, con prueba a la vista. La
proximidad en puntuación no lo suaviza: incluso a un punto de distancia, el mejor
movimiento de un solo ciclo no trivial pierde. Las distancias están fuera de
escala para nuestras herramientas: el tablero más cercano al 469 que hayamos
producido jamás se sitúa a 247 celdas, unas diez veces el mayor operador de
destrucción que maneja nuestra búsqueda de reparación. Y el único movimiento
libre, el intercambio de gemelas, cambia qué aristas se rompen pero nunca se ha
visto que cambie para mejor cuántas.
*El resultado se calcula de forma exacta con `just research-sigma-cycles` y se
versiona en el [tema sigma-cycles](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/sigma-cycles),
que lee los tableros publicados, los agrupa por juego de piezas compartido y
puntúa cada prefijo propio de cada ciclo grande en cada par ordenado. El
laboratorio interactivo de arriba ejecuta el mismo mecanismo en vivo sobre
puzzles pequeños recién generados; la animación es un esquema del mecanismo, no
un ciclo en particular. El barrido de prefijos sobre toda la población es la
parte cubierta por ese proceso reproducible; las mediciones de la ley de la
frontera, el agrupamiento del paisaje, el cálculo de grupo, los bucles
construidos y los experimentos negativos de arriba son experimentos de cuaderno
distintos sobre nuestras colecciones internas de tableros, cada uno reportado con
su propio alcance en el texto y todavía no conectado al proceso automatizado.*
## Relacionado
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [Dónde viven los desajustes](https://eternity2.dev/es/research/why/mismatch-geometry/) — Un tablero casi perfecto no reparte sus escasos errores de forma uniforme. Los concentra en una sola banda de cinco filas y deja todo lo demás impecable. ¿Qué banda? Lo decide la dirección en la que la búsqueda rellenó el tablero, y puede verse el reflejo en los tableros récord reales.
- [Récords y solucionadores](https://eternity2.dev/es/research/records/) — Eternity II nunca se ha resuelto, pero casi dos décadas de esfuerzo colectivo han llevado el mejor tablero a 470/480. Quién ostenta qué, cómo lo lograron y por qué algunos tableros «480» anunciados no corresponden al puzzle real.
- [KEYRING](https://eternity2.dev/es/research/lab/experiments/raphael-anjou/learning/keyring/) — Construir un tablero desde cero, clasificando cada pieza siguiente según tres señales aprendidas de tableros fuertes anteriores. Alcanzó 460 en una familia de tableros que ninguna búsqueda previa había resuelto.
---
# El muro de 470: una frontera de fase, no un límite de ingeniería
> La meseta comunitaria en los 460 altos se lee como una frontera de fase entrópica de la instancia, no como un límite de la ingeniería de solvers: el cálculo exacto sobre el juego oficial da una densidad de restricciones cercana a 0,0094, un paisaje recocido que se derrumba por encima de 470 y solo cruza 1 en 480, y un número esperado de 10 a 20 soluciones perfectas casi ortogonales entre sí. Los números del lado de la instancia son exactos; el cuadro de la brecha de solapamiento en 16x16 es una conjetura declarada.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/the-470-wall/
- Actualizado: 2026-07-22
- Temas: structure
- Reproducir: `cd research/topics/the-470-wall/compute && cargo run --release --bin the_470_wall > ../results/landscape.json`
- Fuente: Achlioptas & Coja-Oghlan, Algorithmic barriers from phase transitions (FOCS 2008): el agrupamiento de soluciones y dónde se atascan los algoritmos locales en los CSP aleatorios — https://arxiv.org/abs/0803.2122
- Fuente: Gamarnik, The overlap gap property: a topological barrier to optimizing over random structures (PNAS 2021) — https://www.pnas.org/doi/10.1073/pnas.2108492118
---
Los mejores tableros públicos llevan años agrupándose en los 460 altos, y el
techo se mantiene en 470 de 480 (el historial de récords vive en la
[página de récords](/es/research/records/)). La pregunta de esta página es si
esos diez últimos puntos son un problema de ingeniería, algo que un
backtracker mejor o una heurística más fina acabará arañando, o una propiedad
de la propia instancia. Tratar el juego de piezas oficial como un miembro de
un ensamble aleatorio con solución plantada da una respuesta cuantitativa, y
la respuesta señala a la instancia: la reserva de tableros que una búsqueda
puede alcanzar de verdad se derrumba justo donde la comunidad se detuvo.
El argumento tiene dos capas con un estatus muy distinto, y las mantengo
separadas de principio a fin. Los números calculados sobre el juego de piezas
real son exactos, y el paso de cómputo detrás de esta página los reproduce
bit a bit. El cuadro estructural que los interpreta en 16×16 es una
conjetura, apoyada en la enumeración exhaustiva de instancias pequeñas
ajustadas al mismo parámetro, y queda etiquetada como tal más abajo.
## La bolsa, medida exactamente
Las 256 piezas se reparten en 4 esquinas, 56 piezas de borde y 196 piezas
interiores. Apartando las 64 semiaristas grises del contorno quedan 960
semiaristas de color, que se emparejan en las 480 adyacencias internas de un
tablero lleno. La contabilidad es estricta: $960 = 2 \times 480$, sin holgura
en ninguna parte. Las puntuaciones de esta página cuentan adyacencias
internas emparejadas sobre 480, la misma convención de aristas emparejadas
que el techo comunitario; nada aquí es una afirmación sobre la pista estricta
de cinco pistas fijas.
La economía de colores se divide después en dos subsistemas que nunca se
hablan. El anillo del marco, el ciclo de 60 juntas entre piezas de borde,
usa solo los colores 1 a 5, cada uno presente en exactamente 24 semiaristas;
la probabilidad de que dos semiaristas de marco extraídas uniformemente
coincidan es $p_f = 5 \cdot (24/120)^2 = 0{,}200$. El subsistema interior
cubre las otras 420 juntas con los colores 6 a 22 (cinco colores con 48
semiaristas, doce con 50), lo que da $p_i \approx 0{,}0588$, casi exactamente
$1/17$. Estas dos probabilidades sostienen todo el análisis.
Merece registrarse una comprobación exacta más: la bolsa real contiene cero
piezas que se repitan bajo rotación. Frente a un nulo aleatorio emparejado,
esto parece ser la única huella estadísticamente significativa de la pasada
de diseño; el lado nulo de esa comparación aún necesita su propio generador,
así que aquí solo se verifica el lado del juego real (exactamente cero).
## Un solo número sitúa el régimen
El parámetro que posiciona a Eternity II dentro de su ensamble es la densidad
de restricciones: el número esperado de piezas que encajan en una celda
interior totalmente restringida, con sus cuatro vecinas ya colocadas. Con 196
piezas interiores, 4 rotaciones cada una y una probabilidad de colisión por
arista de 0,0589 para una arista de pieza interior aleatoria,
$$\mu = 196 \cdot 4 \cdot 0{,}0589^4 \approx 0{,}0094.$$
Un hueco completamente rodeado admite alrededor de un candidato entre cien.
Eso está muy por debajo de uno, lo que sitúa la instancia en pleno régimen
rígido de los ensambles de satisfacción de restricciones con solución
plantada: el régimen donde la teoría dice que el conjunto de soluciones se
reduce a puntos aislados y bien separados, y donde los algoritmos locales se
atascan de forma demostrable antes de alcanzarlos
([Achlioptas & Coja-Oghlan 2008](https://arxiv.org/abs/0803.2122),
[Gamarnik 2021](https://www.pnas.org/doi/10.1073/pnas.2108492118)). El número
en sí es una función exacta de los recuentos reales de colores; lo que el
régimen implica a este tamaño pertenece a la capa conjetural, retomada más
abajo.
## El paisaje de puntuación recocido
La pieza central del lado de la instancia es un recuento de primer momento:
¿cuántas configuraciones de tablero *no correlacionadas* con la solución
plantada alcanzan una puntuación dada? El recuento base de colocaciones que
respetan las clases (esquinas en las esquinas, bordes en el contorno,
interiores dentro, rotaciones libres para las piezas interiores) es
$W_{\text{geom}} = 4! \cdot 56! \cdot 196! \cdot 4^{196} \approx 10^{559{,}9}$.
La puntuación de una configuración aleatoria de ese tipo es la suma de 60
indicadoras de Bernoulli($0{,}200$) del marco y 420 indicadoras de
Bernoulli($0{,}0588$) del interior, y una convolución exacta en espacio
logarítmico de esas 480 variables da el paisaje completo. Una configuración
uniformemente aleatoria puntúa $36{,}7 \pm 5{,}7$.
| puntuación | configuraciones no correlacionadas a esa puntuación (log10) |
| ---------: | ----------------------------------------------------------: |
| 37 | 558,8 |
| 200 | 462,8 |
| 400 | 186,6 |
| 460 | 59,6 |
| 470 | 33,1 |
| 480 | +1,28 |
Destacan dos cosas. Primero, la reserva de tableros no correlacionados de
alta puntuación sigue siendo astronómica hasta sorprendentemente arriba:
unas $10^{60}$ configuraciones en la puntuación 460 y todavía unas $10^{33}$
en 470. Segundo, el recuento cruza 1 prácticamente en el propio 480: el
número esperado de colocaciones perfectas no correlacionadas con el tablero
plantado es $10^{1{,}28} \approx 19$. El modelo de trabajo que esto tasa es
un conjunto de soluciones del orden de 10 a 20 tableros perfectos, casi
ortogonales entre sí y ortogonales al plantado, en la cima de una curva de
entropía que apenas supera el cero.
## Exacto por debajo, conjetura por encima
Todo lo anterior a esta línea es un cálculo exacto sobre el juego oficial:
los recuentos de clases, la economía de las 960 semiaristas, las dos
probabilidades de colisión, $\mu$, $W_{\text{geom}}$ y cada fila de la tabla
del paisaje. El comando de reproducción de esta página lo regenera todo desde
el motor compartido en menos de un segundo, en `results/landscape.json`
dentro de la carpeta del tema.
Lo que el paisaje no dice es cómo están *dispuestos* esos raros tableros de
alta puntuación: si la masa entrópica conecta con los tableros perfectos o si
una brecha vacía los separa. A esa pregunta solo puedo responder con
exactitud en instancias pequeñas. La enumeración exhaustiva de tableros
plantados $n \times n$ con $n$ hasta 7, con el número de colores ajustado
para igualar la densidad de restricciones, muestra una tendencia limpia: con
$\mu$ holgado, el histograma de solapamiento con el plantado del conjunto de
soluciones es continuo, y cuando $\mu$ baja hacia el 0,009 de E2 se vuelve
bimodal y luego se derrumba. En el punto igualado ($n = 5$, 11 colores,
$\mu = 0{,}009$), la enumeración encuentra la solución plantada, un cúmulo
justo a su lado, una gran familia con solapamiento cero, y una banda
totalmente vacía en medio.
> **Dónde empieza la conjetura**
>
> Los enunciados en 16×16 (un conjunto de 10 a 20 tableros perfectos casi ortogonales, una brecha de solapamiento vacía por debajo, y el muro de 470 como borde visible de esa brecha) son extrapolaciones de la tendencia de las instancias pequeñas a lo largo del parámetro de densidad de restricciones. Son conjetura, no medición: ningún cálculo factible los comprueba directamente a tamaño real. La tabla del paisaje y cada número del lado de la instancia de esta página son exactos; la estructura de la brecha en 16×16 es la parte que conviene sostener como modelo de trabajo.
## Leer el muro
Junte la capa exacta y la capa conjetural, y la meseta comunitaria deja de
parecer un déficit de herramientas. Una heurística que escala el paisaje de
puntuación está extrayendo de la banda entrópica, y la banda es profunda: con
$10^{33}$ configuraciones no correlacionadas aún disponibles en 470, llegar a
los 460 altos es barato en un sentido preciso, y la ingeniería de solvers
lleva años cosechando esa banda. Más allá, la reserva se adelgaza unos
treinta órdenes de magnitud en diez puntos de puntuación, y si la
extrapolación de la brecha de solapamiento se sostiene, no hay nada en medio
por donde trepar: los diez puntos que faltan son la anchura de una región
vacía que separa los últimos tableros entrópicos de un puñado de tableros
perfectos aislados. Es la propiedad de la brecha de solapamiento en su papel
de manual, una barrera topológica que una búsqueda local y estable no puede
cruzar, sea cual sea la calidad de la implementación.
Esta lectura concuerda con lo que medimos en otras partes de la wiki: el
[muro de rigidez](/es/research/why/rigidity-wall/) encuentra los tableros récord
congelados en óptimos locales aislados sin gradiente hacia fuera, exactamente
la sensación que debería dar el borde inferior de una brecha visto desde
abajo. También afina lo que "progresar" tendría que significar. Más velocidad
y mejor orden compran puntos entrópicos, y esos se agotan hacia 470 según la
tabla de arriba; lo que cruce la brecha tendrá que inyectar correlación con
una solución perfecta real en lugar de escalar la función de puntuación. Los
enunciados sobre la instancia que se sostienen a nivel de demostración, por
oposición al modelo de trabajo de esta página, se recogen en el
[barrido de teoremas](/es/research/why/theorem-sweep/).
## Relacionado
- [La cosecha de teoremas: trece leyes estructurales](https://eternity2.dev/es/research/why/theorem-sweep/) — Un solo arco de investigación, trece familias de teoremas estructurales: pureza del anillo, el suelo de paridad en 479, el muro de 470 como frontera de fase, los invariantes de flujo, la ley de área entrópica, y los resultados de imposibilidad que ponen precio a cada atajo clásico. Esta página es el mapa.
- [Calibrado en el pico de dificultad](https://eternity2.dev/es/research/why/phase-transition/) — Eternity II utiliza 22 colores, repartidos entre 17 colores interiores y 5 reservados al marco, y ese número de alrededor de 17 se sitúa cerca del punto donde este tipo de puzzle es más difícil de resolver (la transición es una banda, no un entero único).
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [Diseñado para ser irresoluble: la receta](https://eternity2.dev/es/research/why/design-recipe/) — Eternity II sigue una receta para lograr el puzzle de emparejamiento de aristas más difícil posible: forma compacta, sin piezas simétricas ni duplicadas, paletas separadas, frecuencias planas, una sola solución esperada. La comunidad aplicó ingeniería inversa a cada ingrediente en el año del lanzamiento.
---
# La cosecha de teoremas: trece leyes estructurales
> Un solo arco de investigación, trece familias de teoremas estructurales: pureza del anillo, el suelo de paridad en 479, el muro de 470 como frontera de fase, los invariantes de flujo, la ley de área entrópica, y los resultados de imposibilidad que ponen precio a cada atajo clásico. Esta página es el mapa.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/theorem-sweep/
- Actualizado: 2026-07-22
- Temas: structure
- Fuente: Conway y Lagarias, Tiling with polyominoes and combinatorial group theory: el ancestro de los argumentos por invariantes de frontera para problemas de teselado (JCTA 1990) — https://doi.org/10.1016/0097-3165(90)90057-4
- Fuente: El teorema BEST, que cuenta los circuitos eulerianos de un grafo dirigido: la herramienta correcta (y una trampa documentada) para contar los arreglos del borde — https://en.wikipedia.org/wiki/BEST_theorem
- Fuente: Caminos y circuitos eulerianos: la teoría clásica a la que se reduce el anillo del borde — https://en.wikipedia.org/wiki/Eulerian_path
- Fuente: Johnson, Papadimitriou y Yannakakis, How easy is local search?: el marco PLS detrás del resultado de completitud de la búsqueda local (JCSS 1988) — https://doi.org/10.1016/0022-0000(88)90046-3
- Fuente: Ben-Sasson y Wigderson, Short Proofs Are Narrow: la maquinaria de anchura de resolución detrás de la cota inferior de agotamiento (JACM 2001) — https://doi.org/10.1145/375827.375835
- Fuente: Krzakala, Montanari, Ricci-Tersenghi, Semerjian y Zdeborova, Gibbs states and the set of solutions of random CSPs: el cuadro de la fase condensada en que se apoya el análisis del paisaje de puntuaciones (PNAS 2007) — https://doi.org/10.1073/pnas.0703685104
- Fuente: Gamarnik, The overlap gap property: el concepto de barrera que corresponde a la banda de solapamiento vacía medida (PNAS 2021) — https://doi.org/10.1073/pnas.2108492118
---
Durante un tramo de este proyecto dejé los solvers a un lado y planteé otra
pregunta: no «qué puntuación puedo alcanzar» sino «qué puedo demostrar». El
plan era una cosecha. Llevar el rompecabezas a cada rama de las matemáticas que
plausiblemente tenga algo que decir sobre él (flujos y cortes, combinatoria
extremal, física estadística, álgebra, teoría de CSP, autómatas, complejidad de
las pruebas, complejidad de la búsqueda local) y empujar cada rama hasta que
entregue un teorema o explique con precisión por qué no puede. La cosecha
produjo trece familias de resultados. Esta página es el mapa: unas pocas frases
por familia, con enlaces a los artículos completos donde existen. Tres familias
tienen hoy su página dedicada; las demás recibirán la suya a medida que sus
reproducciones lleguen al repositorio.
Una nota de sabor antes de la lista. Algunos de estos resultados son leyes que
el juego de piezas obedece, otros son teoremas de imposibilidad sobre la
escalera de puntuaciones, y otros son negativos limpios: la prueba de que una
herramienta estándar de otro campo, aplicada correctamente, no certifica nada
aquí. Los negativos se enuncian con el mismo cuidado que los positivos. Saber
que una puerta está cerrada con llave, y por qué, es lo que permite dejar de
pagarle alquiler.
## Las leyes que el juego de piezas obedece
**La pureza del anillo.** Los cinco colores que solo aparecen en las piezas del
borde son más escasos de lo que parecen: sus $5\times24=120$ semiaristas
saturan exactamente los 120 huecos orientados al anillo de las 60 piezas del
borde, sin holgura alguna. En toda solución, cada pieza de borde queda forzada
a apuntar su único color no-marco hacia el interior, y todo el problema del
borde colapsa en encontrar un circuito euleriano en un multigrafo de 5 vértices
y 60 aristas. Artículo completo:
[la pureza del anillo](/es/research/why/ring-purity/).
**El conteo del anillo del marco.** Esta familia pone precio a lo que la ley
del anillo compra. Solo el emparejado de colores reduce la primera colocación
del borde de 59 candidatos a unos 21, y un anillo construido legalmente al azar
sigue rondando $10^{-27}$ en la escala de probabilidades: 53 órdenes de
magnitud mejor que un orden uniforme ($10^{-80}$), y todavía astronómicamente
lejos de la certeza. El marco además le pasa una factura fija al interior: cada
color de marco cierra exactamente 12 juntas del anillo, y las 56 aristas
orientadas hacia dentro llevan una demanda de colores, determinada solo por el
juego de piezas, que toda solución debe reproducir. Seguirá un artículo
dedicado.
**Los invariantes de flujo.** Dele a cada color un peso numérico y a cada pieza
el vector de sus diferencias de peso este-oeste y sur-norte; sumado sobre
cualquier región, esto se telescopa en un flujo de frontera, y un cuarto de
vuelta actúa sobre el vector como la multiplicación por $i$. Descomponer según
los cuatro caracteres del grupo de rotaciones da el retículo completo de
invariantes lineales intrínsecos a las piezas: un censo de colores, una ley de
flujo con valores en los enteros de Gauss, de rango pleno 22 sobre el juego de
piezas real, y una paridad de tablero de ajedrez que acopla la rotación de una
pieza con su celda. La ley de flujo sirve además como certificado incremental
válido que atrapa errores de colocación en el final de partida. Seguirá un
artículo.
**Un juego de piezas cuasi aleatorio.** Cada estadística de segundo orden
auditada (frecuencias de pares de colores, matrices de adyacencia, espectro del
grafo de transición inducido) es indistinguible de un control aleatorio con los
mismos conteos de colores; la única señal deliberada es la conocida ausencia de
piezas duplicadas por rotación. Del lado de la generación, la evidencia
respalda conteos de colores impuestos exactamente sobre un coloreado por lo
demás uniforme y consistente con el emparejado, y un teorema cierra el
círculo: reconstruir la disposición oculta a partir de la bolsa de piezas es
exactamente tan difícil como resolver el rompecabezas. Seguirá un artículo.
## Donde la escalera de puntuaciones se cierra
**El suelo de paridad: 479 es imposible.** En cualquier colocación legal, las
apariciones de un color en un solo lado de una junta van por pares. Un único
desajuste dejaría dos colores impares, así que ningún tablero puntúa 479: la
escalera salta de 478 a 480. El defecto mínimo no nulo es 2, realizado
intercambiando piezas casi gemelas, y alrededor de cualquier solución hay a lo
sumo 76 tableros a un movimiento con ese defecto: los casi aciertos son
demostrablemente escasos, no abundantes. Artículo completo:
[el suelo de paridad de defectos](/es/research/why/parity-defect-floor/).
**El paisaje recocido y el muro de 470.** Trate los tableros no correlacionados
con la solución de fábrica como un conjunto aleatorio y cuéntelos por
puntuación: el conteo es astronómico hasta aproximadamente 465 a 470 y se
derrumba más allá. La meseta comunitaria de veinte años se lee entonces como
una frontera de fase, no como un fracaso de ingeniería. El mismo análisis
tasa la instancia en unos 10 a 20 tableros perfectos mutuamente casi
ortogonales, agujas aisladas rodeadas de una banda de solapamiento vacía; esto
es exacto en las instancias plantadas pequeñas y una conjetura enunciada como
tal a tamaño completo. El mejor tablero comunitario está en 470 en la pista
abierta y en 464 en la pista estricta de cinco pistas fijas; las convenciones y
la tabla completa viven en [la página de récords](/es/research/records/). Artículo
completo: [el muro de 470](/es/research/why/the-470-wall/).
**La ley de área entrópica.** El rompecabezas tiene dos reglas: los bordes
deben casar, y cada pieza se usa una sola vez. El presupuesto entrópico medido
muestra que la primera regla es generosa y que la segunda carga con
esencialmente toda la dificultad, con la unicidad de las piezas derrumbando el
conteo de bloques legales a una escala medible. Esta familia ya tiene su
página: [la entropía y la ley de área](/es/research/why/entropy-area-law/).
## Las maquinarias que demostrablemente no pueden comprimirlo
**La anchura del CSP.** La rejilla desnuda de 16 por 16 tiene anchura de árbol
exactamente 16, lo que suena explotable hasta que entra la restricción global
de diferencia sobre las 256 celdas y vacía todo argumento de tratabilidad por
anchura. El cuadro de la propagación concuerda: la consistencia de arco simple
reduce 48 de los 196 dominios interiores, la consistencia global por
emparejamiento reduce 191. La restricción que duele es la que ninguna
descomposición puede cortar. Seguirá un artículo.
**Las relajaciones convexas.** El lift SDP estándar y una relajación LP
correctamente derivada, construidos de forma exacta sobre pequeñas
subinstancias plantadas con óptimos conocidos, solo certifican el techo trivial
y pasan por alto obstrucciones que un conteo elemental resuelve de inmediato. A
la escala de esta instancia, la convexidad no compra nada. Seguirá un artículo.
**Los certificados algebraicos.** En el Nullstellensatz de grado acotado sobre
GF(2), todo lo que ya hace la propagación por conteo de un buen solver tiene un
certificado de grado 2, y nada más resulta barato: refutar un defecto de
reutilización de pieza en una ventana $K\times K$ exige un grado que crece con
el área, así que no existe certificado algebraico global a escala del tablero.
La alternativa por redes de tensores muere por un cálculo de rango: el tensor
por celda tiene una dimensión de enlace efectiva cercana a 289, sin brecha
espectral contra la cual truncar. Seguirá un artículo.
**Ninguna compresión sin pérdida del frente.** Un programa dinámico exacto
sobre los frentes de barrido solo comprime si dos conjuntos distintos de piezas
usadas pueden fusionarse sin riesgo, y un argumento a la Myhill-Nerode muestra
que nunca pueden, bajo ningún orden de barrido; medido en la instancia real, el
frente exacto de la primera fila se multiplica por unos 8,9 en cada columna.
Las particiones meet-in-the-middle fallan por una razón complementaria: las dos
mitades beben del mismo depósito finito de piezas, así que el óptimo a dos vías
es degenerado y no existe firma de interfaz válida por debajo de la igualdad
literal. Seguirá un artículo.
## El suelo de complejidad
**La búsqueda local es PLS-completa.** Para la familia natural de instancias de
emparejado de bordes que contiene este rompecabezas, el paisaje de mejora es
PLS-completo (demostrado para una paleta generalizada, con el refinamiento de
paleta acotada enunciado como conjetura), y decidir si un tablero mejor
concreto es alcanzable solo con movimientos de mejora es PSPACE-completo. Una
meseta de años es el comportamiento esperado de un paisaje así, no la firma de
un solver mal ajustado. Seguirá un artículo.
**La complejidad de las pruebas de agotamiento.** Cada subárbol de «aquí no
existe compleción» que un backtracker cierra es una refutación por resolución
arbórea, y su coste está acotado inferiormente por la anchura de resolución,
gobernada por el corte alrededor de la región abierta. La restricción de
unicidad de las piezas no aporta ninguna dureza de tipo palomar que la
resolución extendida pueda atacar, porque el emparejado de bordes rarifica el
grafo de compatibilidad piezas-celdas hasta una casi permutación. La
consecuencia es nítida: el aprendizaje de cláusulas y los mejores encodings
compran factores polinomiales, y ningún método de la familia de la resolución
agota superpolinomialmente más rápido que lo que ya ejecutamos. Seguirá un
artículo.
## Lo que la cosecha cambia
El objetivo nunca fue rebajar expectativas. Un tablero perfecto existe por
construcción, y nada en estas trece familias toca ese hecho. Lo que la cosecha
hace es sustituir el folclore por enunciados con precio: el muro tiene un
mecanismo, la meseta tiene una clase de complejidad, y cada atajo ausente tiene
una prueba de imposibilidad en lugar de una vaga reputación. Cada ruta que
sigue abierta viene ahora con la factura que deberá pagar, y ese es un punto de
partida mucho mejor para el próximo intento que un mapa en blanco.
## Relacionado
- [Pureza del anillo: el borde es un subpuzle cerrado, sin holgura](https://eternity2.dev/es/research/why/ring-purity/) — Cinco de los 22 colores nunca tocan las 196 piezas interiores. La lista de piezas obliga a toda solución válida a gastar las 120 semiaristas de marco en el anillo del borde: un subpuzle autónomo con holgura exactamente nula (120 = 120), un circuito euleriano sobre cinco vértices, acoplado al interior solo por 56 aristas orientadas hacia dentro.
- [Por qué 479 es imposible](https://eternity2.dev/es/research/why/parity-defect-floor/) — Un argumento de conteo sobre el juego de piezas oficial prohíbe una puntuación de exactamente 479/480: las semiaristas de cada color vienen en cantidades pares, y una sola unión rota dejaría dos cuentas impares. El suelo bajo lo perfecto es 478, y a lo sumo 76 cuasi-soluciones a un movimiento pueden rodear una solución.
- [El muro de 470: una frontera de fase, no un límite de ingeniería](https://eternity2.dev/es/research/why/the-470-wall/) — La meseta comunitaria en los 460 altos se lee como una frontera de fase entrópica de la instancia, no como un límite de la ingeniería de solvers: el cálculo exacto sobre el juego oficial da una densidad de restricciones cercana a 0,0094, un paisaje recocido que se derrumba por encima de 470 y solo cruza 1 en 480, y un número esperado de 10 a 20 soluciones perfectas casi ortogonales entre sí. Los números del lado de la instancia son exactos; el cuadro de la brecha de solapamiento en 16x16 es una conjetura declarada.
- [La entropía y la ley de área](https://eternity2.dev/es/research/why/entropy-area-law/) — Eternity II tiene dos reglas: los bordes deben coincidir y cada pieza se usa una sola vez. La primera es generosa. Toda la dificultad reside en la segunda.
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [¿Es NP-completa esta instancia y cómo la codifico?](https://eternity2.dev/es/research/why/how-hard-is-this-instance/) — El emparejamiento de aristas es NP-completo como familia, pero eso no dice nada de un tablero 16×16 fijo: una instancia aislada es una constante, no un problema. Lo que sí es cierto es la dureza en el peor caso de la familia y la dureza empírica de esta instancia, y cómo escribir el puzzle para un solucionador SAT, de cobertura exacta o de PLE, con pequeños esbozos detallados. Una medición con tableros plantados pone cifras a la elección de la formulación: un acantilado de resolubilidad que un paradigma de búsqueda golpea y otro cruza, y que se mueve con el número de colores.
- [Récords y solucionadores](https://eternity2.dev/es/research/records/) — Eternity II nunca se ha resuelto, pero casi dos décadas de esfuerzo colectivo han llevado el mejor tablero a 470/480. Quién ostenta qué, cómo lo lograron y por qué algunos tableros «480» anunciados no corresponden al puzzle real.
---
# Qué muro detiene a qué método
> La sección de investigación tiene dos vertientes: los muros estructurales que hacen difícil a Eternity II, y los algoritmos concebidos para franquearlos. Esta página es el puente: cada método enfrentado al muro que realmente ataca, y la puntuación en la que ese muro lo detuvo.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/walls-and-methods/
- Actualizado: 2026-07-21
- Temas: structure
- Fuente: Ansótegui, Béjar, Fernández & Mateu, How Hard is a Commercial Puzzle: the Eternity II Challenge — https://repositori.udl.cat/server/api/core/bitstreams/0b6533fe-54e5-4070-85fe-80f7d35837d8/content
---
Esta es la herramienta para elegir tu nicho. Si quieres decidir dónde invertir
el esfuerzo, lee las columnas de arriba abajo: elige el muro que más te interese,
y la tabla te entrega cada método que lo ha atacado y la puntuación exacta donde se
detuvo. Para un panorama más amplio por familia de métodos, mira el
[mapa de todos los enfoques conocidos](/es/research/build/approaches-map/); para los
ángulos aún abiertos, el tablero de [problemas abiertos](/es/research/open-problems/);
y para los enfoques que, de forma probada, no mueven la puntuación, los
[callejones sin salida](/es/research/build/dead-ends/).
Cada celda del mapa siguiente se apoya en el trabajo publicado de este proyecto.
Los cuatro muros en sí están corroborados por la literatura publicada; los
resultados de los experimentos son trabajo propio de este proyecto, cada uno
documentado en su propia página; no se presentan como verificados externamente.
## En qué se apoya cada muro
No todos los muros son la misma clase de evidencia. Algunos son cálculos exactos
y deterministas depositados en este repositorio; uno está replicado externamente
por varios métodos independientes; varios son mediciones reales tomadas sobre el
único tablero Eternity II y su conjunto de récords. Es una base legítima, pero el
lector merece saber cuál es cuál antes de apoyarse en cualquier línea. La tabla
siguiente lee cada afirmación estructural de esta sección hasta la forma más
fuerte que su evidencia realmente sostiene, el nivel de esa evidencia, si alguna
parte externa la ha reproducido, y la única salvedad a tener presente.
> **Los cuatro niveles**
>
> - **Probado, externo.** Un teorema o un cálculo exacto que una parte externa ha enunciado o replicado, y la página cita a esa parte. - **Probado, interno.** Un cálculo exacto y determinista hecho aquí, con el código y el resultado depositados en `research/topics/` y reproducibles desde el comando de la propia página. - **Medido, instancia única.** Una medición real, tomada sobre el único tablero Eternity II (o un tablero de tipo E2), sin replicación. Cierta, y no un defecto en sí, pero es un solo dato. - **Conjetura.** La propia página presenta la afirmación como no probada en general. Un muro no se rebaja por haberse medido sobre una instancia única. Solo se rebaja allí donde un nivel inferior se presenta como superior, y ninguno aquí lo hace.
| Muro / afirmación | Forma más fuerte sostenida | Nivel | Replicación externa | La única salvedad |
| --- | --- | --- | --- | --- |
| [Pico de dificultad](/es/research/why/phase-transition/) | 17,14 colores interiores se derivan del criterio de una solución esperada; 17 queda cerca del pico de dificultad de búsqueda para el emparejamiento de bordes enmarcado | Probado, externo | Sí: la derivación de Owen de 1947; Ansótegui, Béjar, Fernández & Mateu confirman el pico | «Una solución esperada» es un promedio de primer momento que supone colores de borde independientes; localiza el pico, no cuenta las soluciones |
| [Teoría compleja / el embudo](/es/research/why/complex-theory/) | Un estimador de primer momento del ancho de árbol y del número de soluciones, correcto dentro de un factor de dos dondequiera que pudo comprobarse | Conjetura (distintivo de la página), sobre replicación externa | Sí: el modelo de Owen; el porte a C de McGavin y su resolución 10×10, dentro de la predicción | Es un promedio, ciego a si los parciales contados son realmente distintos; una herramienta para ordenar barridos, nunca un conteo exacto ni una cota |
| [Sin movimientos forzados](/es/research/why/no-forced-moves/) | Un conteo exhaustivo exacto sobre el conjunto interior oficial: ninguna pieza interior queda nunca forzada a un único compañero derecho (73 a 137 compañeros cada una) | Probado, interno | Sin replicación externa; el conteo es propio del proyecto, depositado y reproducible | Cuenta compatibilidad por pares sobre el conjunto completo, no candidatos dentro de un tablero parcial vivo; una propiedad de las piezas, no una prueba de que la búsqueda nunca se estrecha |
| [Patrones prohibidos](/es/research/why/forbidden-patterns/) | Conteos exhaustivos exactos: el 38,96 % de los pares, el 83,26 % de los L-triominós, el 99,72 % de los cuadrados 2×2 son inviables sobre piezas interiores distintas | Probado, interno | Los conteos 2×2 son el resultado exacto depositado del proyecto; los 20 pares-esquina vacíos son una observación comunitaria citada de 2008 | La lectura «el conteo de parches prohibidos sigue la distancia a una solución» es una señal heurística, no una distancia monótona probada |
| [Ley de área de la entropía](/es/research/why/entropy-area-law/) | Los conteos de bloques A(n)/B(n) son ahora exactos en el repositorio hasta n=3 (B(2)=4 059 952 cruza con la tabla de subrejillas), dando un exponente en repositorio α≈0,044; el límite de entropía cerca de 0,67 y el punto de colapso son extrapolaciones | Probado, interno (los conteos de bloques) + medido (el ajuste) | Parcial: el lema de Fekete y la entropía de Shannon son los teoremas externos que hacen bien definido el límite; el ajuste de α y la escala de colapso son propios del proyecto | El teorema garantiza que existe un límite positivo; no fija su valor. El exponente se ajusta sobre n≤3 y su valor por bloque aún crece, así que el punto de colapso de parches grandes es una extrapolación más allá de los anchos contados |
| [Rigidez](/es/research/why/rigidity-wall/) | En los tableros récord públicos, ningún reordenamiento de las piezas propias de un tablero dentro de un halo de hasta cuatro celdas cierra un desajuste (SAT: UNSAT), ahora depositado | Probado, interno para el halo SAT; la tabla MIP más profunda está probada para las regiones cerradas pero portada desde un artículo externo al sitio | Sí, el muro mejor replicado: las pruebas de congelación y residuo SAT de Millilaw reproducidas aquí con un control positivo; el núcleo congelado del recocido GPU de benj39100 lo alcanza por un tercer método | La evidencia depositada del sitio es el halo SAT hasta radio 4 en cinco tableros (unas pocas instancias de radio 4 exceden el tiempo, anotadas abiertas). La tabla MIP y la cota tablero completo ≤476 provienen del artículo externo, y el enunciado «todos los tableros» es una conjetura |
| [Sigma-ciclos](/es/research/why/sigma-cycles/) | Sobre **cada** par ordenado del mismo conjunto de piezas de los tableros incluidos (246 pares, 1154 lazos grandes), **cada** prefijo propio de cada lazo grande puntúa estrictamente menos que su punto de partida, en las 54 238 aplicaciones parciales | Probado, interno (un enunciado de población sobre el conjunto incluido) | Sin replicación externa; calculado aquí contra el 469 de McGavin y los tableros récord y de proyecto incluidos | El conteo es exacto sobre los tableros entregados; la propiedad «todo subciclo es peor» aún no está probada para todo tablero posible. Una fuerte observación de población, no un teorema general |
| [Geometría de los desajustes](/es/research/why/mismatch-geometry/) | En los tableros récord y de proyecto, los desajustes residuales se agrupan en una banda de filas que se invierte con el sentido de construcción; un objetivo de conteo de huecos deposita los restos ahí | Medido, instancia única | Parcial: la inversión según el sentido es la lectura del proyecto; el tablero de siete huecos de Verhaard y el residuo en banda alta de Zamofing se citan como observaciones del mismo sentido, ahora verificables en el archivo extendido | Un patrón sobre un puñado de tableros con una historia mecanicista, no una prueba |
| [Robo de pieza](/es/research/why/piece-theft/) | Un conteo exacto de las demandas (norte, oeste) sobre el conjunto interior: la mayoría tiene de uno a tres proveedores, y un número preciso tiene exactamente uno | Probado, interno (los conteos); medido (el mecanismo «dónde mueren los solvers») | Sin replicación externa; Régin 1994 se cita como la teoría all-different que nombra el mecanismo | Los conteos de proveedores escasos son exactos; «aquí es donde mueren los solvers reales» es un mecanismo ilustrado sobre la instancia, no una tasa de fallo medida entre solvers |
| [Geometría de las pistas](/es/research/why/hint-geometry/) | En un puzzle 16×16 de tipo E2, pistas dispersas lo resuelven en minutos donde filas contiguas apiladas no, porque el trabajo vive en la segunda mitad del llenado | Medido, instancia única (un tablero de tipo E2, no el puzzle oficial) | Sí, atribuido con claridad: la resolución a 18 pistas de McGavin y su árbol de 41 mil millones de nodos; las estadísticas de profundidad de Joe | No es el puzzle oficial, cuyas cinco pistas fijas difieren. Las cifras de profundidad son la muestra de un solo backtracker |
| [Equilibrio del borde / NS-1](/es/research/why/border-balance/) | Una condición necesaria exacta; las cuatro soluciones completas conocidas la cumplen; un déficit positivo certifica la inviabilidad. La proporción interior-interior de los errores restantes es ahora exacta: **86,9 %** en los nueve tableros incluidos de clase 469, ninguno borde-borde | Probado, externo (la condición), probado, interno (el reparto de errores) | Sí para la condición, citada a enunciados comunitarios de 2007–2022; el reparto de errores es el reconteo depositado del proyecto | La condición es necesaria, nunca suficiente: un déficit nulo no prueba nada, y el invariante es ciego a la mayoría interior-interior de los errores restantes. El rendimiento de poda es una medición sobre instancia única, aún no un banco depositado |
| [Geografía de los colores raros](/es/research/why/rare-color-geography/) | Un conteo exacto sobre el conjunto oficial: los cinco colores de borde nunca aparecen en un borde interior | Probado, interno | Sin replicación externa del conteo; la intención de diseño 17+5 se cita a Owen | Presentado con acierto como estructural (borde gris, pools de color separados), no una treta de escasez; la etiqueta «raro» es un artefacto del menor número de bordes de marco |
| [Receta de diseño](/es/research/why/design-recipe/) | La comunidad reconstruyó una receta coherente del puzzle más difícil, ingrediente por ingrediente, cada uno con fuente en un mensaje del año de lanzamiento | Conjetura (distintivo de la página), cada ingrediente con fuente externa | Sí, densamente: las derivaciones y mediciones de Owen, el censo del espacio de diseño, la cadena de procedencia hasta Selby y Riordan | Una reconstrucción de la intención de diseño, no un enunciado que los diseñadores publicaran; la página lo marca como conjeturado |
| [Marco de complejidad](/es/research/why/how-hard-is-this-instance/) | El emparejamiento de bordes es NP-completo como familia; un tablero fijo único es una constante, no un problema; la dificultad de E2 es empírica sobre un espacio ~10^557 | Probado, externo | Sí: Demaine & Demaine 2007 para la NP-completitud; Ansótegui et al. para el caso empírico | La distinción de categoría sostiene el razonamiento: la NP-completitud limita lo que los solvers generales pueden prometer, no dice nada de este tablero |
| [Poda contra velocidad](/es/research/why/prune-vs-speed/) | El argumento de composición es aritmética exacta; en E2, una poda legal cuesta a menudo más que el subárbol que elimina | Probado (la aritmética), medido (el veredicto «la poda no compensa») | Parcial: el principio es autónomo; el veredicto comunitario se cita a McGavin y 95A31, ahora verificables en el archivo extendido | Las cifras del árbol de demostración son ilustrativas, no una medición de un solver real, y la página lo dice |
Tres cambios desde que se trazó este mapa por primera vez merecen destacarse,
porque suben afirmaciones de nivel. Los sigma-ciclos eran una observación sobre
tres pares; ahora son un enunciado exacto sobre cada par del mismo conjunto de
piezas de los tableros incluidos, 54 238 aplicaciones parciales sin una sola
excepción. El reparto de errores de borde es ahora un reconteo exacto (86,9 %
interior-interior) en lugar de una cifra externa al sitio. Y los conteos de
bloques de la ley de área se calculan ahora en el repositorio y se reproducen
desde el comando de la propia página, con el exponente ajustado sobre el rango
contado exactamente. Además, las cuatro citas comunitarias que antes quedaban
más allá de la instantánea del archivo validan ahora contra el export extendido,
de modo que los pasajes de corroboración de la rigidez, la geometría de los
desajustes y la poda contra velocidad se apoyan en fuentes que un lector puede
comprobar.
La lectura de conjunto: solo la rigidez lleva tres métodos independientes (SAT,
MIP, recocido) que llegan a un mismo veredicto. Los demás muros son cálculos
exactos propios del proyecto o mediciones sobre instancia única, sobre el único
tablero que importa. Lee «corroborado por la literatura» como que la transición
de fase y el gradiente ausente se han reproducido en otra parte, no cada muro.
## Los cuatro muros, en una línea cada uno
Cada uno de ellos es una versión del mismo enunciado: no hay nada local que podar.
- **[Sin movimientos forzados](/es/research/why/no-forced-moves/)**. Cada celda interior
conserva de 73 a 137 piezas legales, de modo que el factor de ramificación
nunca se colapsa.
- **[El pico de dificultad](/es/research/why/phase-transition/)**. Con ≈17 colores
interiores el puzzle se sitúa en la transición de fase: alrededor de una
solución esperada, el peor lugar donde buscar.
- **[La ley de área](/es/research/why/entropy-area-law/)**. Los tableros parciales
genuinamente distintos se colapsan a medida que crece el área rellenada, pero ninguna
puntuación local puede percibir ese hecho global.
- **[La rigidez](/es/research/why/rigidity-wall/)**. Los récords están localmente
congelados; el paso hacia un tablero mejor es un único intercambio gigante e
indivisible, sin gradiente que seguir.
## El mapa
Las columnas son los muros; las filas, los métodos, con la mejor puntuación
primero. Una marca rellena (●) significa que el método trabaja fundamentalmente
contra ese muro. El techo comunitario en este puzzle es 470; la solución completa
es 480.
| Método | Mejor | [Movimientos forzados](/es/research/why/no-forced-moves/) | [Pico de dificultad](/es/research/why/phase-transition/) | [Ley de área](/es/research/why/entropy-area-law/) | [Rigidez](/es/research/why/rigidity-wall/) | Nueva cuenca |
| --- | --- | :-: | :-: | :-: | :-: | --- |
| [PALIMPSEST](/es/research/lab/experiments/raphael-anjou/learning/palimpsest/) · desde el corpus | 463/480 | | | | ● | no |
| [PRIOR](/es/research/lab/experiments/raphael-anjou/learning/prior/) · from scratch | 460/480 | | ● | | ● | no |
| [KEYRING](/es/research/lab/experiments/raphael-anjou/learning/keyring/) · from scratch | 460/480 | | | | ● | nueva familia |
| [REPLAY](/es/research/lab/experiments/raphael-anjou/learning/replay/) · decodificar y reproducir | 460/480 | | | | ● | no |
| [GAUNTLET](/es/research/lab/experiments/raphael-anjou/pipelines/gauntlet/) · from scratch | 458/480 | | | | ● | nueva familia |
| [CLOISTER](/es/research/lab/experiments/raphael-anjou/pipelines/cloister/) · anclar y restringir | 453/480 | | | ● | ● | no |
| [MIDDEN](/es/research/lab/experiments/raphael-anjou/pipelines/midden/) · anclar y restringir | 452/480 | | | ● | ● | no |
| [LADDER](/es/research/lab/experiments/raphael-anjou/pipelines/ladder/) · concentrar el esfuerzo | 451/480 | ● | ● | | | nueva familia |
| [LODESTONE](/es/research/lab/experiments/raphael-anjou/learning/lodestone/) · from scratch | 451/480 | ● | | | | no |
| [MOSAIC](/es/research/lab/experiments/raphael-anjou/pipelines/mosaic/) · resolver un fragmento exactamente | 448/480 | ● | ● | | | no |
| [BANDSAW](/es/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/) · resolver un fragmento exactamente | 437/480 | ● | ● | | | no |
| [STAGED](/es/research/lab/experiments/raphael-anjou/pipelines/staged/) · from scratch | 436/480 | ● | | ● | | no |
### Cómo leerlo
Casi todos los métodos terminan contra la rigidez, el muro que dice que los
grandes tableros son islas aisladas. Los métodos construidos from scratch y a
partir del corpus (PRIOR, KEYRING, PALIMPSEST, GAUNTLET) intentan alcanzar una
isla nueva pilotando la construcción con una señal aprendida; se estabilizan en
458–463 y un par de ellos sí llegan a familias genuinamente nuevas, pero ninguno
cruza hasta el techo. Los métodos de concentración y exactos (LADDER, BANDSAW)
atacan en cambio la búsqueda misma (el alto factor de ramificación y el pico
inexplorable) y lo pagan en la fase final. Los métodos de anclaje (CLOISTER,
MIDDEN) localizan el daño pero chocan con el muro de la ley de área en el
interior. Ningún muro por sí solo cuenta toda la historia, y ningún método
atraviesa los cuatro.
## Dónde se detuvo cada uno, y por qué
El techo nunca es arbitrario. Para cada método, su propio informe registra la
razón exacta por la que la puntuación dejó de subir, citada aquí en una línea.
- **[PALIMPSEST](/es/research/lab/experiments/raphael-anjou/learning/palimpsest/)** (463/480). Alcanzó
463, lo mejor del proyecto, leyendo el corpus para detectar qué decisiones
compartidas son trampas y pilotando un barrido de 15 cuencas para rodearlas.
Forzar directamente a la búsqueda a evitar las trampas empeoró los tableros: el
valor estaba en dónde mirar, no en una regla estricta.
- **[PRIOR](/es/research/lab/experiments/raphael-anjou/learning/prior/)** (460/480). Se estanca en 460:
el prior de posición aprendido lleva rápido una construcción from scratch a la
clase de los 460, pero la señal del corpus por sí sola no basta para salir de
ella.
- **[KEYRING](/es/research/lab/experiments/raphael-anjou/learning/keyring/)** (460/480). Tres señales
aprendidas votando (posición, adyacencia, parche 2×2) alcanzaron 460 en una
disposición de esquinas que ningún tablero había resuelto antes, una nueva
familia, pero la señal de parche es marginal y el pulido sigue topando en 460.
- **[REPLAY](/es/research/lab/experiments/raphael-anjou/learning/replay/)** (460/480). Reproduce
exactamente los tableros estrictos-460 de la comunidad y revela el movimiento que
la búsqueda ordinaria pasa por alto: 4 a 5 celdas que aceptan dos desajustes a la
vez, inalcanzables para una búsqueda que permite como mucho uno.
- **[GAUNTLET](/es/research/lab/experiments/raphael-anjou/pipelines/gauntlet/)** (458/480). Lanzar el
beam en nueve direcciones de recorrido abrió una familia 458 completamente nueva
(el orden de recorrido es un eje de diversidad más fuerte que la semilla
aleatoria), pero una segunda ronda topó en 457 sin ningún 461: la nueva familia
se satura como las demás.
- **[CLOISTER](/es/research/lab/experiments/raphael-anjou/pipelines/cloister/)** (453/480). Como
solucionador interior autónomo confirma un bonus real de compatibilidad con el
borde, pero ese bonus no puede añadirse a posteriori (la misma rigidez que el
tablero completo), de modo que se asienta en los 450 bajos.
- **[MIDDEN](/es/research/lab/experiments/raphael-anjou/pipelines/midden/)** (452/480). Elegir dónde (no
cuándo) puede romperse el tablero extiende la serie perfecta de 153 a 167–174
celdas, pero la geometría dispersa sigue fallando en la fase final: nada absorbe
el último daño.
- **[LADDER](/es/research/lab/experiments/raphael-anjou/pipelines/ladder/)** (451/480). Inunda de sondas
baratas y promociona la más profunda, alcanzando un tablero estricto-451 sin
récord que copiar, el primer escape de la banda universal 444–450, pero el
suministro de aperturas perfectas se agota y los peldaños convergen todos a un
único techo.
- **[LODESTONE](/es/research/lab/experiments/raphael-anjou/learning/lodestone/)** (451/480). Un prior de
demanda-escasa usado solo como desempate eleva la mediana from scratch en dos
(449→451) y estrecha la varianza, pero cualquier peso mayor lo colapsa: la escasez
es una señal real pero débil, y nunca toca el techo de la cuenca.
- **[MOSAIC](/es/research/lab/experiments/raphael-anjou/pipelines/mosaic/)** (448/480). Compone
soluciones exactas de bloques 4×4 con costuras flexibles, alcanzando 448 from
scratch, pero el déficit recae casi por completo en los tres últimos bloques de
esquina, donde el conjunto de piezas escasea: el mismo robo de piezas, ahora un
único punto brillante.
- **[BANDSAW](/es/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/)** (437/480). Resuelve
una banda de fase final hasta la optimalidad probada, y al hacerlo mide el muro de
la exactitud: el árbol de búsqueda crece alrededor de un factor veinte por cada
desajuste adicional permitido, en ambos lados, de modo que encontrarse en el medio
deja de ser rentable a tamaño completo.
- **[STAGED](/es/research/lab/experiments/raphael-anjou/pipelines/staged/)** (436/480). Construye el
tablero entero sin marco preestablecido y con un borde emergente, alcanzando 436,
muy por debajo de los récords. Esa brecha es el hallazgo: mide exactamente cuánto
vale el habitual anclaje marco-primero.
## La forma de la brecha
Recorra la tabla de arriba abajo y la lección de todo el proyecto salta a la
vista: los métodos que mueven la puntuación cambian la forma de la búsqueda, ya sea
un orden de recorrido, un prior aprendido o una región confinada, nunca su
velocidad bruta. Y todos ellos se detienen ante un muro que es global, no local.
Las diez aristas de 470 a 480 no son un problema de acabado; están al otro lado de
los cuatro muros a la vez.
Una campaña aparte de 2026 a cargo de William Millilaw llegó a la misma conclusión
por el lado de la diversidad. Barriendo la lista completa de métodos, constató que
casi todo (búsqueda local adaptativa from scratch, colocación en serpentina, la
cima de la distribución de un generador entrenado) redescubre una y otra vez el
mismo puñado de cuencas, y que solo el parallel tempering producía de forma fiable
cuencas genuinamente nuevas, tableros muy alejados del conjunto conocido. Incluso
ese se estanca pronto. Su lectura es la que esta tabla no deja de formular: el
cuello de botella no es la puntuación que un método alcanza sino el número de
cuencas distintas que es capaz de encontrar, y ningún método del arsenal estándar
encuentra suficientes.
> **Note**
>
> Cada línea de saturación se destila del cuaderno de laboratorio del proyecto (una entrada por experimento). Los cuatro muros están corroborados por la literatura publicada: la transición de fase a 17 colores por Ansótegui, Béjar, Fernández & Mateu, "How Hard is a Commercial Puzzle: the Eternity II Challenge"; el gradiente ausente y las cuencas profundas por la literatura de búsqueda local sobre Eternity II.
## Relacionado
- [Por qué un ordenador más rápido no ayuda](https://eternity2.dev/es/research/why/prune-vs-speed/) — La idea más importante de la búsqueda combinatoria difícil: reducir el espacio que se explora vence, por un margen exponencial, a explorarlo más rápido. Eternity II está diseñado para que apenas puedas reducirlo.
- [El muro de rigidez](https://eternity2.dev/es/research/why/rigidity-wall/) — Cada tablero récord que tenemos está congelado en su sitio. No se puede progresar a base de pequeños retoques desde un tablero excelente hacia uno perfecto, y podemos demostrarlo.
- [Experimentos](https://eternity2.dev/es/research/lab/experiments/) — Los experimentos de búsqueda con nombre del laboratorio, una sección por investigador. Cada uno es un run real contra Eternity II con su idea, su mejor tablero y las preguntas que dejó abiertas. El cuaderno de Raphaël Anjou está aquí completo; el cuaderno queda abierto a cualquier otra persona.
- [Sin jugadas forzadas](https://eternity2.dev/es/research/why/no-forced-moves/) — La manera habitual de resolver un puzzle lógico es encontrar un lugar donde solo encaja una pieza, colocarla y repetir. Aquí ese recurso no existe: cada pieza interior tiene entre 73 y 137 vecinas posibles, y ninguna queda jamás fijada a una sola opción.
- [Un mapa de todos los enfoques conocidos](https://eternity2.dev/es/research/build/approaches-map/) — La síntesis que la comunidad reclama sin encontrarla nunca: cada familia de ataque probada en Eternity II, lo que cada una alcanzó realmente, dónde se estrella, y un enlace a la página de fondo. Una misma idea rectora las atraviesa todas.
- [Callejones sin salida](https://eternity2.dev/es/research/build/dead-ends/) — Enfoques que probamos que parecen prometedores y no mueven la aguja en Eternity II, documentados con lo que encontramos para que inviertas tu tiempo en otra parte.
- [Problemas abiertos](https://eternity2.dev/es/research/open-problems/) — La frontera abierta de Eternity II reunida en un solo lugar: cada ángulo que todavía merece un intento, el muro que ataca, qué se ha probado y dónde se detuvo, y si es un objetivo accesible para principiantes o uno difícil y bien cartografiado.
---
# Un conjunto de piezas extremo en cada eje medido
> Mida las 256 piezas oficiales sin ningún solucionador a la vista y cada puerta estructural está cerrada: ninguna pieza simétrica por rotación, 5 parejas gemelas entre 32 640 emparejamientos, un tope de 307 sobre 480 si nada gira, presupuestos de color que se emparejan a exactamente 480 sin holgura, y una paleta 17+5 situada en el punto de una-solución-esperada.
- Página canónica (con figuras y demos interactivas): https://eternity2.dev/es/research/why/why-e2-is-hard/
- Actualizado: 2026-07-22
- Temas: structure
- Reproducir: `cd research/topics/adversarial-piece-set/compute && cargo run --release > ../results/invariants.json`
- Fuente: El conjunto de piezas adverso: artículo, código fuente y resultados (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/adversarial-piece-set
- Fuente: Brendan Owen, Design the hardest puzzle: la receta y la derivación del 17,14 (msg 1947, agosto de 2007) — https://groups.io/g/eternity2/message/1947
- Fuente: El censo del espacio de diseño de piezas: las formas simétricas existen en ese espacio y el conjunto real las evita todas (msg 8025, septiembre de 2010) — https://groups.io/g/eternity2/message/8025
- Fuente: Las páginas Eternity de Selby y Riordan, el sitio de los propios diseñadores — https://www.archduke.org/eternity/
---
Deje a un lado los solucionadores y mida el objeto en sí. El conjunto oficial
son 256 piezas cuadradas, con cuatro bordes de color cada una. Si esas piezas
se hubieran sorteado sin cuidado, algo de holgura estructural sobreviviría en
alguna parte: una pieza repetida, una pieza simétrica, un color en exceso, un
sesgo de orientación que no cuesta nada, una camarilla de piezas que se
prefieren entre sí. De esa holgura es de lo que se alimentan los
solucionadores. Esta página comprueba cada una de esas puertas directamente
sobre el conjunto de piezas solo, y todas están cerradas, con exactitud, no de
forma aproximada.
Cinco de las seis mediciones de abajo están versionadas como un único tema
reproducible. Cada una se recalcula desde la instancia publicada en menos de
un segundo, y el binario comprueba por sí mismo sus valores esperados:
reproducir los números y verificarlos son el mismo gesto.
## Las cinco mediciones versionadas
| Eje | Medición | El extremo en el que se sitúa |
| --- | --- | --- |
| Simetría de rotación | 256 de 256 piezas tienen sus cuatro rotaciones distintas | 1 024 piezas-rotación, nada que cocientar |
| Gemelas | 251 multiconjuntos de colores distintos; 5 parejas gemelas y 114 casi gemelas entre 32 640 emparejamientos | ningún duplicado, coincidencia al nivel del 0,4 % |
| Tope con orientación fija | como mucho 307 de 480 uniones pueden casar si ninguna pieza gira | la rotación es estructuralmente necesaria |
| Presupuesto de color | los 22 colores tienen un número par de lados; la capacidad de emparejamiento suma 480 | exactamente suficiente, holgura cero |
| Paleta dividida | 17 colores interiores, 5 colores de uniones del borde | 17 es el ajuste de una-solución-esperada |
### Ninguna simetría de rotación en ninguna parte
Una pieza que se viera igual tras un cuarto o medio giro colapsaría
orientaciones y encogería el espacio de decisión, y la reducción estándar,
buscar una forma canónica por órbita, cobraría el descuento. Medido: cada una
de las 256 piezas tiene una órbita de rotación completa de tamaño 4, así que
el puzle tiene de verdad 1 024 piezas-rotación distintas y la búsqueda por
formas canónicas no gana absolutamente nada. El censo comunitario del espacio
de diseño muestra que esto es una elección, no un accidente: con esta paleta,
el espacio de piezas posibles contiene formas que se repiten bajo rotación, y
el conjunto real las evita todas
([msg 8025](https://groups.io/g/eternity2/message/8025)). La
[receta de diseño](/es/research/why/design-recipe/) lleva el lado intencional de
esa historia, incluida la medición de Brendan Owen de que las piezas
simétricas se colocarían de forma tan desigual que devolverían al solucionador
justo la señal de ordenación por dificultad que los diseñadores estaban
eliminando.
### Cinco gemelas entre 32 640 emparejamientos
Olvide el orden de los bordes y pregunte qué piezas llevan el mismo
presupuesto de cuatro colores. Las 256 piezas producen 251 multiconjuntos
distintos: exactamente 5 parejas coinciden, las piezas (2,3), (5,14), (7,51),
(109,110) y (171,181) en la numeración de investigación, y en cada pareja los
colores compartidos ocupan un orden cíclico diferente, de modo que ninguna
pieza se repite, ni siquiera salvo rotación. Al relajar la pregunta hacia las
casi gemelas, parejas que comparten 3 de sus 4 bordes en la misma posición en
la orientación almacenada, se añaden 114 parejas en 79 grupos. Frente a los
32 640 pares no ordenados que ofrece el conjunto, incluso esa coincidencia
relajada queda en una fracción de un uno por ciento. La puerta que esto cierra
es la duplicación gratuita: una pareja de duplicados de verdad permitiría
reescribir cualquier solución intercambiando las dos piezas, y no hay ninguna.
### La rotación es estructuralmente necesaria
Congele cada pieza en su orientación publicada y pregunte cuántas de las 480
uniones podrían casar. Color por color, las uniones horizontales usan como
mucho la menor de las ofertas orientadas al este y al oeste, y las verticales
la menor de las ofertas norte y sur. La suma tiene un tope de **307 sobre
480**. Es una cota de conteo, no un resultado de búsqueda: ninguna disposición
de piezas sin girar, en ningún lugar del tablero, puede superarla. Una cadena
que fija las orientaciones pronto concede por tanto al menos 173 uniones antes
de empezar a buscar, y 307 queda muy por debajo de todos los tableros altos de
la [página de récords](/es/research/records/). Los dos números cuentan aquí bordes
casados entre piezas adyacentes, excluido el perímetro exterior, la convención
usada en todo este sitio.
### Un presupuesto de color con holgura cero
Cuente los lados de pieza por color. Cada uno de los 22 colores no grises
tiene un total par, y las capacidades de emparejamiento, la mitad del número
de lados por color, suman exactamente 480, el número geométrico de uniones del
tablero. La oferta es exactamente suficiente para un tablero perfecto: ningún
color falta, lo que certificaría imposible la solución construida, y ningún
color sobra, lo que dejaría holgura que los tableros parciales pudieran
gastar. Holgura cero significa también palanca cero. Ningún argumento de
conteo sobre la sola oferta de colores puede podar nada, así que la dificultad
vive por entero en qué piezas llevan qué colores, no en cuánto hay de cada
color. Lo más afilado que produce el razonamiento de oferta es el invariante
de [equilibrio del borde](/es/research/why/border-balance/), y esa condición es
necesaria, nunca suficiente.
### La paleta dividida, y qué se ajustó
Los 22 colores se dividen en 17 colores interiores y 5 que solo aparecen en
las uniones entre piezas del borde. La separación en sí es automática: con un
perímetro gris macizo, los bordes de color de una pieza del borde solo se
encuentran con otros bordes del borde o con el interior, así que los dos
depósitos nunca se mezclan, como explica la página de
[geografía de los colores raros](/es/research/why/rare-color-geography/). Lo que
se eligió son los recuentos. La derivación de Owen del año del lanzamiento
recupera 17,14 colores interiores a partir de la exigencia de aproximadamente
una solución esperada
([msg 1947](https://groups.io/g/eternity2/message/1947)), lo más escasa que
puede ser una solución sin dejar de existir, y la página del
[pico de dificultad](/es/research/why/phase-transition/) mide que ese es el peor
lugar posible para una búsqueda. La receta reconstruida completa, ingrediente
a ingrediente, está en la página de la
[receta de diseño](/es/research/why/design-recipe/).
## El sexto eje, descrito sin sus números
Una medición más pertenece a la tesis pero aún no forma parte del tema
versionado. Construya el grafo cuyos nodos son las 256 piezas, ponderado por
cuántas adyacencias por rotación admite cada pareja, y lea su espectro. El
grafo se separa limpiamente en exactamente dos bloques, las 60 piezas del
marco y las 196 interiores, y más allá de ese corte no muestra estructura de
comunidad a ninguna escala: ni camarillas de piezas mutuamente compatibles, ni
un subpuzle barato que recortar y resolver primero. El agrupamiento es de
escala única, y la única frontera de grupo visible es la línea
marco-interior que cualquier solucionador ya conoce. Los números espectrales
tras esta descripción quedan aplazados hasta que su cálculo se versione junto
a los otros cinco; lea por ahora este eje como una descripción, y los cinco
anteriores como exactos.
## Lo que estos extremos descartan
Cada eje cierra una puerta estándar.
- **Reducción por simetría.** Nada que cocientar: las 1 024 piezas-rotación
son todas distintas.
- **Trucos de duplicados.** Ninguna duplicación gratuita de soluciones: 5
casi coincidencias entre 32 640 emparejamientos, ninguna un duplicado real.
- **Atajos de orientación.** Fijar las rotaciones pronto concede 173 de 480
uniones por un argumento de conteo, antes de cualquier búsqueda.
- **Argumentos de oferta.** Presupuestos pares y exactamente suficientes:
contar colores no poda nada.
- **Subcomunidades baratas.** No existe nada más blando que el corte
marco-interior desde el que empezar.
Esta página es la compañera de medición de dos vecinas. La
[receta de diseño](/es/research/why/design-recipe/) reconstruye, desde el archivo
del año del lanzamiento, por qué el conjunto se construyó así; el
[barrido de teoremas](/es/research/why/theorem-sweep/) reúne las leyes demostradas
sobre el mismo objeto. Y los extremos de aquí son la planta baja de los muros
de la sección: [sin movimientos forzados](/es/research/why/no-forced-moves/) es la
misma llanura sentida celda a celda durante una construcción, y los
[ciclos sigma](/es/research/why/sigma-cycles/) son en lo que se convierte la
ausencia de intercambios pequeños entre tableros altos terminados. Para saber
qué método muere contra qué muro, el
[mapa de muros y métodos](/es/research/why/walls-and-methods/) hace de índice.
## Reproducción y convenciones
El directorio del tema contiene un binario de Rust autónomo que carga la
instancia oficial incluida (256 piezas, sin pistas) y recalcula cada número de
arriba: el censo de órbitas de rotación, los recuentos de gemelas y casi
gemelas, el tope de emparejamiento con orientación fija, y la paridad y
capacidad de emparejamiento por color. La ejecución es determinista, termina
en mucho menos de un segundo, imprime un único documento JSON y sale con
código distinto de cero si falla algún valor esperado; el archivo de
resultados versionado es idéntico byte a byte entre ejecuciones. Los
identificadores de pieza de la lista de gemelas siguen la numeración de
investigación del conjunto. Los dos números de tipo puntuación de esta página,
307 y 480, cuentan bordes casados entre piezas adyacentes con el perímetro
exterior excluido, la misma convención que la página de
[récords](/es/research/records/); nada aquí puntúa un tablero candidato, y nada en
esta página es una reclamación de récord.
## Relacionado
- [Diseñado para ser irresoluble: la receta](https://eternity2.dev/es/research/why/design-recipe/) — Eternity II sigue una receta para lograr el puzzle de emparejamiento de aristas más difícil posible: forma compacta, sin piezas simétricas ni duplicadas, paletas separadas, frecuencias planas, una sola solución esperada. La comunidad aplicó ingeniería inversa a cada ingrediente en el año del lanzamiento.
- [La cosecha de teoremas: trece leyes estructurales](https://eternity2.dev/es/research/why/theorem-sweep/) — Un solo arco de investigación, trece familias de teoremas estructurales: pureza del anillo, el suelo de paridad en 479, el muro de 470 como frontera de fase, los invariantes de flujo, la ley de área entrópica, y los resultados de imposibilidad que ponen precio a cada atajo clásico. Esta página es el mapa.
- [Qué muro detiene a qué método](https://eternity2.dev/es/research/why/walls-and-methods/) — La sección de investigación tiene dos vertientes: los muros estructurales que hacen difícil a Eternity II, y los algoritmos concebidos para franquearlos. Esta página es el puente: cada método enfrentado al muro que realmente ataca, y la puntuación en la que ese muro lo detuvo.
- [Calibrado en el pico de dificultad](https://eternity2.dev/es/research/why/phase-transition/) — Eternity II utiliza 22 colores, repartidos entre 17 colores interiores y 5 reservados al marco, y ese número de alrededor de 17 se sitúa cerca del punto donde este tipo de puzzle es más difícil de resolver (la transición es una banda, no un entero único).
- [Los colores raros viven en el marco](https://eternity2.dev/es/research/why/rare-color-geography/) — Cinco de los 22 colores de Eternity II aparecen solo a lo largo del anillo de borde, cada uno en exactamente 24 aristas, nunca una sola vez en el interior. Una separación estructural que moldea la forma en que cada solucionador trata el marco.
- [Sin jugadas forzadas](https://eternity2.dev/es/research/why/no-forced-moves/) — La manera habitual de resolver un puzzle lógico es encontrar un lugar donde solo encaja una pieza, colocarla y repetir. Aquí ese recurso no existe: cada pieza interior tiene entre 73 y 137 vecinas posibles, y ninguna queda jamás fijada a una sola opción.
- [Por qué el basin-hopping parece imposible](https://eternity2.dev/es/research/why/sigma-cycles/) — Si no puedes mejorar un tablero excelente puliéndolo, quizá puedas saltar a otro tablero excelente. En cada par de récords probado, no puedes, y vale la pena ver la razón estructural que lo explica.