AHC 030 参加記
AHC 030 おつでした。
プレテスト 7,885 M で暫定 55 位です。
(追記)システスは 528 B で 51 位でした。
最終提出
- が小さい場合は可能なすべての状態(各油田の左上の座標の組)を持って、期待獲得情報量がなるべく大きくなるクエリを投げるのを繰り返す(☆)
- が大きくなるにつれて
- 行・列ごとに☆を行い、状態数がある程度減ったらマージして再度☆を行う
- 行 と行 から行を復元する
- 左 列などだけを見て ~ 個の油田の位置を確定してから上のことを行う
- それも無理そうなら セルごとに組にして、それぞれをベイズ推定する
- それも無理そうなら セルごとに聞く
情報量の計算
一般論
事前分布 に従う統計量 を観測することで事後分布 を得た場合に得られる情報量は
あるいは連続の場合は確率密度関数 および を用いて
と表せる *1 。
情報量最大化への帰着
問題の言い換え
問題は「油田埋蔵量が正のマスをすべて特定すること」だが、これを「すべての油田の位置を特定すること」と言い換えたい。
実はこれは が小さければほぼ正しい。つまり油田の配置は油田埋蔵量が正のマスとほぼ一対一に対応する。 が大きい場合は単射にならないことが多いが、 が大きい場合は大変なので(後述するつもり)、この言い換えをする。
情報量のオーダー
油田の配置は、初期情報だけからだと 通りある。これを一意に特定するにはこの対数に相当する情報量 を得る必要がある *2 。
状態数は で抑えられるので、 か かを全部持つ状態数 よりかなり小さくなっている。
コスト当たり約 の情報量が得られるとすると、 で正解に辿り着くことができるという計算になる。
貪欲法
いろいろ不確実性が高いので、「各ターン、(得られる情報量の期待値)÷(コスト)を最大にするムーブを繰り返す」という貪欲法でも十分強そうということが分かる。
正規分布で近似
(この項は結局使わないので読み飛ばしても OK)
仮定
- の事前分布が正規分布
- 観測により、実際の値に誤差 を加えた値が得られる
観測値の分布
このとき観測値 の分布は
事後分布
また観測値が であれば事後分布は正規分布 に従う
ここで
得られる情報量
これを上の一般の場合の式に代入して、簡単のために とすると、得られる情報量は
得られる情報量の期待値
これを について期待値を取ると得られる情報量の期待値が次だと分かる。
何マス選べば良いか
kマス選んだときの平均・分散
適当に近似すると マスを無作為に選んで占ったときに得られる情報量の期待値が分かるのでそれを最大化すれば・・・
あたりまで考えたときに、少し実験してみると が小さいと情報量が増えすぎちゃうことに気付いた(例えば か しかとらない場合、情報量は最大でも だけど正規分布で近似すると とかが得られてしまうなど)。
離散
なので事前分布も誤差関数も離散でやった方が良さそう。
誤差と遷移確率
を固定して考える。
あるサイズ のマスの集合について、油田数の合計の分布は、それまでに聞いたクエリから理論上厳密に計算できる。
よってこの場合もその集合についてクエリを投げたときに得られる情報量の期待値が(計算量を気にしなければ)厳密に求まる。
可能なすべてのクエリに対してコスト当たり期待獲得情報量を計算するのが良いが、時間的に難しいのでいくつか候補を選んでコスト当たり期待獲得情報量が最大のものを選ぶこととしたい。
計算方法(離散の場合)
事前分布が および事後分布が が分かると、得られる情報量は上述のとおり次のように表される。
あるマスの集合について質問するという観測について、観測を行う前の段階でどれぐらいの情報量を得られるか計算するには、次のように考える必要がある。
- 各観測結果について、その観測結果が得られた場合の情報量を計算する
- それらを事前分布の重みで加重平均する
1. については、観測結果から事後分布を計算する必要があるが、これはベイズで計算できる。ちゃんとやるとでかいテーブルが必要になって結構大変だが、 はケースごとに固定なので、 (クエリに投げるセルの個数)ごとにテーブルを前計算しておけばなんとかなる。 Python だとそれでも結構つらいので、なるべく同じ でクエリを投げるようにした。
実装方法
方針
- すべての状態について、クエリ結果をもとに確率分布を管理する。
- トップの状態が 番目にある程度差を付けたら Answer クエリを投げる
データの持ち方
- 通りの状態をすべて管理する。
- 初期状態では事前分布は互いに等確率なので、すべて同じ重みとする
- クエリを行うごとに、結果に対して整合的になる確率を掛ける
- 実装上は対数確率を加算する
- 管理する量が膨大になるのを防ぐため、十分小さい確率になったら管理対象から外す
どのクエリを選ぶか
- なるべく結果の分散が大きくなるようなクエリを聞くのが良い
- マス同士の共分散が高い(≒近くにある)マス同士を一緒に選ぶのが効率的であることが多い
- ただし一度クエリを投げると、次回からはそのクエリの結果は既知となるので、同じ(あるいは似ている)クエリをたくさん投げても得られる情報量の期待値は少なくなりがち
計算量削減の工夫
独立空間への分解
個の状態を管理・更新するのは、 Python では かせいぜい ぐらいしか対応できない *3 。
行だけ見て、すべての油田の行の位置を決定する
→列だけ見て、すべての油田の列の位置を決定する
みたいな方針だと管理する状態数を まで減らせるので ぐらいまで対応できる。
「行だけ見る」というのは、 を に移す関数 により「圧縮」操作をしたと考えることができる。
これでうまくいくのは、「行だけ見る」が加群の商群になっていることが効いている。
より一般化すると加群 の部分加群 を固定すると、その商群で考えることができる。
一部のマスだけで判定する
例えば左 列だけを見て、ここにかぶっている油田が 個以下であると仮定すると、調べるパターンは になる。さらに行をまとめたり列 などを考えることで探索パターンを減らし現実的な計算量で順次特定していくことができる。
私の実装では、これを一度行って ~ この油田の位置を固定して、上の独立空間に分解する方法になった。
その他やったこと・考えたこと
- 今回はローカルで実行せず、すべてコードテストでデバッグした
- 序盤は 以外は打ち切るとかでやっていて、後半に徐々に を増やしていこうと思っていたが増えきらなかった
- Web 版ビジュアライザの罠:
- と の上限・下限が設定されている雰囲気があるが、あり得ないパターンが含まれている
- かつ とかを表示して、特定むずそうだなーとか言ってたけど存在しないケースだった
- と の上限・下限が設定されている雰囲気があるが、あり得ないパターンが含まれている
できなかったこと
- 全部の状態を持たなくても、クエリの結果に矛盾しない配置を焼きなましとかギブスサンプリングとかで得るのでも当てられるか
- 焼きなましは、全部当てないと使いづらそうだし、自分の実力だとだめそうなので棄却
- ギブスサンプリングだと、最初例えばランダムに 10000 状態持っておいて、クエリごとに尤度を更新して、ある閾値を下回ったらダメな部分を付け替えるみたいなイメージを考えていた(けどこれも自分の実力だと無理そうなので棄却)
- 「一部のマスだけで判定」を逐次的に実行することで が大きい場合も計算量を爆発させずに探索ができるはず
- 実装しきれなかった。
- PyPy では 1 回やるだけで 秒程度かかってしまうので、高速化しないとむり
今後やりたいこと
- 焼きなまし(無限回言ってる)
- Rust に乗り換える(無限回言ってる)
- 今回ちょっとだけ chat GPT くんに翻訳してもらおうとしたけど無理だった
関連ツイート
AHC 030 おつでした。
— きり (@kiri8128) February 19, 2024
Pretest 7,885 M で暫定 55 位です。
やったこと:
M が小さいときは全ての状態を持って、得られる情報量の期待値がなるべく大きくなるクエリを投げる貪欲で。
M が大きくなると状態数が爆発するので、圧縮したり数列だけ見てその部分を特定したりして頑張りました。
seed 0 はコスト 0.5 ぐらい#AHC030 https://t.co/zt4aRgVo7Z pic.twitter.com/K7zP89XnTy
— きり (@kiri8128) February 19, 2024
ニーズがあるか分かんないけど、
— きり (@kiri8128) February 19, 2024
・私の提出をコードテストに貼る
・入力の 1 行目を "C" にして、 2 行目以降に Web 版ビジュアライザの Input を貼る
・実行結果をビジュアライザの Output に貼る
でデバッグできるようになっています。
(追記) ごとのシステス順位
以上ほぼ 位付近ですね・・・
(これで全体 位取れてるので力の入れどころは合っていたということで・・・)
2 | 36 | 146,610,872,823 | 369 | 397,319,438 |
3 | 27 | 144,668,767,503 | 354 | 408,668,834 |
4 | 22 | 137,882,178,018 | 358 | 385,145,748 |
5 | 348 | 23,766,708,507 | 398 | 59,715,348 |
6 | 1002 | 7,026,140,456 | 288 | 24,396,321 |
7 | 703 | 7,877,432,650 | 241 | 32,686,442 |
8 | 998 | 5,235,875,353 | 190 | 27,557,238 |
9 | 975 | 6,288,036,010 | 156 | 40,307,923 |
10 | 981 | 4,758,143,130 | 109 | 43,652,689 |
11 | 672 | 7,383,989,361 | 140 | 52,742,781 |
12 | 972 | 5,054,494,368 | 84 | 60,172,552 |
13 | 979 | 4,430,272,358 | 71 | 62,398,202 |
14 | 968 | 4,682,556,825 | 60 | 78,042,613 |
15 | 659 | 5,073,713,315 | 51 | 99,484,574 |
16 | 955 | 4,973,223,557 | 43 | 115,656,361 |
17 | 970 | 3,373,058,320 | 28 | 120,466,368 |
18 | 972 | 6,253,621,561 | 36 | 173,711,710 |
19 | 952 | 1,569,309,822 | 12 | 130,775,818 |
20 | 979 | 1,215,604,211 | 12 | 101,300,350 |
ソース:
https://siman-man.github.io/ahc_statistics/030/index_m.html
End