Kritik_und_Verbesserungsvorschlaege in .gitignore - mit einer Ausnahme
Rezension und Verbesserungsvorschlaege haben ihren Zweck erfuellt und gehoeren nicht in die Veroeffentlichung. Fuenf der sechs Dateien sind ausgetragen; sie bleiben lokal liegen, nur der Index kennt sie nicht mehr. Die Ausnahme ist notwendig, nicht kosmetisch: NEUER_TITEL.md ist seit dem Zusammenfuehren der Titeltexte die EINE Quelle, aus der titeltexte_04.py die PDF-Titelseite und den Hero-Block der Startseite speist. Ohne die Datei bricht lies_titeltexte() mit "Die Quelle des Titeltexts fehlt" ab - ein frischer Klon koennte das Buch nicht mehr bauen. Deshalb 'Kritik_und_Verbesserungsvorschlaege/*' plus Gegenausnahme statt eines Verzeichnismusters: Git kann eine Datei nicht zurueckholen, deren Verzeichnis als Ganzes ausgeschlossen ist. Gegengeprueft mit einem simulierten Klon (git checkout-index in ein leeres Verzeichnis): Dort liegt aus dem Verzeichnis nur NEUER_TITEL.md, und build_version_04.py --check liefert dieselben Zahlen wie lokal - 5 Teile, 23 Kapitel, 6 Anhaenge, 998 Querverweise, 456 Indexmarken. CLAUDE.md und README.md beschrieben das Verzeichnis noch als vollstaendige Quelle; beide sind nachgezogen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
dschlueter
parent
803d8aa91e
commit
7f32ef3b8d
8 changed files with 19 additions and 813 deletions
11
.gitignore
vendored
11
.gitignore
vendored
|
|
@ -27,3 +27,14 @@ produktionsmix_ergebnis.xlsx
|
|||
# kein Passwort - die Anmeldung laeuft ueber den SSH-Schluessel -, aber Host,
|
||||
# Benutzer und Serverpfad gehen niemanden etwas an. Vorlage: .env.beispiel
|
||||
.env
|
||||
|
||||
# Die Arbeitsgrundlagen des Umbaus - Rezension und Verbesserungsvorschlaege.
|
||||
# Sie haben ihren Zweck erfuellt und gehoeren nicht in die Veroeffentlichung.
|
||||
#
|
||||
# AUSNAHME: NEUER_TITEL.md bleibt versioniert. Es ist die einzige Quelle des
|
||||
# Titeltexts (siehe titeltexte_04.py); ohne diese Datei bricht der Bau ab,
|
||||
# bevor er die erste Seite schreibt. Deshalb '/*' und Gegenausnahme statt
|
||||
# eines Verzeichnismusters - Git kann eine Datei nicht zurueckholen, deren
|
||||
# Verzeichnis als Ganzes ausgeschlossen ist.
|
||||
Kritik_und_Verbesserungsvorschlaege/*
|
||||
!Kritik_und_Verbesserungsvorschlaege/NEUER_TITEL.md
|
||||
|
|
|
|||
11
CLAUDE.md
11
CLAUDE.md
|
|
@ -33,9 +33,10 @@ Operations_Research_mit_Python_Version_04.pdf generiert: PDF (xelatex)
|
|||
OR_HTML_04/ generiert: Mehrseiten-Website
|
||||
Operations_Research_mit_Python_Version_04_Programme/ generiert: Beispielprogramme
|
||||
Notebooks_04/ generiert: ein .ipynb je Kapitel
|
||||
Kritik_und_Verbesserungsvorschlaege/ Quelle: Rezension, Verbesserungsvorschläge,
|
||||
NEUER_TITEL.md - die EINE Quelle des
|
||||
Titeltexts (PDF-Titelseite + Startseite)
|
||||
Kritik_und_Verbesserungsvorschlaege/ NEUER_TITEL.md - die EINE Quelle des
|
||||
Titeltexts (PDF-Titelseite + Startseite).
|
||||
Nur diese Datei ist versioniert; Rezension und
|
||||
Verbesserungsvorschläge stehen in .gitignore
|
||||
pyproject.toml Quelle: Abhängigkeiten in Gruppen
|
||||
Dockerfile, .dockerignore Quelle: Kurs-Image (Programme + JupyterLab)
|
||||
LICENSE, LICENSE-TEXT.md MIT fuer Code, CC BY-SA 4.0 fuer den Text
|
||||
|
|
@ -119,7 +120,9 @@ bewacht jede Familie. Konkret:
|
|||
existieren, und kein Verweis darf auf das Glossar selbst zeigen. Begriffe, die es nur im
|
||||
Glossar gibt, stehen ausdrücklich in `NUR_IM_GLOSSAR` — sonst ließe sich ein solcher Fall
|
||||
nicht von einem Tippfehler unterscheiden.
|
||||
* **Der Titeltext steht in `Kritik_und_Verbesserungsvorschlaege/NEUER_TITEL.md`** und
|
||||
* **Der Titeltext steht in `Kritik_und_Verbesserungsvorschlaege/NEUER_TITEL.md`** — die
|
||||
einzige versionierte Datei dieses Verzeichnisses, und zwar genau deshalb: Ohne sie bricht
|
||||
der Bau ab, bevor er die erste Seite schreibt. Der Titel steht dort und
|
||||
nirgends sonst. `titeltexte_04.py` liest ihn; die PDF-Titelseite
|
||||
(`bilder_04/erzeuge_titelseite.py`) und der Hero-Block der Startseite
|
||||
(`baue_landingpage()`) speisen sich daraus. Eine Titeländerung wird **einmal** dort
|
||||
|
|
|
|||
|
|
@ -1,48 +0,0 @@
|
|||
## Buchkritik: *Operations Research mit Python* (Version 03)
|
||||
**Autor:** Dieter Schlüter
|
||||
**Titel:** *Operations Research mit Python – Von den mathematischen Grundlagen zur quantitativen Portfolio-Optimierung an den Finanzmärkten*
|
||||
**Format:** E-Book / Kompendium (PDF & Web-Handbuch auf jamulix.de)
|
||||
**Eingesetztes Ökosystem:** Python, HiGHS, SciPy, Google OR-Tools (CP-SAT), CVXPY
|
||||
### 1. Überblick und thematische Ausrichtung
|
||||
Operations Research (OR) leidet in der Fachliteratur häufig unter einer Zweiteilung: Auf der einen Seite stehen klassisch-mathematische Universitätslehrbücher, die sich in Konvexitätsbeweisen und Simplex-Tableaus verlieren, ohne eine einzige Zeile lauffähigen Code zu liefern; auf der anderen Seite finden sich oberflächliche Programmier-Tutorials, die API-Befehle auflisten, ohne das Verständnis für Dualität, Schattenpreise oder algorithmische Komplexität zu schärfen.
|
||||
Dieter Schlüters Kompendium *Operations Research mit Python* setzt genau an dieser Schnittstelle an. Das Werk spannt einen weiten Bogen von den theoretischen Grundlagen der linearen und diskreten Optimierung über Constraint Programming bis hin zur quantitativen Portfolio- und Risikomodellierung an den Finanzmärkten. Mit 15 Hauptkapiteln, einer eigenständigen Projektwerkstatt sowie umfangreichen Anhängen präsentiert sich Version 03 als anspruchsvolles, praxisorientiertes Handbuch für Praktiker, Entwickler und quantitative Analysten.
|
||||
### 2. Struktur und didaktisches Konzept
|
||||
Das Werk ist in fünf logische Hauptabschnitte unterteilt:
|
||||
* **Teil I: Grundlagen des Operations Research (Kap. 1–3):**
|
||||
Einführung in die Denkweise mathematischer Modellierung (Entscheidungsvariablen, Zielfunktion, Restriktionen), Auffrischung der Vektor- und Matrixrechnung mit Fokus auf Konvexität sowie eine systematische Einordnung der Python-Solver-Landschaft (HiGHS, SciPy, OR-Tools, CVXPY).
|
||||
* **Teil II: Kernverfahren der deterministischen Optimierung (Kap. 4–7):**
|
||||
Lineare Programmierung (LP) inklusive Simplex und Dualitätsinterpretation, Mixed-Integer Linear Programming (MILP) mit Branch-and-Bound, Constraint Programming via Google OR-Tools CP-SAT sowie klassische Graphen- und Tourenprobleme (Min-Cost-Flow, TSP/VRP).
|
||||
* **Teil III: Nichtlinearität, Unsicherheit und Dynamik (Kap. 8–10):**
|
||||
Quadratische und nichtlineare Optimierung (KKT-Bedingungen, Lagrange), stochastische Optimierung und Robustheit sowie Dynamische Programmierung mit der Bellman-Gleichung.
|
||||
* **Teil IV: Operations Research an den Finanzmärkten (Kap. 11–14):**
|
||||
Der Brückenschlag zur Quant-Finance: Kovarianzschätzung und Shrinkage (Ledoit-Wolf), klassische Markowitz-Portfolios, Conditional Value at Risk (CVaR) unter Berücksichtigung von Transaktionskosten sowie der Aufbau einer modularen Backtest-Handelsmaschine.
|
||||
* **Teil V: Praxis, Projektwerkstatt & Anhänge (Kap. 15, Anhänge A–D):**
|
||||
Konkrete Fallstricke beim Produktivgang, 7 realistische End-to-End-Projekte (von Schichtplanung bis Portfolio-Rebalancer), Musterkatalog, Debugging-Leitfaden und Übungslösungen.
|
||||
Besonders hervorzuheben sind die im Einstieg definierten **Lernpfade (A bis E)**. Sie ermöglichen es Lesern, das Monumentalwerk je nach individuellem Ziel zu erschließen – beispielsweise fokussiert auf Personaleinsatz/Scheduling (~20 h), Tourenplanung (~20 h), Quantitative Finance (~30 h) oder als 80-stündiges Vollstudium.
|
||||
### 3. Was das Buch besonders stark macht
|
||||
#### Konsequente Fokussierung auf moderne Open-Source-Werkzeuge
|
||||
Anstatt auf teure proprietäre Suiten (wie Gurobi oder CPLEX) oder veraltete Lehrbuchwerkzeuge zu setzen, nutzt der Autor moderne, produktionsreife Open-Source-Engines:
|
||||
* **HiGHS** als erstklassiger linearer/MILP-Solver,
|
||||
* **Google OR-Tools (CP-SAT)** für kombinatorische Scheduling- und Zuweisungsprobleme,
|
||||
* **CVXPY** für konvexe Optimierungsprobleme.
|
||||
Dadurch bleiben alle Beispiele ohne Lizenzhürden für jeden Leser auf Standard-Hardware nachvollziehbar.
|
||||
#### Ausgeprägter Realismus und Warnung vor Modellierungs-Fallen
|
||||
Das Buch meidet akademische Laborbedingungen. Dies zeigt sich exemplarisch in Kapitel 11: Anstatt die historische Kovarianzmatrix naiv in das Markowitz-Modell einzuspeisen (was in der Realität lediglich Schätzrauschen optimiert und erratische Portfoliogewichte erzeugt), zwingt der Autor den Leser zunächst durch Verfahren wie Shrinkage und Regularisierung. Ebenso widmen sich Kapitel 15 und Anhang C gezielt typischen Produktivitätskillern (numerische Instabilitäten, unbounded/infeasible states, Lookahead-Bias in Backtests).
|
||||
#### Symbiose aus mathematischer Exaktheit und lauffähigem Code
|
||||
Mathematische Formulierungen werden nicht als Selbstzweck präsentiert, sondern dienen unmittelbar als Blaupause für die Modellierung in Python. Die Implementierungen sind didaktisch aufbereitet: Algorithmen wie der Simplex werden in Basisschritten demonstriert, um die Mechanik zu verstehen, bevor für den Produktiveinsatz auf hochoptimierte C++-Kern-Bindings zurückgegriffen wird.
|
||||
### 4. Schwachpunkte und Grenzen
|
||||
* **Ungewöhnlich steiler thematischer Bruch (Logistik vs. Finance):**
|
||||
Der Übergang von klassischen OR-Domänen (Schicht- und Tourenplanung, Flussnetzwerke) zur quantitativen Kapitalmarkttheorie (CVaR, Order-Execution, Markowitz) ist fachlich anspruchsvoll. Während OR-Spezialisten den Finanzteil möglicherweise als zu nischig empfinden, könnten Finanzanalysten die ersten Kapitel über klassische Tourenplanung als Ballast wahrnehmen.
|
||||
* **Hohe Einstiegshürde bei Mathematik und Software-Architektur:**
|
||||
Obwohl das Buch Grundlagenkapitel enthält, setzt das Tempo ein solides Verständnis von linearer Algebra, Wahrscheinlichkeitsrechnung und idiomatischem Python (OOP, NumPy, Vektorisierung) voraus. Für Quereinsteiger ohne mathematisch-technischen Hintergrund ist die Lernkurve steil.
|
||||
* **Fokus auf Konvexität:**
|
||||
Komplexe, hochgradig nicht-konvexe Optimierungslandschaften oder metaheuristische Verfahren (genetische Algorithmen, Simulated Annealing) werden im Vergleich zur exakten konvexen und diskreten Optimierung eher am Rande behandelt.
|
||||
### 5. Fazit
|
||||
*Operations Research mit Python* von Dieter Schlüter ist ein bemerkenswert tiefgründiges, anwendungsnahes deutschsprachiges Fachkompendium. Es schließt die Lücke zwischen formaler Operations-Research-Theorie und moderner Softwareentwicklung auf beispielhafte Weise.
|
||||
**Zielgruppen-Empfehlung:**
|
||||
* **Data Scientists und Software-Ingenieure**, die über Machine Learning hinausgehen und deterministische Entscheidungssysteme oder Zuweisungs-Engines bauen wollen.
|
||||
* **Quantitative Analysten und Finanzökonomen**, die Portfolio-Optimierung jenseits vereinfachter Lehrbuchmodelle robust und fehlerresistent implementieren möchten.
|
||||
* **Studierende und Dozenten** der Wirtschaftsmathematik, Wirtschaftsinformatik und des Maschinenbaus, die nach praxistauglichen Python-Vorlagen für OR-Vorlesungen suchen.
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,300 +0,0 @@
|
|||
### Rolle und Ziel
|
||||
Du bist ein erfahrener Fachlektor, leitender Didaktiker für technische Weiterbildung, Senior Operations Research Scientist und Lead Python Software Architect. Überarbeite und erweitere das Kompendium **„Operations Research mit Python“ (Version 03)** von Dieter Schlüter umfassend.
|
||||
|
||||
|
||||
### Primäres Lehr- und Kursziel
|
||||
Wichtigstes Ziel: Das Buch soll nicht nur als akademisches Nachschlagewerk dienen, sondern als **begeisternder, hocheffektiver Kursbegleiter**. Die Kursteilnehmer sollen Lust bekommen, sich mit dem Thema zu beschäftigen, schnell messbare Erfolgserlebnisse erzielen und die erlernten Methoden unmittelbar am nächsten Tag in ihrer beruflichen Praxis (z. B. Logistik, Disposition, Produktion, Finanzen, Data Science) produktiv einsetzen können.
|
||||
|
||||
Dein Ziel ist es, bei der Überarbeitung didaktische Brüche zu glätten, methodische Lücken zu schließen, die Code-Architektur auf Enterprise-Niveau zu heben und das Werk als unangefochtenes Standardwerk im deutschsprachigen Raum zu etablieren.
|
||||
|
||||
|
||||
### Die drei Leitprinzipien der Überarbeitung
|
||||
1. **Time-to-First-Success minimieren:** Schnelle, lauffähige Aha-Erlebnisse vor formaler Theorie.
|
||||
2. **Kognitive Entlastung:** Abstrakte Formeln konsequent durch visuelle Analogien und Klartext übersetzen.
|
||||
3. **Robuste Praxistauglichkeit:** Solide Python-Architektur, realistische Datenpipelines (Excel/Pandas) und praxiserprobtes Debugging statt realitätsferner Laborbeispiele.
|
||||
|
||||
|
||||
Führe die folgenden fünf Arbeitspakete präzise und vollständig aus:
|
||||
|
||||
---
|
||||
|
||||
## 1. Didaktik, Kurserlebnis und schneller Praxistransfer
|
||||
|
||||
Setze in jedem Kapitel die folgenden didaktischen Bausteine um:
|
||||
|
||||
### A. Das „In 5 Minuten gelöst“-Erfolgserlebnis an den Kapitelanfang
|
||||
* **Struktur:** Beginne jedes Kapitel mit einer prominent hervorgehobenen Box: Ein minimales, realistisches Problem (4–6 Zeilen Daten, maximal 10–15 Zeilen Python-Code), das per Copy-Paste sofort lauffähig ist und ein klares betriebswirtschaftliches/praktisches Ergebnis liefert.
|
||||
* **Didaktische Umkehrung:** Erst wenn der Code erfolgreich gelaufen ist und die Kursteilnehmer das Resultat sehen, folgt die Erklärung: *„Warum funktioniert das? Wie rechnet der Solver im Hintergrund? Was bedeuten die Variablen?“*
|
||||
|
||||
### B. Formel-Übersetzer: Mathe für Praktiker
|
||||
* **Zweispaltige Notation:** Stelle jeder zentralen mathematischen Formel eine tabellarische Klartext-Übersetzung gegenüber:
|
||||
* *Links (Mathematik):* $\sum_{i \in I} x_{i,j} \le C_j \quad \forall j \in J$
|
||||
* *Rechts (Alltagssprache):* „Für jede Maschine $j$ darf die Summe aller zugewiesenen Aufträge $i$ die Maximalkapazität $C_j$ nicht überschreiten.“
|
||||
* **Geometrische Intuition vor Beweis:** Führe Konzepte wie Konvexität, Simplex-Ecken, Hyperebenen und Branch-and-Bound-Bäume stets zuerst als visuelle Metaphern und 2D-/3D-Skizzen ein, bevor algebraische Definitionen folgen.
|
||||
|
||||
### C. Die „Excel-zu-Python“-Brücke für den Berufsalltag
|
||||
* Zeige in Kapitel 1 und Kapitel 3 explizit, wie typische Modelle aus dem Standard-Excel-Solver in modernes Python überführt werden.
|
||||
* Integriere wiederverwendbare Hilfsfunktionen, um Parameter direkt via `pandas.read_excel()` oder `.to_csv()` einzulesen, an den Solver zu übergeben und die Optimierungsergebnisse wieder als formatierte Tabellen (inkl. Kennzahlen) zu exportieren.
|
||||
|
||||
### D. Spickzettel (Cheat Sheets) & Visuelle Checklisten
|
||||
* Ergänze die Anhänge und Kapitel um **1-Seiten-Syntax-Spickzettel** für die Kernbibliotheken (SciPy, HiGHS, Google OR-Tools CP-SAT, CVXPY):
|
||||
* Wie definiere ich Binär-, Ganzzahl- und kontinuierliche Variablen?
|
||||
* Wie formuliere ich Entweder-Oder-Bedingungen (Big-M)?
|
||||
* Wie setze ich weiche Restriktionen mit Strafkosten (Slack-Variablen)?
|
||||
* Wie frage ich Dualwerte, Schattenpreise und Lösungsstatus ab?
|
||||
* Erstelle ein **Entscheidungs-Flussdiagramm** zu Beginn von Teil II und III: *„Welcher Solver und welches Paradigma passt zu meinem konkreten Problem?“* (Kriterien: Linearität, Ganzzahligkeit, Konvexität, Problemgröße, Laufzeitanforderungen).
|
||||
|
||||
### E. Praxistransfer: „Vom Management-Wunsch zum Modell“
|
||||
* Füge einen Leitfaden zur **Anforderungsanalyse für OR-Projekte** ein.
|
||||
* Demonstriere anhand praxisnaher Dialoge, wie man vage Vorgaben („Kosten senken, aber die Mitarbeiterzufriedenheit hochhalten“) systematisch zerlegt:
|
||||
1. *Entscheidungsvariablen:* Was sind die echten Stellschrauben?
|
||||
2. *Restriktionen:* Was sind harte physikalische Grenzen, was sind verhandelbare Wünsche?
|
||||
3. *Zielfunktion:* Wie messen wir Erfolg mathematisch sauber, ohne Fehlanreize zu setzen?
|
||||
|
||||
### F. Micro-Quizzes und „Finde den Modellierungsfehler“-Übungen
|
||||
* Schließe jedes Kapitel mit einem kurzen Selbsttest ab (3 Multiple-Choice-Fragen).
|
||||
* Ergänze gezielte Debugging-Aufgaben: Code, der fehlerfrei kompiliert, aber betriebswirtschaftlich unsinnige Ergebnisse liefert (z. B. unendliche Produktion durch falsches Relationszeichen `>=` statt `<=`, vergessene Ganzzahligkeit oder Zirkelbezüge).
|
||||
|
||||
---
|
||||
|
||||
## 2. Software-Architektur und Code-Qualität
|
||||
|
||||
Hebe sämtliche Implementierungen im Buch auf ein sauberes, wartbares Enterprise-Niveau:
|
||||
|
||||
### A. Typsicherheit und Datenvalidierung
|
||||
* Verwende durchgängig moderne Python-Features (Python 3.11+): strenge Type Hints (`typing`), Dataclasses oder **Pydantic v2**-Modelle für alle Input- und Output-Daten (Ressourcen, Bedarfe, Kostenmatrizen).
|
||||
* Validiere Randbedingungen (z. B. strikt positive Kapazitäten, stochastische Vektoren mit Summe 1) bereits beim Einlesen der Daten.
|
||||
|
||||
### B. Klare Entkopplung (Clean Architecture / Service-Pattern)
|
||||
* Trenne Domänenlogik strikt von der Solver-API:
|
||||
$$\text{Rohdaten (Excel/JSON)} \longrightarrow \text{Pydantic-Domänenmodell} \longrightarrow \text{Model-Builder (Solver)} \longrightarrow \text{Lösungs-DTO}$$
|
||||
* Kursteilnehmer sollen lernen, wie man Modelle baut, bei denen der zugrundeliegende Solver (z. B. Wechsel von HiGHS auf Gurobi oder CP-SAT) ausgetauscht werden kann, ohne die Business-Logik neu schreiben zu müssen.
|
||||
|
||||
### C. Explizite Status- und Fehlerbehandlung
|
||||
* Beseitige alle impliziten Annahmen über optimale Lösungen.
|
||||
* Implementiere für jedes Modell eine explizite Auswertung des Solver-Status (`OPTIMAL`, `FEASIBLE`, `INFEASIBLE`, `UNBOUNDED`, `TIME_LIMIT`).
|
||||
* Zeige, wie Timeouts, Suboptimalitätsgrenzen (MIP-Gap) und Näherungslösungen im Code professionell abgefangen, protokolliert und weiterverarbeitet werden.
|
||||
|
||||
### D. Vektorisierte Modellgenerierung
|
||||
* Zeige in Kapitel 3 und fortgeschrittenen Beispielen, wie man bei großen Datenmengen langsame Python-`for`-Schleifen vermeidet.
|
||||
* Demonstriere den Einsatz von vektorisierten Matrizenoperationen (NumPy) bzw. Tabellen-Pipelines (**Polars** / **Pandas**), um tausende Nebenbedingungen performant aufzubauen.
|
||||
|
||||
---
|
||||
|
||||
## 3. Fachliche, methodische und algorithmische Erweiterungen
|
||||
|
||||
Schließe die methodischen Lücken zwischen akademischer Lehrbuch-Theorie und realer Industrie-Komplexität:
|
||||
|
||||
### A. Didaktische Harmonisierung: Der Wechsel von Logistik zu Finance
|
||||
* Schlage eine methodische Brücke vor Kapitel 11: Zeige auf, dass die mathematischen Strukturen der Portfoliotheorie identisch sind mit klassischen OR-Problemen (z. B. Ressourcenallokation im Lager $\leftrightarrow$ Kapitalallokation im Portfolio; Robustheit gegen Lieferkettenausfälle $\leftrightarrow$ Risikomaße gegen Kursabstürze).
|
||||
* Ergänze für Nicht-Finanz-Interessierte ein paralleles, alternatives Transfer-Beispiel (z. B. **Supply-Chain-Netzwerkdesign unter Unsicherheit** oder **Energieeinsatzplanung**), das dieselben mathematischen Werkzeuge (Stochastik, CVaR, Dynamische Programmierung) nutzt.
|
||||
|
||||
### B. Metaheuristiken für nicht-konvexe und großskalige Probleme
|
||||
* Ergänze einen praxisnahen Leitfaden für NP-schwere Probleme, bei denen exakte MILP-Solver an Skalierungsgrenzen stoßen.
|
||||
* Implementiere verständliche Metaheuristiken (z. B. Large Neighborhood Search (LNS), Genetische Algorithmen via `Pymoo` oder Simulated Annealing) für komplexe Touren- und Belegungsplanungs-Probleme.
|
||||
|
||||
### C. Multi-Objective-Optimierung und Pareto-Effizienz
|
||||
* Erkläre, warum einfache Zielgewichtungen ($\min w_1 f_1 + w_2 f_2$) bei Zielkonflikten in der Praxis oft versagen.
|
||||
* Implementiere praxisnah die **$\epsilon$-Constraint-Methode** und die lexikografische Optimierung (z. B. Minimierung von Logistikkosten bei gleichzeitiger Minimierung des CO₂-Ausstoßes) inklusive Visualisierung der Pareto-Front.
|
||||
|
||||
### D. Schnittstelle Data Science: Predict-then-Optimize
|
||||
* Zeige das Zusammenspiel von Machine Learning und Optimierung: Warum führt ein ML-Modell mit minimalem Vorhersagefehler (MSE) im nachgelagerten Optimierungsmodell oft zu suboptimalen Entscheidungen?
|
||||
* Demonstriere den Unterschied an einem Beispiel (Nachfrageprognose $\rightarrow$ Lagerbestandsoptimierung) und gib einen Ausblick auf differenzierbare Optimierungsschichten (`cvxpylayers`).
|
||||
|
||||
### E. NLP/MINLP und Warm-Starts
|
||||
* Zeige die Grundlagen nicht-konvexer Optimierung mit Open-Source-Solvern wie **Ipopt** (über CyIpopt).
|
||||
* Ergänze praxisnahe Code-Beispiele für **MIP-Warm-Starts** (Einspeisen bekannter Ausgangslösungen zur massiven Beschleunigung der Lösungszeit).
|
||||
|
||||
---
|
||||
|
||||
## 4. Numerik, Debugging und Produktionsreife (MLOps)
|
||||
|
||||
Stelle sicher, dass die Modelle der Kursteilnehmer auch im harten Produktivbetrieb fehlerfrei funktionieren:
|
||||
|
||||
### A. Numerische Stabilität, Konditionierung und Toleranzen
|
||||
* Erkläre die Matrix-Konditionszahl $\kappa(A)$ anhand eines konkreten Python-Experiments: Zeige, wie schlecht skalierte Koeffizienten (z. B. große Kostenbeträge gemischt mit winzigen Mengeneinheiten) zu scheinbar unlösbaren Modellen (`INFEASIBLE`) oder Lösungsdrift führen.
|
||||
* Zeige Standard-Skalierungsverfahren (Ruiz-Equilibrierung) und schärfe das Bewusstsein für Primal-, Dual- und Integrabilitäts-Toleranzen (z. B. warum $0.99999998$ niemals leichtfertig mit `int()` gerundet werden darf).
|
||||
|
||||
### B. Solver-Diagnose & Unlösbarkeits-Analyse (IIS)
|
||||
* Baue Anhang C zu einem vollwertigen Troubleshooting-Handbuch aus.
|
||||
* Implementiere Werkzeuge zur Ermittlung eines **Irreducible Infeasible Subsystem (IIS)** bzw. Conflict Refiners: Wie isoliert man in einem Modell mit tausenden Restriktionen automatisiert genau die Teilmenge, die den mathematischen Widerspruch erzeugt?
|
||||
* Erläutere, wie duale Entartung (Degeneriertheit) instabile Schattenpreise erzeugt und wie man fundierte Sensitivitätsanalysen für Entscheidungsträger erstellt.
|
||||
|
||||
### C. Testing, Benchmarking und API-Deployment
|
||||
* **Pytest-Framework:** Entwickle standardisierte Testroutinen für Optimierungsmodelle (Invarianztests, Überprüfung von Restriktionsverletzungen, Regressionstests an Benchmark-Instanzen).
|
||||
* **Solver-Benchmarks:** Zeige reproduzierbare Laufzeit- und Speicher-Benchmarks beim Vergleich von SciPy, HiGHS, OR-Tools und CVXPY über skalierende Instanzgrößen ($N \in \{10^2, 10^3, 10^4\}$).
|
||||
* **FastAPI & Async:** Zeige das Deployment eines Optimierungsmodells als Microservice via **FastAPI** mit asynchroner Aufgabenwarteschlange (Celery/Redis) für rechenintensive Solver-Läufe, inklusive eines kompakten `Dockerfile`.
|
||||
|
||||
---
|
||||
|
||||
## 5. Auszuführende Arbeitsanweisung
|
||||
|
||||
Setze diese Verbesserungen kapitelweise und systematisch um:
|
||||
1. **Analysiere** das jeweilige Kapitel auf didaktische Verständlichkeit, mathematische Zugänglichkeit und Code-Qualität.
|
||||
2. **Erstelle** für jedes Kapitel zuerst die „In 5 Minuten gelöst“-Box und die Formel-Übersetzer-Tabellen.
|
||||
3. **Refaktoriere** den Python-Code gemäß den Standards für Typsicherheit, Validierung und Statusbehandlung.
|
||||
4. **Erweitere** die methodischen Abschnitte und baue die praktischen Excel-/Pandas-Workflows ein.
|
||||
5. **Schließe** jedes Kapitel mit den Übungen zur Fehlerdiagnose („Finde den Denkfehler“) und den interaktiven Micro-Quizzes ab.
|
||||
|
||||
|
||||
|
||||
Im Einzelnen führe unter diesen Prämissen folgendes präzise und vollständig aus:
|
||||
|
||||
---
|
||||
|
||||
### 1. Architektur und Code-Qualität: Transformation zu produktionsreifem Python
|
||||
Überarbeite alle Skripte und Code-Beispiele im Buch nach modernen Software-Engineering-Standards:
|
||||
* **Typsicherheit & Verträge:** Führe durchgehend Type Hints (`typing`, `mypy`-kompatibel) und Laufzeitvalidierung via **Pydantic v2** für alle Modellparameter (z. B. Nachfragedaten, Kapazitäten, Renditevektoren) ein.
|
||||
* **Trennung von Domäne und Solver:** Refaktoriere den Code so, dass Domänenlogik strikt von der Solver-Syntax getrennt ist. Führe ein klares Repository-/Service-Pattern ein: Rohdaten $\rightarrow$ Validiertes Domänenmodell $\rightarrow$ Solver-Builder (z. B. CVXPY/OR-Tools) $\rightarrow$ Lösungs-DTO.
|
||||
* **Fehler- und Statusbehandlung:** Ersetze implizite Annahmen über Solver-Ergebnisse durch explizite Fehlerbehandlung für Randfälle: `INFEASIBLE`, `UNBOUNDED`, `NUMERICAL_ERROR` oder Timeouts. Zeige für MILP und CP-SAT, wie Suboptimalitätsgrenzen (MIP-Gap) und Abbruchkriterien sauber abgefangen und geloggt werden.
|
||||
|
||||
---
|
||||
|
||||
### 2. Methodische Ergänzungen: Schließen der algorithmischen Lücken
|
||||
Ergänze den theoretischen und praktischen Kanon um drei bisher unterrepräsentierte, in der Praxis aber essenzielle Bereiche:
|
||||
* **Metaheuristiken für Nicht-Konvexes & NP-Schwere (Neues Kapitel oder Brückenteil):**
|
||||
* Integriere einen praktischen Leitfaden für Probleme, bei denen exakte Solver (HiGHS, CP-SAT) skalierungsbedingt scheitern.
|
||||
* Implementiere praxisnahe Metaheuristiken (z. B. Large Neighborhood Search (LNS), Simulated Annealing oder Genetische Algorithmen) mit Bibliotheken wie `Pymoo` oder nativem Python für großskalige Vehicle-Routing- oder Scheduling-Instanzen.
|
||||
* **Nicht-lineare nicht-konvexe Optimierung (NLP / MINLP):**
|
||||
* Zeige den praktischen Einsatz von Solvern wie **Ipopt** (über CyIpopt oder Pyomo/CasADi) für nicht-konvexe kontinuierliche Probleme. Diskutiere den Unterschied zwischen lokalen und globalen Optima sowie Strategien zur Wahl von Startwerten (Warm-Starts).
|
||||
* **Warm-Starts & Dekomposition:**
|
||||
* Ergänze in Teil II praxisnahe Beispiele für **MIP Warm-Starts** (Einspeisen bekannter zulässiger Lösungen) sowie eine verständliche Einführung in Dekompositionsverfahren (z. B. Spaltengenerierung / Dantzig-Wolfe für Cutting-Stock- oder Crew-Scheduling-Probleme).
|
||||
|
||||
---
|
||||
|
||||
### 3. Didaktische Harmonisierung: Glättung des Wechsels von Logistik zu Finance
|
||||
Löse den abrupten thematischen Bruch zwischen Teil II/III (diskrete Optimierung, Logistik) und Teil IV (Finanzmärkte):
|
||||
* **Konzeptionelle Brückenkapitel:** Führe vor Kapitel 11 eine explizite methodische Überleitung ein: Zeige, dass die mathematischen Strukturen identisch sind (z. B. Resource Allocation in der Produktion $\leftrightarrow$ Kapitalallokation im Portfolio; Robust Counterparts bei Lieferkettenausfällen $\leftrightarrow$ Worst-Case-Risikomaße am Markt).
|
||||
* **Entflechtung der Zielgruppen:**
|
||||
* Kennzeichne Teil IV klar als spezialisierte Vertiefungsdomäne.
|
||||
* Ergänze für Leser, die *nicht* aus dem Finanzbereich kommen, ein paralleles, alternatives Vertiefungskapitel für industrielle Wertschöpfung (z. B. **Supply-Chain-Netzwerkdesign unter Unsicherheit** oder **Energie- und Kraftwerkseinsatzplanung**), das dieselben mathematischen Werkzeuge (Stochastik, CVaR/Robustheit, dynamische Programmierung) auf physische Systeme anwendet.
|
||||
|
||||
---
|
||||
|
||||
### 4. Enterprise-Testing, Benchmarking & MLOps-Integration
|
||||
Erweitere Kapitel 15 und die Projektwerkstatt um operative Deployment-Standards:
|
||||
* **Testing-Framework für Optimierungsmodelle:**
|
||||
* Entwickle ein dediziertes Testkonzept mit `pytest`: Regressionstests gegen bekannte Testinstanzen, Validierung von Restriktionsverletzungen (Infeasibility-Checks) und Invarianztests (z. B. Skalierungsinvarianz der Zielfunktion).
|
||||
* **Benchmarking & Performance-Profiling:**
|
||||
* Baue eine strukturierte Benchmark-Pipeline auf: Vergleich von Lösungszeit und Speicherverbrauch zwischen SciPy, HiGHS, Google OR-Tools und CVXPY bei wachsender Problemgröße ($N \in \{10^2, 10^3, 10^4, 10^5\}$).
|
||||
* **Containerisierung & API-Bereitstellung:**
|
||||
* Zeige die Kapselung eines Optimierungsmodells in einer **FastAPI**-Anwendung inklusive asynchroner Job-Queue (z. B. via Celery/Redis) für länger laufende Solver-Jobs.
|
||||
* Liefere ein einsatzbereites `Dockerfile`, das C++-Abhängigkeiten und Solver-Bibliotheken performant und schlank baut.
|
||||
|
||||
---
|
||||
|
||||
### 5. Format, Interaktivität und Leseerlebnis
|
||||
* **Interaktive Ausführungsumgebung:** Ergänze jedes Kapitel um Links zu validierten Jupyter Notebooks bzw. Google-Colab-Instanzen mit One-Click-Setup (`pip install highs cvxpy ortools ...`).
|
||||
* **Visualisierungs-Upgrade:** Ersetze rein statische Matplotlib-Plots durch interaktive Visualisierungen (z. B. via `Plotly` für 3D-Konvexitätsflächen, KKT-Bedingungen, Pareto-Fronten bei Multi-Objective-Problemen und dynamische Gantt-Diagramme in CP-SAT).
|
||||
* **Entscheidungs-Flussdiagramm:** Füge zu Beginn von Teil II und Teil III ein visuelles Ablaufdiagramm ein: *„Welcher Solver / welches Paradigma passt zu meinem Problem?“* (Entscheidungskriterien: linear vs. nichtlinear, stetig vs. diskret, konvex vs. nicht-konvex, Skalierungsanforderungen, Lösungszeitgarantien).
|
||||
|
||||
---
|
||||
|
||||
### 6. Numerische Stabilität, Konditionierung und Skalierung (Deep Dive)
|
||||
Erweitere Kapitel 2, 4 und Anhang C um einen tiefgehenden praktischen Leitfaden zur numerischen Linearen Algebra:
|
||||
* **Konditionszahlen in der Praxis:** Erkläre nicht nur formal die Matrix-Konditionszahl $\kappa(A)$, sondern demonstriere mit einem konkreten Python-Experiment, wie schlecht skalierte Koeffizienten (z. B. Kosten im Bereich $10^7$ kombiniert mit Toleranzen von $10^{-6}$) zu stillschweigendem Lösungsdrift oder falschen `INFEASIBLE`-Meldungen führen.
|
||||
* **Skalierungs- und Vorverarbeitungs-Routinen:** Zeige, wie man Koeffizientenmatrizen systematisch über Methoden wie Ruiz-Equilibrierung oder geometrische Skalierung transformiert, bevor sie an den Solver übergeben werden.
|
||||
* **Toleranzen verstehen:** Schärfe das Bewusstsein für Primal-, Dual- und Integrabilitäts-Toleranzen der Solver (z. B. `feasibility_tolerance` in HiGHS vs. OR-Tools). Erkläre, warum eine Variable mit dem Wert `0.99999998` in einem MILP nicht einfach mit `int()` gecastet werden darf.
|
||||
|
||||
---
|
||||
|
||||
### 7. Modernes Modellierungs-Ökosystem: Pyomo, Linopy und Polars
|
||||
Erweitere Kapitel 3 um moderne Modellierungs-Frameworks und Big-Data-Anbindungen:
|
||||
* **Evaluierung von Linopy & Pyomo:** CVXPY und OR-Tools decken viel ab, aber für große industrielle LP/MILP-Probleme sind **Pyomo** (als klassischer Industriestandard) oder das neuere **Linopy** (optimiert für $N$-dimensionale xarray-Strukturen und extrem schnelle Matrix-Generierung) unverzichtbar. Ergänze einen kompakten Vergleich dieser Modellierungsschichten.
|
||||
* **Polars & Vektorisierte Modellgenerierung:** In der Praxis verbringen OR-Ingenieure oft 80 % der Rechenzeit nicht im Solver, sondern beim Aufbau der Constraints über langsame Python-`for`-Schleifen. Zeige, wie man mithilfe von **Polars** oder Vektorisierung in NumPy Millionen von Nebenbedingungen um Größenordnungen schneller konstruiert.
|
||||
|
||||
---
|
||||
|
||||
### 8. Schnittstelle zwischen Machine Learning und Operations Research (Smart Predict-then-Optimize)
|
||||
Baue in Teil III oder IV eine methodische Brücke zur modernen Data Science:
|
||||
* **Predict-then-Optimize:** Zeige das Zusammenspiel von Prognose und Optimierung. Klassische ML-Modelle minimieren den Mean Squared Error (MSE), nicht die Kosten im nachgelagerten Optimierungsmodell. Demonstriere anhand eines Beispiels (z. B. Nachfrageprognose $\rightarrow$ Lagerhaltung), warum ein isoliert „gutes“ ML-Modell zu teuren OR-Entscheidungen führen kann.
|
||||
* **Differenzierbare Optimierung:** Führe kurz das Paradigma differenzierbarer Layer ein (z. B. über `cvxpylayers`), bei denen Optimierungsmodelle als Schicht direkt in neuronale PyTorch-Netze eingebettet werden können.
|
||||
|
||||
---
|
||||
|
||||
### 9. Multi-Objective-Optimierung und Pareto-Effizienz
|
||||
Ergänze in Teil II und Teil IV die Behandlung konkurrierender Zielkonflikte, die in realen Projekten die Regel sind:
|
||||
* **Jenseits linearer Skalarisierung:** Erkläre, warum die simple Gewichtung von Zielen ($\min w_1 f_1 + w_2 f_2$) bei nicht-konvexen Pareto-Fronten versagt und wie man stattdessen mit der **$\epsilon$-Constraint-Methode** oder lexikografischer (hierarchischer) Optimierung arbeitet.
|
||||
* **Praxisbeispiel:** Implementiere ein zweidimensionales Trade-off-Modell (z. B. Kosten vs. CO₂-Ausstoß in der Tourenplanung oder Rendite vs. Drawdown) und berechne die exakte Pareto-Front inklusive Visualisierung.
|
||||
|
||||
---
|
||||
|
||||
### 10. Professionelle Solver-Diagnose und Unlösbarkeits-Analyse (IIS)
|
||||
Vertiefe Anhang C (Fehlerdiagnose) um fortgeschrittene Debugging-Techniken:
|
||||
* **Irreducible Infeasible Subsystem (IIS):** Wenn ein Modell mit 50.000 Restriktionen `INFEASIBLE` meldet, ist der Entwickler ohne Werkzeuge verloren. Erkläre die mathematische Funktionsweise eines IIS/Conflict Refiners und zeige, wie man mit Python-Mitteln isoliert, welche minimale Teilmenge von Restriktionen den Konflikt verursacht.
|
||||
* **Dual-Analyse bei Degeneriertheit:** Zeige auf, wie duale Entartung (Multiple Dual Solutions) dazu führt, dass Schattenpreise instabil werden, und wie man damit bei Sensitivitätsanalysen für das Management umgeht.
|
||||
|
||||
|
||||
|
||||
|
||||
### 11. Didaktischer Kurs-Fokus: Motivation, Zugänglichkeit & Praxistransfer
|
||||
|
||||
Unter der Prämisse, dass das Buch primär als **didaktischer Kursbegleiter** dient, müssen rein akademische Vertiefungen und industrielle Enterprise-Overheads zurücktreten. Im Zentrum stehen drei Faktoren:
|
||||
1. **Sofortige Erfolgserlebnisse (Time-to-First-Success)**,
|
||||
2. **Kognitive Entlastung bei Hürden** (Mathematik, Solver-Syntax, Debugging),
|
||||
3. **Direkte Übertragbarkeit in den Arbeitsalltag**.
|
||||
|
||||
Führe zur Umsetzung dieser Kursziele die folgenden didaktischen und strukturellen Verbesserungen aus:
|
||||
|
||||
---
|
||||
|
||||
### 11.1. Das „5-Minuten-Erfolgserlebnis“ an den Anfang jedes Kapitels stellen
|
||||
* **Didaktisches Problem:** Wer erst 15 Seiten Vektorräume oder Simplex-Tableaus liest, bevor der erste Code läuft, verliert Motivation und Schwung.
|
||||
* **Maßnahme:**
|
||||
* Jedes Kapitel beginnt mit einer **„In 5 Minuten gelöst“-Box**: Ein minimales, realistisches Mini-Problem (z. B. 4 Zeilen Daten, 6 Zeilen Python-Code), das der Teilnehmer per Copy-Paste sofort ausführt und dessen Ergebnis sofort einleuchtet.
|
||||
* Erst **nach** dem funktionierenden Ergebnis folgt die methodische Erklärung: *„Warum funktioniert das? Wie rechnet der Solver das im Hintergrund? Was bedeuten die Variablen?“*
|
||||
* **Effekt:** Neugier und Selbstwirksamkeit statt theoretischer Lähmung.
|
||||
|
||||
---
|
||||
|
||||
### 11.2. Duale Lesart: „Mathe für Anwender“ mit visuellen Analogien
|
||||
* **Didaktisches Problem:** Die Formelsprache (Summenzeichen mit Doppelindizes, Matrixschreibweisen, KKT-Gradienten) wirkt auf Praktiker oft abschreckend.
|
||||
* **Maßnahme:**
|
||||
* **Formel-Übersetzer-Boxen:** Jede zentrale mathematische Formulierung erhält eine zweispaltige Darstellung:
|
||||
* Links: Die mathematische Formel $\sum_{i \in I} x_{i,j} \le C_j$.
|
||||
* Rechts: Der Klartext in Alltagssprache: *„Für jede Maschine $j$ darf die Summe aller zugewiesenen Aufträge $i$ die Gesamtkapazität $C_j$ nicht überschreiten.“*
|
||||
* **Geometrische Intuition vor algebraischem Beweis:** Konvexität, Simplex-Ecken und Branch-and-Bound-Bäume zuerst als 2D-Skizzen und anschauliche Metaphern (z. B. „Eine Seifenblase, die sich in die Ecke eines Zimmers spannt“) einführen, bevor algebraische Definitionen folgen.
|
||||
|
||||
---
|
||||
|
||||
### 11.3. „Excel-zu-Python“-Brücken für den Berufsalltag bauen
|
||||
* **Didaktisches Problem:** Im betrieblichen Alltag liegen 90 % aller Daten in Tabellenkalkulationen, und viele Kursteilnehmer kennen Optimierung bisher nur aus dem Excel-Solver.
|
||||
* **Maßnahme:**
|
||||
* Baue in Kapitel 1 und Kapitel 3 explizite Brücken: *„Wie Sie Ihr Excel-Solver-Modell in sauberen Python-Code übersetzen.“*
|
||||
* Zeige, wie Parameter direkt aus `pandas.read_excel()` oder CSV eingelesen, als Modell formuliert und die optimierten Zuweisungen wieder als saubere Excel-Tabelle mit Kennzahlen exportiert werden.
|
||||
* **Effekt:** Die Teilnehmer können das Gelernte am nächsten Tag direkt an ihren eigenen Arbeitsdateien ausprobieren.
|
||||
|
||||
---
|
||||
|
||||
### 11.4. Spickzettel & Visuelle Checklisten („Cheat Sheets“)
|
||||
* **Didaktisches Problem:** Wenn Teilnehmer ein eigenes Problem lösen wollen, wissen sie oft nicht, welcher Baustein (Variable, Constraint, Zielfunktion) wie in Python heißt.
|
||||
* **Maßnahme:**
|
||||
* **1-Seiten-Syntax-Cheat-Sheet:** Eine kompakte Übersichtstabelle für die drei Hauptwerkzeuge (SciPy, OR-Tools, CVXPY):
|
||||
* *Wie definiere ich eine Binärvariable?*
|
||||
* *Wie formuliere ich eine Entweder-Oder-Bedingung?*
|
||||
* *Wie setze ich eine Obergrenze?*
|
||||
* *Wie lese ich den optimalen Wert aus?*
|
||||
* **Modellierungs-Baukasten:** Visuelle Rezeptkarten für Standardfragen des Arbeitsalltags: *„Wie modelliere ich Mindestabnahmemengen?“, „Wie verhindere ich Rüstzeiten?“, „Wie baue ich ein Budgetlimit ein?“*
|
||||
|
||||
---
|
||||
|
||||
### 11.5. Selbsteinschätzungs-Meilensteine & „Finde den Denkfehler“-Übungen
|
||||
* **Didaktisches Problem:** Reine Programmieraufgaben frustrieren, wenn man an Syntax-Details hängenbleibt.
|
||||
* **Maßnahme:**
|
||||
* Ergänze jedes Kapitel um 2–3 kurze **Micro-Quizzes** (3 Multiple-Choice-Fragen) zur Selbstkontrolle vor dem nächsten Kapitel.
|
||||
* Führe **„Finde den Modellierungsfehler“-Aufgaben** ein: Der Code läuft fehlerfrei durch, aber das Ergebnis ist unplausibel (z. B. Maschine produziert unendlich viel, weil eine Nebenbedingung als `>=` statt `<=` formuliert wurde; oder Ganzzahligkeit vergessen).
|
||||
* **Effekt:** Das schult den kritischen Blick auf Ergebnisse, der in der Praxis wichtiger ist als das reine Schreiben von Code.
|
||||
|
||||
---
|
||||
|
||||
### 11.6. Praxistransfer-Protokoll: „Vom Management-Wunsch zum Modell“
|
||||
* **Didaktisches Problem:** Im Berufsleben kommt selten jemand mit einer fertigen Zielfunktion. Chefs und Fachabteilungen formulieren vage: *„Wir wollen die Kosten senken, aber die Mitarbeiter sollen nicht meckern und die Liefertreue muss hoch bleiben.“*
|
||||
* **Maßnahme:**
|
||||
* Ergänze ein methodisches Kapitel oder Leitfaden: **„Anforderungsanalyse für OR-Projekte“**.
|
||||
* Zeige anhand eines realistischen Dialogs, wie man vage Geschäftsanforderungen systematisch zerlegt:
|
||||
1. Was sind die echten Stellschrauben? $\rightarrow$ *Entscheidungsvariablen*
|
||||
2. Was sind harte Grenzen, was weiche Wünsche? $\rightarrow$ *Harte vs. Weiche Constraints (Penalties)*
|
||||
3. Woran messen wir Erfolg wirklich? $\rightarrow$ *Zielfunktion*
|
||||
* **Effekt:** Die Teilnehmer lernen die wichtigste Fähigkeit für den Arbeitsalltag: das Übersetzen von Business-Problemen in mathematische Logik.
|
||||
|
||||
|
||||
|
|
@ -1,310 +0,0 @@
|
|||
> **Historisches Dokument — nicht nachschlagen, sondern einordnen.**
|
||||
> Dies ist der ursprüngliche Auftrag, mit dem der Umbau von Version 03 zu Version 04 begonnen
|
||||
> wurde. Die darin genannten Pfade beziehen sich auf die damalige Verzeichnisstruktur, in der
|
||||
> beide Versionen nebeneinander unter `~/Python_Programs/OR_mit_Python/` lagen. Seit der
|
||||
> Trennung liegt Version 04 in `Version_04/`, Version 03 in `Version_03/`. Der Text bleibt
|
||||
> unverändert, weil er festhält, was verlangt war — nicht, wo heute etwas liegt.
|
||||
|
||||
### Rolle und Ziel
|
||||
Du bist ein erfahrener Fachlektor, leitender Didaktiker für technische Weiterbildung, Senior Operations Research Scientist und Lead Python Software Architect. Überarbeite und erweitere das Kompendium **„Operations Research mit Python“ (Version 03)** von Dieter Schlüter umfassend. Alle Veränderungen sollen sich an den MD-Dateien im Verzeichnis "Operations_Research_mit_Python_Version_03" orientieren. Sie bilden die Grundlage für alle anderen Dateien.
|
||||
|
||||
Lies zunächst die Buchrezension "Kritik.md" im Verzeichnis "~/Python_Programs/OR_mit_Python/Kritik_und_Verbesserungsvorschlaege". Sie wurde vom KI-Tool "Gemini" verfasst. Dann wirst Du verstehen, was es zu verbesseren gilt.
|
||||
|
||||
Orientiere Dich an folgenden Vorgaben und lege für die verbesserte Version eine komplett neue Fassung im neu zu erzeugenden Verzeichnis "~/Python_Programs/OR_mit_Python/Operations_Research_mit_Python_Version_04" und den entsprechenden anderen Verzeichnissen für die neue Fassung an (Operations_Research_mit_Python_Version_04_Programme, bilder, OR_HTML_04 etc.) an.
|
||||
|
||||
### Primäres Lehr- und Kursziel
|
||||
Wichtigstes Ziel: Das Buch soll nicht nur als akademisches Nachschlagewerk dienen, sondern als **begeisternder, hocheffektiver Kursbegleiter**. Die Kursteilnehmer sollen Lust bekommen, sich mit dem Thema zu beschäftigen, schnell messbare Erfolgserlebnisse erzielen und die erlernten Methoden unmittelbar am nächsten Tag in ihrer beruflichen Praxis (z. B. Logistik, Disposition, Produktion, Finanzen, Data Science) produktiv einsetzen können.
|
||||
|
||||
Dein Ziel ist es, bei der Überarbeitung didaktische Brüche zu glätten, methodische Lücken zu schließen, die Code-Architektur auf Enterprise-Niveau zu heben und das Werk als unangefochtenes Standardwerk im deutschsprachigen Raum zu etablieren.
|
||||
|
||||
|
||||
### Die drei Leitprinzipien der Überarbeitung
|
||||
1. **Time-to-First-Success minimieren:** Schnelle, lauffähige Aha-Erlebnisse vor formaler Theorie.
|
||||
2. **Kognitive Entlastung:** Abstrakte Formeln konsequent durch visuelle Analogien und Klartext übersetzen.
|
||||
3. **Robuste Praxistauglichkeit:** Solide Python-Architektur, realistische Datenpipelines (Excel/Pandas) und praxiserprobtes Debugging statt realitätsferner Laborbeispiele.
|
||||
|
||||
|
||||
Führe die folgenden fünf Arbeitspakete präzise und vollständig aus:
|
||||
|
||||
---
|
||||
|
||||
## 1. Didaktik, Kurserlebnis und schneller Praxistransfer
|
||||
|
||||
Setze in jedem Kapitel die folgenden didaktischen Bausteine um:
|
||||
|
||||
### A. Das „In 5 Minuten gelöst“-Erfolgserlebnis an den Kapitelanfang
|
||||
* **Struktur:** Beginne jedes Kapitel mit einer prominent hervorgehobenen Box: Ein minimales, realistisches Problem (4–6 Zeilen Daten, maximal 10–15 Zeilen Python-Code), das per Copy-Paste sofort lauffähig ist und ein klares betriebswirtschaftliches/praktisches Ergebnis liefert.
|
||||
* **Didaktische Umkehrung:** Erst wenn der Code erfolgreich gelaufen ist und die Kursteilnehmer das Resultat sehen, folgt die Erklärung: *„Warum funktioniert das? Wie rechnet der Solver im Hintergrund? Was bedeuten die Variablen?“*
|
||||
|
||||
### B. Formel-Übersetzer: Mathe für Praktiker
|
||||
* **Zweispaltige Notation:** Stelle jeder zentralen mathematischen Formel eine tabellarische Klartext-Übersetzung gegenüber:
|
||||
* *Links (Mathematik):* $\sum_{i \in I} x_{i,j} \le C_j \quad \forall j \in J$
|
||||
* *Rechts (Alltagssprache):* „Für jede Maschine $j$ darf die Summe aller zugewiesenen Aufträge $i$ die Maximalkapazität $C_j$ nicht überschreiten.“
|
||||
* **Geometrische Intuition vor Beweis:** Führe Konzepte wie Konvexität, Simplex-Ecken, Hyperebenen und Branch-and-Bound-Bäume stets zuerst als visuelle Metaphern und 2D-/3D-Skizzen ein, bevor algebraische Definitionen folgen.
|
||||
|
||||
### C. Die „Excel-zu-Python“-Brücke für den Berufsalltag
|
||||
* Zeige in Kapitel 1 und Kapitel 3 explizit, wie typische Modelle aus dem Standard-Excel-Solver in modernes Python überführt werden.
|
||||
* Integriere wiederverwendbare Hilfsfunktionen, um Parameter direkt via `pandas.read_excel()` oder `.to_csv()` einzulesen, an den Solver zu übergeben und die Optimierungsergebnisse wieder als formatierte Tabellen (inkl. Kennzahlen) zu exportieren.
|
||||
|
||||
### D. Spickzettel (Cheat Sheets) & Visuelle Checklisten
|
||||
* Ergänze die Anhänge und Kapitel um **1-Seiten-Syntax-Spickzettel** für die Kernbibliotheken (SciPy, HiGHS, Google OR-Tools CP-SAT, CVXPY):
|
||||
* Wie definiere ich Binär-, Ganzzahl- und kontinuierliche Variablen?
|
||||
* Wie formuliere ich Entweder-Oder-Bedingungen (Big-M)?
|
||||
* Wie setze ich weiche Restriktionen mit Strafkosten (Slack-Variablen)?
|
||||
* Wie frage ich Dualwerte, Schattenpreise und Lösungsstatus ab?
|
||||
* Erstelle ein **Entscheidungs-Flussdiagramm** zu Beginn von Teil II und III: *„Welcher Solver und welches Paradigma passt zu meinem konkreten Problem?“* (Kriterien: Linearität, Ganzzahligkeit, Konvexität, Problemgröße, Laufzeitanforderungen).
|
||||
|
||||
### E. Praxistransfer: „Vom Management-Wunsch zum Modell“
|
||||
* Füge einen Leitfaden zur **Anforderungsanalyse für OR-Projekte** ein.
|
||||
* Demonstriere anhand praxisnaher Dialoge, wie man vage Vorgaben („Kosten senken, aber die Mitarbeiterzufriedenheit hochhalten“) systematisch zerlegt:
|
||||
1. *Entscheidungsvariablen:* Was sind die echten Stellschrauben?
|
||||
2. *Restriktionen:* Was sind harte physikalische Grenzen, was sind verhandelbare Wünsche?
|
||||
3. *Zielfunktion:* Wie messen wir Erfolg mathematisch sauber, ohne Fehlanreize zu setzen?
|
||||
|
||||
### F. Micro-Quizzes und „Finde den Modellierungsfehler“-Übungen
|
||||
* Schließe jedes Kapitel mit einem kurzen Selbsttest ab (3 Multiple-Choice-Fragen).
|
||||
* Ergänze gezielte Debugging-Aufgaben: Code, der fehlerfrei kompiliert, aber betriebswirtschaftlich unsinnige Ergebnisse liefert (z. B. unendliche Produktion durch falsches Relationszeichen `>=` statt `<=`, vergessene Ganzzahligkeit oder Zirkelbezüge).
|
||||
|
||||
---
|
||||
|
||||
## 2. Software-Architektur und Code-Qualität
|
||||
|
||||
Hebe sämtliche Implementierungen im Buch auf ein sauberes, wartbares Enterprise-Niveau:
|
||||
|
||||
### A. Typsicherheit und Datenvalidierung
|
||||
* Verwende durchgängig moderne Python-Features (Python 3.11+): strenge Type Hints (`typing`), Dataclasses oder **Pydantic v2**-Modelle für alle Input- und Output-Daten (Ressourcen, Bedarfe, Kostenmatrizen).
|
||||
* Validiere Randbedingungen (z. B. strikt positive Kapazitäten, stochastische Vektoren mit Summe 1) bereits beim Einlesen der Daten.
|
||||
|
||||
### B. Klare Entkopplung (Clean Architecture / Service-Pattern)
|
||||
* Trenne Domänenlogik strikt von der Solver-API:
|
||||
$$\text{Rohdaten (Excel/JSON)} \longrightarrow \text{Pydantic-Domänenmodell} \longrightarrow \text{Model-Builder (Solver)} \longrightarrow \text{Lösungs-DTO}$$
|
||||
* Kursteilnehmer sollen lernen, wie man Modelle baut, bei denen der zugrundeliegende Solver (z. B. Wechsel von HiGHS auf Gurobi oder CP-SAT) ausgetauscht werden kann, ohne die Business-Logik neu schreiben zu müssen.
|
||||
|
||||
### C. Explizite Status- und Fehlerbehandlung
|
||||
* Beseitige alle impliziten Annahmen über optimale Lösungen.
|
||||
* Implementiere für jedes Modell eine explizite Auswertung des Solver-Status (`OPTIMAL`, `FEASIBLE`, `INFEASIBLE`, `UNBOUNDED`, `TIME_LIMIT`).
|
||||
* Zeige, wie Timeouts, Suboptimalitätsgrenzen (MIP-Gap) und Näherungslösungen im Code professionell abgefangen, protokolliert und weiterverarbeitet werden.
|
||||
|
||||
### D. Vektorisierte Modellgenerierung
|
||||
* Zeige in Kapitel 3 und fortgeschrittenen Beispielen, wie man bei großen Datenmengen langsame Python-`for`-Schleifen vermeidet.
|
||||
* Demonstriere den Einsatz von vektorisierten Matrizenoperationen (NumPy) bzw. Tabellen-Pipelines (**Polars** / **Pandas**), um tausende Nebenbedingungen performant aufzubauen.
|
||||
|
||||
---
|
||||
|
||||
## 3. Fachliche, methodische und algorithmische Erweiterungen
|
||||
|
||||
Schließe die methodischen Lücken zwischen akademischer Lehrbuch-Theorie und realer Industrie-Komplexität:
|
||||
|
||||
### A. Didaktische Harmonisierung: Der Wechsel von Logistik zu Finance
|
||||
* Schlage eine methodische Brücke vor Kapitel 11: Zeige auf, dass die mathematischen Strukturen der Portfoliotheorie identisch sind mit klassischen OR-Problemen (z. B. Ressourcenallokation im Lager $\leftrightarrow$ Kapitalallokation im Portfolio; Robustheit gegen Lieferkettenausfälle $\leftrightarrow$ Risikomaße gegen Kursabstürze).
|
||||
* Ergänze für Nicht-Finanz-Interessierte ein paralleles, alternatives Transfer-Beispiel (z. B. **Supply-Chain-Netzwerkdesign unter Unsicherheit** oder **Energieeinsatzplanung**), das dieselben mathematischen Werkzeuge (Stochastik, CVaR, Dynamische Programmierung) nutzt.
|
||||
|
||||
### B. Metaheuristiken für nicht-konvexe und großskalige Probleme
|
||||
* Ergänze einen praxisnahen Leitfaden für NP-schwere Probleme, bei denen exakte MILP-Solver an Skalierungsgrenzen stoßen.
|
||||
* Implementiere verständliche Metaheuristiken (z. B. Large Neighborhood Search (LNS), Genetische Algorithmen via `Pymoo` oder Simulated Annealing) für komplexe Touren- und Belegungsplanungs-Probleme.
|
||||
|
||||
### C. Multi-Objective-Optimierung und Pareto-Effizienz
|
||||
* Erkläre, warum einfache Zielgewichtungen ($\min w_1 f_1 + w_2 f_2$) bei Zielkonflikten in der Praxis oft versagen.
|
||||
* Implementiere praxisnah die **$\epsilon$-Constraint-Methode** und die lexikografische Optimierung (z. B. Minimierung von Logistikkosten bei gleichzeitiger Minimierung des CO₂-Ausstoßes) inklusive Visualisierung der Pareto-Front.
|
||||
|
||||
### D. Schnittstelle Data Science: Predict-then-Optimize
|
||||
* Zeige das Zusammenspiel von Machine Learning und Optimierung: Warum führt ein ML-Modell mit minimalem Vorhersagefehler (MSE) im nachgelagerten Optimierungsmodell oft zu suboptimalen Entscheidungen?
|
||||
* Demonstriere den Unterschied an einem Beispiel (Nachfrageprognose $\rightarrow$ Lagerbestandsoptimierung) und gib einen Ausblick auf differenzierbare Optimierungsschichten (`cvxpylayers`).
|
||||
|
||||
### E. NLP/MINLP und Warm-Starts
|
||||
* Zeige die Grundlagen nicht-konvexer Optimierung mit Open-Source-Solvern wie **Ipopt** (über CyIpopt).
|
||||
* Ergänze praxisnahe Code-Beispiele für **MIP-Warm-Starts** (Einspeisen bekannter Ausgangslösungen zur massiven Beschleunigung der Lösungszeit).
|
||||
|
||||
---
|
||||
|
||||
## 4. Numerik, Debugging und Produktionsreife (MLOps)
|
||||
|
||||
Stelle sicher, dass die Modelle der Kursteilnehmer auch im harten Produktivbetrieb fehlerfrei funktionieren:
|
||||
|
||||
### A. Numerische Stabilität, Konditionierung und Toleranzen
|
||||
* Erkläre die Matrix-Konditionszahl $\kappa(A)$ anhand eines konkreten Python-Experiments: Zeige, wie schlecht skalierte Koeffizienten (z. B. große Kostenbeträge gemischt mit winzigen Mengeneinheiten) zu scheinbar unlösbaren Modellen (`INFEASIBLE`) oder Lösungsdrift führen.
|
||||
* Zeige Standard-Skalierungsverfahren (Ruiz-Equilibrierung) und schärfe das Bewusstsein für Primal-, Dual- und Integrabilitäts-Toleranzen (z. B. warum $0.99999998$ niemals leichtfertig mit `int()` gerundet werden darf).
|
||||
|
||||
### B. Solver-Diagnose & Unlösbarkeits-Analyse (IIS)
|
||||
* Baue Anhang C zu einem vollwertigen Troubleshooting-Handbuch aus.
|
||||
* Implementiere Werkzeuge zur Ermittlung eines **Irreducible Infeasible Subsystem (IIS)** bzw. Conflict Refiners: Wie isoliert man in einem Modell mit tausenden Restriktionen automatisiert genau die Teilmenge, die den mathematischen Widerspruch erzeugt?
|
||||
* Erläutere, wie duale Entartung (Degeneriertheit) instabile Schattenpreise erzeugt und wie man fundierte Sensitivitätsanalysen für Entscheidungsträger erstellt.
|
||||
|
||||
### C. Testing, Benchmarking und API-Deployment
|
||||
* **Pytest-Framework:** Entwickle standardisierte Testroutinen für Optimierungsmodelle (Invarianztests, Überprüfung von Restriktionsverletzungen, Regressionstests an Benchmark-Instanzen).
|
||||
* **Solver-Benchmarks:** Zeige reproduzierbare Laufzeit- und Speicher-Benchmarks beim Vergleich von SciPy, HiGHS, OR-Tools und CVXPY über skalierende Instanzgrößen ($N \in \{10^2, 10^3, 10^4\}$).
|
||||
* **FastAPI & Async:** Zeige das Deployment eines Optimierungsmodells als Microservice via **FastAPI** mit asynchroner Aufgabenwarteschlange (Celery/Redis) für rechenintensive Solver-Läufe, inklusive eines kompakten `Dockerfile`.
|
||||
|
||||
---
|
||||
|
||||
## 5. Auszuführende Arbeitsanweisung
|
||||
|
||||
Setze diese Verbesserungen kapitelweise und systematisch um:
|
||||
1. **Analysiere** das jeweilige Kapitel auf didaktische Verständlichkeit, mathematische Zugänglichkeit und Code-Qualität.
|
||||
2. **Erstelle** für jedes Kapitel zuerst die „In 5 Minuten gelöst“-Box und die Formel-Übersetzer-Tabellen.
|
||||
3. **Refaktoriere** den Python-Code gemäß den Standards für Typsicherheit, Validierung und Statusbehandlung.
|
||||
4. **Erweitere** die methodischen Abschnitte und baue die praktischen Excel-/Pandas-Workflows ein.
|
||||
5. **Schließe** jedes Kapitel mit den Übungen zur Fehlerdiagnose („Finde den Denkfehler“) und den interaktiven Micro-Quizzes ab.
|
||||
|
||||
|
||||
|
||||
Im Einzelnen führe unter diesen Prämissen folgendes präzise und vollständig aus:
|
||||
|
||||
---
|
||||
|
||||
### 1. Architektur und Code-Qualität: Transformation zu produktionsreifem Python
|
||||
Überarbeite alle Skripte und Code-Beispiele im Buch nach modernen Software-Engineering-Standards:
|
||||
* **Typsicherheit & Verträge:** Führe durchgehend Type Hints (`typing`, `mypy`-kompatibel) und Laufzeitvalidierung via **Pydantic v2** für alle Modellparameter (z. B. Nachfragedaten, Kapazitäten, Renditevektoren) ein.
|
||||
* **Trennung von Domäne und Solver:** Refaktoriere den Code so, dass Domänenlogik strikt von der Solver-Syntax getrennt ist. Führe ein klares Repository-/Service-Pattern ein: Rohdaten $\rightarrow$ Validiertes Domänenmodell $\rightarrow$ Solver-Builder (z. B. CVXPY/OR-Tools) $\rightarrow$ Lösungs-DTO.
|
||||
* **Fehler- und Statusbehandlung:** Ersetze implizite Annahmen über Solver-Ergebnisse durch explizite Fehlerbehandlung für Randfälle: `INFEASIBLE`, `UNBOUNDED`, `NUMERICAL_ERROR` oder Timeouts. Zeige für MILP und CP-SAT, wie Suboptimalitätsgrenzen (MIP-Gap) und Abbruchkriterien sauber abgefangen und geloggt werden.
|
||||
|
||||
---
|
||||
|
||||
### 2. Methodische Ergänzungen: Schließen der algorithmischen Lücken
|
||||
Ergänze den theoretischen und praktischen Kanon um drei bisher unterrepräsentierte, in der Praxis aber essenzielle Bereiche:
|
||||
* **Metaheuristiken für Nicht-Konvexes & NP-Schwere (Neues Kapitel oder Brückenteil):**
|
||||
* Integriere einen praktischen Leitfaden für Probleme, bei denen exakte Solver (HiGHS, CP-SAT) skalierungsbedingt scheitern.
|
||||
* Implementiere praxisnahe Metaheuristiken (z. B. Large Neighborhood Search (LNS), Simulated Annealing oder Genetische Algorithmen) mit Bibliotheken wie `Pymoo` oder nativem Python für großskalige Vehicle-Routing- oder Scheduling-Instanzen.
|
||||
* **Nicht-lineare nicht-konvexe Optimierung (NLP / MINLP):**
|
||||
* Zeige den praktischen Einsatz von Solvern wie **Ipopt** (über CyIpopt oder Pyomo/CasADi) für nicht-konvexe kontinuierliche Probleme. Diskutiere den Unterschied zwischen lokalen und globalen Optima sowie Strategien zur Wahl von Startwerten (Warm-Starts).
|
||||
* **Warm-Starts & Dekomposition:**
|
||||
* Ergänze in Teil II praxisnahe Beispiele für **MIP Warm-Starts** (Einspeisen bekannter zulässiger Lösungen) sowie eine verständliche Einführung in Dekompositionsverfahren (z. B. Spaltengenerierung / Dantzig-Wolfe für Cutting-Stock- oder Crew-Scheduling-Probleme).
|
||||
|
||||
---
|
||||
|
||||
### 3. Didaktische Harmonisierung: Glättung des Wechsels von Logistik zu Finance
|
||||
Löse den abrupten thematischen Bruch zwischen Teil II/III (diskrete Optimierung, Logistik) und Teil IV (Finanzmärkte):
|
||||
* **Konzeptionelle Brückenkapitel:** Führe vor Kapitel 11 eine explizite methodische Überleitung ein: Zeige, dass die mathematischen Strukturen identisch sind (z. B. Resource Allocation in der Produktion $\leftrightarrow$ Kapitalallokation im Portfolio; Robust Counterparts bei Lieferkettenausfällen $\leftrightarrow$ Worst-Case-Risikomaße am Markt).
|
||||
* **Entflechtung der Zielgruppen:**
|
||||
* Kennzeichne Teil IV klar als spezialisierte Vertiefungsdomäne.
|
||||
* Ergänze für Leser, die *nicht* aus dem Finanzbereich kommen, ein paralleles, alternatives Vertiefungskapitel für industrielle Wertschöpfung (z. B. **Supply-Chain-Netzwerkdesign unter Unsicherheit** oder **Energie- und Kraftwerkseinsatzplanung**), das dieselben mathematischen Werkzeuge (Stochastik, CVaR/Robustheit, dynamische Programmierung) auf physische Systeme anwendet.
|
||||
|
||||
---
|
||||
|
||||
### 4. Enterprise-Testing, Benchmarking & MLOps-Integration
|
||||
Erweitere Kapitel 15 und die Projektwerkstatt um operative Deployment-Standards:
|
||||
* **Testing-Framework für Optimierungsmodelle:**
|
||||
* Entwickle ein dediziertes Testkonzept mit `pytest`: Regressionstests gegen bekannte Testinstanzen, Validierung von Restriktionsverletzungen (Infeasibility-Checks) und Invarianztests (z. B. Skalierungsinvarianz der Zielfunktion).
|
||||
* **Benchmarking & Performance-Profiling:**
|
||||
* Baue eine strukturierte Benchmark-Pipeline auf: Vergleich von Lösungszeit und Speicherverbrauch zwischen SciPy, HiGHS, Google OR-Tools und CVXPY bei wachsender Problemgröße ($N \in \{10^2, 10^3, 10^4, 10^5\}$).
|
||||
* **Containerisierung & API-Bereitstellung:**
|
||||
* Zeige die Kapselung eines Optimierungsmodells in einer **FastAPI**-Anwendung inklusive asynchroner Job-Queue (z. B. via Celery/Redis) für länger laufende Solver-Jobs.
|
||||
* Liefere ein einsatzbereites `Dockerfile`, das C++-Abhängigkeiten und Solver-Bibliotheken performant und schlank baut.
|
||||
|
||||
---
|
||||
|
||||
### 5. Format, Interaktivität und Leseerlebnis
|
||||
* **Interaktive Ausführungsumgebung:** Ergänze jedes Kapitel um Links zu validierten Jupyter Notebooks bzw. Google-Colab-Instanzen mit One-Click-Setup (`pip install highs cvxpy ortools ...`).
|
||||
* **Visualisierungs-Upgrade:** Ersetze rein statische Matplotlib-Plots durch interaktive Visualisierungen (z. B. via `Plotly` für 3D-Konvexitätsflächen, KKT-Bedingungen, Pareto-Fronten bei Multi-Objective-Problemen und dynamische Gantt-Diagramme in CP-SAT).
|
||||
* **Entscheidungs-Flussdiagramm:** Füge zu Beginn von Teil II und Teil III ein visuelles Ablaufdiagramm ein: *„Welcher Solver / welches Paradigma passt zu meinem Problem?“* (Entscheidungskriterien: linear vs. nichtlinear, stetig vs. diskret, konvex vs. nicht-konvex, Skalierungsanforderungen, Lösungszeitgarantien).
|
||||
|
||||
---
|
||||
|
||||
### 6. Numerische Stabilität, Konditionierung und Skalierung (Deep Dive)
|
||||
Erweitere Kapitel 2, 4 und Anhang C um einen tiefgehenden praktischen Leitfaden zur numerischen Linearen Algebra:
|
||||
* **Konditionszahlen in der Praxis:** Erkläre nicht nur formal die Matrix-Konditionszahl $\kappa(A)$, sondern demonstriere mit einem konkreten Python-Experiment, wie schlecht skalierte Koeffizienten (z. B. Kosten im Bereich $10^7$ kombiniert mit Toleranzen von $10^{-6}$) zu stillschweigendem Lösungsdrift oder falschen `INFEASIBLE`-Meldungen führen.
|
||||
* **Skalierungs- und Vorverarbeitungs-Routinen:** Zeige, wie man Koeffizientenmatrizen systematisch über Methoden wie Ruiz-Equilibrierung oder geometrische Skalierung transformiert, bevor sie an den Solver übergeben werden.
|
||||
* **Toleranzen verstehen:** Schärfe das Bewusstsein für Primal-, Dual- und Integrabilitäts-Toleranzen der Solver (z. B. `feasibility_tolerance` in HiGHS vs. OR-Tools). Erkläre, warum eine Variable mit dem Wert `0.99999998` in einem MILP nicht einfach mit `int()` gecastet werden darf.
|
||||
|
||||
---
|
||||
|
||||
### 7. Modernes Modellierungs-Ökosystem: Pyomo, Linopy und Polars
|
||||
Erweitere Kapitel 3 um moderne Modellierungs-Frameworks und Big-Data-Anbindungen:
|
||||
* **Evaluierung von Linopy & Pyomo:** CVXPY und OR-Tools decken viel ab, aber für große industrielle LP/MILP-Probleme sind **Pyomo** (als klassischer Industriestandard) oder das neuere **Linopy** (optimiert für $N$-dimensionale xarray-Strukturen und extrem schnelle Matrix-Generierung) unverzichtbar. Ergänze einen kompakten Vergleich dieser Modellierungsschichten.
|
||||
* **Polars & Vektorisierte Modellgenerierung:** In der Praxis verbringen OR-Ingenieure oft 80 % der Rechenzeit nicht im Solver, sondern beim Aufbau der Constraints über langsame Python-`for`-Schleifen. Zeige, wie man mithilfe von **Polars** oder Vektorisierung in NumPy Millionen von Nebenbedingungen um Größenordnungen schneller konstruiert.
|
||||
|
||||
---
|
||||
|
||||
### 8. Schnittstelle zwischen Machine Learning und Operations Research (Smart Predict-then-Optimize)
|
||||
Baue in Teil III oder IV eine methodische Brücke zur modernen Data Science:
|
||||
* **Predict-then-Optimize:** Zeige das Zusammenspiel von Prognose und Optimierung. Klassische ML-Modelle minimieren den Mean Squared Error (MSE), nicht die Kosten im nachgelagerten Optimierungsmodell. Demonstriere anhand eines Beispiels (z. B. Nachfrageprognose $\rightarrow$ Lagerhaltung), warum ein isoliert „gutes“ ML-Modell zu teuren OR-Entscheidungen führen kann.
|
||||
* **Differenzierbare Optimierung:** Führe kurz das Paradigma differenzierbarer Layer ein (z. B. über `cvxpylayers`), bei denen Optimierungsmodelle als Schicht direkt in neuronale PyTorch-Netze eingebettet werden können.
|
||||
|
||||
---
|
||||
|
||||
### 9. Multi-Objective-Optimierung und Pareto-Effizienz
|
||||
Ergänze in Teil II und Teil IV die Behandlung konkurrierender Zielkonflikte, die in realen Projekten die Regel sind:
|
||||
* **Jenseits linearer Skalarisierung:** Erkläre, warum die simple Gewichtung von Zielen ($\min w_1 f_1 + w_2 f_2$) bei nicht-konvexen Pareto-Fronten versagt und wie man stattdessen mit der **$\epsilon$-Constraint-Methode** oder lexikografischer (hierarchischer) Optimierung arbeitet.
|
||||
* **Praxisbeispiel:** Implementiere ein zweidimensionales Trade-off-Modell (z. B. Kosten vs. CO₂-Ausstoß in der Tourenplanung oder Rendite vs. Drawdown) und berechne die exakte Pareto-Front inklusive Visualisierung.
|
||||
|
||||
---
|
||||
|
||||
### 10. Professionelle Solver-Diagnose und Unlösbarkeits-Analyse (IIS)
|
||||
Vertiefe Anhang C (Fehlerdiagnose) um fortgeschrittene Debugging-Techniken:
|
||||
* **Irreducible Infeasible Subsystem (IIS):** Wenn ein Modell mit 50.000 Restriktionen `INFEASIBLE` meldet, ist der Entwickler ohne Werkzeuge verloren. Erkläre die mathematische Funktionsweise eines IIS/Conflict Refiners und zeige, wie man mit Python-Mitteln isoliert, welche minimale Teilmenge von Restriktionen den Konflikt verursacht.
|
||||
* **Dual-Analyse bei Degeneriertheit:** Zeige auf, wie duale Entartung (Multiple Dual Solutions) dazu führt, dass Schattenpreise instabil werden, und wie man damit bei Sensitivitätsanalysen für das Management umgeht.
|
||||
|
||||
|
||||
|
||||
|
||||
### 11. Didaktischer Kurs-Fokus: Motivation, Zugänglichkeit & Praxistransfer
|
||||
|
||||
Unter der Prämisse, dass das Buch primär als **didaktischer Kursbegleiter** dient, müssen rein akademische Vertiefungen und industrielle Enterprise-Overheads zurücktreten. Im Zentrum stehen drei Faktoren:
|
||||
1. **Sofortige Erfolgserlebnisse (Time-to-First-Success)**,
|
||||
2. **Kognitive Entlastung bei Hürden** (Mathematik, Solver-Syntax, Debugging),
|
||||
3. **Direkte Übertragbarkeit in den Arbeitsalltag**.
|
||||
|
||||
Führe zur Umsetzung dieser Kursziele die folgenden didaktischen und strukturellen Verbesserungen aus:
|
||||
|
||||
---
|
||||
|
||||
### 11.1. Das „5-Minuten-Erfolgserlebnis“ an den Anfang jedes Kapitels stellen
|
||||
* **Didaktisches Problem:** Wer erst 15 Seiten Vektorräume oder Simplex-Tableaus liest, bevor der erste Code läuft, verliert Motivation und Schwung.
|
||||
* **Maßnahme:**
|
||||
* Jedes Kapitel beginnt mit einer **„In 5 Minuten gelöst“-Box**: Ein minimales, realistisches Mini-Problem (z. B. 4 Zeilen Daten, 6 Zeilen Python-Code), das der Teilnehmer per Copy-Paste sofort ausführt und dessen Ergebnis sofort einleuchtet.
|
||||
* Erst **nach** dem funktionierenden Ergebnis folgt die methodische Erklärung: *„Warum funktioniert das? Wie rechnet der Solver das im Hintergrund? Was bedeuten die Variablen?“*
|
||||
* **Effekt:** Neugier und Selbstwirksamkeit statt theoretischer Lähmung.
|
||||
|
||||
---
|
||||
|
||||
### 11.2. Duale Lesart: „Mathe für Anwender“ mit visuellen Analogien
|
||||
* **Didaktisches Problem:** Die Formelsprache (Summenzeichen mit Doppelindizes, Matrixschreibweisen, KKT-Gradienten) wirkt auf Praktiker oft abschreckend.
|
||||
* **Maßnahme:**
|
||||
* **Formel-Übersetzer-Boxen:** Jede zentrale mathematische Formulierung erhält eine zweispaltige Darstellung:
|
||||
* Links: Die mathematische Formel $\sum_{i \in I} x_{i,j} \le C_j$.
|
||||
* Rechts: Der Klartext in Alltagssprache: *„Für jede Maschine $j$ darf die Summe aller zugewiesenen Aufträge $i$ die Gesamtkapazität $C_j$ nicht überschreiten.“*
|
||||
* **Geometrische Intuition vor algebraischem Beweis:** Konvexität, Simplex-Ecken und Branch-and-Bound-Bäume zuerst als 2D-Skizzen und anschauliche Metaphern (z. B. „Eine Seifenblase, die sich in die Ecke eines Zimmers spannt“) einführen, bevor algebraische Definitionen folgen.
|
||||
|
||||
---
|
||||
|
||||
### 11.3. „Excel-zu-Python“-Brücken für den Berufsalltag bauen
|
||||
* **Didaktisches Problem:** Im betrieblichen Alltag liegen 90 % aller Daten in Tabellenkalkulationen, und viele Kursteilnehmer kennen Optimierung bisher nur aus dem Excel-Solver.
|
||||
* **Maßnahme:**
|
||||
* Baue in Kapitel 1 und Kapitel 3 explizite Brücken: *„Wie Sie Ihr Excel-Solver-Modell in sauberen Python-Code übersetzen.“*
|
||||
* Zeige, wie Parameter direkt aus `pandas.read_excel()` oder CSV eingelesen, als Modell formuliert und die optimierten Zuweisungen wieder als saubere Excel-Tabelle mit Kennzahlen exportiert werden.
|
||||
* **Effekt:** Die Teilnehmer können das Gelernte am nächsten Tag direkt an ihren eigenen Arbeitsdateien ausprobieren.
|
||||
|
||||
---
|
||||
|
||||
### 11.4. Spickzettel & Visuelle Checklisten („Cheat Sheets“)
|
||||
* **Didaktisches Problem:** Wenn Teilnehmer ein eigenes Problem lösen wollen, wissen sie oft nicht, welcher Baustein (Variable, Constraint, Zielfunktion) wie in Python heißt.
|
||||
* **Maßnahme:**
|
||||
* **1-Seiten-Syntax-Cheat-Sheet:** Eine kompakte Übersichtstabelle für die drei Hauptwerkzeuge (SciPy, OR-Tools, CVXPY):
|
||||
* *Wie definiere ich eine Binärvariable?*
|
||||
* *Wie formuliere ich eine Entweder-Oder-Bedingung?*
|
||||
* *Wie setze ich eine Obergrenze?*
|
||||
* *Wie lese ich den optimalen Wert aus?*
|
||||
* **Modellierungs-Baukasten:** Visuelle Rezeptkarten für Standardfragen des Arbeitsalltags: *„Wie modelliere ich Mindestabnahmemengen?“, „Wie verhindere ich Rüstzeiten?“, „Wie baue ich ein Budgetlimit ein?“*
|
||||
|
||||
---
|
||||
|
||||
### 11.5. Selbsteinschätzungs-Meilensteine & „Finde den Denkfehler“-Übungen
|
||||
* **Didaktisches Problem:** Reine Programmieraufgaben frustrieren, wenn man an Syntax-Details hängenbleibt.
|
||||
* **Maßnahme:**
|
||||
* Ergänze jedes Kapitel um 2–3 kurze **Micro-Quizzes** (3 Multiple-Choice-Fragen) zur Selbstkontrolle vor dem nächsten Kapitel.
|
||||
* Führe **„Finde den Modellierungsfehler“-Aufgaben** ein: Der Code läuft fehlerfrei durch, aber das Ergebnis ist unplausibel (z. B. Maschine produziert unendlich viel, weil eine Nebenbedingung als `>=` statt `<=` formuliert wurde; oder Ganzzahligkeit vergessen).
|
||||
* **Effekt:** Das schult den kritischen Blick auf Ergebnisse, der in der Praxis wichtiger ist als das reine Schreiben von Code.
|
||||
|
||||
---
|
||||
|
||||
### 11.6. Praxistransfer-Protokoll: „Vom Management-Wunsch zum Modell“
|
||||
* **Didaktisches Problem:** Im Berufsleben kommt selten jemand mit einer fertigen Zielfunktion. Chefs und Fachabteilungen formulieren vage: *„Wir wollen die Kosten senken, aber die Mitarbeiter sollen nicht meckern und die Liefertreue muss hoch bleiben.“*
|
||||
* **Maßnahme:**
|
||||
* Ergänze ein methodisches Kapitel oder Leitfaden: **„Anforderungsanalyse für OR-Projekte“**.
|
||||
* Zeige anhand eines realistischen Dialogs, wie man vage Geschäftsanforderungen systematisch zerlegt:
|
||||
1. Was sind die echten Stellschrauben? $\rightarrow$ *Entscheidungsvariablen*
|
||||
2. Was sind harte Grenzen, was weiche Wünsche? $\rightarrow$ *Harte vs. Weiche Constraints (Penalties)*
|
||||
3. Woran messen wir Erfolg wirklich? $\rightarrow$ *Zielfunktion*
|
||||
* **Effekt:** Die Teilnehmer lernen die wichtigste Fähigkeit für den Arbeitsalltag: das Übersetzen von Business-Problemen in mathematische Logik.
|
||||
|
||||
|
||||
|
|
@ -1,60 +0,0 @@
|
|||
### Rolle und Ziel
|
||||
Du bist ein erfahrener Fachlektor, Senior Operations Research Scientist und Principal Systems Architect für High-Performance Analytics. Überarbeite und perfektioniere das Kompendium **„Optimierte Entscheidungsfindung mit Python“ (Version 04)** von Dieter Schlüter.
|
||||
|
||||
Das Werk hat mit Version 04 bereits ein herausragendes didaktisches Niveau erreicht. Ziel dieser nächsten Revision ist es, die letzten verbliebenen Hürden in **Software-Architektur, Packaging, Skalierung auf Multithreading/HPC, Explainable Optimization und Visualisierung** zu beseitigen.
|
||||
|
||||
Setze die folgenden präzisen Arbeitspakete vollständig um:
|
||||
|
||||
---
|
||||
|
||||
### 1. Bereinigung des C++-Symbolkonflikts und modernes Packaging
|
||||
* **Das Problem:** Derzeit crasht die gemeinsame Verwendung von `ortools` und `highspy` im selben Prozess durch doppelte HiGHS-Symbolauflösungen im dynamic linker, was im Buch über umständliche `subprocess`-Wrapper gelöst wird.
|
||||
* **Maßnahme:**
|
||||
* Implementiere im Setup- und Architektur-Teil ein sauberes, produktionsreifes Isolationskonzept: Zeige auf, wie ein solches Multi-Solver-Setup über **Multiprocessing mit `ProcessPoolExecutor` / IPC** oder über modulare Worker-Architekturen gelöst wird, ohne auf instabile `subprocess.run([sys.executable, "-c", ...])`-Strings zurückzugreifen.
|
||||
* Baue für das Buch ein begleitendes `pyproject.toml` (unter Verwendung von `uv` oder `poetry`) mit optionalen Dependency-Gruppen (`extras = ["finance", "large-scale", "api"]`), damit Kursteilnehmer schlanke, isolierte Umgebungen ohne überflüssigen Overhead aufsetzen können.
|
||||
* Erstelle ein offizielles, mehrstufiges `Dockerfile` (Multi-Stage Build), das die Solver sauber kompiliert bzw. bindet und ein reproduzierbares Kurs-Image bereitstellt.
|
||||
|
||||
---
|
||||
|
||||
### 2. Multi-Core, Parallelisierung und Solver-Ressourcenmanagement
|
||||
* **Das Problem:** In Version 04 wird Parallelität nur am Rande bei Benchmarks berührt; viele Beispiele laufen standardmäßig auf einem Core.
|
||||
* **Maßnahme:**
|
||||
* Ergänze in Kapitel 6 (MILP) und Kapitel 7 (CP-SAT) einen dedizierten Abschnitt über **Multi-Threading und deterministische Suche**:
|
||||
* Wie nutzt man `num_workers` in CP-SAT und HiGHS optimal aus?
|
||||
* Was bedeutet Nicht-Determinismus bei paralleler Branch-and-Bound-Suche (Race Conditions bei Incumbents) und wie erzwingt man reproduzierbare Runs für Tests?
|
||||
* Zeige in Kapitel 23 auf, wie man parallele Modellläufe (z. B. Szenarienanalysen in Monte-Carlo oder Hyperparameter-Tuning in Metaheuristiken) speichereffizient über `joblib` oder `ray` verteilt, ohne das Python-GIL zum Flaschenhals zu machen.
|
||||
|
||||
---
|
||||
|
||||
### 3. Explainable AI / Explainable Optimization (X-OR) für Entscheider
|
||||
* **Das Problem:** Wenn das Modell eine Lösung ausgibt, fragen Fachabteilungen und Betriebsräte: *„Warum genau diese Zuweisung und nicht jene?“* Schattenpreise beantworten das nur lokal bei LPs.
|
||||
* **Maßnahme:**
|
||||
* Erweitere Kapitel 4 („Vom Wunsch zum Modell“) und Kapitel 22 („Praxisfallen“) um Methoden der **Erklärbaren Optimierung**:
|
||||
* **Automatisierte Was-wäre-wenn-Analysen (Counterfactual Explanations):** Wie viel schlechter wird der Zielfunktionswert, wenn man eine vom Disponenten gewünschte manuelle Zuweisung fest erzwingt?
|
||||
* **Constraint Attribution:** Ein System, das visualisiert, welche 3 Nebenbedingungen die größten Opportunitätskosten (Erlöseinbußen) verursachen.
|
||||
* **Generierung natürlicher Sprachberichte:** Zeige, wie man aus den Dualwerten und Slack-Variablen automatisiert textuelle Zusammenfassungen für das Management formuliert (z. B.: *„Plan B kostet 4.200 € mehr, weil die gesetzliche Ruhezeit von Mitarbeiter X die günstigere Schicht blockiert.“*).
|
||||
|
||||
---
|
||||
|
||||
|
||||
### 4. Stochastik & Unsicherheit: Chance-Constrained Programming
|
||||
* **Das Problem:** Kapitel 12 behandelt Monte-Carlo, zweistufige stochastische Programmierung und Worst-Case-Robustheit. In der Industrie verlangt das Management jedoch fast immer Wahrscheinlichkeitszusagen („Mit 95 % Sicherheit darf der Tank nicht leerlaufen“).
|
||||
* **Maßnahme:**
|
||||
* Ergänze in Kapitel 12 einen Abschnitt zu **Wahrscheinlichkeitsbeschränkungen (Chance Constraints / Probabilistic Constraints)**:
|
||||
* Zeige, wie Bedingungen der Form $P(a^\top x \le b) \ge 1 - \alpha$ unter Normalverteilungsannahmen in deterministische Second-Order Cone Constraints (SOCP via CVXPY) umgeformt werden.
|
||||
* Zeige die szenariobasierte Alternative (Big-M mit Binärvariablen für Ausfall-Szenarien) für beliebige, empirische Verteilungen.
|
||||
|
||||
---
|
||||
|
||||
### 5. Didaktisches Redigieren: Kognitive Entlastung und modulare Leseführung
|
||||
* **Das Problem:** Bei über 700 Seiten droht das Buch neue Kursteilnehmer trotz Lernpfaden zu erschlagen.
|
||||
* **Maßnahme:**
|
||||
* Führe ein klares visuelles Farbleitsystem (Callout-Typen) ein:
|
||||
* `[Muss für alle]` (Kernkonzepte und Code).
|
||||
* `[Nur für Entwickler]` (NumPy-Vektorisierung, CSR-Format, Profiling).
|
||||
* `[Nur für Management/Planer]` (Kennzahleninterpretation, Zielkonflikte, Heuristiken).
|
||||
* Ergänze am Ende von Teil I bis IV jeweils eine **„Synthese-Doppelseite“**, die die Kernideen auf einen Blick zusammenfasst (Mindmap + Entscheidungsmatrix), damit Kursteilnehmer vor den Übungen rekapitulieren können, ohne zurückblättern zu müssen.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,90 +0,0 @@
|
|||
### Rolle und Ziel
|
||||
Du bist ein erfahrener Kursdesigner, Senior Operations Research Consultant und Full-Stack Python Architect. Überarbeite das Kompendium **„Optimierte Entscheidungsfindung mit Python“** mit dem klaren Fokus auf **maximale Zugänglichkeit, Begeisterung und sofortige betriebliche Überzeugungskraft** für eine heterogene Zielgruppe (Studierende, Manager, Ingenieure, Entscheider, Investoren).
|
||||
|
||||
Beseitige die Hürde, dass Nicht-Programmierer und Entscheider sich durch Jupyter Notebooks oder Terminal-Ausgaben kämpfen müssen. Mache Operations Research zu einem **visuellen, interaktiven und präsentierbaren Erlebnis**, das Kursteilnehmer direkt als Argumentationshilfe im Unternehmen nutzen können.
|
||||
|
||||
Setze dazu die folgenden sechs Module präzise um:
|
||||
|
||||
---
|
||||
|
||||
### 1. Interaktive Streamlit-Apps als primäre Nutzeroberfläche (No-Code/Low-Code)
|
||||
Ersetze für Einsteiger und Nicht-Programmierer die reine Notebook-Nutzung durch sofort startbare, leicht verständliche **Streamlit-Web-Apps** (unter 80 Zeilen Code je App):
|
||||
* **Baukasten-Prinzip:** Kursteilnehmer müssen keinen UI-Code von Grund auf schreiben, sondern erhalten standardisierte App-Templates:
|
||||
* `app_schichtplan.py` (Personal & Disposition)
|
||||
* `app_touren.py` (Logistik & Routing)
|
||||
* `app_portfolio.py` (Investoren & Finanzen)
|
||||
* `app_produktionsmix.py` (Ingenieure & Fertigung)
|
||||
* **Interaktive Eingabeelemente:**
|
||||
* **Schieberegler (Sliders):** Budgets, Rohstoffpreise, Risikoaversion $\lambda$, Überstundenlimits dynamisch verändern.
|
||||
* **Toggles/Checkboxen:** Einzelne Restriktionen live zu- oder abschalten (z. B. *„Mitarbeiter X darf am Wochenende arbeiten: Ja/Nein“* oder *„Maximal 3 Positionen im Depot: An/Aus“*).
|
||||
* **Excel-Upload:** Drag-and-Drop für `.xlsx`-Dateien, sodass Entscheider sofort eigene Unternehmensdaten einwerfen und per Mausklick optimieren können.
|
||||
* **1-Klick-Ausführung:** Bereitstellung eines zentralen Startskripts (z. B. `streamlit run dashboard.py` oder vorkonfigurierte Cloud-Demos via Streamlit Community Cloud), damit auch technisch unerfahrene Teilnehmer in unter 60 Sekunden ihre erste eigene Optimierungs-App im Browser bedienen.
|
||||
|
||||
---
|
||||
|
||||
### 2. Interaktive Dashboards und UI-Brücke (Streamlit / Panel)
|
||||
* **Das Problem:** Die Excel-Brücke in Kapitel 1.8 ist hervorragend, aber moderne Disponenten und Manager verlangen nach browserbasierten Dashboards mit Sofort-Feedback.
|
||||
* **Maßnahme:**
|
||||
* Ergänze die Projektwerkstatt (z. B. Projekt P1 „Schul-Vertretungsplaner“ oder P3 „Liefertouren“) um eine kompakte, einsatzbereite **Streamlit-Web-App** (unter 100 Zeilen Code):
|
||||
1. Upload von Excel-Dateien per Drag-and-Drop.
|
||||
2. Slider für Parameter und Gewichte (Budgetgrenzen, Überstundentoleranz).
|
||||
3. Live-Visualisierung der Ergebnisse: Interaktive Gantt-Charts (via Plotly) für Maschinenbelegung und Folium-Karten für Routen.
|
||||
4. 1-Klick-Download des optimierten Excel-Ergebnisberichts.
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
### 3. Präsentationsreife Management-Visualisierungen (Visual ROI)
|
||||
Ersetze reine Tabellen- und Textausgaben durch Grafiken, die Kursteilnehmer ohne Nachbearbeitung direkt in eine Vorstandspräsentation oder Team-Besprechung einfügen können:
|
||||
* **Interaktive Gantt-Diagramme (Plotly):** Für Schicht- und Maschinenbelegungspläne mit farbkodierter Auslastung, visualisierten Rüstzeiten und sofort erkennbaren Puffern.
|
||||
* **Geografische Routenkarten (Folium / Plotly Mapbox):** Für Logistik und Außendienst: Anzeige der optimalen Touren auf echten Straßenkarten mit nummerierten Stopps, Depotstandorten und interaktiven Tooltips zu Liefermengen und Zeitfenstern.
|
||||
* **Vorher-Nachher-Wasserfalldiagramme (Business Impact):**
|
||||
* Gegenüberstellung: *Heuristik / Bauchgefühl des Disponenten* vs. *Optimierte Solver-Lösung*.
|
||||
* Zeige in Euro und Prozent den genauen Mehrwert (z. B. Einsparung von 12 % Treibstoff, 4.500 € weniger Strafkosten, 15 % höhere Maschinenauslastung).
|
||||
* **Interaktive Pareto-Fronten mit Klick-Auswahl:**
|
||||
* Schieberegler für Multi-Objective-Trade-offs: Ein Klick auf die Pareto-Kurve zeigt dem Management sofort den Plan: *„Wenn wir 5 % mehr CO₂ einsparen wollen, kostet uns das exakt 3.200 € mehr Logistikkosten.“*
|
||||
|
||||
---
|
||||
|
||||
### 4. Zielgruppen-spezifische „One-Pager“ & Einstiegsdialoge
|
||||
Differenziere den Kurseinstieg nach den vier Hauptzielgruppen, um jede Gruppe bei ihren spezifischen Schmerzpunkten abzuholen:
|
||||
* **Für Manager & Entscheider („Der Business-Case“):**
|
||||
* 1-Seiter vor jedem Großthema: *„Was bringt das dem Unternehmen?“*, *„Typischer ROI und Amortisationszeit“*, *„Wie verkaufe ich das dem Betriebsrat/der Geschäftsführung?“*.
|
||||
* **Für Ingenieure & Produktionsplaner („Die Physik des Systems“):**
|
||||
* Fokus auf Engpässe, Taktzeiten, Rüstkosten, Kapazitätsabgleiche und Toleranzen.
|
||||
* **Für Investoren & Finanzanalysten („Risiko & Ertrag“):**
|
||||
* Fokus auf Diversifikationseffizienz, Drawdown-Minimierung, Tail-Risk (CVaR) und Rebalancing-Transaktionskosten.
|
||||
* **Für Studierende & Data Scientists („Die Methodik“):**
|
||||
* Fokus auf algorithmische Eleganz, saubere Formulierung und den Brückenschlag von Machine-Learning-Prognosen zur Optimierung.
|
||||
|
||||
---
|
||||
|
||||
### 5. Der „Was-wäre-wenn“-Simulator (Sandbox-Modus)
|
||||
Mache Optimierung greifbar, indem Kursteilnehmer erleben, wie das System auf unvorhergesehene Ereignisse reagiert:
|
||||
* Baue in die Streamlit-Apps einen **Szenarien-Simulator** ein:
|
||||
* *„Was passiert, wenn Rohstoff A plötzlich 30 % teurer wird?“*
|
||||
* *„Was passiert, wenn Maschine 2 für 48 Stunden ausfällt?“*
|
||||
* *„Was passiert, wenn ein Stammkunde seine Bestellmenge verdoppelt?“*
|
||||
* **Live-Delta-Anzeige:** Die App berechnet in Sekundenbruchteilen die neue Zuweisung und blendet einen roten/grünen Differenzbericht ein: *„Ausweichplan gefunden: 800 € Mehrkosten, alle Liefertermine gehalten.“*
|
||||
* **Lerneffekt:** Entscheider begreifen sofort, dass OR nicht nur starre Pläne erzeugt, sondern ein mächtiges digitales Notfall- und Simulationswerkzeug für den Ernstfall ist.
|
||||
|
||||
---
|
||||
|
||||
### 6. Management-taugliche 1-Klick-Exporte (PDF & Excel)
|
||||
Damit der Praxistransfer im Arbeitsalltag nicht an der Weitergabe der Ergebnisse scheitert:
|
||||
* Integriere in jede Streamlit-Vorlage eine **Export-Engine**:
|
||||
* **Excel-Export:** Schreibt einen fertigen, optisch ansprechend formatierten Dienst- oder Produktionsplan mit Summenformeln und Kennzahlen zurück in eine `.xlsx`-Datei, die der Disponent direkt an die Mitarbeiter aushändigen kann.
|
||||
* **Executive PDF-Report:** Ein 1-seitiger Management-Summary-Report (via ReportLab oder Weasyprint), der die wichtigsten Kennzahlen, Kostenvergleiche und das Hauptdiagramm für die nächste Abteilungsleiter-Runde zusammenfasst.
|
||||
|
||||
---
|
||||
|
||||
### 7. Didaktisches Redigieren: Glossar für Nicht-Mathematiker („Deutsch – OR / OR – Deutsch“)
|
||||
* Ergänze den Einstieg und die Anhänge um ein pragmatisches **Übersetzungslexikon für den Berufsalltag**:
|
||||
* *„Wir haben nicht genug Budget/Zeit“* $\rightarrow$ Harte Kapazitätsrestriktion (`<= b`).
|
||||
* *„Mitarbeiter X möchte lieber vormittags arbeiten“* $\rightarrow$ Weiche Restriktion mit Strafkosten (Penalty).
|
||||
* *„Was bringt mir eine zusätzliche Arbeitsstunde?“* $\rightarrow$ Schattenpreis / Dualwert.
|
||||
* *„Wir können nur ganze Kisten liefern“* $\rightarrow$ Ganzzahligkeitsbedingung (MILP).
|
||||
* *„Wenn wir Anlage A bauen, brauchen wir auch Lager B“* $\rightarrow$ Logische Verknüpfung / Big-M.
|
||||
* **Effekt:** Senkt die Fachsprachenbarriere radikal und befähigt jeden Teilnehmer, Fachprobleme aus Besprechungen sofort in die richtigen mathematischen Bausteine zu übersetzen.
|
||||
|
||||
|
|
@ -116,7 +116,7 @@ pip install -r Operations_Research_mit_Python_Version_04_Programme/requirements.
|
|||
| `Operations_Research_mit_Python_Version_04/` | **Quelle**: 37 Kapiteldateien (inkl. 5 Teil-Synthesen) + Build-Skripte |
|
||||
| `bilder_04/` | **Quelle**: 33 Diagramme (SVG) + 16 `erzeuge_*.py`-Generatoren |
|
||||
| `web_04/` | **Quelle**: `site.css`, `site.js`, `icons.svg`, `plotly.min.js`, `katex/` — die statischen Bestandteile der Website |
|
||||
| `Kritik_und_Verbesserungsvorschlaege/` | **Quelle**: die Rezensionen und Vorschläge, die den Umbau ausgelöst haben |
|
||||
| `Kritik_und_Verbesserungsvorschlaege/NEUER_TITEL.md` | **Quelle**: der Titeltext — daraus entstehen PDF-Titelseite und Startseite |
|
||||
| `pyproject.toml`, `Dockerfile`, `.dockerignore` | **Quelle**: Abhängigkeitsgruppen und Kurs-Image |
|
||||
| `pandoc-defaults-*.yaml`, `pandoc/` | **Quelle**: Konfiguration des PDF-Baus |
|
||||
| `PLAN.md` / `PROGRESS.md` | **Quelle**: Ziel des Umbaus und erreichter Stand |
|
||||
|
|
|
|||
Loading…
Reference in a new issue