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
710
IBM Cloud Festa 2020 GUIから始める量子コンピューター超入門
ayumu0118
1
750
量子コンピューター超入門ハンズオン 補足資料 線形代数
ayumu0118
1
1.3k
量子コンピューター超入門ハンズオン 2020/04/24
ayumu0118
1
1.3k
Other Decks in Technology
See All in Technology
RubyのWebアプリケーションを50倍速くする方法 / How to Make a Ruby Web Application 50 Times Faster
hogelog
3
950
Incident Response Practices: Waroom's Features and Future Challenges
rrreeeyyy
0
160
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
3.2k
エンジニア人生の拡張性を高める 「探索型キャリア設計」の提案
tenshoku_draft
1
130
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
28
13k
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
190
B2B SaaSから見た最近のC#/.NETの進化
sansantech
PRO
0
880
Evangelismo técnico: ¿qué, cómo y por qué?
trishagee
0
360
Lambdaと地方とコミュニティ
miu_crescent
2
370
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
1.3k
Amplify Gen2 Deep Dive / バックエンドの型をいかにしてフロントエンドへ伝えるか #TSKaigi #TSKaigiKansai #AWSAmplifyJP
tacck
PRO
0
390
100 名超が参加した日経グループ横断の競技型 AWS 学習イベント「Nikkei Group AWS GameDay」の紹介/mediajaws202411
nikkei_engineer_recruiting
1
170
Featured
See All Featured
Visualization
eitanlees
145
15k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Adopting Sorbet at Scale
ufuk
73
9.1k
Embracing the Ebb and Flow
colly
84
4.5k
GraphQLとの向き合い方2022年版
quramy
43
13k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Statistics for Hackers
jakevdp
796
220k
Optimizing for Happiness
mojombo
376
70k
Automating Front-end Workflow
addyosmani
1366
200k
4 Signs Your Business is Dying
shpigford
180
21k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
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にでもコチラの解説記事を書きます。