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
150
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
690
IBM Cloud Festa 2020 GUIから始める量子コンピューター超入門
ayumu0118
1
730
量子コンピューター超入門ハンズオン 補足資料 線形代数
ayumu0118
1
1.2k
量子コンピューター超入門ハンズオン 2020/04/24
ayumu0118
1
1.2k
Other Decks in Technology
See All in Technology
「家族アルバム みてね」における運用管理・ オブザーバビリティの全貌 / Overview of Operation Management and Observability in FamilyAlbum
isaoshimizu
4
160
『GRANBLUE FANTASY: Relink』最高の「没入感」を実現するカットシーン制作手法とそれを支える技術
cygames
1
140
Tricentisにおけるテスト自動化へのAI活用ご紹介/20240910Shunsuke Katakura
shift_evolve
0
200
The XZ Backdoor Story
fr0gger
0
3.6k
JTCや セキュリティチェックリストが夢の跡
nikinusu
0
620
React Aria で実現する次世代のアクセシビリティ
ryo_manba
4
1.2k
Developer Experienceを向上させる基盤づくりの取り組み事例集
coconala_engineer
0
150
QAに対する超個人的な解釈 / Personal Take on QA
toma_sm
1
100
事前準備が肝!AI活用のための業務改革
layerx
PRO
1
380
DuckDB雑紹介(1.1対応版)@DuckDB座談会
ktz
6
1.4k
忙しい人のためのLangGraph概要まとめ
__ymgc__
1
190
あなたの知らないiOS開発の世界
recruitengineers
PRO
3
180
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
26
5.1k
Mobile First: as difficult as doing things right
swwweet
221
8.8k
We Have a Design System, Now What?
morganepeng
48
7.1k
Writing Fast Ruby
sferik
623
60k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
248
20k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
123
18k
Principles of Awesome APIs and How to Build Them.
keavy
125
16k
Code Reviewing Like a Champion
maltzj
517
39k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Git: the NoSQL Database
bkeepers
PRO
425
64k
Why You Should Never Use an ORM
jnunemaker
PRO
53
8.9k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
38
9.2k
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にでもコチラの解説記事を書きます。