IBM Quantum Challenge Spring 2023 Lab5解説

社内勉強会で発表した、IBM Quantum Challenge Spring 2023 の最終問題で、量子回路を改良した内容です。

Transcript

1. Quantum Tokyo Qt IBM Quantum Challenge Spring 2023 Lab5解説 Ayumu Shiraishi (ISE, Data Science Lab) Qiskit Advocate
2. Quantum Tokyo アジェンダ ⚫ Lab5の概要 ⚫ Exercise1 ⚫ Exercise2 ⚫ Exercise3 ⚫ Depthを改良する ⚫ 最後に
3. Quantum Tokyo Lab5概要
4. Quantum Tokyo 余談）Sherbrooke
5. Quantum Tokyo GHZ状態とは
6. Quantum Tokyo GHZ状態とは 全ての量子ビットが|0>もしくは|1>がちょうど1/2の確率で観測される状態 | ۧ 0 + | ۧ 1 2 | ۧ 00 + | ۧ 11 2 | ۧ 000 + | ۧ 111 2 | ۧ 00 ⋯ 0 + | ۧ 11 ⋯ 1 2 = | ۧ 0 ⊗𝑛 + | ۧ 1 ⊗𝑛 2 𝑛 = 1： 𝑛 = 2： 𝑛 = 3： 一般の𝑛： ←１量子ビットの単なる重ね合わせ ←EPR状態 ←（歴史的に最初に定義された）GHZ状態 ←一般化されたGHZ状態
7. Quantum Tokyo ibm_sherbrooke
8. Quantum Tokyo Exercise1
9. Quantum Tokyo Exercise1 このexerciseのGraderを通すだけなら、量子H/Wデバイスのレイアウトを無視して、 GHZ状態をシンプルに生成することでも可能 Depth = 127
10. Quantum Tokyo Exercise2
11. Quantum Tokyo Exercise2 GHZビット（”odd”） スタビライザー ビット(“even”)
12. Quantum Tokyo Exercise2 このexerciseもGraderを通すだけなら、レイアウトを無視して、GHZ量子ビットのい ずれかから、スタビライザー量子ビットにCNOTを通すだけで良い 最も単純には量子ビット0をコントロールとする Depth = 73
13. Quantum Tokyo 実機で動かすための準備（Step2続き）
14. Quantum Tokyo 実機で動かす（Step3）
15. Quantum Tokyo 実機で動かす（Step3）
16. Quantum Tokyo Exercise3
17. Quantum Tokyo Exercise3 1回ごとの出力結果をget_memory関数で取得することが前提となる
18. Quantum Tokyo Exercise3 |0>か|1>の状態が多い方を観測時に決定した状態とみなすと、少ない方の数をエラー 数としてカウントする 配列の右側から小さいビット 番号になることに注意し、 GHZビットの’1’の数を数える 最後に平均を取る ‘0’と’1’の少ない方を エラーとみなして選定
19. Quantum Tokyo Exercise3 研究者の皆さん、 教えてください！
20. Quantum Tokyo ボーナス：エラー訂正への道 ごめんなさい、ここから先はできていません。。。
21. Quantum Tokyo 回路全体の更なる改良 実機で動かす上ではエラーを減らして計算精度を高い状態にするためには、Depthを 減らすことが重要になってくるので、その観点で改良を試みる • GHZ状態をどう効率的作るか（Exercise1の改良） → hard • Stabilizer状態の生成をどう効率的に作るか（Exercise2の改良）→ easy（先にこち らから）
22. Quantum Tokyo Exercise2の改良 物理的に隣合う量子ビットで交互にGHZ状態とスタビライザー状態が折りたたまれて いるので、GHZ状態を残す量子ビットを制御に、隣合うスタビライザー用の量子ビッ トをターゲットにすることで少ないdepthで構成が可能 例えば0->1、18->19、・・・・
23. Quantum Tokyo Exercise2の改良
24. Quantum Tokyo Exercise1の改良 まだレイアウトを無視した上で、もう少し効率的な方法は樹形図的にGHZ状態を波及 させていく方法がある
25. Quantum Tokyo Exercise1のさらなる改良 着想： • 端から始めるのではなく、真ん中から始めてGHZ状態を波及させていてくのが速 いのでは？？？
26. Quantum Tokyo Transpiled Depthは何故増えるのか① • 直接接続が無い量子ビット同士に対して、多量子ビットゲート（例：CNOT）を使 う場合には、接続できている量子ビット間を経由して、より多くのDepthを使うこ とで同一の処理となるゲートを再構成しなければならない Transpile Sherbrookeの量 子ビット0から2 をCNOTする
27. Quantum Tokyo Depth=1（63にHadamardをかける） H
28. Quantum Tokyo Depth=2 (63を制御に64にCNOT） +
29. Quantum Tokyo Depth=3 (63->64、62->72それぞれ同時に CNOT) + +
30. Quantum Tokyo Depth=4 (63->64、62->72それぞれ同時に CNOT) + + +
31. Quantum Tokyo Depth=5 ～ + + + +
32. Quantum Tokyo クリティカルパスに如何に早く届けるかを意識 する
33. Quantum Tokyo 白石が書いた最小Depthコード （Depth=18） 実は124に向か うルートが最後 の改良ポイント になる
34. Quantum Tokyo 描画してみたんですが・・・
35. Quantum Tokyo 最終的なTranspiled Depth しかし、人によっては似たような回路を作っているけども、depthがこれよりも長く なってしまっているケースがある → 疑問
36. Quantum Tokyo Transpiled Depthは何故増えるのか② • 直接接続がある量子ビット間でも、直接CNOT可能な“向き”が存在し、コントロー ルとターゲットをどちらにするかで追加のゲートを必要とする場合がある • 以下はibm_sherbrookeの量子ビット0番と1番の場合
37. Quantum Tokyo Transpiled Depthは何故増えるのか②
38. Quantum Tokyo Depth=52の人もいる？ おそらく、この“向き”も考慮しているのではないか？
39. Quantum Tokyo 参考情報 https://soon-teh.github.io/blog/2023/quantum-challenge-spring-ghz/
40. Quantum Tokyo 最後に 近い内にQiitaにでもコチラの解説記事を書きます。