Algoritmos

DispatchAtlas separa el comportamiento de los solvers de la generación de benchmarks y de la ejecución de campañas. Cada solver vive en dispatchatlas.solve detrás de un único registro, y los metadatos del solver son el contrato público para objetivos, capacidades, codificaciones, dependencias, estocasticidad, visibilidad por nivel de evidencia y backends opcionales. Esta página explica las familias de solvers a nivel operativo; la página del registro del sistema de solvers es el catálogo autoritativo por solver.

🏗️ Cómo se organizan los solvers

default_solver_registry() devuelve el registro de fábricas de solvers sin estado. Cada entrada declara etiquetas de capacidad, objetivos soportados, criterios de parada por defecto, comportamiento de reproducción determinista o estocástico-con-semilla, una codificación de solución, requisitos de dependencias opcionales, visibilidad por nivel de evidencia, y una citación canónica (o una justificación explícita de citación-no-aplicable). Las citaciones fallan en cerrado: una familia con un origen seminal canónico que omite su referencia no puede construirse.

🧰 Familias de solvers

📋 Reglas de despacho constructivo

Las líneas base deterministas incluidas son solvers constructivos de list-scheduling: cada una controla el orden de tareas, y el constructor en serie honra las demandas de recursos declaradas de cada tarea. Las siete familias — earliest-start, shortest-processing-time, longest-processing-time, earliest-deadline, earliest-finish-time, minimum-slack y greedy-completion — nombran cada una su referencia seminal canónica en los metadatos. Son el camino más rápido a una planificación factible y anclan toda comparación, como en el primer tutorial.

🔀 Líneas base metaheurísticas

Cinco metaheurísticas con semilla representativas — algoritmo genético, recocido simulado, colonia de hormigas, enjambre de partículas y evolución diferencial — comparten los mismos operadores de factibilidad, reparación, puntuación y búsqueda local, de modo que una comparación mide la estrategia de búsqueda en lugar de diferencias incidentales de fontanería.

🔌 Solvers de adaptador codificado

El enjambre de partículas de aprendizaje comprensivo (clpso, d-clpso) y la evolución diferencial adaptativa por historia-de-éxitos (lshade, d-lshade) buscan un vector continuo de valores reales con un componente por tarea. Cada núcleo es genérico sobre un objetivo continuo y se liga a la planificación mediante un adaptador de codificación nombrado (random-key, spv, rounding, y las decodificaciones por función de transferencia) que convierte un vector en un orden de tareas con precedencia factible, con una política de reparación explícita que registra si la reparación se activó.

🥊 Competidores diversificados y el carril multi-objetivo

Un conjunto curado de pares publicados recientes amplía la comparación más allá de las líneas base representativas, cada uno llevando su referencia de texto completo, fortalezas y advertencias en los metadatos. Un par se une al campo público solo cuando supera una barra de fortaleza-de-venue con fuente; un grupo más amplio de líneas base clásicas permanece registrado para comparación interna. nsga3 es el competidor multi-objetivo nombrado: evalúa cada orden con precedencia segura sobre un vector multi-objetivo (makespan, tardanza, equidad de carga) y selecciona supervivientes por nichado de punto de referencia.

🎯 Adaptadores exactos

Los adaptadores de backend opcional (CP-SAT, MILP, branch-and-bound) declaran una dependencia opcional y sondean su raíz de importación en tiempo de ejecución; cuando el backend está ausente plantean MissingOptionalDependencyError con el nombre del extra y la nota de licencia en lugar de importar una dependencia pesada en la importación del paquete. Los adaptadores nativos-acotados (exhaustive-enumeration y decision-diagram-sequencing) no llevan dependencia de terceros y resuelven instancias pequeñas exactamente, planteando UnsupportedCapabilityError más allá del conteo de tareas soportado. El envoltorio comercial de Gurobi permanece detrás del extra exact-commercial y nunca se incluye; un grupo más amplio de backends opcionales permanece registrado para uso interno.

🐝 La familia NDSO

NDSO es la familia de solvers de codificación nativa del registro: busca directamente sobre planificaciones factibles, de modo que cada planificación que produce es factible por construcción y la familia nunca ejecuta un paso de codificación/decodificación ni una pasada de reparación. Compone un pequeño conjunto de mecanismos nombrados:

• una Matriz de Confianza de confianza aprendida por celda (posición, tarea), reforzada por mejores planificaciones;
• Votación Ponderada por Confianza, que sintetiza la planificación elite votando a través de la población ponderada por esa matriz;
• planificaciones de Cantidad-y-Calidad que fijan cuánto cambia un candidato y de qué fuente de guía aprende;
• guía de tres fuentes — la elite sintetizada (explotación), un par (diversidad), o una fuente de conocimiento desvanecido (exploración radical);
• un coeficiente adaptativo unificado, una planificación no lineal que desplaza la familia de la exploración a la explotación.

Un mapa de ablación enumera una configuración aislante por cada mecanismo nombrado para que el análisis posterior pueda atribuir la contribución de cada mecanismo, y un filtro de exportación por etapas falla en cerrado en lugar de exponer un mecanismo de nivel posterior bajo un alcance de informe inferior. El detalle completo de mecanismos, concilio, ablación y diagnósticos vive en el sistema de solvers; no se hace ninguna afirmación de rendimiento antes de que se ejecuten las campañas comparativas.

🎛️ Selección

SolverRegistry.select empareja solvers por etiquetas de capacidad, restricciones declaradas, objetivo soportado y visibilidad por nivel de evidencia — el registry.select(objective="makespan", disclosure_label=DisclosureLabel.CORE) del inicio rápido es el ejemplo más pequeño. Por encima del registro, la capa de selección clasifica solvers para un problema a partir de características de caracterización y metadatos públicos, etiqueta cada recomendación por su fuente y confianza, y nunca afirma un solver universalmente mejor. El recomendador de solvers presenta esas explicaciones, incluido por qué se excluyó un solver.