Algorithmen

DispatchAtlas trennt das Solver-Verhalten von der Benchmark-Generierung und der Kampagnenausführung. Jeder Solver lebt in dispatchatlas.solve hinter einer einzigen Registry, und die Solver-Metadaten sind der öffentliche Vertrag für Ziele, Fähigkeiten, Encodings, Abhängigkeiten, Stochastizität, Belegstufen-Sichtbarkeit und optionale Backends. Diese Seite erklärt die Solver-Familien auf Arbeitsebene; die Registry-Seite des Solver-Systems ist der maßgebliche Katalog pro Solver.

🏗️ Wie Solver organisiert sind

default_solver_registry() gibt die Registry zustandsloser Solver-Fabriken zurück. Jeder Eintrag deklariert Fähigkeits-Tags, unterstützte Ziele, Standard-Stoppkriterien, deterministisches oder seed-stochastisches Replay-Verhalten, ein Lösungs-Encoding, Anforderungen an optionale Abhängigkeiten, Belegstufen-Sichtbarkeit und eine kanonische Zitation (oder eine explizite Zitation-nicht-anwendbar-Begründung). Zitationen schlagen schließend fehl: eine Familie mit einem kanonischen, wegweisenden Ursprung, die ihre Referenz auslässt, kann nicht konstruiert werden.

🧰 Solver-Familien

📋 Konstruktive Dispatching-Regeln

Die mitgelieferten deterministischen Baselines sind konstruktive List-Scheduling-Solver: jede kontrolliert die Aufgabenordnung, und der serielle Konstruktor honoriert die deklarierten Ressourcenanforderungen jeder Aufgabe. Die sieben Familien — earliest-start, shortest-processing-time, longest-processing-time, earliest-deadline, earliest-finish-time, minimum-slack und greedy-completion — nennen jeweils ihre kanonische wegweisende Referenz in den Metadaten. Sie sind der schnellste Weg zu einem machbaren Schedule und verankern jeden Vergleich, wie im ersten Tutorial.

🔀 Metaheuristische Baselines

Fünf repräsentative seed-Metaheuristiken — genetischer Algorithmus, simuliertes Annealing, Ameisenkolonie, Partikelschwarm und differentielle Evolution — teilen dieselben Operatoren für Machbarkeit, Reparatur, Scoring und lokale Suche, sodass ein Vergleich die Suchstrategie misst statt zufälliger Klempnereiunterschiede.

🔌 Encodierte Adapter-Solver

Der Partikelschwarm mit umfassendem Lernen (clpso, d-clpso) und die adaptive differentielle Evolution nach Erfolgshistorie (lshade, d-lshade) durchsuchen einen kontinuierlichen reellwertigen Vektor mit einer Komponente pro Aufgabe. Jeder Kern ist generisch über ein kontinuierliches Ziel und wird über einen benannten Encoding-Adapter (random-key, spv, rounding und die Transferfunktions-Decodes) an das Scheduling gebunden, der einen Vektor in eine präzedenz-machbare Aufgabenordnung verwandelt, mit einer expliziten Reparaturpolitik, die festhält, ob die Reparatur ausgelöst wurde.

🥊 Diversifizierte Konkurrenten und die Mehrziel-Spur

Ein kuratiertes Set aktueller publizierter Peers verbreitert den Vergleich über die repräsentativen Baselines hinaus, jeder mit seiner Volltext-Referenz, seinen Stärken und Vorbehalten in den Metadaten. Ein Peer tritt dem öffentlichen Feld nur bei, wenn er eine quellengestützte Venue-Stärke-Schwelle überschreitet; ein breiterer Pool klassischer Baselines bleibt für den internen Vergleich registriert. nsga3 ist der benannte Mehrziel-Konkurrent: er bewertet jede präzedenzsichere Ordnung auf einem Mehrzielvektor (Makespan, Verspätung, Lastfairness) und wählt Überlebende per Referenzpunkt-Nischenbildung.

🎯 Exakte Adapter

Optional-Backend-Adapter (CP-SAT, MILP, branch-and-bound) deklarieren eine optionale Abhängigkeit und prüfen ihre Import-Wurzel zur Laufzeit; wenn das Backend fehlt, lösen sie MissingOptionalDependencyError mit dem Extra-Namen und Lizenzhinweis aus, statt eine schwere Abhängigkeit beim Paketimport zu importieren. Nativ-beschränkte Adapter (exhaustive-enumeration und decision-diagram-sequencing) tragen keine Drittabhängigkeit und lösen kleine Instanzen exakt, wobei sie jenseits der unterstützten Aufgabenanzahl UnsupportedCapabilityError auslösen. Der kommerzielle Gurobi-Wrapper bleibt hinter dem Extra exact-commercial und wird nie mitgeliefert; ein breiterer Pool optionaler Backends bleibt für den internen Gebrauch registriert.

🐝 Die NDSO-Familie

NDSO ist die nativ-encodierende Solver-Familie der Registry: sie durchsucht direkt machbare Schedules, sodass jeder von ihr erzeugte Schedule per Konstruktion machbar ist und die Familie nie einen Encode/Decode-Schritt oder einen Reparaturdurchlauf ausführt. Sie komponiert ein kleines Set benannter Mechanismen:

• eine Konfidenzmatrix gelernten Vertrauens pro Zelle (Position, Aufgabe), verstärkt durch bessere Schedules;
• konfidenzgewichtetes Voting, das den Elite-Schedule synthetisiert, indem es über die mit dieser Matrix gewichtete Population abstimmt;
• Quantitäts-und-Qualitäts-Schedules, die festlegen, wie stark ein Kandidat sich ändert und aus welcher Leitquelle er lernt;
• Drei-Quellen-Leitung — die synthetisierte Elite (Exploitation), ein Peer (Diversität) oder eine verschwundene-Wissens-Quelle (radikale Exploration);
• ein vereinheitlichter adaptiver Koeffizient, ein nichtlinearer Zeitplan, der die Familie von Exploration zu Exploitation verschiebt.

Eine Ablations-Karte enumeriert eine isolierende Konfiguration pro benanntem Mechanismus, damit die nachgelagerte Analyse den Beitrag jedes Mechanismus zuordnen kann, und ein gestufter Export-Filter schlägt schließend fehl, statt einen Mechanismus späterer Stufe unter einem niedrigeren Berichtsumfang offenzulegen. Das vollständige Detail zu Mechanismus, Rat, Ablation und Diagnose lebt im Solver-System; vor dem Lauf der vergleichenden Kampagnen wird keine Leistungsaussage gemacht.

🎛️ Auswahl

SolverRegistry.select ordnet Solver nach Fähigkeits-Tags, deklarierten Constraints, unterstütztem Ziel und Belegstufen-Sichtbarkeit zu — das registry.select(objective="makespan", disclosure_label=DisclosureLabel.CORE) des Schnellstarts ist das kleinste Beispiel. Über der Registry ordnet die Auswahlschicht Solver für ein Problem aus Charakterisierungsmerkmalen und öffentlichen Metadaten, kennzeichnet jede Empfehlung nach Quelle und Konfidenz und behauptet nie einen universell besten Solver. Der Solver-Empfehler präsentiert diese Erklärungen, einschließlich warum ein Solver ausgeschlossen wurde.