Skip to content

Conversation

@yasuhito
Copy link
Contributor

@yasuhito yasuhito commented Mar 11, 2025

実装方針まとめ(レビュー用・詳細)

ゴール

「Qiskit と同等に tket をバックエンドとして使える」レベルを Tranqu で実現する。

  • device を渡せば制約を満たす回路に変換される
  • optimization_level で最適化の強さが変わる
  • 変換後の回路・統計・mapping(virtual→physical)が返る

例(Tranqu 側の利用イメージ)

Qiskit から tket backend を使う

result = tranqu.transpile(
    program=circuit,
    program_lib="qiskit",
    transpiler_lib="tket",
    device=FakeSantiagoV2(),
    device_lib="qiskit",
    transpiler_options={"optimization_level": 1},
)

OpenQASM3 から tket を使う

result = tranqu.transpile(
    program=qasm,
    program_lib="openqasm3",
    transpiler_lib="tket",
    transpiler_options={"optimization_level": 1},
)


背景(main の現状)

  • Tranqu は Qiskit / ouqu-tp の transpiler を持つが、tket は未登録
  • ProgramConverter は qiskit <-> tket を既に持つ(pytket-qiskit)
  • DeviceConverter は qiskit -> tket が未実装
  • Tranqu の統計/マッピングは Qiskit 側と同じ形で返す仕様

本PRのスコープ(追加/変更)

  • tket transpiler を追加(device あり/なし分岐)
  • stats / mapping 取得のための helper を追加
  • qiskit -> tket device conversion を追加
  • mapping の index 解決(tket の list index 互換)を追加
  • tket の最小限の互換性テストを追加

設計原則(Qiskit と差異を最小化)

  1. Tranqu の使い方は共通(program_lib/transpiler_lib/device_lib の使い方は同じ)
  2. device がある場合は backend の既定パスに委譲(Qiskit の preset に相当)
  3. mapping を返すために CompilationUnit を使う
  4. 最初は pass-through 優先(Qiskit と同様、options は基本そのまま渡す)

tket 側の動作仕様

1) device がある場合(推奨ルート)

採用: CompilationUnit + backend.default_compilation_pass()

  • 目的: mapping を返すため
  • get_compiled_circuit() は回路のみで mapping を取れないため採用しない

処理イメージ

cu = CompilationUnit(circ)
backend.default_compilation_pass(optimisation_level=1).apply(cu)
compiled = cu.circuit
final_map = cu.final_map

2) device がない場合

  • optimization_level=0: no-op(回路そのまま)
  • optimization_level=1: DecomposeBoxes + SynthesiseTket(デフォルト)
  • optimization_level=2: DecomposeBoxes + FullPeepholeOptimise
  • 目的: backend 依存の制約が無いので、最小限の変換で安定性を優先

optimization_level の扱い(tket)

  • tket は 0..2 のみ許可
  • 3 は明示的に ValueError(暫定)
  • 理由: tket の公式ドキュメントで標準レベルは 0..2

共通オプションの扱い(v0 pass-through)

  • Qiskit と同様に 基本はそのまま渡す
  • tket 側は 不明キーは無視(当面は最小限の吸収のみ)
  • 将来 strict_compat を導入して差異を明示化

統計 / mapping

  • 統計は Qiskit と同じ指標を返す
    • n_qubits, n_gates, n_gates_1q, n_gates_2q, depth
  • mapping は virtual → physical で統一
  • mapping の出所は CompilationUnit.initial_map / final_map

レビュワーに確認したい設計ポイント

  • device なし時の挙動: optimization_level=0 は no-op、1 は DecomposeBoxes + SynthesiseTket(デフォルト)、2 は DecomposeBoxes + FullPeepholeOptimise。この段階分けで妥当か。
  • optimization_level=3: 現状は ValueError として明示的に拒否(tket 標準が 0..2 のため)。互換性の期待値として問題ないか。
  • device あり時のパス: CompilationUnit + backend.default_compilation_pass() に統一し、get_compiled_circuit() は採用しない方針で問題ないか。
  • coupling_map 不在時の扱い: qiskit backend に coupling_map が無い場合、full connectivity を仮定して Architecture を構築(コメントで意図を明記)。この前提は妥当か。
  • mapping 解決失敗時: qubit が circuit に見つからない場合は例外で fail fast。サイレント fallback ではなく例外で良いか。

公式ドキュメント参照

@yasuhito yasuhito marked this pull request as draft March 11, 2025 01:24
@codecov
Copy link

codecov bot commented Mar 11, 2025

@yasuhito yasuhito force-pushed the feature/add-tket-transpiler branch 3 times, most recently from 483f006 to e84bc23 Compare January 22, 2026 23:46
@yasuhito yasuhito force-pushed the feature/add-tket-transpiler branch from e84bc23 to 9e5e3ee Compare January 23, 2026 00:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant