MATLAB durch Python ersetzen heißt Kernel tauschen

Wer MATLAB durch Python ersetzen will, plant meistens eine Portierung: alles neu, ein Stichtag, ein Risiko. Das ist der teuerste der möglichen Wege. Jupyter ist eine Oberfläche mit austauschbarem Kernel, und einen dieser Kernel liefert MathWorks selbst.

Dieser Beitrag beantwortet eine Frage: Womit fängt der Ausstieg an, wenn er ohne Stichtag auskommen soll? Er stellt MATLAB keine eigenen Messwerte gegenüber und sagt an mehreren Stellen, wann Sie besser bleiben, wo Sie sind.

Der Kern ist austauschbar

Die Dokumentation beschreibt den Jupyter-Kernel als eigenen Prozess: Kernels are programming language specific processes that run independently and interact with the Jupyter Applications and their user interfaces. Das Notebook kennt selbst keine Sprache; welcher Kernel rechnet, entscheidet ein Eintrag in einem Verzeichnis.

Die Liste der verfügbaren Kernel führt das Jupyter-Projekt im eigenen Repository. Am 25. August 2026 stehen dort 144 Einträge, gezählt in der Quelldatei der Wiki-Seite, darunter Julia, R, Octave und MATLAB.

Das übersieht die übliche Erzählung: MATLAB ersetzen heißt zuerst, die Oberfläche zu wechseln; die Sprache bleibt, wo sie ist. Praktisch sieht das so aus, hier für Octave:

pip install octave_kernel
python -m octave_kernel install --user
jupyter kernelspec list

Der letzte Befehl gab in unserer Umgebung am 25. August 2026 zwei Zeilen zurück, octave und python3. Ab da steht der Octave-Kernel in derselben Auswahlliste wie Python, und dasselbe Notebook rechnet Zelle für Zelle in beiden Sprachen.

Drei MATLAB-Kernel, einer gepflegt

Wer einen MATLAB-Kernel für Jupyter sucht, findet mehrere und bekommt selten dazugesagt, welcher noch lebt. Die Liste nennt die jüngste veröffentlichte Version, abgerufen am 25. August 2026; bei imatlab gibt es kein Release, dort steht nur die letzte Änderung.

• mathworks/jupyter-matlab-proxy: Version 0.19.1 vom 08.05.2026
• Calysto/matlab_kernel: Version 0.17.1 vom 09.05.2022
• imatlab: kein Release, letzte Änderung am 01.02.2023
• Calysto/octave_kernel: Version 1.1.1 vom 17.08.2026
• xeus-octave: Version 0.6.3 vom 26.01.2026
• IJulia für Julia: Version 1.34.4 vom 25.02.2026
• IRkernel für R: Version 1.3.2 vom 20.01.2023
• xeus-r für R: Version 0.11.2 vom 17.07.2026

Der einzige gepflegte MATLAB-Kernel kommt von MathWorks selbst. In der Wiki-Liste des Jupyter-Projekts stehen unter MATLAB nur Calysto/matlab_kernel und imatlab. Bei R hat einer der beiden Kernel seit Januar 2023 keine Version mehr bekommen, der andere im Juli 2026 eine.

Daraus folgt eine Faustregel: Die Sprache sagt nichts darüber, ob ihr Kernel gepflegt wird. Bevor eine Sprache in einen Plan kommt, sehen wir das Datum des letzten Release nach.

Zum offiziellen Weg schreibt MathWorks: Once installed, you can use existing MATLAB licenses to work with MATLAB in Jupyter. Vorausgesetzt wird ein installiertes MATLAB ab R2020b.

Der Kernel ersetzt also keine Lizenz. Er nimmt der Umstellung den Stichtag: Die alten Rechnungen laufen weiter, im selben Dokument, in dem die neuen entstehen.

Der Solver ist nicht derselbe Solver

Als Beispiel dient eine Aufgabe aus der Literatur: der Van-der-Pol-Oszillator im Relaxationsbereich mit dem Parameter 1000, aus dem Aufsatz The MATLAB ODE Suite (SIAM Journal on Scientific Computing 18 (1), 1997). Er ist steif: Die Lösung steht lange fast still und springt dann. Der folgende Quelltext ist Abbildung 4 des Aufsatzes, Zeichen für Zeichen:

