Solver-Kreuzvalidierung
Die Solver-Kreuzvalidierung prüft einen numerischen Simulator gegen unabhängig gebaute Implementierungen, die sich sowohl in der Methode als auch in der Codebasis unterscheiden — weil Implementierungsfehler selbstkonsistent und von innerhalb einer einzigen Codebasis unsichtbar sind.
Was es bedeutet
Ein Simulator stimmt immer mit sich selbst überein.Ein gekipptes Vorzeichen, ein Faktor 2, ein Normierungsfehler oder eine falsche Basisreihenfolge erzeugen eine mathematisch gültige Evolution — nur eben der falschen Physik —, sodass kein Test innerhalb derselben Codebasis garantiert fündig wird: Der irrende Kopf und der prüfende Kopf sind derselbe Kopf.Die strukturelle Lösung ist unabhängige Neuimplementierung entlang zweier Achsen zugleich: eine andere numerische Methode UND eine andere Codebasis.Die GradPulse-Fallstudie nutzt drei Solver: einen differenzierbaren PyTorch-Propagator mit Trotter-Zerlegung (das Prüfobjekt), einen reinen NumPy-Solver mit dem exakten Matrixexponential des vollen Liouvillians (der einzige, der die Zeit nie zerschneidet) und QuTiPs gemeinschaftlich validierten adaptiven ODE-Integrator.Beobachtete Übereinstimmung von ~10⁻¹⁴ schließt Übertragungsfehler aus; die drei Residuen treffen sich beim Trotter-Fehler erster Ordnung ~2×10⁻⁷ und extrapolieren mit dt → 0 auf ~10⁻¹³ — der Approximationsfehler verhält sich exakt wie vorhergesagt (Stand 2026).Ein CI-Gate vollendet das Design: Weichen zwei beliebige Solver am Betriebspunkt voneinander ab, schlägt der Build automatisch fehl — Verifikation wird zur Invariante bei jedem Commit statt zu einem einmaligen Ereignis.Alltagsvergleich
Häufige Missverständnisse
- Übereinstimmung zwischen zwei Implementierungen beweist NICHTS, wenn sie Code oder dieselbe Approximationsfamilie teilen — eine geteilte Annahme hallt wider, sie verifiziert nicht. Unabhängigkeit muss ENTWORFEN werden: eine andere Methodenachse UND eine andere Codebasisachse.
- Unit-Tests fangen nur Fehler, die sich ihr Autor vorgestellt hat — ist die mentale Physik des Autors falsch, sind die Erwartungswerte des Tests auf dieselbe Weise falsch. Nicht vorgestellte Fehler zu fangen erfordert unabhängige Neuimplementierung.
- Einmalige Validierung lässt jeden späteren Commit unverifiziert — ein CI-Gate verwandelt Verifikation von einem Ereignis in eine Invariante bei jedem Commit.
Das Wichtigste
- Implementierungsfehler (Vorzeichenfehler, Faktoren von 2, Normierung, Basisreihenfolge) sind selbstkonsistent und von innerhalb einer Codebasis nicht erkennbar.
- Die Dreiteilung: Trotter-Propagation vs. exaktes Matrixexponential vs. adaptive ODE — jeder fängt Fehler, die die anderen nicht sehen können.
- Beobachtete Übereinstimmungen von ~10⁻¹⁴ (keine Übertragungsfehler) und Residuen, die sich beim Trotter-Fehler erster Ordnung ~2×10⁻⁷ treffen und mit dt → 0 auf ~10⁻¹³ extrapolieren, zeigen den Fehler wie vorhergesagt (GradPulse-Fallstudie, Stand 2026); ein CI-Gate macht jede Solver-Abweichung zum Build-Fehler.
Verständnis prüfen
Warum kann ein Unit-Test innerhalb einer einzigen Codebasis einen Vorzeichenfehler in einem Lindblad-Generator übersehen?
- A.Weil Vorzeichenfehler keine Auswirkung auf die berechnete Dynamik haben
- B.Weil der falsche Generator dennoch eine selbstkonsistente, mathematisch gültige Evolution erzeugt und die Erwartungswerte des Tests aus demselben, möglicherweise falschen mentalen Modell stammen
- C.Weil Gleitkommaarithmetik alle Vorzeichenfehler unterhalb der Maschinengenauigkeit versteckt
- D.Weil Lindblad-Generatoren überhaupt nicht numerisch getestet werden können
Antwort anzeigen
Antwort: B. Weil der falsche Generator dennoch eine selbstkonsistente, mathematisch gültige Evolution erzeugt und die Erwartungswerte des Tests aus demselben, möglicherweise falschen mentalen Modell stammen
Warum: Ein falsch übertragener Generator entwickelt die falsche Physik mit perfekter innerer Konsistenz, und die Erwartungswerte des Testautors stammen aus demselben Kopf, der den Fehler gemacht hat — der irrende Kopf und der prüfende Kopf sind derselbe Kopf.
Warum muss bei einer Dreifach-Solver-Kreuzvalidierung mindestens ein Solver das exakte Matrixexponential statt Zeitscheiben verwenden?
- A.Weil das exakte Matrixexponential immer schneller ist als Trotter-Schritte
- B.Weil adaptive ODE-Integratoren keine Lindblad-Gleichungen verarbeiten können
- C.Weil Solver, die dieselbe Zeitdiskretisierungsfamilie teilen, ihren gemeinsamen Trotter-Klassen-Fehler (Gleichtaktfehler) nicht erkennen können — nur eine Methode, die die Zeit nie zerschneidet, kann ihn aufdecken
- D.Weil CI-Systeme mindestens eine geschlossene Berechnung verlangen
Antwort anzeigen
Antwort: C. Weil Solver, die dieselbe Zeitdiskretisierungsfamilie teilen, ihren gemeinsamen Trotter-Klassen-Fehler (Gleichtaktfehler) nicht erkennen können — nur eine Methode, die die Zeit nie zerschneidet, kann ihn aufdecken
Warum: Zwei Solver der Trotter-Familie teilen denselben Diskretisierungsfehler und sind füreinander blind (Gleichtaktfehler). Das exakte Matrixexponential zerschneidet die Zeit nie, sodass der geteilte Approximationsfehler als Residuum gegen es sichtbar wird — und tatsächlich bei der vorhergesagten Trotter-Skala erster Ordnung zusammentrifft.
Baut auf
Independent-reimplementation methodology is sound practice, but the concrete figures (1e-14 agreement, 2e-7 Trotter residual) are from the 2026 GradPulse case study (repo verified 2026-07-03).
Praktisch lernen
Dieses Konzept ist Teil eines Curriculums mit 46 Leveln, einem interaktiven Simulator und Lumen — einem Tutor, dessen Antworten vor der Anzeige geprüft werden. Level 1–5 sind kostenlos.