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
170
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
750
IBM Cloud Festa 2020 GUIから始める量子コンピューター超入門
ayumu0118
1
770
量子コンピューター超入門ハンズオン 補足資料 線形代数
ayumu0118
1
1.4k
量子コンピューター超入門ハンズオン 2020/04/24
ayumu0118
1
1.3k
Other Decks in Technology
See All in Technology
デスクトップだけじゃないUbuntu
mtyshibata
0
570
エンジニアの育成を支える爆速フィードバック文化
sansantech
PRO
3
1.1k
Building Products in the LLM Era
ymatsuwitter
10
6.2k
Developers Summit 2025 浅野卓也(13-B-7 LegalOn Technologies)
legalontechnologies
PRO
1
1.3k
株式会社EventHub・エンジニア採用資料
eventhub
0
4.3k
OpenID BizDay#17 KYC WG活動報告(法人) / 20250219-BizDay17-KYC-legalidentity
oidfj
0
380
Culture Deck
optfit
0
480
利用終了したドメイン名の最強終活〜観測環境を育てて、分析・供養している件〜 / The Ultimate End-of-Life Preparation for Discontinued Domain Names
nttcom
2
320
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
180
プロダクトエンジニア構想を立ち上げ、プロダクト志向な組織への成長を続けている話 / grow into a product-oriented organization
hiro_torii
1
300
「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly
i35_267
1
540
Windows の新しい管理者保護モード
murachiakira
0
180
Featured
See All Featured
Scaling GitHub
holman
459
140k
Being A Developer After 40
akosma
89
590k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
9
500
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
How to Ace a Technical Interview
jacobian
276
23k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
21
2.5k
The World Runs on Bad Software
bkeepers
PRO
67
11k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
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にでもコチラの解説記事を書きます。