function dy = vdpex(t,y)
dy = zeros(size(y));      % preallocate column vector dy
dy(1,:) = y(2,:);
dy(2,:) = 1000*(1 - y(1,:).^2).*y(2,:) - y(1,:);

Aufgerufen wird er über ode15s, mit der Zeitspanne [0 3000] und den Anfangswerten [2 0], wie die Herstellerdokumentation es vormacht. Dieselbe Aufgabe rechnet Python im selben Notebook, eine Zelle weiter:

def vdp(t, y, mu=1000.0):
    return [y[1], mu * (1 - y[0]**2) * y[1] - y[0]]

loesung = solve_ivp(vdp, [0, 3000], [2.0, 0.0], method="BDF")

Was das Verfahren am Ergebnis verschiebt

Der Abstand zwischen beiden Varianten ist kleiner, als die Debatte vermuten lässt. Die Falle steckt an einer anderen Stelle. Wir haben denselben Quelltext am 25. August 2026 laufen lassen, mit denselben Anfangswerten und derselben Zeitspanne, und nur das Verfahren gewechselt.

Drei Solver aus SciPy 1.17.1:

Zwei Solver aus GNU Octave 7.3.0:

Die letzte Zeile ist die lehrreichste. GNU Octave bezeichnet sich selbst als „drop-in compatible with many Matlab scripts“. Für den Quelltext oben stimmt das: Er läuft ohne eine geänderte Zeile. Der Solver mit demselben Namen bricht trotzdem ab, während der andere sauber durchläuft.

Eine Zeile für MATLAB fehlt, denn hier liegt keine Lizenz. Wichtig für die Entscheidung ist ohnehin etwas anderes: Bei unverändertem Modell und unveränderter Genauigkeitsvorgabe verschiebt allein die Wahl des Verfahrens den Endwert in der zweiten Nachkommastelle.

Die Abweichung stammt hier aus dem Verfahren selbst: Jeder Solver steuert Schrittweite und Fehlerschätzung anders, und die Toleranzvorgabe begrenzt den Fehler je Schritt. Über den Endwert sagt sie nichts.

Darunter liegt eine zweite Streuquelle, die der Aufsatz The pitfalls of verifying floating-point computations (ACM TOPLAS 30 (3), 2008) beschreibt: Compiler, Mathematikbibliothek und Recheneinheit verändern das Ergebnis, ohne dass sich eine Zeile Quelltext ändert. Legen Sie deshalb vorab fest, welche Stellen der Zahlen übereinstimmen müssen.

Das Notebook ist das Dokument

Wer ein Skript ein halbes Jahr später öffnet, hat den Quelltext, aber nicht die Kurve und nicht die Begründung für den Parameter. Im Notebook stehen Text, Rechnung, Ergebnis und Abbildung an einer Stelle.

Ein Einwand dagegen lautet, dass am Ende kein lauffähiges Programm dasteht. Das stimmt nicht. Ein Befehl macht aus dem Dokument eine Skriptdatei, ein zweiter lässt dasselbe Notebook mit einem anderen Parameter ohne Oberfläche laufen:

jupyter nbconvert --to script vdp1000.ipynb
papermill vdp1000.ipynb ergebnisse/lauf-042.ipynb -p mu 42

Der zweite Befehl betrifft genau die Automatisierung von Rechenläufen, die wir anbieten. Aus dem Dokument, an dem jemand von Hand gearbeitet hat, wird ohne Umbau ein Auftrag in einer Warteschlange. Voraussetzung ist, dass die Zelle mit den Parametern das Tag parameters trägt.

Für die Nachvollziehbarkeit wichtiger ist die Versionsverwaltung. MathWorks beschreibt das Format der eigenen Live-Skripte offen: By default, MATLAB stores live scripts and functions using a binary Live Code file format in a file with a .mlx extension. Und weiter: If you use source control, register the .mlx extension as binary.

