TKET

Einleitung: Was ist TKET?

Kurze Definition

TKET ist ein Quantum-Software-Framework und optimierender Compiler für Gate-basierte Quantenprogramme. Es wurde ursprünglich von Cambridge Quantum entwickelt und gehört heute zum Quantinuum-Software-Ökosystem. Über pytket steht TKET als Python-Schnittstelle zur Verfügung.

Im Kern dient TKET dazu, Quantenschaltkreise nicht nur zu beschreiben, sondern sie für konkrete Ausführungsumgebungen vorzubereiten. Ein abstrakter Schaltkreis, der aus logischen Qubits, Quantengattern und Messoperationen besteht, muss auf reale Quantenhardware übertragen werden. Diese Hardware besitzt jedoch eigene Einschränkungen: begrenzte Qubit-Konnektivität, native Gate-Sets, unterschiedliche Fehlerraten und technische Vorgaben für Messung und Ausführung.

TKET setzt genau an dieser Schnittstelle an. Das Framework nimmt einen Quantenschaltkreis, analysiert seine Struktur und transformiert ihn so, dass er besser zu einem Zielsystem passt. Dabei geht es nicht um kosmetische Vereinfachung, sondern um technische Ausführbarkeit und Effizienz. In der heutigen NISQ-Ära ist das entscheidend, weil jeder unnötige Gate-Schritt die Fehlerwahrscheinlichkeit erhöhen kann.

Ein einfacher Quantenschaltkreis lässt sich abstrakt als Abfolge von Operationen auf Qubits verstehen:

\(C = G_n \cdots G_2 G_1\)

Dabei steht \(C\) für den gesamten Quantenschaltkreis und \(G_1, G_2, ..., G_n\) für einzelne Quantengatter. Ein Compiler wie TKET untersucht diese Abfolge und versucht, sie in eine äquivalente, aber für die Zielhardware günstigere Form zu bringen.

Zentrale These der Abhandlung

TKET ist kein einzelnes Programmierwerkzeug für Quantenalgorithmen, sondern eine Compiler-Schicht zwischen abstraktem Quantenschaltkreis und realer Quantenhardware. Seine Bedeutung liegt in der Optimierung, Portabilität und Hardware-Anpassung von Quantenprogrammen.

Die zentrale These dieser Abhandlung lautet: TKET ist eine Schlüsseltechnologie für die praktische Nutzbarkeit Gate-basierter Quantencomputer, weil es den Abstand zwischen theoretischem Algorithmus und physikalischer Ausführung verringert. Ein Quantenalgorithmus ist in seiner mathematischen Beschreibung meist hardwareunabhängig. Die reale Ausführung ist es nicht.

Ein ideal formulierter Schaltkreis kann auf echter Hardware ineffizient, fehleranfällig oder direkt unausführbar sein, wenn seine Struktur nicht zu den technischen Eigenschaften des Prozessors passt. Genau deshalb braucht die Quantentechnologie Compiler, die mehr leisten als reine Übersetzung. Sie müssen optimieren, umordnen, ersetzen, anpassen und dabei die logische Bedeutung des Schaltkreises erhalten.

Formal lässt sich dieses Prinzip als Transformation eines ursprünglichen Schaltkreises \(C\) in einen optimierten Schaltkreis \(C'\) beschreiben:

\(C \rightarrow C'\)

Die entscheidende Bedingung lautet, dass beide Schaltkreise dieselbe logische Funktion erfüllen sollen:

\(U(C) = U(C')\)

Dabei beschreibt \(U(C)\) die unitäre Wirkung des ursprünglichen Schaltkreises und \(U(C')\) die unitäre Wirkung des optimierten Schaltkreises. In der Praxis kann diese Gleichheit je nach Messstruktur, Approximation und Hardwaremodell unterschiedlich behandelt werden. Der Grundgedanke bleibt jedoch klar: Der optimierte Schaltkreis soll dieselbe rechnerische Aufgabe erfüllen, aber besser auf die Zielplattform passen.

TKET ist damit nicht nur ein Hilfswerkzeug für Entwickler, sondern ein Bestandteil der technischen Infrastruktur moderner Quantenprogrammierung. Es entscheidet mit darüber, wie effizient ein Quantenprogramm auf realen Geräten ausgeführt werden kann.

Abgrenzung des Themas

Die Abhandlung behandelt TKET als Quantum-Compiler und Entwicklungswerkzeug. Nicht im Mittelpunkt stehen allgemeine Grundlagen der Quantenmechanik, vollständige Einführungen in Quantenalgorithmen oder eine reine Python-Tutorial-Darstellung.

Der Fokus liegt auf der Rolle von TKET innerhalb des Quantum-Software-Stacks. Betrachtet werden vor allem die Aufgaben, die ein Compiler in der Quantentechnologie erfüllen muss: Schaltkreisoptimierung, Gate-Transformation, Qubit-Mapping, Routing, Backend-Anbindung und Interoperabilität mit anderen Frameworks.

Nicht ausführlich behandelt werden die physikalischen Grundlagen einzelner Hardwareplattformen, etwa Ionenfallen, supraleitende Qubits oder photonische Systeme. Diese Hardwareformen sind für TKET als Zielsysteme relevant, stehen aber nicht im Zentrum dieser Abhandlung. Entscheidend ist hier nicht die konkrete Bauweise eines Quantenprozessors, sondern die Frage, wie ein Schaltkreis für ein solches System vorbereitet wird.

Ebenso wird TKET nicht als reine Programmiereinführung dargestellt. pytket ist zwar die praktische Python-Schnittstelle, doch die Abhandlung konzentriert sich nicht auf vollständige Codebeispiele oder API-Details. Im Mittelpunkt steht die technische Bedeutung von TKET als Compiler-Werkzeug.

Damit ergibt sich eine klare thematische Eingrenzung: TKET wird als Brücke zwischen Quantenalgorithmus und Quantenhardware analysiert. Diese Brücke ist notwendig, weil ein abstrakter Quantenschaltkreis erst durch Kompilierung, Optimierung und Hardware-Anpassung real ausführbar wird.

Technologischer Hintergrund

Gate-basierte Quantencomputer

Gate-basierte Quantencomputer beschreiben Quantenberechnungen als Abfolge gezielter Operationen auf Qubits. Dieses Modell ähnelt auf abstrakter Ebene der klassischen Schaltkreislogik, arbeitet jedoch nicht mit klassischen Bits, sondern mit quantenmechanischen Zuständen. Ein Qubit kann nicht nur die Basiszustände \(0\) und \(1\) annehmen, sondern auch eine Superposition dieser Zustände.

Ein einzelner Qubit-Zustand lässt sich vereinfacht so darstellen:

\(|\psi\rangle = \alpha |0\rangle + \beta |1\rangle\)

Dabei sind \(\alpha\) und \(\beta\) komplexe Amplituden. Die Wahrscheinlichkeiten für eine Messung ergeben sich aus:

\(|\alpha|^2 + |\beta|^2 = 1\)

Quantenprogramme werden häufig als Quantenschaltkreise modelliert, weil dieses Modell klar zeigt, welche Operationen in welcher Reihenfolge auf welche Qubits angewendet werden. Ein solcher Schaltkreis besteht aus Qubits, Quantengattern und Messungen. Die Gatter verändern den Quantenzustand, während Messungen quantenmechanische Information in klassische Messergebnisse überführen.

Ein Quantenschaltkreis kann formal als geordnete Folge von Gattern beschrieben werden:

\(C = G_n \cdots G_2 G_1\)

Die Reihenfolge ist entscheidend, weil Quantengatter im Allgemeinen nicht vertauschbar sind. Für zwei Gatter \(A\) und \(B\) gilt häufig:

\(AB \neq BA\)

Ein zentrales technisches Maß ist die Schaltkreistiefe. Sie beschreibt, wie viele aufeinanderfolgende Operationsschichten ein Schaltkreis besitzt. Je größer die Tiefe, desto länger muss der Quantenzustand kohärent bleiben. Auf heutiger Hardware ist das kritisch, weil Qubits nur für begrenzte Zeit zuverlässig kontrolliert werden können.

Die Fehleranfälligkeit gate-basierter Quantencomputer entsteht aus mehreren Quellen: unvollkommene Gate-Ausführung, Rauschen, Dekohärenz, Messfehler und zusätzliche Operationen, die durch Hardwareeinschränkungen notwendig werden. Deshalb ist ein Quantenschaltkreis nicht nur eine abstrakte mathematische Struktur, sondern immer auch ein technisches Risikoobjekt. Jeder unnötige Schritt kann die Wahrscheinlichkeit erhöhen, dass das Ergebnis unbrauchbar wird.

Die NISQ-Ära als Ausgangspunkt

Die heutige Quantenhardware wird häufig der NISQ-Ära zugeordnet. NISQ steht für Noisy Intermediate-Scale Quantum. Gemeint sind Quantenprozessoren mit einer noch begrenzten Anzahl von Qubits, ohne vollständige Fehlerkorrektur und mit deutlicher Empfindlichkeit gegenüber Rauschen.

Diese Geräte sind wissenschaftlich hoch relevant, aber technisch noch nicht mit idealisierten, fehlerkorrigierten Quantencomputern gleichzusetzen. Sie können Quantenschaltkreise ausführen, doch die Ausführung bleibt fehleranfällig. Für die praktische Quantum-Software bedeutet das: Ein Algorithmus muss nicht nur theoretisch korrekt sein, sondern auch zur realen Hardware passen.

Die wichtigsten Begrenzungen der NISQ-Ära sind:

• begrenzte Qubit-Zahl,
• Rauschen in der Zustandsentwicklung,
• kurze Kohärenzzeiten,
• fehlerbehaftete ein- und zweiqubitige Gates,
• Messfehler,
• eingeschränkte Konnektivität zwischen Qubits,
• fehlende oder nur teilweise einsetzbare Quantenfehlerkorrektur.

Besonders wichtig ist die eingeschränkte Konnektivität. In einem idealen Schaltkreis könnte jedes Qubit direkt mit jedem anderen Qubit wechselwirken. Auf realer Hardware ist das selten der Fall. Häufig können nur bestimmte physische Qubits direkt miteinander gekoppelt werden. Wenn ein Schaltkreis eine Operation zwischen zwei logisch verbundenen, aber physisch nicht benachbarten Qubits verlangt, muss der Compiler zusätzliche Schritte einfügen.

Diese zusätzlichen Schritte erhöhen die Schaltkreistiefe und oft auch die Gate-Anzahl. Genau dadurch steigt die Fehlerwahrscheinlichkeit. Vereinfacht lässt sich die Erfolgswahrscheinlichkeit eines Schaltkreises als Produkt einzelner Gate-Zuverlässigkeiten betrachten:

\(P_{\mathrm{success}} \approx \prod_{i=1}^{n} p_i\)

Dabei steht \(p_i\) für die Erfolgswahrscheinlichkeit des jeweiligen Gate-Schritts. Je mehr fehlerbehaftete Operationen ein Schaltkreis enthält, desto stärker kann die Gesamtzuverlässigkeit sinken.

Für TKET ist diese Ausgangslage zentral. Das Framework wurde nicht für eine ideale Quantenwelt entworfen, sondern für die konkrete Realität heutiger und naher Quantenhardware. Optimierung ist in diesem Kontext kein Komfortmerkmal, sondern eine Voraussetzung für brauchbare Ausführung.

Warum Quantum-Compiler notwendig sind

Ein Quantum-Compiler übersetzt und optimiert abstrakte Quantenschaltkreise für konkrete Zielhardware. Diese Aufgabe ist deutlich komplexer als eine einfache Formatumwandlung. Der Compiler muss die logische Struktur des Programms erhalten und zugleich die technischen Einschränkungen des Zielsystems berücksichtigen.

Ein abstrakter Quantenschaltkreis beschreibt, was berechnet werden soll. Die Hardware bestimmt, wie diese Berechnung tatsächlich ausgeführt werden kann. Zwischen beiden Ebenen liegt die Compiler-Schicht. Genau hier setzt TKET an.

Ein Quantum-Compiler muss unter anderem folgende Fragen beantworten:

• Welche Gates des abstrakten Schaltkreises sind auf der Zielhardware direkt verfügbar?
• Welche Gates müssen in native Operationen zerlegt werden?
• Welche logischen Qubits werden welchen physischen Qubits zugeordnet?
• Welche Qubits sind auf der Hardware direkt miteinander verbunden?
• Welche zusätzlichen Routing-Operationen sind notwendig?
• Welche Gate-Sequenzen können vereinfacht oder entfernt werden?
• Wie lässt sich die Schaltkreistiefe reduzieren?

Ein zentrales Konzept ist das Gate-Set. Jede Hardwareplattform unterstützt bestimmte native Operationen besonders effizient. Ein Schaltkreis, der abstrakte Gates verwendet, muss daher in ein Ziel-Gate-Set übersetzt werden:

\(\{G_1, G_2, ..., G_n\} \rightarrow \{N_1, N_2, ..., N_m\}\)

Dabei stehen \(G_i\) für abstrakte Gates und \(N_j\) für native Gates der Zielhardware. Diese Transformation muss so erfolgen, dass die gewünschte logische Wirkung erhalten bleibt.

Ebenso wichtig ist der Kopplungsgraph der Hardware. Er beschreibt, welche physischen Qubits direkt miteinander Operationen ausführen können. Ein solcher Graph kann vereinfacht als Menge von Qubits und Verbindungen dargestellt werden:

\(G_{\mathrm{hardware}} = (V, E)\)

Dabei steht \(V\) für die Menge der physischen Qubits und \(E\) für die erlaubten direkten Kopplungen zwischen ihnen. Wenn ein Schaltkreis eine Zweiqubit-Operation zwischen Qubits verlangt, die im Kopplungsgraphen nicht direkt verbunden sind, muss der Compiler eine geeignete Routing-Strategie finden.

Qubit-Mapping beschreibt die Zuordnung logischer Qubits zu physischen Qubits:

\(q_{\mathrm{logical}} \rightarrow q_{\mathrm{physical}}\)

Diese Zuordnung ist entscheidend. Ein schlechtes Mapping kann viele zusätzliche Operationen erzwingen. Ein gutes Mapping kann die Zahl der notwendigen Routing-Schritte reduzieren und damit die Ausführungsqualität verbessern.

Schaltkreisvereinfachung ist ein weiterer zentraler Bereich. Wenn zwei aufeinanderfolgende Operationen sich gegenseitig aufheben, kann der Compiler sie entfernen. Ein einfaches Beispiel ist:

\(X X = I\)

Dabei steht \(I\) für die Identitätsoperation. Solche Vereinfachungen wirken klein, können aber in großen Schaltkreisen erhebliche Auswirkungen haben.

Quantum-Compiler sind deshalb notwendig, weil reale Quantencomputer keine idealen mathematischen Maschinen sind. Sie sind physikalische Systeme mit konkreten Beschränkungen. TKET übernimmt die Aufgabe, abstrakte Quantenprogramme in eine Form zu bringen, die auf solchen Systemen besser ausführbar ist. Damit wird der Compiler zu einer entscheidenden technischen Brücke zwischen Algorithmus, Software-Framework und Quantenprozessor.

TKET als retargetierender Quantum-Compiler

Bedeutung von Retargetability

Retargetability beschreibt die Fähigkeit, einen Quantenschaltkreis für unterschiedliche Hardwareplattformen und Architekturen anzupassen. Genau hier liegt eine Kernstärke von TKET: Der Compiler ist nicht auf eine einzelne Hardwarefamilie beschränkt.

Diese Eigenschaft ist in der Quantentechnologie besonders wichtig, weil es bisher keinen einheitlichen Standardprozessor gibt. Unterschiedliche Quantencomputer arbeiten mit unterschiedlichen physikalischen Qubit-Technologien, unterschiedlichen nativen Gates, unterschiedlichen Kopplungsstrukturen und unterschiedlichen Fehlereigenschaften. Ein Schaltkreis, der auf einem System gut ausführbar ist, kann auf einem anderen System ungeeignet sein.

Retargetability bedeutet deshalb nicht nur, dass ein Schaltkreis in ein anderes Dateiformat übersetzt wird. Es bedeutet, dass der Compiler den Schaltkreis neu auf die Zielarchitektur ausrichtet. Die logische Berechnung bleibt erhalten, aber die technische Darstellung wird an die jeweilige Hardware angepasst.

Vereinfacht lässt sich dieser Vorgang als Abbildung eines abstrakten Schaltkreises auf mehrere mögliche Zielsysteme darstellen:

\(C_{\mathrm{abstract}} \rightarrow C_{\mathrm{hardware\ A}}\)

\(C_{\mathrm{abstract}} \rightarrow C_{\mathrm{hardware\ B}}\)

\(C_{\mathrm{abstract}} \rightarrow C_{\mathrm{hardware\ C}}\)

Dabei steht \(C_{\mathrm{abstract}}\) für den ursprünglichen, hardwareunabhängigen Quantenschaltkreis. Die Schaltkreise \(C_{\mathrm{hardware\ A}}\), \(C_{\mathrm{hardware\ B}}\) und \(C_{\mathrm{hardware\ C}}\) sind angepasste Versionen für unterschiedliche Zielplattformen.

Für TKET ist diese Fähigkeit zentral. Der Compiler wird nicht nur eingesetzt, um einen Schaltkreis zu optimieren, sondern um ihn zwischen verschiedenen Hardwarewelten beweglich zu halten. Das ist ein praktischer Vorteil für Forschung, Entwicklung und Benchmarking. Ein Algorithmus kann zunächst abstrakt entworfen und anschließend für verschiedene Zielsysteme kompiliert werden.

Gerade in einem fragmentierten Quantum-Ökosystem ist diese Flexibilität entscheidend. Es gibt supraleitende Qubits, Ionenfallen, photonische Ansätze, Neutralatom-Systeme und weitere Architekturen. Jede dieser Plattformen stellt andere Anforderungen an den Schaltkreis. Ein retargetierender Compiler wie TKET ermöglicht es, diese Unterschiede auf der Compiler-Ebene zu behandeln, statt jeden Algorithmus vollständig neu zu schreiben.

Hardwareunabhängige Schaltkreisbeschreibung

TKET erlaubt die Arbeit mit einer abstrakten Darstellung von Quantenschaltkreisen, bevor diese auf konkrete Backend-Anforderungen zugeschnitten werden.

Diese Trennung zwischen abstrakter Schaltkreisbeschreibung und hardwareabhängiger Ausführung ist ein Grundprinzip moderner Quantum-Software. Entwicklerinnen und Entwickler sollen einen Algorithmus zunächst logisch formulieren können, ohne sofort alle Details eines konkreten Quantenprozessors berücksichtigen zu müssen. Erst in späteren Kompilierungsschritten wird der Schaltkreis an ein bestimmtes Backend angepasst.

Ein abstrakter Quantenschaltkreis enthält logische Qubits, Gates und Messungen. Er beschreibt die beabsichtigte Berechnung, aber noch nicht zwingend die endgültige physikalische Ausführungsform. Diese Ebene ist besonders wichtig, weil sie algorithmisches Denken von Hardwaredetails trennt.

Ein logischer Schaltkreis kann vereinfacht als Kombination aus Qubit-Register, Gate-Folge und Messoperationen verstanden werden:

\(C_{\mathrm{logical}} = (Q, G, M)\)

Dabei steht \(Q\) für die Menge der logischen Qubits, \(G\) für die angewendeten Quantengatter und \(M\) für die Messoperationen.

Auf dieser abstrakten Ebene ist zunächst nicht entscheidend, ob zwei logische Qubits auf der späteren Hardware direkt miteinander verbunden sind. Ebenso ist noch nicht endgültig festgelegt, ob ein verwendetes Gate nativ verfügbar ist oder später zerlegt werden muss. Diese Fragen gehören zur hardwareabhängigen Kompilierung.

Die hardwareunabhängige Darstellung hat mehrere Vorteile:

• Algorithmen können zunächst klar und logisch formuliert werden.
• Schaltkreise können analysiert werden, bevor sie an ein Backend gebunden werden.
• Optimierungen können auf allgemeiner Ebene durchgeführt werden.
• Der gleiche Ausgangsschaltkreis kann für verschiedene Zielsysteme verwendet werden.
• Interoperabilität zwischen unterschiedlichen Quantum-Frameworks wird erleichtert.

Für TKET ist diese Zwischenebene entscheidend. Der Compiler kann einen Schaltkreis zunächst strukturell analysieren: Welche Gates kommen vor? Welche Qubits interagieren? Gibt es redundante Operationen? Welche Teilstrukturen lassen sich vereinfachen? Erst danach wird der Schaltkreis auf konkrete Hardwarebedingungen ausgerichtet.

Diese Trennung kann als zweistufiger Prozess beschrieben werden:

\(C_{\mathrm{algorithm}} \rightarrow C_{\mathrm{logical}} \rightarrow C_{\mathrm{target}}\)

Dabei steht \(C_{\mathrm{algorithm}}\) für die algorithmische Idee, \(C_{\mathrm{logical}}\) für die abstrakte Schaltkreisdarstellung und \(C_{\mathrm{target}}\) für den auf ein Zielsystem angepassten Schaltkreis.

Die Stärke dieser Struktur liegt in der Kontrolle. TKET kann auf der logischen Ebene allgemeine Optimierungen vornehmen und anschließend auf der Zielsystemebene konkrete Hardwarebeschränkungen einarbeiten. Dadurch wird der Schaltkreis nicht nur übersetzt, sondern systematisch vorbereitet.

Hardwareabhängige Optimierung

Hardwareabhängige Optimierung beschreibt den Schritt, in dem TKET einen Quantenschaltkreis auf konkrete Einschränkungen eines Zielsystems vorbereitet. Dazu gehören native Gate-Sets, Qubit-Konnektivität, Routing, Gate-Zerlegung und Messstruktur.

Der Ausgangspunkt ist die Tatsache, dass reale Quantencomputer nicht beliebige Operationen in beliebiger Form ausführen können. Jede Plattform besitzt ein eigenes natives Gate-Set. Ein abstraktes Gate muss daher häufig in eine Folge hardwareunterstützter Gates zerlegt werden.

Diese Transformation lässt sich vereinfacht so darstellen:

\(G_{\mathrm{abstract}} \rightarrow N_k \cdots N_2 N_1\)

Dabei steht \(G_{\mathrm{abstract}}\) für ein abstraktes Quantengatter und \(N_1, N_2, ..., N_k\) für native Gates des Zielsystems. Ziel ist, dieselbe logische Wirkung mit den tatsächlich verfügbaren Operationen zu erzeugen.

Eine weitere zentrale Einschränkung ist die Qubit-Konnektivität. Ein idealer Schaltkreis kann Operationen zwischen beliebigen Qubits enthalten. Reale Hardware erlaubt jedoch meist nur direkte Operationen zwischen bestimmten physischen Qubits. Diese Struktur wird durch den Kopplungsgraphen beschrieben:

\(G_{\mathrm{coupling}} = (V, E)\)

Dabei bezeichnet \(V\) die physischen Qubits und \(E\) die erlaubten direkten Verbindungen. Wenn zwei logische Qubits miteinander interagieren sollen, ihre zugeordneten physischen Qubits aber nicht verbunden sind, muss der Compiler Routing-Operationen einfügen.

Routing bedeutet, dass der Schaltkreis so umgebaut wird, dass notwendige Zweiqubit-Operationen trotz eingeschränkter Konnektivität möglich werden. Häufig geschieht dies durch zusätzliche Vertauschungsoperationen. Eine SWAP-Operation kann abstrakt so beschrieben werden:

\(\mathrm{SWAP}(q_i, q_j): q_i \leftrightarrow q_j\)

Solche Routing-Schritte sind technisch notwendig, aber teuer. Sie erhöhen die Gate-Anzahl und meist auch die Schaltkreistiefe. Deshalb besteht eine wichtige Aufgabe von TKET darin, Routing möglichst effizient durchzuführen und unnötige Zusatzoperationen zu vermeiden.

Auch das Qubit-Mapping ist Teil der hardwareabhängigen Optimierung. Dabei werden logische Qubits physischen Qubits zugeordnet:

\(f: Q_{\mathrm{logical}} \rightarrow Q_{\mathrm{physical}}\)

Ein gutes Mapping berücksichtigt, welche Qubits im Schaltkreis häufig miteinander interagieren und welche physischen Qubits auf der Hardware günstig verbunden sind. Dadurch können Routing-Kosten reduziert werden.

Zusätzlich muss der Compiler die Messstruktur beachten. Messungen markieren den Übergang von Quanteninformation zu klassischer Information. In vielen Schaltkreisen stehen Messungen am Ende, aber moderne Quantenprogramme können auch Zwischenmessungen, klassische Kontrolllogik oder bedingte Operationen enthalten. Ein Compiler muss solche Strukturen korrekt erhalten und mit den Fähigkeiten des Zielsystems abgleichen.

Die hardwareabhängige Optimierung verfolgt mehrere technische Ziele gleichzeitig:

• Reduktion der Gate-Anzahl,
• Reduktion der Schaltkreistiefe,
• Anpassung an native Gate-Sets,
• effizientes Qubit-Mapping,
• minimales Routing,
• korrekte Behandlung von Messungen,
• Erhaltung der logischen Schaltkreisfunktion.

Formal kann man die Optimierung als Suche nach einem Zielschaltkreis beschreiben, der dieselbe Funktion erfüllt, aber geringere technische Kosten besitzt:

\(C' = \arg\min_{C_i \sim C} \mathrm{Cost}(C_i)\)

Dabei bedeutet \(C_i \sim C\), dass der Kandidatenschaltkreis \(C_i\) logisch äquivalent zum ursprünglichen Schaltkreis \(C\) ist. Die Kostenfunktion \(\mathrm{Cost}(C_i)\) kann verschiedene Faktoren enthalten, etwa Gate-Anzahl, Schaltkreistiefe, Routing-Aufwand oder erwartete Fehlerrate.

Eine einfache Kostenfunktion könnte beispielsweise so aussehen:

\(\mathrm{Cost}(C) = a \cdot d(C) + b \cdot g(C) + c \cdot r(C)\)

Dabei steht \(d(C)\) für die Schaltkreistiefe, \(g(C)\) für die Gate-Anzahl und \(r(C)\) für den Routing-Aufwand. Die Faktoren \(a\), \(b\) und \(c\) gewichten die Bedeutung der jeweiligen Kostenanteile.

TKET ist in diesem Zusammenhang ein Werkzeug, das die abstrakte Welt des Quantenalgorithmus mit der konkreten Welt der Quantenhardware verbindet. Retargetability ist dabei keine Zusatzfunktion, sondern ein Kernprinzip. Ohne sie wäre Quantum-Software eng an einzelne Plattformen gebunden. Mit ihr wird ein Schaltkreis beweglich, optimierbar und für unterschiedliche Zielsysteme nutzbar.

Architektur und Kernkomponenten von TKET

pytket als Python-Schnittstelle

pytket ist das zentrale Python-Modul für die Interaktion mit TKET. Es unterstützt den Aufbau, die Manipulation, Kompilierung und Ausführung von Quantenschaltkreisen über Backends und Erweiterungsmodule.

Die Bedeutung von pytket liegt darin, dass es die Compiler-Funktionen von TKET in eine praktische Entwicklungsumgebung überführt. Forschende, Entwicklerinnen und Entwickler können Quantenschaltkreise definieren, bestehende Schaltkreise importieren, Optimierungsschritte anwenden und anschließend ein geeignetes Backend für Simulation oder Hardwareausführung verwenden.

pytket ist damit nicht nur eine Programmierschnittstelle, sondern der praktische Zugang zur TKET-Architektur. Die eigentliche Stärke entsteht durch die Verbindung aus abstrakter Schaltkreisbeschreibung, struktureller Analyse, Compiler-Passes und backendbezogener Ausführung.

Ein typischer Arbeitsfluss mit TKET lässt sich vereinfacht so darstellen:

\(C_{\mathrm{input}} \rightarrow C_{\mathrm{optimised}} \rightarrow C_{\mathrm{backend}} \rightarrow R_{\mathrm{result}}\)

Dabei steht \(C_{\mathrm{input}}\) für den ursprünglichen Schaltkreis, \(C_{\mathrm{optimised}}\) für die optimierte Version, \(C_{\mathrm{backend}}\) für den an ein Zielsystem angepassten Schaltkreis und \(R_{\mathrm{result}}\) für das Ergebnis nach Simulation oder Ausführung.

pytket macht diesen Ablauf kontrollierbar. Ein Schaltkreis kann schrittweise aufgebaut, verändert, analysiert und kompiliert werden. Dadurch eignet sich pytket sowohl für experimentelle Forschung als auch für reproduzierbare Quantum-Software-Workflows.

Besonders wichtig ist, dass pytket nicht auf eine einzige Hardwareplattform festgelegt ist. Über Erweiterungsmodule kann es mit verschiedenen Quantum-Frameworks und Backends verbunden werden. Das unterstützt den retargetierenden Charakter von TKET: Der gleiche logische Schaltkreis kann in unterschiedlichen technischen Umgebungen weiterverarbeitet werden.

Circuit-Modell

Das Circuit-Modell ist die interne Grundlage, auf der TKET Quantenschaltkreise beschreibt, analysiert und transformiert. Ein Quantenschaltkreis besteht dabei aus Qubits, klassischen Bits, Gates, Messungen, Registern und Operationen.

Qubits bilden die quantenmechanische Rechenebene. Auf ihnen wirken Quantengatter, die den Zustand des Systems verändern. Klassische Bits speichern Messergebnisse oder dienen als Ziel klassischer Kontrollstrukturen. Diese Verbindung von quantenmechanischer und klassischer Information ist wichtig, weil reale Quantenprogramme nicht nur aus unitären Operationen bestehen, sondern auch Messungen und klassische Auswertung enthalten können.

Ein Schaltkreis kann abstrakt als Struktur aus Qubits, klassischen Bits und Operationen beschrieben werden:

\(C = (Q, B, O)\)

Dabei steht \(Q\) für die Menge der Qubits, \(B\) für die Menge der klassischen Bits und \(O\) für die geordnete Menge der Operationen.

Die Operationen können ein- oder mehrqubitige Gates, Messungen oder andere schaltkreisbezogene Befehle sein. Ein einfaches einqubitiges Gate wirkt auf einen einzelnen Qubit-Zustand:

\(|\psi'\rangle = U|\psi\rangle\)

Dabei bezeichnet \(U\) die Gate-Operation, \(|\psi\rangle\) den ursprünglichen Zustand und \(|\psi'\rangle\) den Zustand nach der Anwendung des Gates.

Zweiqubit-Gates sind besonders wichtig, weil sie Verschränkung erzeugen können. Gleichzeitig sind sie auf realer Hardware oft fehleranfälliger als einqubitige Gates. Für Compiler wie TKET sind sie daher besonders relevant. Ihre Platzierung, Zerlegung und Anpassung an die Hardware beeinflussen die Qualität des gesamten Schaltkreises.

Register dienen der strukturierten Organisation von Qubits und Bits. Sie ermöglichen es, größere Schaltkreise übersichtlich zu verwalten und logisch zusammengehörige Rechenelemente zu gruppieren. Das ist besonders wichtig, wenn Algorithmen viele Qubits, mehrere Messbereiche oder hybride quantenklassische Abläufe verwenden.

Messungen markieren den Übergang von Quanteninformation zu klassischer Information. Eine Messung auf einem Qubit liefert ein klassisches Ergebnis, das probabilistisch vom Quantenzustand abhängt. Vereinfacht gilt:

\(P(0) = |\alpha|^2\)

\(P(1) = |\beta|^2\)

für einen Zustand:

\(|\psi\rangle = \alpha|0\rangle + \beta|1\rangle\)

Das Circuit-Modell von TKET muss diese verschiedenen Elemente so darstellen, dass sie zuverlässig transformiert werden können. Ein Compiler darf bei der Optimierung nicht nur Gates verschieben oder entfernen, sondern muss die logische Bedeutung des gesamten Schaltkreises erhalten. Dazu gehören auch Messungen, klassische Bits und mögliche Abhängigkeiten zwischen quantenmechanischen und klassischen Operationen.

Compiler-Passes

TKET arbeitet mit Compiler-Passes, die einzelne Transformations- und Optimierungsschritte auf Quantenschaltkreise anwenden. Diese Passes können kombiniert werden, um circuitspezifische oder hardwarespezifische Optimierungsziele zu erreichen.

Ein Compiler-Pass ist ein klar definierter Bearbeitungsschritt. Er nimmt einen Schaltkreis als Eingabe, verändert ihn nach bestimmten Regeln und gibt eine neue Version des Schaltkreises zurück. Diese Veränderung kann eine Vereinfachung, eine Umformung, eine Zerlegung, ein Mapping oder eine hardwarebezogene Anpassung sein.

Formal lässt sich ein einzelner Pass als Funktion auf einem Schaltkreis beschreiben:

\(P(C) = C'\)

Dabei steht \(P\) für den Compiler-Pass, \(C\) für den Eingangsschaltkreis und \(C'\) für den transformierten Schaltkreis.

Mehrere Passes können nacheinander angewendet werden:

\(C_{\mathrm{final}} = P_n(\cdots P_2(P_1(C_{\mathrm{initial}}))) \)

Diese Verkettung ist entscheidend, weil Quantum Compilation selten aus einem einzigen Optimierungsschritt besteht. Ein Schaltkreis muss oft zuerst vereinfacht, dann in ein Ziel-Gate-Set zerlegt, anschließend gemappt, geroutet und danach erneut optimiert werden.

Typische Aufgaben von Compiler-Passes sind:

• Entfernung redundanter Gates,
• Vereinfachung von Gate-Sequenzen,
• Zerlegung abstrakter Gates in native Gates,
• Anpassung an ein bestimmtes Gate-Set,
• Zuordnung logischer Qubits zu physischen Qubits,
• Routing entlang eines Kopplungsgraphen,
• Reduktion der Schaltkreistiefe,
• Erhaltung oder Neuordnung von Messstrukturen.

Ein einfaches Beispiel für eine lokale Vereinfachung ist das Entfernen zweier identischer Pauli-X-Gates hintereinander:

\(X X = I\)

Da die doppelte Anwendung des X-Gates wieder zur Identität führt, kann ein Compiler diese Operationen entfernen, wenn dadurch keine andere Abhängigkeit verletzt wird.

Ein anderes Beispiel ist die Anpassung eines nicht-nativen Gates an ein unterstütztes Gate-Set:

\(G_{\mathrm{abstract}} \rightarrow G_{\mathrm{native},1} G_{\mathrm{native},2} \cdots G_{\mathrm{native},k}\)

Dabei bleibt die logische Wirkung erhalten, aber die konkrete Umsetzung wird an die Zielhardware angepasst.

Die Stärke von TKET liegt darin, dass solche Passes nicht isoliert betrachtet werden müssen. Sie lassen sich zu gezielten Kompilierungsstrategien verbinden. Für einen Simulator können andere Passes sinnvoll sein als für einen realen Quantenprozessor. Für eine Hardware mit vollständiger Konnektivität sind andere Schritte nötig als für eine Hardware mit stark eingeschränktem Kopplungsgraphen.

Compiler-Passes machen TKET modular. Statt eine starre Kompilierung vorzuschreiben, erlaubt das System die Kombination unterschiedlicher Transformationsschritte. Dadurch können Schaltkreise für verschiedene Ziele optimiert werden: geringere Tiefe, weniger Zweiqubit-Gates, bessere Hardwarekompatibilität oder einfachere Analyse.

Backends und Erweiterungsmodule

Backends verbinden TKET mit Simulatoren und realen Quantencomputern. Erweiterungsmodule ermöglichen Interoperabilität mit Plattformen und Frameworks wie Qiskit, Cirq oder PennyLane.

Ein Backend ist die Zielumgebung, auf der ein Quantenschaltkreis ausgeführt oder simuliert werden soll. Das kann ein lokaler Simulator, ein Cloud-Simulator oder ein realer Quantenprozessor sein. Für TKET ist das Backend nicht nur ein Ausführungsort, sondern auch eine Quelle technischer Anforderungen. Ein Backend bestimmt, welche Gates unterstützt werden, welche Qubit-Konnektivität vorliegt und welche Ausführungsregeln gelten.

Der Übergang von einem allgemeinen TKET-Schaltkreis zu einem Backend-Schaltkreis lässt sich vereinfacht so darstellen:

\(C_{\mathrm{tket}} \rightarrow C_{\mathrm{backend}}\)

Dabei ist \(C_{\mathrm{backend}}\) die Version des Schaltkreises, die den Anforderungen des Zielsystems entspricht.

Erweiterungsmodule sind ein wichtiger Teil dieses Konzepts. Sie verbinden TKET mit externen Frameworks, Hardwarediensten und Softwareumgebungen. Dadurch kann TKET in bestehende Quantum-Workflows integriert werden, statt als isoliertes Werkzeug zu arbeiten.

Interoperabilität ist dabei mehr als ein Komfortmerkmal. In der Quantentechnologie ist das Software-Ökosystem stark fragmentiert. Verschiedene Anbieter, Frameworks und Hardwareplattformen verwenden eigene Modelle, Schnittstellen und Ausführungswege. Ein Compiler wie TKET gewinnt an Wert, wenn er zwischen diesen Welten vermitteln kann.

Ein typischer interoperabler Arbeitsfluss kann so aussehen:

\(C_{\mathrm{external}} \rightarrow C_{\mathrm{tket}} \rightarrow C_{\mathrm{optimised}} \rightarrow C_{\mathrm{target}}\)

Dabei steht \(C_{\mathrm{external}}\) für einen Schaltkreis aus einem externen Framework, \(C_{\mathrm{tket}}\) für die TKET-interne Darstellung, \(C_{\mathrm{optimised}}\) für die optimierte Form und \(C_{\mathrm{target}}\) für den zielsystemgerechten Schaltkreis.

Diese Struktur macht TKET zu einer Compiler-Schicht innerhalb eines größeren Quantum-Software-Stacks. Ein Schaltkreis kann in einem Framework entworfen, in TKET optimiert und anschließend für ein anderes Backend vorbereitet werden. Dadurch entsteht eine flexible Arbeitsweise, die besonders für Forschung, Vergleichsstudien und hardwareübergreifende Experimente relevant ist.

Backends und Erweiterungsmodule erfüllen damit drei zentrale Aufgaben:

• Sie ermöglichen die Ausführung oder Simulation von Schaltkreisen.
• Sie liefern technische Zielbedingungen für die Kompilierung.
• Sie verbinden TKET mit anderen Frameworks und Plattformen.

Die Architektur von TKET ist deshalb nicht als geschlossenes System zu verstehen, sondern als vermittelnde Schicht. pytket stellt den praktischen Zugang bereit, das Circuit-Modell bildet die interne Struktur, Compiler-Passes führen die Transformationen aus, und Backends sowie Erweiterungsmodule verbinden das Ergebnis mit realen oder simulierten Zielsystemen.

Optimierungsfunktionen von TKET

Reduktion der Schaltkreistiefe

Die Reduktion der Schaltkreistiefe gehört zu den wichtigsten Optimierungszielen von TKET. Die Schaltkreistiefe beschreibt, wie viele aufeinanderfolgende Operationsschichten ein Quantenschaltkreis besitzt. Sie ist nicht identisch mit der reinen Anzahl der Gates, sondern gibt an, wie viele Zeitschritte notwendig sind, wenn parallel ausführbare Operationen zusammengefasst werden.

Für NISQ-Geräte ist eine geringe Schaltkreistiefe entscheidend. Qubits sind empfindliche physikalische Systeme. Je länger ein Quantenzustand erhalten bleiben muss, desto stärker wirken Rauschen, Dekohärenz und Kontrollfehler. Ein tiefer Schaltkreis verlangt längere kohärente Entwicklung und erhöht damit die Wahrscheinlichkeit, dass das Messergebnis vom idealen Ergebnis abweicht.

Die Tiefe eines Schaltkreises kann abstrakt als Funktion beschrieben werden:

\(d(C)\)

Dabei steht \(C\) für den Schaltkreis und \(d(C)\) für seine Tiefe. Ein Optimierungsziel besteht darin, einen äquivalenten Schaltkreis \(C'\) zu finden, für den gilt:

\(d(C') < d(C)\)

Diese Reduktion kann durch verschiedene Maßnahmen erreicht werden: Entfernen redundanter Operationen, Umordnen kommutierender Gates, Zusammenfassen von Gate-Sequenzen oder bessere Ausnutzung paralleler Ausführungsmöglichkeiten.

Der technische Nutzen ist direkt: Weniger Tiefe bedeutet meist kürzere Laufzeit, geringere Fehlerakkumulation und höhere Erfolgschancen bei der Ausführung auf realer Hardware. Besonders bei Algorithmen mit vielen Zweiqubit-Gates kann die Tiefe zum begrenzenden Faktor werden, weil Zweiqubit-Gates häufig langsamer und fehleranfälliger sind als einqubitige Operationen.

TKET behandelt Schaltkreistiefe deshalb nicht als bloßen Kennwert, sondern als praktische Optimierungsgröße. Ein Schaltkreis, der mathematisch korrekt ist, kann auf NISQ-Hardware trotzdem unbrauchbar sein, wenn er zu tief ist. Die Reduktion der Schaltkreistiefe ist daher ein direkter Beitrag zur Ausführbarkeit.

Gate-Optimierung

Gate-Optimierung bezeichnet die systematische Vereinfachung und Anpassung der Gate-Struktur eines Quantenschaltkreises. TKET analysiert die Folge der Operationen und sucht nach Möglichkeiten, den Schaltkreis kürzer, kompakter oder hardwaregerechter zu machen, ohne seine logische Wirkung zu verändern.

Ein einfaches Optimierungsziel ist das Entfernen redundanter Gates. Manche Gate-Folgen heben sich gegenseitig auf und können vollständig gestrichen werden. Ein klassisches Beispiel ist die doppelte Anwendung des Pauli-X-Gates:

\(X X = I\)

Dabei steht \(I\) für die Identitätsoperation. Wird diese Struktur im Schaltkreis erkannt und bestehen keine zusätzlichen Abhängigkeiten, kann der Compiler beide Gates entfernen.

Auch andere Gate-Sequenzen lassen sich vereinfachen. Rotationsgates können beispielsweise zusammengefasst werden, wenn sie auf derselben Achse und auf demselben Qubit wirken:

\(R_z(\theta_1) R_z(\theta_2) = R_z(\theta_1 + \theta_2)\)

Solche lokalen Vereinfachungen reduzieren die Gate-Anzahl und können zugleich die Schaltkreistiefe senken. In großen Schaltkreisen entstehen durch algorithmische Konstruktion, Framework-Konvertierung oder vorherige Kompilierungsschritte häufig redundante Muster. Ein optimierender Compiler muss diese Muster erkennen und beseitigen.

Ein weiteres zentrales Ziel ist die effiziente Zerlegung in native Operationen. Nicht jedes abstrakte Gate ist auf jeder Hardware direkt verfügbar. Ein Gate muss daher häufig in eine Sequenz unterstützter nativer Gates übersetzt werden:

\(G_{\mathrm{abstract}} \rightarrow N_1 N_2 \cdots N_k\)

Dabei steht \(G_{\mathrm{abstract}}\) für ein abstraktes Gate und \(N_1, N_2, ..., N_k\) für native Gates der Zielhardware. Die Qualität dieser Zerlegung ist entscheidend. Eine unnötig lange Zerlegung erhöht die Fehlerwahrscheinlichkeit und kann den Vorteil eines Algorithmus praktisch zerstören.

Gate-Optimierung umfasst daher drei Hauptaufgaben:

• redundante Gates entfernen,
• Gate-Sequenzen vereinfachen,
• abstrakte Operationen effizient in native Operationen zerlegen.

TKET nutzt diese Optimierungen, um Schaltkreise nicht nur syntaktisch umzuschreiben, sondern physikalisch sinnvoller ausführbar zu machen. In der NISQ-Ära zählt jedes vermiedene Gate, weil jedes zusätzliche Gate eine weitere Fehlerquelle darstellt.

Qubit-Mapping

Qubit-Mapping beschreibt die Zuordnung logischer Qubits eines Quantenschaltkreises zu physischen Qubits einer konkreten Hardware. Diese Aufgabe ist notwendig, weil ein Algorithmus zunächst mit abstrakten Qubits arbeitet, während reale Quantenprozessoren konkrete physische Qubits mit bestimmten Verbindungen und Eigenschaften besitzen.

Ein logisches Qubit ist Teil der algorithmischen Beschreibung. Ein physisches Qubit ist ein tatsächliches kontrollierbares Element auf einem Quantenprozessor. Der Compiler muss entscheiden, welches logische Qubit auf welchem physischen Qubit ausgeführt wird.

Formal lässt sich diese Zuordnung als Abbildung beschreiben:

\(f: Q_{\mathrm{logical}} \rightarrow Q_{\mathrm{physical}}\)

Dabei bezeichnet \(Q_{\mathrm{logical}}\) die Menge der logischen Qubits und \(Q_{\mathrm{physical}}\) die Menge der physischen Qubits.

Diese Zuordnung ist nicht beliebig. Sie beeinflusst direkt, wie viele zusätzliche Operationen später notwendig werden. Der Grund liegt in der Hardware-Konnektivität. Viele Quantenprozessoren erlauben Zweiqubit-Gates nur zwischen bestimmten physischen Qubits. Wenn zwei logische Qubits im Schaltkreis häufig miteinander interagieren, sollten sie möglichst auf physische Qubits abgebildet werden, die direkt oder zumindest günstig verbunden sind.

Die Hardware-Konnektivität kann als Kopplungsgraph beschrieben werden:

\(G_{\mathrm{hardware}} = (V, E)\)

Dabei steht \(V\) für die physischen Qubits und \(E\) für die erlaubten direkten Kopplungen. Eine Zweiqubit-Operation ist direkt ausführbar, wenn die beteiligten physischen Qubits durch eine Kante in \(E\) verbunden sind.

Ein schlechtes Mapping kann dazu führen, dass viele zusätzliche Routing-Operationen eingefügt werden müssen. Ein gutes Mapping reduziert diese Zusatzkosten. Deshalb ist Qubit-Mapping keine formale Nebensache, sondern eine der zentralen Optimierungsaufgaben in der Quantum Compilation.

Das Ziel kann vereinfacht als Minimierung der späteren Routing-Kosten beschrieben werden:

\(f^* = \arg\min_f \mathrm{Cost}_{\mathrm{routing}}(f)\)

Dabei steht \(f^*\) für eine günstige Mapping-Funktion und \(\mathrm{Cost}_{\mathrm{routing}}(f)\) für die Routing-Kosten, die aus dieser Zuordnung entstehen.

TKET nutzt Qubit-Mapping, um den Schaltkreis besser an die Zielhardware anzupassen. Je passender die Zuordnung, desto weniger zusätzliche Gates sind notwendig. Dadurch sinken Gate-Anzahl, Schaltkreistiefe und potenzielle Fehlerakkumulation.

Routing

Routing ist das Verfahren, mit dem ein Compiler Zweiqubit-Operationen ausführbar macht, wenn die beteiligten Qubits auf der Hardware nicht direkt verbunden sind. Es ist eng mit Qubit-Mapping verbunden, wird aber relevant, sobald die gewählte Zuordnung nicht ausreicht, um alle benötigten Interaktionen direkt auszuführen.

Ein abstrakter Quantenschaltkreis kann eine Operation zwischen zwei beliebigen logischen Qubits enthalten. Reale Hardware erlaubt jedoch häufig nur Operationen entlang eines Kopplungsgraphen. Wenn zwei physische Qubits nicht direkt verbunden sind, muss der Compiler den Zustand so durch die Hardware bewegen, dass die gewünschte Operation möglich wird.

Ein häufiges Mittel dafür sind SWAP-Operationen. Eine SWAP-Operation vertauscht die Zustände zweier Qubits:

\(\mathrm{SWAP}(q_i, q_j): q_i \leftrightarrow q_j\)

Durch mehrere SWAPs kann ein logischer Zustand entlang des Kopplungsgraphen verschoben werden. Dadurch wird eine ursprünglich nicht direkt ausführbare Interaktion möglich. Der Preis dafür sind zusätzliche Gates.

Das Routing-Problem besteht darin, diese zusätzlichen Gates möglichst gering zu halten. Ein naiver Routing-Ansatz kann die Gate-Anzahl stark erhöhen. Ein guter Routing-Ansatz sucht dagegen eine effiziente Sequenz, die die gewünschte Konnektivität herstellt und die Schaltkreisstruktur möglichst wenig belastet.

Vereinfacht kann Routing als Transformation beschrieben werden:

\(C_{\mathrm{mapped}} \rightarrow C_{\mathrm{routed}}\)

Dabei ist \(C_{\mathrm{mapped}}\) der Schaltkreis nach dem Qubit-Mapping und \(C_{\mathrm{routed}}\) der Schaltkreis, in dem alle benötigten Operationen mit der Hardware-Konnektivität vereinbar sind.

Das Ziel lautet:

\(\mathrm{Cost}(C_{\mathrm{routed}}) \rightarrow \min\)

Die Kosten können zusätzliche SWAPs, zusätzliche Zweiqubit-Gates, größere Schaltkreistiefe oder höhere erwartete Fehlerraten umfassen.

Routing ist besonders kritisch, weil SWAP-Operationen selbst nicht immer native Einzeloperationen sind. Häufig müssen sie in mehrere elementare Zweiqubit-Gates zerlegt werden. Eine mögliche Darstellung ist:

\(\mathrm{SWAP}(q_i, q_j) = \mathrm{CX}(q_i, q_j)\mathrm{CX}(q_j, q_i)\mathrm{CX}(q_i, q_j)\)

Das zeigt, warum Routing teuer sein kann. Jeder zusätzliche SWAP kann mehrere fehleranfällige Zweiqubit-Operationen erzeugen. TKET muss daher nicht nur irgendeinen Weg durch den Kopplungsgraphen finden, sondern einen möglichst günstigen.

Routing ist somit eine der Stellen, an denen sich die praktische Qualität eines Quantum-Compilers besonders deutlich zeigt. Ein guter Algorithmus kann durch schlechtes Routing stark an Ausführbarkeit verlieren. Umgekehrt kann intelligentes Routing einen Schaltkreis deutlich näher an eine realistische Hardwareausführung bringen.

Fehlerbewusste Kompilierung

TKET wurde für NISQ-Geräte entwickelt und zielt darauf ab, den Einfluss von Hardwarefehlern durch bessere Kompilierung zu reduzieren. Fehlerbewusste Kompilierung bedeutet, dass der Compiler die physikalischen Schwächen heutiger Quantenhardware nicht ignoriert, sondern bei der Schaltkreisvorbereitung berücksichtigt.

In der NISQ-Ära entstehen Fehler durch mehrere Mechanismen: Rauschen, Dekohärenz, unvollkommene Gates, Messfehler und technische Schwankungen im Hardwarebetrieb. Da vollständige Quantenfehlerkorrektur auf breiter praktischer Ebene noch nicht selbstverständlich verfügbar ist, muss bereits die Kompilierung helfen, die Fehlerbelastung zu reduzieren.

Ein vereinfachtes Modell der Schaltkreiszuverlässigkeit kann so aussehen:

\(P_{\mathrm{success}} \approx \prod_{i=1}^{n} p_i\)

Dabei steht \(p_i\) für die Erfolgswahrscheinlichkeit der jeweiligen Operation. Je mehr Operationen ein Schaltkreis enthält und je fehleranfälliger diese Operationen sind, desto geringer kann die Gesamterfolgswahrscheinlichkeit werden.

Fehlerbewusste Kompilierung versucht daher, besonders teure oder fehleranfällige Strukturen zu vermeiden. Dazu gehören unnötige Zweiqubit-Gates, lange Routing-Sequenzen, große Schaltkreistiefe und ungünstige Qubit-Zuordnungen. Wenn Hardwareinformationen über Fehlerraten verfügbar sind, können diese in die Optimierungsentscheidung einfließen.

Eine einfache fehlerbezogene Kostenfunktion kann so formuliert werden:

\(\mathrm{Cost}_{\mathrm{error}}(C) = \sum_{i=1}^{n} \epsilon_i\)

Dabei steht \(\epsilon_i\) für den geschätzten Fehlerbeitrag der jeweiligen Operation. Ziel ist es, einen logisch äquivalenten Schaltkreis mit geringerer Fehlerkostenfunktion zu finden:

\(C' = \arg\min_{C_i \sim C} \mathrm{Cost}_{\mathrm{error}}(C_i)\)

Die Bedingung \(C_i \sim C\) bedeutet, dass der Kandidatenschaltkreis \(C_i\) dieselbe logische Aufgabe erfüllen soll wie der ursprüngliche Schaltkreis \(C\).

In der Praxis bedeutet fehlerbewusste Kompilierung nicht, dass der Compiler alle Hardwarefehler beseitigt. Das kann er nicht. Er kann aber die Struktur des Schaltkreises so wählen, dass weniger riskante Operationen entstehen, weniger Routing nötig ist und die Ausführung kürzer oder robuster wird.

TKET verbindet dafür mehrere Optimierungsfunktionen: Schaltkreistiefenreduktion, Gate-Vereinfachung, Qubit-Mapping, Routing und Anpassung an native Gate-Sets. Diese Funktionen greifen ineinander. Eine bessere Qubit-Zuordnung kann Routing reduzieren. Weniger Routing kann die Gate-Anzahl senken. Eine geringere Gate-Anzahl kann die Fehlerakkumulation reduzieren. Eine geringere Tiefe kann die Wirkung von Dekohärenz begrenzen.

Der Nutzen fehlerbewusster Kompilierung liegt daher nicht in einem einzelnen Trick, sondern in der koordinierten Verbesserung des gesamten Schaltkreises. TKET wird dadurch zu einem Werkzeug, das die praktische Ausführung von Quantenprogrammen realistischer macht. Es übersetzt nicht nur, sondern bereitet Quantenprogramme auf eine Hardwarewelt vor, in der Fehler nicht Ausnahme, sondern Grundbedingung sind.

TKET im Quantum-Software-Ökosystem

Verhältnis zu Qiskit, Cirq und PennyLane

TKET kann nicht nur als eigenständiges Tool betrachtet werden, sondern auch als Compiler- und Optimierungsschicht innerhalb größerer Workflows. Diese Einordnung ist wichtig, weil moderne Quantum-Software selten aus einem einzigen Werkzeug besteht. In der Praxis werden Quantenprogramme häufig in einem Framework entworfen, in einem anderen optimiert und anschließend über ein weiteres System simuliert oder auf realer Hardware ausgeführt.

Qiskit, Cirq und PennyLane stehen für unterschiedliche Schwerpunkte innerhalb dieses Ökosystems. Qiskit ist stark mit dem IBM-Quantum-Umfeld verbunden und bietet Werkzeuge für Schaltkreiserstellung, Transpilation, Simulation und Hardwarezugriff. Cirq wurde für die Arbeit mit Quantenschaltkreisen und insbesondere für experimentelle Hardware-nahe Forschung entwickelt. PennyLane legt einen starken Schwerpunkt auf hybride quantenklassische Workflows, Variational Quantum Algorithms und Quantum Machine Learning.

TKET nimmt in diesem Umfeld eine besondere Rolle ein. Es ist nicht primär als domänenspezifische Algorithmusplattform zu verstehen, sondern als Compiler- und Optimierungsebene. Seine Aufgabe besteht darin, Quantenschaltkreise strukturell zu analysieren, zu transformieren und für Zielsysteme vorzubereiten.

Ein typischer Workflow kann daher so aussehen:

\(C_{\mathrm{framework}} \rightarrow C_{\mathrm{tket}} \rightarrow C_{\mathrm{optimised}} \rightarrow C_{\mathrm{backend}}\)

Dabei steht \(C_{\mathrm{framework}}\) für einen Schaltkreis, der in einem externen Framework erstellt wurde. \(C_{\mathrm{tket}}\) bezeichnet die TKET-interne Darstellung. \(C_{\mathrm{optimised}}\) ist die durch TKET optimierte Version, und \(C_{\mathrm{backend}}\) ist der für ein bestimmtes Zielsystem vorbereitete Schaltkreis.

Diese Struktur zeigt den eigentlichen Wert von TKET: Es ersetzt nicht zwangsläufig andere Frameworks, sondern kann sie ergänzen. Ein Schaltkreis kann in Qiskit, Cirq oder PennyLane entstehen und anschließend durch TKET optimiert werden. Umgekehrt kann ein in TKET bearbeiteter Schaltkreis wieder in ein anderes Ökosystem überführt werden, wenn der Workflow dies verlangt.

Damit wirkt TKET als technische Vermittlungsschicht. Es verbindet algorithmische Entwicklung, Schaltkreisoptimierung und Hardware-Anpassung. Gerade diese Rolle macht TKET für Forschung und Entwicklung interessant, weil unterschiedliche Quantenplattformen verglichen, getestet oder gemeinsam in einem Workflow verwendet werden können.

Interoperabilität als praktischer Vorteil

Durch Erweiterungsmodule können Schaltkreise zwischen unterschiedlichen Frameworks und Hardwarezugängen konvertiert oder ausgeführt werden. Diese Interoperabilität ist ein praktischer Vorteil, weil das Quantum-Software-Ökosystem stark fragmentiert ist. Unterschiedliche Anbieter verwenden unterschiedliche Schnittstellen, Schaltkreismodelle, Backend-Strukturen und Ausführungswege.

Ohne Interoperabilität müsste ein Schaltkreis häufig für jedes Zielsystem neu aufgebaut oder manuell angepasst werden. Das wäre fehleranfällig, langsam und für systematische Vergleiche ungeeignet. TKET reduziert diese Reibung, indem es als gemeinsame Compiler-Ebene zwischen verschiedenen Werkzeugen eingesetzt werden kann.

Ein interoperabler Ablauf lässt sich vereinfacht so darstellen:

\(C_A \rightarrow C_{\mathrm{tket}} \rightarrow C_B\)

Dabei steht \(C_A\) für einen Schaltkreis aus einem Ausgangsframework und \(C_B\) für eine Darstellung, die in einem anderen Framework oder Backend weiterverwendet werden kann. TKET übernimmt dabei nicht nur die reine Konvertierung, sondern kann während dieses Übergangs auch Optimierungen durchführen.

Der praktische Nutzen zeigt sich besonders in vier Bereichen:

• Schaltkreise können zwischen Frameworks übertragen werden.
• Optimierungen können unabhängig vom ursprünglichen Entwicklungswerkzeug angewendet werden.
• Ein Algorithmus kann für verschiedene Hardwareplattformen vorbereitet werden.
• Benchmarking über mehrere Backends hinweg wird einfacher und vergleichbarer.

Interoperabilität ist dabei nicht nur eine Frage der Bequemlichkeit. Sie beeinflusst direkt die wissenschaftliche Arbeitsweise. Wer Quantenalgorithmen testet, muss oft wissen, ob ein Ergebnis von der algorithmischen Idee, vom Compiler, vom Backend oder von der Hardwarearchitektur abhängt. Eine flexible Compiler-Schicht hilft, diese Faktoren kontrollierter zu untersuchen.

Besonders wichtig ist die Unterscheidung zwischen logischer Schaltkreisstruktur und backendabhängiger Ausführung. Ein Algorithmus kann auf logischer Ebene gleich bleiben, während verschiedene kompilierte Versionen für verschiedene Zielsysteme entstehen:

\(C_{\mathrm{logical}} \rightarrow \{C_{\mathrm{backend\ 1}}, C_{\mathrm{backend\ 2}}, ..., C_{\mathrm{backend\ n}}\}\)

Diese Fähigkeit unterstützt hardwareübergreifende Forschung. Ein Schaltkreis kann auf Simulatoren, Cloud-Zugängen oder realen Quantenprozessoren untersucht werden, ohne dass die algorithmische Ausgangsbeschreibung jedes Mal vollständig neu formuliert werden muss.

TKET gewinnt dadurch eine strategische Rolle: Es macht Quantum-Software beweglicher. In einem Feld, in dem Hardware, Frameworks und Schnittstellen sich schnell entwickeln, ist diese Beweglichkeit entscheidend. Interoperabilität schützt vor starrer Bindung an eine einzelne Plattform und erleichtert den Vergleich unterschiedlicher technologischer Ansätze.

TKET und Quantinuum

TKET ist Teil der Quantinuum-Entwicklerwerkzeuge. Quantinuum beschreibt TKET als Open-Source-Toolkit zur Konstruktion, Optimierung und Ausführung von Quantenprogrammen auf verschiedenen Geräten und Simulatoren.

Diese Einordnung verbindet TKET mit einem industriellen Quantum-Software- und Hardware-Ökosystem. Quantinuum entstand aus der Verbindung von Cambridge Quantum und Honeywell Quantum Solutions. Dadurch steht TKET in einem Umfeld, das sowohl Compiler-Technologie als auch reale Quantenhardware und anwendungsnahe Quantum-Software umfasst.

Für die Abhandlung ist dabei vor allem wichtig, dass TKET nicht nur als isoliertes Forschungsprojekt betrachtet werden sollte. Es ist Teil einer breiteren Infrastruktur für Quantum Development. Dazu gehören Werkzeuge für Schaltkreiserstellung, Optimierung, Ausführung, Fehlerbehandlung, Backend-Anbindung und Workflow-Integration.

Die Rolle von TKET innerhalb dieses Zusammenhangs lässt sich vereinfacht so beschreiben:

\(\mathrm{Algorithmus} \rightarrow \mathrm{TKET} \rightarrow \mathrm{Quantinuum\ oder\ anderes\ Backend}\)

TKET steht dabei zwischen der algorithmischen Beschreibung und der konkreten Ausführungsumgebung. Es bereitet den Schaltkreis so vor, dass er besser zu den Anforderungen des Zielsystems passt. Das Zielsystem kann ein Quantinuum-System sein, muss aber nicht darauf beschränkt bleiben.

Gerade diese Offenheit ist wesentlich. Obwohl TKET Teil der Quantinuum-Werkzeuglandschaft ist, bleibt sein technischer Anspruch retargetierend und plattformübergreifend. Das unterscheidet TKET von Werkzeugen, die ausschließlich für eine einzelne Hardwarefamilie konzipiert sind.

Für Entwicklerinnen und Entwickler bedeutet das: TKET kann in Workflows eingesetzt werden, die Quantinuum-Systeme nutzen, aber auch in Szenarien, in denen andere Frameworks, Simulatoren oder Hardwarezugänge beteiligt sind. Dadurch bleibt TKET als Compiler-Schicht flexibel einsetzbar.

Die Verbindung zu Quantinuum stärkt zugleich den Praxisbezug. Compiler-Optimierung ist in der Quantentechnologie kein rein theoretisches Thema. Sie muss sich an realen Geräten, realen Fehlerprofilen und realen Ausführungsbedingungen bewähren. TKET ist genau an dieser Schnittstelle positioniert.

Zusammengefasst nimmt TKET im Quantum-Software-Ökosystem eine vermittelnde Rolle ein. Es verbindet Frameworks, Backends und Hardwareziele über eine optimierende Compiler-Schicht. Dadurch wird TKET nicht nur zu einem Werkzeug für einzelne Schaltkreise, sondern zu einem Baustein für portable, vergleichbare und hardwarebewusste Quantum-Software.

Wissenschaftliche Einordnung

TKET in der Forschungsliteratur

Die zentrale wissenschaftliche Veröffentlichung zu TKET beschreibt es als retargetierbaren Compiler für NISQ-Geräte. Der Fokus liegt auf Schaltkreisoptimierung, Routing und Geräteunabhängigkeit.

Diese Einordnung ist präzise, weil TKET nicht aus der Perspektive eines einzelnen Quantenalgorithmus entwickelt wurde, sondern aus der Perspektive der praktischen Ausführbarkeit auf begrenzter Hardware. In der Forschungsliteratur steht daher nicht nur die Frage im Mittelpunkt, wie ein Quantenschaltkreis dargestellt wird, sondern wie er für reale Geräte umgeformt werden kann.

Die wissenschaftliche Relevanz von TKET ergibt sich aus drei Kernproblemen der NISQ-Ära:

• Quantenschaltkreise müssen trotz Rauschen und Fehlerraten ausführbar bleiben.
• Abstrakte Schaltkreise müssen an unterschiedliche Hardwarearchitekturen angepasst werden.
• Compiler müssen zusätzliche Kosten durch Mapping, Routing und Gate-Zerlegung minimieren.

In der Forschung wird TKET deshalb als Werkzeug betrachtet, das zwischen der mathematischen Beschreibung eines Quantenalgorithmus und der technischen Realität eines Quantenprozessors vermittelt. Diese Vermittlungsfunktion ist für NISQ-Geräte besonders wichtig, weil dort keine vollständige Fehlerkorrektur vorausgesetzt werden kann.

Ein abstrakter Quantenalgorithmus kann formal als ideale Operation beschrieben werden:

\(U_{\mathrm{ideal}}\)

Die reale Ausführung auf Hardware entspricht jedoch einer fehlerbehafteten Annäherung:

\(U_{\mathrm{real}} = U_{\mathrm{ideal}} + E\)

Dabei steht \(E\) für den Fehleranteil, der durch Rauschen, unvollkommene Gates, Messfehler und technische Einschränkungen entsteht. Ein Compiler wie TKET kann \(E\) nicht vollständig eliminieren, aber er kann Schaltkreise so transformieren, dass unnötige Fehlerquellen reduziert werden.

Die wissenschaftliche Betrachtung von TKET konzentriert sich daher auf Optimierungsqualität, Hardwareanpassung und strukturelle Flexibilität. Besonders relevant sind Verfahren zur Reduktion der Schaltkreistiefe, zur Verringerung von Zweiqubit-Gates, zur Auswahl günstiger Qubit-Zuordnungen und zur effizienten Einbindung von Routing-Operationen.

Damit steht TKET exemplarisch für eine zentrale Entwicklung in der Quantentechnologie: Der Quantum-Compiler wird nicht mehr als nachgelagerter Übersetzer betrachtet, sondern als aktiver Bestandteil der Leistungsfähigkeit eines Quantum-Software-Stacks.

Vergleich mit anderen Quantum-Compilern

Ein Vergleich von TKET mit anderen Quantum-Compilern wie Qiskit, ProjectQ, Quilc und weiteren Compiler-Ansätzen sollte sich auf konkrete technische Kriterien stützen. Ein bloßer Vergleich nach Bekanntheit oder Plattformzugehörigkeit wäre unzureichend. Entscheidend ist, wie gut ein Compiler abstrakte Schaltkreise optimiert, auf Zielhardware abbildet und in unterschiedliche Workflows integriert werden kann.

Ein sinnvoller Vergleich kann nach folgenden Kriterien erfolgen:

• Optimierungsleistung,
• Reduktion der Schaltkreistiefe,
• Reduktion der Gate-Anzahl,
• Effizienz des Qubit-Mappings,
• Qualität des Routings,
• Unterstützung verschiedener Hardwarearchitekturen,
• Interoperabilität mit anderen Frameworks,
• Erweiterbarkeit durch Module oder Schnittstellen,
• Transparenz der Compiler-Pipeline,
• Nutzung in Forschung, Industrie und Lehre.

Qiskit bietet einen umfangreichen Software-Stack mit starker Anbindung an IBM Quantum. Sein Transpiler ist eng mit den Anforderungen der IBM-Hardware und des Qiskit-Ökosystems verbunden, kann aber auch breiter eingesetzt werden. ProjectQ verfolgt einen modularen Ansatz für Quantum Programming und Compilation. Quilc ist im Umfeld von Quil und Rigetti-Systemen relevant und konzentriert sich auf die Kompilierung von Quantenprogrammen in diesem Kontext.

TKET unterscheidet sich durch seinen stark retargetierenden Compiler-Ansatz. Es ist darauf ausgelegt, Quantenschaltkreise unabhängig von einer einzelnen Hardwareplattform zu optimieren und an unterschiedliche Zielsysteme anzupassen. Dadurch eignet sich TKET besonders für Workflows, in denen Portabilität, Interoperabilität und hardwareübergreifende Vergleichbarkeit wichtig sind.

Ein abstraktes Vergleichsmodell kann so formuliert werden:

\(\mathrm{Compiler\ Quality} = f(O, H, I, E)\)

Dabei steht \(O\) für Optimierungsleistung, \(H\) für Hardwareunterstützung, \(I\) für Interoperabilität und \(E\) für Erweiterbarkeit.

Für einen NISQ-Compiler reicht es nicht, nur syntaktisch korrekte Zielschaltkreise zu erzeugen. Er muss die Kosten der Ausführung senken. Diese Kosten können als Kombination verschiedener Faktoren verstanden werden:

\(\mathrm{Cost}(C) = a \cdot d(C) + b \cdot g_2(C) + c \cdot r(C) + e \cdot \epsilon(C)\)

Dabei steht \(d(C)\) für die Schaltkreistiefe, \(g_2(C)\) für die Anzahl der Zweiqubit-Gates, \(r(C)\) für den Routing-Aufwand und \(\epsilon(C)\) für den geschätzten Fehlerbeitrag. Die Gewichtungen \(a\), \(b\), \(c\) und \(e\) hängen vom Zielsystem und vom Optimierungsziel ab.

Ein belastbarer Vergleich verschiedener Compiler sollte daher nicht nur prüfen, ob ein Schaltkreis erfolgreich kompiliert wird. Er sollte messen, wie sich die Kompilierung auf Tiefe, Gate-Anzahl, Zweiqubit-Gate-Anteil, zusätzliche SWAP-Operationen, Laufzeit der Kompilierung und Ausführungsqualität auswirkt.

TKET ist in einem solchen Vergleich besonders dort stark einzuordnen, wo retargetierbare Optimierung und plattformübergreifende Nutzung gefragt sind. Andere Compiler können in bestimmten Ökosystemen, Hardwarekontexten oder Spezialanwendungen Vorteile besitzen. Die wissenschaftliche Bewertung muss deshalb immer vom konkreten Anwendungsszenario ausgehen.

Aktuelle Forschung zu Retargetability

Neuere Arbeiten untersuchen die Retargetability von Quantum-Compilern und vergleichen unter anderem TKET, Qiskit und ProjectQ. Eine 2026 veröffentlichte Untersuchung sieht TKET bei den betrachteten Retargetability-Kriterien stark positioniert.

Retargetability wird in der aktuellen Forschung zunehmend als eigenständiges Qualitätsmerkmal von Quantum-Compilern betrachtet. Der Grund ist einfach: Quantenhardware entwickelt sich nicht entlang einer einzigen, einheitlichen Architektur. Verschiedene Plattformen besitzen unterschiedliche native Gates, unterschiedliche Konnektivitätsmodelle, unterschiedliche Fehlerraten und unterschiedliche Ausführungsbedingungen. Ein Compiler, der nur für eine Zielarchitektur optimiert ist, kann in einem solchen Umfeld schnell an Grenzen stoßen.

Retargetability beschreibt deshalb die Fähigkeit, einen Schaltkreis nicht nur einmal zu kompilieren, sondern ihn systematisch an verschiedene Zielsysteme anzupassen:

\(C_{\mathrm{logical}} \rightarrow C_{\mathrm{target},1}\)

\(C_{\mathrm{logical}} \rightarrow C_{\mathrm{target},2}\)

\(C_{\mathrm{logical}} \rightarrow C_{\mathrm{target},3}\)

Dabei bleibt \(C_{\mathrm{logical}}\) die logische Ausgangsbeschreibung, während \(C_{\mathrm{target},1}\), \(C_{\mathrm{target},2}\) und \(C_{\mathrm{target},3}\) unterschiedliche hardwareangepasste Versionen darstellen.

Aktuelle Forschung zu Retargetability betrachtet unter anderem folgende Fragen:

• Wie flexibel kann ein Compiler unterschiedliche Gate-Sets unterstützen?
• Wie gut kann er verschiedene Kopplungsgraphen verarbeiten?
• Wie modular ist seine Backend-Anbindung?
• Wie klar lassen sich hardwareabhängige und hardwareunabhängige Kompilierungsschritte trennen?
• Wie gut kann ein Compiler mit neuen oder veränderten Zielarchitekturen umgehen?
• Wie transparent und anpassbar ist die Compiler-Pipeline?

TKET ist für solche Untersuchungen besonders relevant, weil sein Ansatz nicht auf ein einzelnes Hardwaremodell reduziert ist. Die Compiler-Struktur erlaubt eine Trennung zwischen abstrakter Schaltkreisrepräsentation, allgemeinen Optimierungsschritten und backendbezogener Anpassung. Genau diese Trennung ist für Retargetability entscheidend.

Ein retargetierbarer Compiler muss mindestens drei Ebenen sauber behandeln:

• die logische Ebene des Algorithmus,
• die compilerinterne Ebene der Optimierung,
• die physische Ebene der Zielhardware.

Diese Ebenen können formal als Abfolge beschrieben werden:

\(A \rightarrow C_{\mathrm{logical}} \rightarrow C_{\mathrm{optimised}} \rightarrow C_{\mathrm{physical}}\)

Dabei steht \(A\) für den Algorithmus, \(C_{\mathrm{logical}}\) für den logischen Schaltkreis, \(C_{\mathrm{optimised}}\) für den optimierten Schaltkreis und \(C_{\mathrm{physical}}\) für die hardwareangepasste Ausführungsform.

Die wissenschaftliche Bedeutung dieser Forschung liegt darin, dass Retargetability eine Voraussetzung für robuste Quantum-Software-Infrastrukturen ist. Wenn Quantenprogramme langfristig nutzbar, vergleichbar und portabel sein sollen, dürfen sie nicht vollständig an eine einzelne Hardwaregeneration gebunden sein.

TKET steht in dieser Entwicklung für einen Compiler-Ansatz, der Portabilität und Optimierung verbindet. Das ist für die gegenwärtige NISQ-Ära relevant und kann auch für zukünftige, größere und stärker spezialisierte Quantenarchitekturen wichtig bleiben. Je vielfältiger die Hardwarelandschaft wird, desto wichtiger wird eine Compiler-Schicht, die diese Vielfalt technisch handhabbar macht.

Praktische Anwendungsfelder

Forschung und Prototyping

TKET eignet sich für Forschende, die Quantenschaltkreise entwickeln, analysieren und auf unterschiedliche Zielsysteme vorbereiten möchten. Gerade in der Forschung ist diese Flexibilität wichtig, weil Quantenalgorithmen häufig zunächst abstrakt formuliert und anschließend auf mehreren Simulatoren oder Hardwareplattformen getestet werden.

Im Prototyping geht es nicht nur darum, einen Schaltkreis einmal auszuführen. Entscheidend ist, verschiedene Varianten eines Schaltkreises zu erzeugen, zu vergleichen und zu bewerten. TKET unterstützt diesen Prozess, indem Schaltkreise transformiert, optimiert und für verschiedene Backends vorbereitet werden können.

Ein typischer Forschungsworkflow lässt sich vereinfacht so darstellen:

\(Idee \rightarrow C_{\mathrm{prototype}} \rightarrow C_{\mathrm{optimised}} \rightarrow C_{\mathrm{target}} \rightarrow Ergebnis\)

Dabei steht \(C_{\mathrm{prototype}}\) für den ersten experimentellen Schaltkreis, \(C_{\mathrm{optimised}}\) für die optimierte Fassung und \(C_{\mathrm{target}}\) für die Version, die an ein konkretes Zielsystem angepasst wurde.

Für Forschende ist besonders wertvoll, dass TKET nicht nur das Endergebnis betrachtet, sondern auch Zwischenschritte sichtbar und kontrollierbar machen kann. Dadurch lässt sich untersuchen, wie sich bestimmte Compiler-Passes auf Gate-Anzahl, Schaltkreistiefe, Routing-Aufwand oder Hardwarekompatibilität auswirken.

Ein Schaltkreis kann beispielsweise nach seiner Tiefe, Gate-Anzahl oder Zahl der Zweiqubit-Gates bewertet werden:

\(M(C) = (d(C), g(C), g_2(C))\)

Dabei steht \(d(C)\) für die Schaltkreistiefe, \(g(C)\) für die gesamte Gate-Anzahl und \(g_2(C)\) für die Anzahl der Zweiqubit-Gates.

Diese Kennzahlen sind für Prototyping entscheidend. Ein Algorithmus kann theoretisch korrekt sein, aber auf NISQ-Hardware praktisch scheitern, wenn seine kompilierte Form zu tief oder zu fehleranfällig ist. TKET hilft dabei, diese technische Grenze früh sichtbar zu machen.

Algorithmendesign

TKET kann beim Design und bei der praktischen Untersuchung von Quantenalgorithmen eingesetzt werden. Relevant ist dies besonders bei Variational Quantum Algorithms, Quantenchemie, Optimierungsproblemen, Simulation und hardwarebewusster Algorithmusentwicklung.

Variational Quantum Algorithms verbinden Quantenschaltkreise mit klassischer Optimierung. Ein parametrisierter Quantenschaltkreis wird wiederholt ausgeführt, während ein klassischer Optimierer die Parameter anpasst. Ein einfaches Variationsproblem kann so formuliert werden:

\(\theta^* = \arg\min_{\theta} E(\theta)\)

Dabei steht \(\theta\) für die Parameter des Schaltkreises und \(E(\theta)\) für die zu minimierende Zielfunktion, etwa eine Energie in der Quantenchemie oder eine Kostenfunktion in einem Optimierungsproblem.

Der zugehörige Quantenzustand kann als parametrisierter Zustand beschrieben werden:

\(|\psi(\theta)\rangle = U(\theta)|0\rangle\)

Dabei ist \(U(\theta)\) der parametrisierte Quantenschaltkreis. TKET kann helfen, diesen Schaltkreis effizienter zu gestalten, bevor er auf einem Backend ausgeführt wird.

Bei Quantenchemie-Anwendungen ist die Schaltkreisstruktur oft anspruchsvoll, weil elektronische Zustände, Hamiltonoperatoren und Erwartungswerte abgebildet werden müssen. Ein typisches Ziel ist die Minimierung eines Erwartungswertes:

\(E(\theta) = \langle \psi(\theta)|H|\psi(\theta)\rangle\)

Dabei steht \(H\) für den Hamiltonoperator des betrachteten Systems. Je tiefer und komplexer der Schaltkreis ist, desto schwieriger wird die zuverlässige Ausführung auf NISQ-Geräten. Compiler-Optimierung ist deshalb direkt mit der praktischen Nutzbarkeit solcher Verfahren verbunden.

Auch bei Optimierungsproblemen spielt TKET eine wichtige Rolle. Viele quantennahe Optimierungsverfahren erzeugen Schaltkreise mit wiederkehrenden Strukturen. Diese Strukturen können redundante Gates enthalten oder durch hardwareabhängige Anpassung deutlich verändert werden. TKET unterstützt hier die Analyse, wie ein algorithmisches Design nach der Kompilierung tatsächlich aussieht.

Für hardwarebewusstes Algorithmendesign ist diese Rückkopplung entscheidend. Entwicklerinnen und Entwickler können nicht nur fragen, ob ein Algorithmus mathematisch funktioniert, sondern auch, ob seine Schaltkreisform zu einer realen Architektur passt. TKET macht diesen Übergang sichtbar:

\(Algorithmus \rightarrow Schaltkreis \rightarrow kompilierte\ Hardwareform\)

Damit wird TKET zu einem Werkzeug, das Algorithmendesign und Hardware-Realität enger miteinander verbindet.

Benchmarking von Quantenhardware

TKET kann zur Vereinheitlichung und Optimierung von Testschaltkreisen genutzt werden, wenn Schaltkreise für unterschiedliche Hardwareplattformen kompiliert werden sollen. Das ist besonders wichtig für Benchmarking, weil ein fairer Vergleich zwischen Quantenhardware nicht nur vom Algorithmus abhängt, sondern auch von der Art der Kompilierung.

Benchmarking in der Quantentechnologie ist anspruchsvoll. Unterschiedliche Hardwareplattformen besitzen unterschiedliche native Gates, Kopplungsgraphen, Fehlerraten und Ausführungsbedingungen. Ein Testschaltkreis muss daher für jede Plattform angepasst werden. Ohne kontrollierte Kompilierung wäre unklar, ob Unterschiede im Ergebnis durch die Hardware, durch den Compiler oder durch eine ungünstige Schaltkreisübersetzung entstehen.

Ein hardwareübergreifender Benchmarking-Ablauf kann so dargestellt werden:

\(C_{\mathrm{test}} \rightarrow C_{\mathrm{backend\ 1}}\)

\(C_{\mathrm{test}} \rightarrow C_{\mathrm{backend\ 2}}\)

\(C_{\mathrm{test}} \rightarrow C_{\mathrm{backend\ 3}}\)

Dabei bleibt \(C_{\mathrm{test}}\) der gemeinsame Ausgangsschaltkreis, während die einzelnen Zielschaltkreise an unterschiedliche Backends angepasst werden.

TKET kann in solchen Szenarien helfen, die Kompilierung systematischer und nachvollziehbarer zu machen. Es erlaubt, vergleichbare Optimierungsschritte auf verschiedene Zielsysteme anzuwenden und anschließend die resultierenden Schaltkreise zu bewerten.

Wichtige Benchmarking-Kennzahlen sind:

• Schaltkreistiefe,
• Gesamtzahl der Gates,
• Anzahl der Zweiqubit-Gates,
• Anzahl zusätzlicher Routing-Operationen,
• erwartete Fehlerrate,
• Ausführungszeit,
• Qualität der Messergebnisse.

Eine einfache Benchmarking-Funktion kann als Kombination technischer Messgrößen formuliert werden:

\(B(C) = a \cdot d(C) + b \cdot g_2(C) + c \cdot r(C) + e \cdot \epsilon(C)\)

Dabei steht \(d(C)\) für die Tiefe, \(g_2(C)\) für die Zahl der Zweiqubit-Gates, \(r(C)\) für den Routing-Aufwand und \(\epsilon(C)\) für einen geschätzten Fehlerbeitrag. Die Gewichtungen \(a\), \(b\), \(c\) und \(e\) hängen vom konkreten Benchmarking-Ziel ab.

Für Hardwarevergleiche ist TKET vor allem deshalb nützlich, weil es die gleiche algorithmische Ausgangsbasis in verschiedene hardwaregerechte Formen überführen kann. Dadurch wird sichtbarer, welche Plattform welche Art von Schaltkreis gut bewältigt und wo zusätzliche Kompilierungskosten entstehen.

Ausbildung und Lehre

TKET eignet sich zur Demonstration moderner Compilerfragen in der Quantentechnologie: Routing, Gate-Set-Transformation, Circuit Depth, Noise und Hardware-Mapping. Damit ist es nicht nur ein Forschungs- und Entwicklungswerkzeug, sondern auch ein didaktisch wertvolles System.

In der Lehre kann TKET zeigen, dass Quantenprogrammierung nicht bei der Formulierung eines Algorithmus endet. Ein Quantenschaltkreis muss für reale Hardware vorbereitet werden. Genau dieser Schritt ist für viele Lernende entscheidend, weil er die abstrakte Theorie mit der technischen Praxis verbindet.

Ein didaktischer Ablauf kann beispielsweise so aufgebaut sein:

\(C_{\mathrm{ideal}} \rightarrow C_{\mathrm{mapped}} \rightarrow C_{\mathrm{routed}} \rightarrow C_{\mathrm{native}}\)

Dabei steht \(C_{\mathrm{ideal}}\) für den idealisierten Schaltkreis, \(C_{\mathrm{mapped}}\) für den Schaltkreis nach Qubit-Mapping, \(C_{\mathrm{routed}}\) für den gerouteten Schaltkreis und \(C_{\mathrm{native}}\) für die Darstellung im nativen Gate-Set des Zielsystems.

An diesem Ablauf lassen sich zentrale Fragen moderner Quantum Compilation erklären:

• Warum ist ein idealer Schaltkreis nicht automatisch hardwaretauglich?
• Warum müssen logische Qubits auf physische Qubits abgebildet werden?
• Warum erzeugt eingeschränkte Konnektivität zusätzliche Gates?
• Warum sind Zweiqubit-Gates besonders kritisch?
• Wie beeinflusst Schaltkreistiefe die Fehleranfälligkeit?
• Warum unterscheiden sich kompilierte Schaltkreise je nach Backend?

Auch einfache Beispiele können starke Lernwirkung entfalten. Wenn zwei nicht benachbarte Qubits miteinander interagieren sollen, muss Routing eingesetzt werden. Eine SWAP-Operation kann dabei abstrakt als Vertauschung zweier Qubit-Zustände beschrieben werden:

\(\mathrm{SWAP}(q_i, q_j): q_i \leftrightarrow q_j\)

In der Lehre wird dadurch sofort sichtbar, warum Hardware-Konnektivität nicht nur ein technisches Detail ist, sondern die Struktur des Schaltkreises verändert.

Ebenso kann die Gate-Set-Transformation anschaulich demonstrieren, dass ein abstraktes Gate nicht immer direkt auf der Hardware existiert:

\(G_{\mathrm{abstract}} \rightarrow G_{\mathrm{native},1}G_{\mathrm{native},2}\cdots G_{\mathrm{native},k}\)

Damit wird klar, dass Quantum-Compiler nicht bloß übersetzen, sondern technische Kompromisse erzeugen. Jeder zusätzliche Schritt kann Tiefe, Gate-Anzahl und Fehlerwahrscheinlichkeit beeinflussen.

TKET eignet sich deshalb besonders für Lehrveranstaltungen, Übungen und praktische Demonstrationen zur Quantum Software. Es macht sichtbar, wie sich ein Schaltkreis durch Kompilierung verändert und welche Entscheidungen ein Compiler treffen muss. Dadurch wird die Quantentechnologie nicht nur als mathematische Theorie, sondern als reale Software- und Hardwaredisziplin verständlich.

Stärken von TKET

Hardwareübergreifender Ansatz

TKET ist nicht auf eine einzelne Plattform beschränkt und kann dadurch als neutrale Compiler-Schicht in heterogenen Quantenworkflows dienen. Diese Plattformunabhängigkeit ist eine der wichtigsten Stärken des Frameworks, weil die Quantenhardwarelandschaft technisch stark fragmentiert ist.

Verschiedene Quantencomputer unterscheiden sich in Qubit-Technologie, nativen Gates, Konnektivität, Fehlerraten, Messverfahren und Ausführungsbedingungen. Ein Schaltkreis, der für eine Architektur geeignet ist, kann auf einer anderen Architektur ineffizient oder unausführbar sein. TKET setzt genau an dieser Stelle an: Der gleiche logische Schaltkreis kann für unterschiedliche Zielsysteme vorbereitet werden.

Der hardwareübergreifende Ansatz lässt sich vereinfacht so darstellen:

\(C_{\mathrm{logical}} \rightarrow C_{\mathrm{target\ A}}\)

\(C_{\mathrm{logical}} \rightarrow C_{\mathrm{target\ B}}\)

\(C_{\mathrm{logical}} \rightarrow C_{\mathrm{target\ C}}\)

Dabei steht \(C_{\mathrm{logical}}\) für den logischen Ausgangsschaltkreis. Die Zielschaltkreise \(C_{\mathrm{target\ A}}\), \(C_{\mathrm{target\ B}}\) und \(C_{\mathrm{target\ C}}\) sind hardwareangepasste Varianten desselben algorithmischen Konzepts.

Diese Fähigkeit ist besonders wertvoll für Forschung, Benchmarking und industrielle Experimente. Sie ermöglicht es, denselben Algorithmus auf verschiedenen Plattformen zu untersuchen, ohne ihn vollständig neu entwickeln zu müssen. Dadurch wird sichtbarer, welche Unterschiede aus der Hardware stammen und welche aus der Compiler-Strategie oder dem Algorithmus selbst entstehen.

TKET kann dadurch als vermittelnde Schicht zwischen verschiedenen Quantum-Ökosystemen verstanden werden. Es stellt nicht eine einzelne Hardware in den Mittelpunkt, sondern den Transformationsprozess vom abstrakten Schaltkreis zur zielsystemgerechten Ausführung.

Starke Compiler-Orientierung

Der Kernnutzen von TKET liegt nicht nur im Erstellen von Schaltkreisen, sondern in deren systematischer Optimierung. Diese Compiler-Orientierung unterscheidet TKET von Werkzeugen, die primär als Schaltkreis-Editor, Algorithmusbibliothek oder Hardwarezugang dienen.

TKET behandelt einen Quantenschaltkreis als technische Struktur, die analysiert, transformiert und verbessert werden kann. Dabei stehen Fragen im Mittelpunkt, die für reale Quantenhardware entscheidend sind: Wie tief ist der Schaltkreis? Wie viele Zweiqubit-Gates enthält er? Welche Gates sind nativ verfügbar? Wie viel Routing ist notwendig? Welche Qubit-Zuordnung ist günstig?

Ein Compiler-orientierter Blick betrachtet den Schaltkreis nicht nur als mathematische Operation \(U\), sondern auch als kostenbehaftete Realisierung dieser Operation:

\(U \rightarrow C \rightarrow C'\)

Dabei steht \(U\) für die gewünschte logische Operation, \(C\) für eine konkrete Schaltkreisdarstellung und \(C'\) für eine optimierte oder hardwareangepasste Variante.

Die Optimierungsaufgabe kann allgemein so formuliert werden:

\(C' = \arg\min_{C_i \sim C} \mathrm{Cost}(C_i)\)

Dabei bedeutet \(C_i \sim C\), dass der Kandidatenschaltkreis \(C_i\) logisch äquivalent zum ursprünglichen Schaltkreis \(C\) ist. Die Kostenfunktion \(\mathrm{Cost}(C_i)\) kann Tiefe, Gate-Anzahl, Routing-Aufwand oder erwartete Fehlerbelastung berücksichtigen.

Diese systematische Optimierung ist in der Quantentechnologie besonders wichtig, weil kleine strukturelle Unterschiede große Auswirkungen auf die Ausführbarkeit haben können. Ein zusätzliches Zweiqubit-Gate, eine ungünstige Qubit-Zuordnung oder ein unnötiger SWAP kann bei NISQ-Geräten die Messergebnisse deutlich verschlechtern.

TKETs Stärke liegt deshalb in der Kombination aus formaler Schaltkreisrepräsentation und praktischen Compiler-Passes. Der Schaltkreis wird nicht nur erzeugt, sondern in mehreren Schritten verbessert. Genau diese Ausrichtung macht TKET zu einem Werkzeug für ernsthafte Quantum-Software-Entwicklung.

Gute Integration in bestehende Workflows

Durch pytket und Erweiterungsmodule kann TKET mit verbreiteten Frameworks und Backends zusammenarbeiten. Diese Integrationsfähigkeit ist ein praktischer Vorteil, weil Quantum-Software-Workflows häufig aus mehreren spezialisierten Werkzeugen bestehen.

Ein Schaltkreis kann in einem externen Framework erstellt, in TKET optimiert und anschließend für ein bestimmtes Backend vorbereitet werden. Umgekehrt können TKET-Schaltkreise in andere Formate oder Frameworks überführt werden, wenn ein Workflow dies verlangt.

Ein solcher Ablauf kann vereinfacht so beschrieben werden:

\(C_{\mathrm{source}} \rightarrow C_{\mathrm{tket}} \rightarrow C_{\mathrm{optimised}} \rightarrow C_{\mathrm{backend}}\)

Dabei steht \(C_{\mathrm{source}}\) für einen Schaltkreis aus einem Ausgangssystem, \(C_{\mathrm{tket}}\) für die TKET-interne Darstellung, \(C_{\mathrm{optimised}}\) für die optimierte Fassung und \(C_{\mathrm{backend}}\) für die backendgerechte Version.

Diese Struktur macht TKET anschlussfähig. Es muss nicht zwingend den gesamten Entwicklungsprozess dominieren, sondern kann gezielt dort eingesetzt werden, wo Compiler-Optimierung und Hardware-Anpassung benötigt werden. Das ist besonders nützlich, wenn Teams bereits mit bestimmten Frameworks arbeiten, aber zusätzliche Optimierung oder Portabilität benötigen.

Die gute Integration zeigt sich in mehreren praktischen Vorteilen:

• bestehende Schaltkreise können weiterverwendet werden,
• Optimierung kann in vorhandene Workflows eingebaut werden,
• verschiedene Backends können vergleichbarer angesprochen werden,
• Framework-Wechsel werden technisch leichter,
• Forschungsergebnisse lassen sich besser reproduzieren und übertragen.

Gerade in einem dynamischen Feld wie der Quantentechnologie ist diese Flexibilität wichtig. Frameworks, Hardwareangebote und Cloud-Zugänge verändern sich schnell. Ein Werkzeug, das sich in unterschiedliche Umgebungen einfügen lässt, bleibt länger nützlich als ein geschlossenes Einzelsystem.

TKET kann dadurch als verbindendes Element in einem Quantum-Software-Stack dienen. Es unterstützt nicht nur die Erstellung einzelner Schaltkreise, sondern die technische Bewegung von Schaltkreisen zwischen Entwicklungsumgebung, Compiler-Schicht und Ausführungsplattform.

Relevanz für NISQ-Geräte

Gerade weil heutige Quantenhardware fehleranfällig ist, sind Compileroptimierungen nicht nebensächlich, sondern zentral für praktische Experimente. NISQ-Geräte besitzen begrenzte Qubit-Zahlen, Rauschen, kurze Kohärenzzeiten, fehlerbehaftete Gates und eingeschränkte Konnektivität. Diese Bedingungen machen jede unnötige Operation problematisch.

TKET ist für diese Realität besonders relevant, weil es Schaltkreise so umformen kann, dass sie besser zu den technischen Grenzen heutiger Geräte passen. Die Optimierung betrifft nicht nur die ästhetische Struktur eines Schaltkreises, sondern direkt seine praktische Erfolgschance.

Die Fehleranfälligkeit eines Schaltkreises kann vereinfacht über die Erfolgswahrscheinlichkeiten einzelner Operationen beschrieben werden:

\(P_{\mathrm{success}} \approx \prod_{i=1}^{n} p_i\)

Dabei steht \(p_i\) für die Erfolgswahrscheinlichkeit der jeweiligen Operation. Wenn zusätzliche Gates eingefügt werden, wächst \(n\), und die Gesamterfolgswahrscheinlichkeit kann sinken.

Besonders kritisch sind Zweiqubit-Gates und Routing-Operationen. Sie sind häufig fehleranfälliger als einqubitige Gates und werden durch eingeschränkte Hardware-Konnektivität zusätzlich belastet. Eine Compiler-Strategie, die Routing reduziert und Gate-Folgen vereinfacht, kann deshalb die Qualität der Ausführung deutlich beeinflussen.

Ein NISQ-orientiertes Optimierungsziel kann so formuliert werden:

\(\mathrm{Cost}_{\mathrm{NISQ}}(C) = a \cdot d(C) + b \cdot g_2(C) + c \cdot r(C) + e \cdot \epsilon(C)\)

Dabei steht \(d(C)\) für die Schaltkreistiefe, \(g_2(C)\) für die Anzahl der Zweiqubit-Gates, \(r(C)\) für den Routing-Aufwand und \(\epsilon(C)\) für den geschätzten Fehlerbeitrag. Die Faktoren \(a\), \(b\), \(c\) und \(e\) gewichten die jeweiligen Anteile.

TKETs Relevanz für NISQ-Geräte liegt darin, diese Kosten nicht zu ignorieren. Der Compiler kann Schaltkreise vereinfachen, an native Gates anpassen, günstiger mappen und effizienter routen. Dadurch wird aus einem abstrakten Quantenprogramm eine realistischere Ausführungsform.

Diese Stärke darf nicht missverstanden werden: TKET beseitigt nicht die physikalischen Grenzen heutiger Quantenhardware. Es macht aus fehleranfälligen Geräten keine fehlerfreien Maschinen. Aber es hilft, die vorhandene Hardware besser zu nutzen. Genau darin liegt der praktische Wert eines guten Quantum-Compilers in der NISQ-Ära.

Grenzen und Herausforderungen

Keine Lösung für Hardwarefehler an sich

TKET kann Schaltkreise optimieren, aber es beseitigt nicht die physikalischen Grenzen heutiger Quantenhardware. Diese Unterscheidung ist zentral. Ein Quantum-Compiler kann die Struktur eines Schaltkreises verbessern, unnötige Gates entfernen, Routing reduzieren und eine günstigere Anpassung an die Zielhardware erzeugen. Er kann jedoch keine fehlerfreien Qubits herstellen und keine vollständige Fehlerkorrektur ersetzen.

Die Grundprobleme heutiger NISQ-Geräte bleiben bestehen: Rauschen, Dekohärenz, Messfehler, begrenzte Kohärenzzeiten und fehlerbehaftete Gate-Operationen. Ein optimierter Schaltkreis kann diese Einflüsse verringern, aber nicht vollständig ausschalten.

Vereinfacht kann die reale Ausführung eines idealen Quantenschaltkreises als fehlerbehaftete Annäherung beschrieben werden:

\(U_{\mathrm{real}} = U_{\mathrm{ideal}} + E\)

Dabei steht \(U_{\mathrm{ideal}}\) für die ideale logische Operation, \(U_{\mathrm{real}}\) für die tatsächliche Ausführung und \(E\) für den Fehleranteil. TKET kann dazu beitragen, den durch den Schaltkreis verursachten Anteil von \(E\) zu reduzieren, aber der physikalische Fehlerbeitrag der Hardware bleibt bestehen.

Auch eine bessere Schaltkreisstruktur garantiert daher kein korrektes Ergebnis. Sie erhöht lediglich die Chance, dass die reale Ausführung näher am gewünschten Verhalten liegt. Besonders bei tiefen Schaltkreisen, vielen Zweiqubit-Gates oder ungünstigen Routing-Strukturen kann die Optimierung entscheidend sein. Sie ist aber kein Ersatz für bessere Hardware, stabilere Qubits oder skalierbare Quantenfehlerkorrektur.

Diese Grenze muss klar benannt werden, damit TKET nicht überschätzt wird. Der Compiler ist ein leistungsfähiges Werkzeug zur Verbesserung der Ausführungsbedingungen. Er ist jedoch keine physikalische Lösung für die grundlegenden Schwächen heutiger Quantenprozessoren.

Abhängigkeit von Backend-Informationen

Gute Kompilierung braucht präzise Informationen über Zielhardware, Gate-Sets, Konnektivität und Fehlerprofile. Ohne diese Informationen kann ein Compiler zwar allgemeine Optimierungen durchführen, aber keine wirklich zielgerichtete hardwareabhängige Optimierung leisten.

Ein Backend liefert die technischen Rahmenbedingungen, unter denen ein Schaltkreis ausgeführt werden soll. Dazu gehören die verfügbaren physischen Qubits, die erlaubten Kopplungen zwischen ihnen, das native Gate-Set, Messmöglichkeiten, Kalibrierungsdaten und idealerweise auch aktuelle Fehlerraten.

Die Hardware-Konnektivität kann als Kopplungsgraph beschrieben werden:

\(G_{\mathrm{hardware}} = (V, E)\)

Dabei steht \(V\) für die Menge der physischen Qubits und \(E\) für die erlaubten direkten Verbindungen. Wenn dieser Graph unvollständig, veraltet oder ungenau ist, kann das Mapping und Routing des Compilers suboptimal werden.

Auch das native Gate-Set ist entscheidend. Ein abstrakter Schaltkreis muss in Operationen überführt werden, die das Zielsystem tatsächlich unterstützt:

\(\{G_{\mathrm{abstract}}\} \rightarrow \{G_{\mathrm{native}}\}\)

Je genauer der Compiler die nativen Operationen kennt, desto besser kann er Gate-Zerlegung und Optimierung durchführen. Fehlende oder unpräzise Angaben können zu unnötig langen Gate-Sequenzen führen.

Noch anspruchsvoller ist die Nutzung von Fehlerprofilen. Wenn bestimmte Qubits oder Kopplungen deutlich fehleranfälliger sind als andere, kann der Compiler davon profitieren, diese Unterschiede zu berücksichtigen. Eine einfache fehlerbezogene Kostenfunktion kann so aussehen:

\(\mathrm{Cost}_{\mathrm{error}}(C) = \sum_{i=1}^{n} \epsilon_i\)

Dabei steht \(\epsilon_i\) für den geschätzten Fehlerbeitrag einer Operation. Die Qualität dieser Optimierung hängt direkt davon ab, ob die Fehlerdaten aktuell und aussagekräftig sind.

Hier liegt eine praktische Herausforderung: Quantenhardware ist dynamisch. Kalibrierungswerte, Fehlerraten und verfügbare Backend-Eigenschaften können sich ändern. Ein Compiler kann nur mit den Informationen arbeiten, die ihm bereitgestellt werden. Sind diese Informationen unvollständig oder veraltet, sinkt die Qualität der hardwarebewussten Kompilierung.

Komplexität für Einsteiger

Wer TKET effektiv nutzen will, muss nicht nur Python kennen, sondern auch Grundbegriffe der Quantum Compilation verstehen. Das macht TKET leistungsfähig, aber für Einsteiger anspruchsvoller als einfache Schaltkreis-Interfaces.

Die Arbeit mit TKET verlangt Verständnis für mehrere Ebenen gleichzeitig: den abstrakten Quantenschaltkreis, die interne Circuit-Struktur, Compiler-Passes, Gate-Sets, Qubit-Mapping, Routing, Backends und Messauswertung. Diese Konzepte sind eng miteinander verbunden. Wer sie isoliert betrachtet, kann die Wirkung einer Kompilierung leicht falsch einschätzen.

Ein typischer Kompilierungsprozess kann als mehrstufige Transformation beschrieben werden:

\(C_{\mathrm{logical}} \rightarrow C_{\mathrm{optimised}} \rightarrow C_{\mathrm{mapped}} \rightarrow C_{\mathrm{routed}} \rightarrow C_{\mathrm{native}}\)

Dabei steht \(C_{\mathrm{logical}}\) für den logischen Ausgangsschaltkreis, \(C_{\mathrm{optimised}}\) für eine optimierte Fassung, \(C_{\mathrm{mapped}}\) für die Version nach Qubit-Mapping, \(C_{\mathrm{routed}}\) für die Version nach Routing und \(C_{\mathrm{native}}\) für den Schaltkreis im nativen Gate-Set des Zielsystems.

Für Einsteiger ist besonders schwierig, dass ein Compiler den Schaltkreis sichtbar verändern kann, ohne die beabsichtigte logische Funktion zu verändern. Ein kompilierter Schaltkreis kann deutlich anders aussehen als der ursprüngliche Entwurf. Das ist kein Fehler, sondern das Ergebnis von Optimierung und Hardware-Anpassung.

Gleichzeitig können Optimierungsentscheidungen Zielkonflikte erzeugen. Eine geringere Gate-Anzahl bedeutet nicht immer automatisch geringere Tiefe. Ein besseres Mapping kann Routing reduzieren, aber andere Strukturkosten erhöhen. Eine hardwaregerechte Gate-Zerlegung kann den Schaltkreis technisch ausführbar machen, aber zusätzliche Operationen erzeugen.

Diese Zielkonflikte lassen sich durch eine allgemeine Kostenfunktion ausdrücken:

\(\mathrm{Cost}(C) = a \cdot d(C) + b \cdot g(C) + c \cdot r(C) + e \cdot \epsilon(C)\)

Dabei steht \(d(C)\) für die Schaltkreistiefe, \(g(C)\) für die Gate-Anzahl, \(r(C)\) für Routing-Kosten und \(\epsilon(C)\) für einen geschätzten Fehlerbeitrag. Die Gewichtungen \(a\), \(b\), \(c\) und \(e\) können je nach Zielsystem und Anwendung unterschiedlich relevant sein.

TKET ist daher kein Werkzeug, das man nur über oberflächliche Syntax verstehen sollte. Die eigentliche Stärke liegt in der kontrollierten Nutzung der Compiler-Funktionen. Wer diese Kontrolle ausüben möchte, muss die dahinterliegenden Konzepte kennen.

Schneller Wandel des Ökosystems

Quantum-Software-Stacks entwickeln sich schnell. Versionen, Erweiterungsmodule und Ausführungswege können sich ändern. Ein Beispiel ist pytket-quantinuum, das ab Version 0.56.0 auf Kompilierung und lokale Emulation beschränkt ist; für die Einreichung von Jobs auf Quantinuum-Geräten wird qnexus verwendet.

Diese Dynamik ist typisch für die Quantentechnologie. Hardwareplattformen entwickeln sich weiter, Cloud-Zugänge werden angepasst, APIs ändern sich, und Softwarepakete werden neu strukturiert. Für Nutzerinnen und Nutzer bedeutet das: Ein Workflow, der in einer Version funktioniert, kann in einer späteren Version andere Pakete, andere Befehle oder andere Zugangswege benötigen.

Der Wandel betrifft mehrere Ebenen:

• Python-Versionen und Paketabhängigkeiten,
• pytket-Versionen,
• Erweiterungsmodule,
• Backend-Schnittstellen,
• Cloud-Zugänge und Authentifizierung,
• Geräteverfügbarkeit,
• Emulatoren und Simulatoren,
• Einreichung von Jobs auf realer Hardware.

Für wissenschaftliche Arbeiten und reproduzierbare Experimente ist das eine Herausforderung. Es reicht nicht, nur den Algorithmus zu dokumentieren. Auch die Softwareumgebung muss präzise festgehalten werden. Dazu gehören Paketversionen, Backend-Konfigurationen, verwendete Compiler-Passes und Zielsysteme.

Ein reproduzierbarer Workflow sollte daher mindestens folgende Ebenen erfassen:

\(W = (C, P, B, V)\)

Dabei steht \(C\) für den Ausgangsschaltkreis, \(P\) für die verwendete Compiler-Pipeline, \(B\) für das Backend und \(V\) für die relevanten Softwareversionen.

Der schnelle Wandel ist kein spezielles Problem von TKET allein, sondern ein Merkmal des gesamten Quantum-Software-Ökosystems. Dennoch betrifft er TKET unmittelbar, weil TKET stark mit Backends, Erweiterungsmodulen und externen Frameworks verbunden ist.

Für die Praxis bedeutet das: TKET sollte nicht als statisches Werkzeug betrachtet werden. Es ist Teil einer aktiven, sich weiterentwickelnden Infrastruktur. Wer damit arbeitet, muss Dokumentation, Versionshinweise und Backend-Änderungen beachten. Nur so bleiben Workflows stabil, nachvollziehbar und wissenschaftlich belastbar.

Schlussbetrachtung

Zusammenfassung der Hauptaussage

TKET ist eine zentrale Compiler-Technologie für die praktische Nutzung Gate-basierter Quantencomputer. Seine Stärke liegt in der Optimierung, Portabilität und hardwarebewussten Transformation von Quantenschaltkreisen.

Die Hauptaussage dieser Abhandlung lautet: TKET ist nicht nur ein Werkzeug zum Erstellen oder Ausführen von Quantenschaltkreisen, sondern eine technische Zwischenschicht, die abstrakte Quantenprogramme näher an reale Hardware bringt. Genau diese Zwischenschicht ist in der heutigen Quantentechnologie entscheidend, weil Quantenhardware noch stark begrenzt ist.

Ein Quantenschaltkreis kann auf logischer Ebene korrekt sein und dennoch auf realer Hardware schlecht funktionieren. Der Grund liegt in den Eigenschaften heutiger NISQ-Geräte: begrenzte Qubit-Zahl, Rauschen, kurze Kohärenzzeiten, fehlerbehaftete Gates und eingeschränkte Konnektivität. TKET adressiert diese Probleme nicht auf physikalischer Ebene, aber auf der Ebene der Schaltkreisstruktur.

Der grundlegende Ablauf lässt sich zusammenfassend so darstellen:

\(C_{\mathrm{logical}} \rightarrow C_{\mathrm{optimised}} \rightarrow C_{\mathrm{hardware}}\)

Dabei steht \(C_{\mathrm{logical}}\) für den abstrakten logischen Schaltkreis, \(C_{\mathrm{optimised}}\) für die durch Compiler-Passes verbesserte Version und \(C_{\mathrm{hardware}}\) für die an ein konkretes Zielsystem angepasste Form.

Die Stärke von TKET liegt in mehreren miteinander verbundenen Funktionen: Schaltkreisoptimierung, Gate-Vereinfachung, Zerlegung in native Operationen, Qubit-Mapping, Routing, Backend-Anpassung und Interoperabilität mit anderen Frameworks. Diese Funktionen greifen ineinander und bestimmen gemeinsam, wie gut ein Quantenprogramm praktisch ausführbar wird.

Damit zeigt sich: Die Qualität eines Quantenprogramms hängt nicht nur vom Algorithmus ab. Sie hängt auch davon ab, wie dieser Algorithmus kompiliert wird. TKET macht genau diesen Übergang kontrollierbar.

Bedeutung für die weitere Entwicklung der Quantentechnologie

Je stärker Quantenhardware skaliert und je vielfältiger die Gerätearchitekturen werden, desto wichtiger werden Compiler wie TKET. Sie entscheiden mit darüber, ob ein theoretischer Quantenschaltkreis auf realer Hardware effizient ausführbar ist.

Die weitere Entwicklung der Quantentechnologie wird nicht allein durch bessere Qubits bestimmt. Ebenso wichtig sind Software-Schichten, die diese Hardware nutzbar machen. Quantum-Compiler bilden dabei eine Schlüsselkomponente. Sie übersetzen nicht nur, sondern optimieren, strukturieren und vermitteln zwischen Algorithmus und Prozessor.

Mit wachsender Hardwarevielfalt steigt die Bedeutung von Retargetability. Unterschiedliche Plattformen verwenden unterschiedliche native Gate-Sets, Kopplungsgraphen und Fehlerprofile. Ein Schaltkreis muss deshalb flexibel an verschiedene Zielsysteme angepasst werden können:

\(C_{\mathrm{algorithm}} \rightarrow \{C_{\mathrm{target\ 1}}, C_{\mathrm{target\ 2}}, ..., C_{\mathrm{target\ n}}\}\)

Diese Fähigkeit ist für Forschung, Benchmarking und industrielle Entwicklung zentral. Sie erlaubt es, denselben algorithmischen Kern auf mehreren Plattformen zu untersuchen, ohne jedes Mal bei null beginnen zu müssen.

Auch mit wachsender Qubit-Zahl wird Kompilierung nicht unwichtiger. Im Gegenteil: Größere Systeme erzeugen komplexere Mapping- und Routing-Probleme. Mehr Qubits bedeuten mehr mögliche Wechselwirkungen, aber auch größere Suchräume für optimale Zuordnungen. Die Compiler-Aufgabe wird dadurch anspruchsvoller, nicht einfacher.

Eine allgemeine Optimierungsaufgabe kann weiterhin als Minimierung technischer Kosten beschrieben werden:

\(C' = \arg\min_{C_i \sim C} \mathrm{Cost}(C_i)\)

Dabei steht \(C_i \sim C\) für logische Äquivalenz zum ursprünglichen Schaltkreis. Die Kostenfunktion kann Tiefe, Gate-Anzahl, Routing-Aufwand, Zweiqubit-Gate-Anteil und geschätzte Fehlerbeiträge enthalten.

Für die Zukunft bedeutet das: Quantum-Compiler wie TKET werden nicht nur Hilfswerkzeuge bleiben. Sie werden zu strategischen Komponenten des Quantum-Software-Stacks. Je näher Quantencomputer an praktische Anwendungen rücken, desto stärker entscheidet die Compiler-Qualität über Ausführbarkeit, Vergleichbarkeit und Nutzen von Quantenprogrammen.

Abschließende Bewertung

TKET ist kein Randwerkzeug, sondern eine technische Brücke zwischen Quantenalgorithmus und Quantenprozessor. Für Forschung, Entwicklung und Benchmarking in der Quantentechnologie ist diese Brücke entscheidend.

Die abschließende Bewertung fällt klar aus: TKET besitzt seine Bedeutung nicht, weil es ein weiteres Quantum-Software-Paket ist, sondern weil es eine zentrale Schwachstelle der praktischen Quantenprogrammierung adressiert. Diese Schwachstelle liegt im Übergang von der abstrakten Idee zur realen Ausführung.

Ein Quantenalgorithmus kann elegant, mathematisch korrekt und theoretisch interessant sein. Für reale Nutzung reicht das nicht. Er muss in eine Schaltkreisform gebracht werden, die auf konkreter Hardware mit begrenzten Ressourcen ausführbar ist. Genau hier liegt der Wert von TKET.

TKET unterstützt diesen Übergang durch einen klaren Compiler-Fokus:

• Es optimiert Schaltkreise strukturell.
• Es reduziert unnötige Operationen.
• Es unterstützt hardwareabhängiges Mapping und Routing.
• Es erleichtert die Anpassung an verschiedene Backends.
• Es stärkt Interoperabilität zwischen Quantum-Frameworks.
• Es macht hardwareübergreifende Experimente und Benchmarks praktikabler.

Gleichzeitig bleiben die Grenzen deutlich. TKET kann keine fehlerfreie Quantenhardware erzeugen, keine physikalischen Rauschquellen beseitigen und keine vollständige Quantenfehlerkorrektur ersetzen. Sein Wert liegt darin, die vorhandene Hardware besser nutzbar zu machen.

In einer realistischen Bewertung ist genau das entscheidend. Die Quantentechnologie entwickelt sich nicht durch einzelne Durchbrüche allein, sondern durch das Zusammenspiel von Hardware, Algorithmen, Compilern, Software-Stacks und experimenteller Kontrolle. TKET ist in diesem Zusammenspiel ein wichtiger Baustein.

Die Schlussfolgerung lautet daher: Wer Gate-basierte Quantencomputer praktisch nutzen, vergleichen oder erforschen will, muss Quantum Compilation ernst nehmen. TKET zeigt, wie diese Compiler-Schicht aussehen kann: retargetierbar, optimierungsorientiert, interoperabel und auf die Bedingungen realer Quantenhardware ausgerichtet.

Mit freundlichen Grüßen

---

Anhang

Wissenschaftliche Zeitschriften und Artikel

Die folgenden wissenschaftlichen Quellen bilden die fachliche Grundlage für eine Abhandlung über TKET als retargetierenden Quantum-Compiler. Sie decken Primärliteratur zu TKET, spezialisierte Arbeiten zu Routing und Schaltkreisoptimierung sowie Vergleichsliteratur zu anderen Quantum-Software-Stacks ab.

Grundlegende Primärliteratur zu TKET

• Sivarajah, Seyon; Dilkes, Silas; Cowtan, Alexander; Simmons, Will; Edgington, Alec; Duncan, Ross: t|ket>: A Retargetable Compiler for NISQ Devices, Quantum Science and Technology, 2020.
  • Diese Veröffentlichung ist die zentrale Primärquelle zu TKET. Sie beschreibt TKET als sprachunabhängigen, optimierenden und retargetierbaren Compiler für NISQ-Geräte. Für eine wissenschaftliche Abhandlung ist sie besonders wichtig, weil sie die Kernargumente zu Schaltkreisoptimierung, Qubit-Routing, Geräteunabhängigkeit und Fehlerreduktion direkt aus der TKET-Entwicklung heraus darstellt.
    • URL: https://iopscience.iop.org/...
    • arXiv: https://arxiv.org/...
    • DOI: https://doi.org/...

Spezialisierte Arbeiten zu Qubit-Routing und Architekturabhängigkeit

• Cowtan, Alexander; Dilkes, Silas; Duncan, Ross; Krajenbrink, Alexandre; Simmons, Will; Sivarajah, Seyon: On the Qubit Routing Problem, 14th Conference on the Theory of Quantum Computation, Communication and Cryptography, 2019.
  • Diese Arbeit behandelt das Qubit-Routing-Problem als eine der zentralen technischen Hürden bei der Ausführung abstrakter Quantenschaltkreise auf Hardware mit eingeschränkter Konnektivität. Sie ist für die TKET-Abhandlung besonders relevant, weil sie Routing nicht als Nebenthema, sondern als entscheidenden Bestandteil hardwarebewusster Quantum Compilation analysiert.
    • URL: https://drops.dagstuhl.de/...
    • arXiv: https://arxiv.org/...
    • DOI: https://doi.org/...

• Cowtan, Alexander; Dilkes, Silas; Duncan, Ross; Simmons, Will; Sivarajah, Seyon: Phase Gadget Synthesis for Shallow Circuits, Electronic Proceedings in Theoretical Computer Science, 2020.
  • Diese Quelle ist für die Analyse von TKETs Optimierungslogik wichtig. Sie behandelt Phase Gadgets und zeigt, wie bestimmte Schaltkreisstrukturen in flachere und gate-effizientere Formen überführt werden können. Für die Abhandlung eignet sich die Quelle besonders zur Vertiefung von Schaltkreistiefe, CNOT-Reduktion und struktureller Circuit-Optimierung.
    • URL: https://cgi.cse.unsw.edu.au/...
    • arXiv: https://arxiv.org/...
    • DOI: https://doi.org/...

Vergleichende Literatur zu Quantum-Compilern und Software-Stacks

• Southall, Luke; Ammermann, Joshua; Kelmendi, Rinor; Eichhorn, Domenik; Schaefer, Ina: Investigating Retargetability Claims for Quantum Compilers, arXiv, 2026.
  • Diese aktuelle Arbeit untersucht Retargetability als Qualitätsmerkmal von Quantum-Compilern und vergleicht unter anderem TKET, Qiskit und ProjectQ. Sie eignet sich besonders für den Abschnitt zur wissenschaftlichen Einordnung, weil sie TKET nicht isoliert, sondern im Vergleich zu anderen Compiler-Ansätzen bewertet.
    • arXiv: https://arxiv.org/...

• Steiger, Damian S.; Häner, Thomas; Troyer, Matthias: ProjectQ: An Open Source Software Framework for Quantum Computing, Quantum, 2018.
  • ProjectQ ist ein wichtiger Vergleichspunkt für TKET, weil es ebenfalls einen Compiler-orientierten Quantum-Software-Ansatz verfolgt. Die Quelle kann genutzt werden, um TKETs retargetierende Compiler-Architektur mit einem anderen modularen Quantum-Framework zu vergleichen.
    • URL: https://quantum-journal.org/...
    • arXiv: https://arxiv.org/...
    • DOI: https://doi.org/...

• Javadi-Abhari, Ali et al.: Quantum Computing with Qiskit, arXiv, 2024.
  • Diese Quelle beschreibt Qiskit als umfangreichen Quantum-Software-Stack. Sie ist für eine TKET-Abhandlung nützlich, wenn TKET mit Qiskit als alternativer oder ergänzender Compiler- und Entwicklungsumgebung verglichen werden soll.
    • arXiv: https://arxiv.org/...

• Smith, Robert S.; Curtis, Michael J.; Zeng, William J.: A Practical Quantum Instruction Set Architecture, arXiv, 2016.
  • Diese Arbeit ist für den Vergleich mit Quil und Rigetti-nahen Compiler-Ansätzen relevant. Sie behandelt die praktische Schnittstelle zwischen Quantenprogrammen, Instruktionsformaten und Hardwareausführung und kann genutzt werden, um TKETs Rolle als retargetierende Compiler-Schicht gegenüber instruktionssatzorientierten Ansätzen einzuordnen.
    • arXiv: https://arxiv.org/...

Bücher und Monographien

Die folgenden Bücher und monographie-nahen Werke liefern den theoretischen Rahmen, um TKET fachlich einzuordnen. Sie erklären die Grundlagen von Quanteninformation, Gate-Modellen, Quantenschaltkreisen, Fehlerkorrektur, Algorithmen und praktischer Quantum-Software.

Standardwerke zur Quanteninformation

• Nielsen, Michael A.; Chuang, Isaac L.: Quantum Computation and Quantum Information, Cambridge University Press, 2010.
  • Dieses Werk ist eines der zentralen Standardbücher der Quanteninformation. Für eine TKET-Abhandlung ist es besonders geeignet, um die Grundlagen von Qubits, Quantengattern, Schaltkreismodellen, Messungen, Quantenalgorithmen und Fehlerkorrektur sauber abzusichern.
    • URL: https://www.cambridge.org/...
    • DOI: https://doi.org/...

• Mermin, N. David: Quantum Computer Science: An Introduction, Cambridge University Press, 2007.
  • Mermins Buch ist eine klare Einführung in Quanteninformation aus informatischer Perspektive. Es eignet sich besonders, um die logische Struktur von Quantenschaltkreisen, die Rolle von Gates und die Verbindung zwischen Berechnungsmodell und Algorithmik zu erklären.
    • URL: https://www.cambridge.org/...
    • DOI: https://doi.org/...

• Kaye, Phillip; Laflamme, Raymond; Mosca, Michele: An Introduction to Quantum Computing, Oxford University Press, 2007.
  • Dieses Lehrbuch bietet eine kompakte und mathematisch belastbare Einführung in Quantenberechnung. Für eine Abhandlung über TKET ist es vor allem als Hintergrundliteratur sinnvoll, wenn grundlegende Konzepte wie Qubit-Zustände, Gate-Operationen und algorithmische Schaltkreise knapp eingeordnet werden sollen.
    • URL: https://global.oup.com/...

Vorlesungsnotizen und Monographie-nahe Ressourcen

• Preskill, John: Lecture Notes for Physics 229: Quantum Information and Computation, California Institute of Technology, fortlaufend aktualisierte Vorlesungsnotizen.
  • Preskills Vorlesungsnotizen sind eine hochwertige wissenschaftliche Ressource für Quanteninformation, Quantenalgorithmen und Fehlerkorrektur. Sie eignen sich besonders, um TKETs Bedeutung in der NISQ-Ära vor dem Hintergrund von Rauschen, Fehlern und skalierbarer Quantenberechnung einzuordnen.
    • URL: https://theory.caltech.edu/...

• Hidary, Jack D.: Quantum Computing: An Applied Approach, Springer, 2021.
  • Hidarys Buch verbindet Grundlagen der Quantenberechnung mit praktischen Software- und Anwendungsfragen. Es ist hilfreich, um TKET nicht nur theoretisch, sondern als Bestandteil eines praktischen Quantum-Software-Workflows zu betrachten.
    • URL: https://link.springer.com/...
    • DOI: https://doi.org/...

Hintergrundliteratur zu Quantum Software Engineering

• LaRose, Ryan: Overview and Comparison of Gate Level Quantum Software Platforms, Quantum, 2019.
  • Diese Übersicht ist nützlich, um TKET in das breitere Feld gate-basierter Quantum-Software-Plattformen einzuordnen. Sie kann in einer Abhandlung verwendet werden, um Unterschiede zwischen Frameworks, Programmierschnittstellen, Simulatoren und Hardwarezugängen methodisch zu strukturieren.
    • URL: https://quantum-journal.org/...
    • arXiv: https://arxiv.org/...
    • DOI: https://doi.org/...

Online-Ressourcen und Datenbanken

Die folgenden Online-Ressourcen sind für die praktische Arbeit mit TKET, die Prüfung aktueller Versionen und die wissenschaftliche Recherche besonders relevant. Sie sollten ergänzend zur Primärliteratur genutzt werden, weil sich Quantum-Software-Stacks, Erweiterungsmodule und Backend-Zugänge schnell verändern.

Offizielle TKET- und Quantinuum-Ressourcen

• Quantinuum: TKET Documentation, Quantinuum, laufend aktualisiert.
  • Die offizielle TKET-Dokumentation ist die wichtigste Ressource für aktuelle technische Informationen zu Installation, Circuit Construction, Compilation, Backends und Erweiterungen. Für eine wissenschaftliche Abhandlung sollte sie genutzt werden, um aktuelle Funktionsweisen und Begriffe korrekt zu beschreiben.
    • URL: https://docs.quantinuum.com/...

• Quantinuum: pytket API Documentation, Quantinuum, laufend aktualisiert.
  • Die API-Dokumentation ist besonders wichtig, wenn in der Abhandlung zwischen TKET als Compiler-Technologie und pytket als Python-Schnittstelle unterschieden wird. Sie bietet präzise Informationen zu Klassen, Methoden, Circuit-Modell, Backends und Compiler-Passes.
    • URL: https://docs.quantinuum.com/...

• Quantinuum: pytket User Guide, Quantinuum, laufend aktualisiert.
  • Der User Guide ist eine praxisnahe Quelle für typische Arbeitsabläufe mit pytket. Er eignet sich besonders, um die Schritte von Circuit-Erstellung, Analyse, Kompilierung und Backend-Ausführung anschaulich, aber fachlich korrekt zu erklären.
    • URL: https://docs.quantinuum.com/...

• Quantinuum: Compilation Manual, Quantinuum, laufend aktualisiert.
  • Dieses Manual ist für die Darstellung von Compiler-Passes, Constraints und Optimierungsstrategien besonders relevant. Es kann genutzt werden, um TKETs modulare Compiler-Architektur und die praktische Bedeutung einzelner Transformationsschritte zu erläutern.
    • URL: https://docs.quantinuum.com/...

• Quantinuum: Developer Tools, Quantinuum, laufend aktualisiert.
  • Diese Seite ordnet TKET in die breitere Quantinuum-Werkzeuglandschaft ein. Sie ist geeignet, um TKETs Rolle als Open-Source-Toolkit für Konstruktion, Optimierung und Ausführung von Quantenprogrammen auf verschiedenen Geräten und Simulatoren darzustellen.
    • URL: https://www.quantinuum.com/...

Code-Repositories und Paketquellen

• Quantinuum: TKET GitHub Repository, GitHub, laufend aktualisiert.
  • Das offizielle Repository ist eine zentrale Quelle für den Entwicklungsstand des TKET-Projekts. Es eignet sich zur Prüfung von Lizenz, Quellcode-Struktur, Release-Historie und technischer Weiterentwicklung.
    • URL: https://github.com/...

• Quantinuum: pytket, Python Package Index, laufend aktualisiert.
  • Die PyPI-Seite ist relevant für Installation, Versionsprüfung und Abhängigkeiten von pytket. Sie sollte genutzt werden, wenn die Abhandlung aktuelle technische Angaben zur Python-Schnittstelle oder zur Paketverfügbarkeit enthält.
    • URL: https://pypi.org/...

• Quantinuum: pytket-qiskit, Python Package Index, laufend aktualisiert.
  • Diese Erweiterung ist wichtig für die Interoperabilität zwischen TKET und Qiskit. Sie kann in einer Abhandlung genutzt werden, um konkret zu zeigen, wie TKET als Compiler- und Optimierungsschicht in bestehende Qiskit-nahe Workflows eingebunden werden kann.
    • URL: https://pypi.org/...

• Quantinuum: pytket-quantinuum Documentation, Quantinuum, laufend aktualisiert.
  • Diese Dokumentation ist für die konkrete Einordnung von Quantinuum-Backends wichtig. Sie zeigt zugleich, warum aktuelle Dokumentation in der Quantum-Software notwendig ist: Ab Version 0.56.0 dient pytket-quantinuum nicht mehr zur Job-Einreichung auf Quantinuum-Geräten, sondern verweist dafür auf qnexus.
    • URL: https://docs.quantinuum.com/...

Fachjournale und Verlage

• Quantum Science and Technology, IOP Publishing, laufend aktualisiert.
  • Quantum Science and Technology ist für TKET besonders relevant, weil die zentrale TKET-Primärarbeit dort erschienen ist. Das Journal eignet sich allgemein für Forschung zu Quantenhardware, Quantum Software, NISQ-Geräten und Compiler-nahen Themen.
    • URL: https://iopscience.iop.org/...

• Quantum, Verein zur Förderung des Open Access Publizierens in den Quantenwissenschaften, laufend aktualisiert.
  • Quantum ist eine wichtige Open-Access-Zeitschrift für Quanteninformation und Quantenberechnung. Für eine TKET-Abhandlung ist das Journal besonders nützlich, wenn vergleichende Arbeiten zu Quantum-Software-Frameworks und Compiler-nahen Themen berücksichtigt werden sollen.
    • URL: https://quantum-journal.org/

• Electronic Proceedings in Theoretical Computer Science, Open Publishing Association, laufend aktualisiert.
  • EPTCS ist relevant, weil dort Arbeiten zur formalen und theoretischen Seite von Quantenprogrammen, Schaltkreissynthese und diagrammatischen Methoden erscheinen. Für TKET ist dies besonders im Zusammenhang mit Phase Gadgets und Circuit-Optimierung nützlich.
    • URL: https://cgi.cse.unsw.edu.au/...

Lern- und Forschungsplattformen

• arXiv: Quantum Physics, arXiv, laufend aktualisiert.
  • arXiv ist eine zentrale Rechercheplattform für aktuelle Preprints zu Quantum Computing, Quantum Compilation, NISQ-Geräten und Quantum Software Engineering. Für eine TKET-Abhandlung ist arXiv besonders wichtig, weil viele relevante Arbeiten zuerst dort erscheinen.
    • URL: https://arxiv.org/...

• ACM Digital Library, Association for Computing Machinery, laufend aktualisiert.
  • Die ACM Digital Library ist für compilernahe und softwaretechnische Perspektiven relevant. Sie eignet sich für Recherchen zu Compilerbau, Programmanalyse, Software Engineering und Quantum Software Engineering.
    • URL: https://dl.acm.org/

• IEEE Xplore, Institute of Electrical and Electronics Engineers, laufend aktualisiert.
  • IEEE Xplore ist eine wichtige Datenbank für technische Forschung zu Quantenhardware, Softwarearchitekturen, Cloud-Zugängen und Systemdesign. Für TKET kann sie ergänzend genutzt werden, wenn die Abhandlung stärker auf Hardware-Software-Co-Design oder industrielle Quantum-Computing-Architekturen eingeht.
    • URL: https://ieeexplore.ieee.org/

• Google Scholar, Google, laufend aktualisiert.
  • Google Scholar eignet sich als ergänzende Recherchehilfe, um Zitationen, verwandte Arbeiten und neuere Veröffentlichungen zu TKET, Quantum Compilation, Qubit Routing und Retargetability zu finden. Es sollte jedoch nicht als alleinige Quelle dienen, sondern zur Suche nach primären Veröffentlichungen genutzt werden.
    • URL: https://scholar.google.com/

Empfohlene Nutzung des Anhangs

Für eine wissenschaftliche Abhandlung über TKET sollte zuerst die Primärliteratur zu TKET selbst ausgewertet werden. Besonders die Veröffentlichung zu t|ket> als retargetierbarem Compiler für NISQ-Geräte ist die zentrale Grundlage für Definition, Motivation, Architektur und technische Einordnung.

Die spezialisierten Arbeiten zu Qubit-Routing und Phase-Gadget-Synthese sollten verwendet werden, um die Optimierungsfunktionen von TKET fachlich zu vertiefen. Sie erklären, warum Compiler-Entscheidungen bei NISQ-Hardware nicht nur formale Übersetzungsschritte sind, sondern die praktische Ausführbarkeit eines Quantenschaltkreises wesentlich beeinflussen.

Vergleichende Quellen zu Qiskit, ProjectQ und Quil sollten gezielt für die Einordnung von TKET im Quantum-Software-Ökosystem genutzt werden. Sie helfen, TKET nicht isoliert zu betrachten, sondern seine Stärken bei Retargetability, Interoperabilität und hardwarebewusster Optimierung gegenüber anderen Ansätzen klar herauszuarbeiten.

Die offiziellen Dokumentationen, Repositories und Paketquellen sollten immer zusätzlich geprüft werden, wenn aktuelle technische Aussagen zu pytket, Erweiterungsmodulen, Backends oder Quantinuum-Zugängen gemacht werden. Gerade bei Quantum-Software können sich Versionen, APIs und Ausführungswege schnell ändern; deshalb sollten wissenschaftliche Aussagen zu praktischen Workflows immer mit der aktuellen Dokumentation abgeglichen werden.