Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
IBM Quantum Challenge Spring 2023 Lab5解説
Search
Ayumu-walker
July 16, 2023
Technology
0
220
IBM Quantum Challenge Spring 2023 Lab5解説
社内勉強会で発表した、IBM Quantum Challenge Spring 2023 の最終問題で、量子回路を改良した内容です。
Ayumu-walker
July 16, 2023
Tweet
Share
More Decks by Ayumu-walker
See All by Ayumu-walker
円周率の日スペシャル 量子コンピューターと円周率の話
ayumu0118
0
860
IBM Cloud Festa 2020 GUIから始める量子コンピューター超入門
ayumu0118
1
810
量子コンピューター超入門ハンズオン 補足資料 線形代数
ayumu0118
1
1.5k
量子コンピューター超入門ハンズオン 2020/04/24
ayumu0118
1
1.5k
Other Decks in Technology
See All in Technology
フレームワークを意識させないワークショップづくり
keigosuda
0
210
能登半島地震で見えた災害対応の課題と組織変革の重要性
ditccsugii
0
1k
難しいセキュリティ用語をわかりやすくしてみた
yuta3110
0
320
Introduction to Sansan Meishi Maker Development Engineer
sansan33
PRO
0
310
Biz職でもDifyでできる! 「触らないAIワークフロー」を実現する方法
igarashikana
2
620
RDS の負荷が高い場合に AWS で取りうる具体策 N 連発/a-series-of-specific-countermeasures-available-on-aws-when-rds-is-under-high-load
emiki
7
4.2k
AWS Top Engineer、浮いてませんか? / As an AWS Top Engineer, Are You Out of Place?
yuj1osm
2
220
LLMアプリの地上戦開発計画と運用実践 / 2025.10.15 GPU UNITE 2025
smiyawaki0820
1
650
20251007: What happens when multi-agent systems become larger? (CyberAgent, Inc)
ornew
1
460
能登半島地震において デジタルができたこと・できなかったこと
ditccsugii
0
250
Introduction to Bill One Development Engineer
sansan33
PRO
0
300
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
12
81k
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Become a Pro
speakerdeck
PRO
29
5.6k
Site-Speed That Sticks
csswizardry
13
910
Into the Great Unknown - MozCon
thekraken
40
2.1k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
980
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Unsuck your backbone
ammeep
671
58k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.7k
The Pragmatic Product Professional
lauravandoore
36
6.9k
Context Engineering - Making Every Token Count
addyosmani
7
270
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Transcript
Quantum Tokyo Qt IBM Quantum Challenge Spring 2023 Lab5解説 Ayumu
Shiraishi (ISE, Data Science Lab) Qiskit Advocate
Quantum Tokyo アジェンダ ⚫ Lab5の概要 ⚫ Exercise1 ⚫ Exercise2 ⚫
Exercise3 ⚫ Depthを改良する ⚫ 最後に
Quantum Tokyo Lab5概要
Quantum Tokyo 余談)Sherbrooke
Quantum Tokyo GHZ状態とは
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: 一般の𝑛: ←1量子ビットの単なる重ね合わせ ←EPR状態 ←(歴史的に最初に定義された)GHZ状態 ←一般化されたGHZ状態
Quantum Tokyo ibm_sherbrooke
Quantum Tokyo Exercise1
Quantum Tokyo Exercise1 このexerciseのGraderを通すだけなら、量子H/Wデバイスのレイアウトを無視して、 GHZ状態をシンプルに生成することでも可能 Depth = 127
Quantum Tokyo Exercise2
Quantum Tokyo Exercise2 GHZビット(”odd”) スタビライザー ビット(“even”)
Quantum Tokyo Exercise2 このexerciseもGraderを通すだけなら、レイアウトを無視して、GHZ量子ビットのい ずれかから、スタビライザー量子ビットにCNOTを通すだけで良い 最も単純には量子ビット0をコントロールとする Depth = 73
Quantum Tokyo 実機で動かすための準備(Step2続き)
Quantum Tokyo 実機で動かす(Step3)
Quantum Tokyo 実機で動かす(Step3)
Quantum Tokyo Exercise3
Quantum Tokyo Exercise3 1回ごとの出力結果をget_memory関数で取得することが前提となる
Quantum Tokyo Exercise3 |0>か|1>の状態が多い方を観測時に決定した状態とみなすと、少ない方の数をエラー 数としてカウントする 配列の右側から小さいビット 番号になることに注意し、 GHZビットの’1’の数を数える 最後に平均を取る ‘0’と’1’の少ない方を
エラーとみなして選定
Quantum Tokyo Exercise3 研究者の皆さん、 教えてください!
Quantum Tokyo ボーナス:エラー訂正への道 ごめんなさい、ここから先はできていません。。。
Quantum Tokyo 回路全体の更なる改良 実機で動かす上ではエラーを減らして計算精度を高い状態にするためには、Depthを 減らすことが重要になってくるので、その観点で改良を試みる • GHZ状態をどう効率的作るか(Exercise1の改良) → hard •
Stabilizer状態の生成をどう効率的に作るか(Exercise2の改良)→ easy(先にこち らから)
Quantum Tokyo Exercise2の改良 物理的に隣合う量子ビットで交互にGHZ状態とスタビライザー状態が折りたたまれて いるので、GHZ状態を残す量子ビットを制御に、隣合うスタビライザー用の量子ビッ トをターゲットにすることで少ないdepthで構成が可能 例えば0->1、18->19、・・・・
Quantum Tokyo Exercise2の改良
Quantum Tokyo Exercise1の改良 まだレイアウトを無視した上で、もう少し効率的な方法は樹形図的にGHZ状態を波及 させていく方法がある
Quantum Tokyo Exercise1のさらなる改良 着想: • 端から始めるのではなく、真ん中から始めてGHZ状態を波及させていてくのが速 いのでは???
Quantum Tokyo Transpiled Depthは何故増えるのか① • 直接接続が無い量子ビット同士に対して、多量子ビットゲート(例:CNOT)を使 う場合には、接続できている量子ビット間を経由して、より多くのDepthを使うこ とで同一の処理となるゲートを再構成しなければならない Transpile Sherbrookeの量
子ビット0から2 をCNOTする
Quantum Tokyo Depth=1(63にHadamardをかける) H
Quantum Tokyo Depth=2 (63を制御に64にCNOT) +
Quantum Tokyo Depth=3 (63->64、62->72それぞれ同時に CNOT) + +
Quantum Tokyo Depth=4 (63->64、62->72それぞれ同時に CNOT) + + +
Quantum Tokyo Depth=5 ~ + + + +
Quantum Tokyo クリティカルパスに如何に早く届けるかを意識 する
Quantum Tokyo 白石が書いた最小Depthコード (Depth=18) 実は124に向か うルートが最後 の改良ポイント になる
Quantum Tokyo 描画してみたんですが・・・
Quantum Tokyo 最終的なTranspiled Depth しかし、人によっては似たような回路を作っているけども、depthがこれよりも長く なってしまっているケースがある → 疑問
Quantum Tokyo Transpiled Depthは何故増えるのか② • 直接接続がある量子ビット間でも、直接CNOT可能な“向き”が存在し、コントロー ルとターゲットをどちらにするかで追加のゲートを必要とする場合がある • 以下はibm_sherbrookeの量子ビット0番と1番の場合
Quantum Tokyo Transpiled Depthは何故増えるのか②
Quantum Tokyo Depth=52の人もいる? おそらく、この“向き”も考慮しているのではないか?
Quantum Tokyo 参考情報 https://soon-teh.github.io/blog/2023/quantum-challenge-spring-ghz/
Quantum Tokyo 最後に 近い内にQiitaにでもコチラの解説記事を書きます。