Bei einer als binär angemeldeten Datei zeigt Git nur ein Vorher und ein Nachher. Ein Notebook ist eine JSON-Datei und damit lesbar; für den Vergleich Zelle für Zelle gibt es nbdime.

Was MATLAB besser kann

Ein Text, der hier aufhört, ist Werbung. Drei Dinge sprechen für das Bleiben, und keines davon ist mit einem Wechsel der Oberfläche zu haben.

• Simulink hat kein Gegenstück. Ein Blockschaltbild, das seit Jahren gepflegt wird, ist kein Quelltext, den man übersetzt.
• Codeerzeugung für Steuergeräte. Wer aus dem Modell C erzeugt und damit in eine Freigabe geht, arbeitet mit einer Werkzeugkette aus einer Hand; ob sie für Ihren Nachweis qualifiziert ist, entscheidet Ihre Freigabestelle.
• Nachweisbarkeit. In regulierten Bereichen zählt, dass hinter der Werkzeugkette ein Hersteller mit Haftung steht und Versionen jahrelang verfügbar bleiben.

Der Preis ist das schwächste Argument gegen MATLAB, und er wird trotzdem am häufigsten genannt. Im Online-Shop des Herstellers kosten Einzelplatzlizenzen für Deutschland am 25. August 2026 ohne Steuern: MATLAB 2.410,00 €, Simulink 3.640,00 €, MATLAB Coder 7.275,00 €, Optimization Toolbox 1.375,00 €.

Wer daraus eine Ersparnis rechnet, rechnet meistens falsch: Die Lizenz steht in der Buchhaltung, die Arbeitszeit für eine Umstellung steht dort nicht.

Auch am Notebook ist die Kritik berechtigt, und sie ist mit Zahlen belegt. Die Studie A Large-scale Study about Quality and Reproducibility of Jupyter Notebooks (MSR 2019) hat 1.159.166 Notebooks aus 264.023 GitHub-Repositories untersucht. Von 863.878 Ausführungsversuchen liefen 24,11 Prozent ohne Fehler durch, 4,03 Prozent lieferten dieselben Ergebnisse wie zuvor.

Die Gegenprobe ohne uns

Dafür brauchen Sie weder Auftrag noch Termin, nur ein Skript, das im Betrieb läuft.

1. Schreiben Sie auf, welche Toolboxen dieses eine Skript tatsächlich aufruft. 2. Schlagen Sie für jeden Aufruf nach, ob NumPy, SciPy oder Octave eine Entsprechung haben. 3. Richten Sie den Octave-Kernel ein, die drei Befehle stehen oben, und lassen Sie das Skript unverändert laufen. 4. Vergleichen Sie die Zahlen Stelle für Stelle, mit der vorher festgelegten Stellenzahl.

Läuft das Skript in Schritt 3 ohne eine geänderte Zeile durch und hält es in Schritt 4 Ihre Stellenzahl, dann reicht für Ihr Skript eine Kernel-Installation, und die kann Ihr eigenes Team selbst durchführen. Scheitert Schritt 2 an einer Toolbox, die im Kern des Verfahrens sitzt, würden wir abraten.

Wo diese Aussage aufhört zu gelten

Wir rechnen nicht. Was wir anbieten, ist die Automatisierung von Rechenläufen: Parametervariation, das Erzeugen von Solver-Eingabedateien, Läufe als Warteschlange, Auswertung. Ob ein Verfahren für Ihre Aufgabe das richtige ist, beantwortet Ihre Fachabteilung.

Die Messwerte oben stammen aus einer einzigen Umgebung, an einem einzigen Tag. Das benutzte GNU Octave trägt die Version 7.3.0, wie Debian 12 sie mitbringt; die aktuelle Version ist 11.3.0 vom 1. Juni 2026, und der Abbruch kann dort anders ausgehen. Die Umgebung entscheidet mit und gehört deshalb in jedes Protokoll.

Für einen Betrieb, der ein zertifiziertes Verfahren fährt, gilt dieser Beitrag nicht. Dort ist die Werkzeugkette Teil des Nachweises, und ein Wechsel kostet zuerst die Freigabe.