AHC025で優勝しました。長期AHCの過去最高順位は10位だったということもあり、非常に嬉しく思います。
はじめに
- 解法だけでなく、考察や余談についても記載しました。
- 重要度が低いと思われるものは折りたたみにしました。必要に応じてクリック(タップ)してください。
- ベイズ推定やMCMCについては私自身が詳しくないため、コンテスト後に少し勉強して理解したことを書きました。「お気持ち」だけ汲み取っていただければ幸いです。
- アイテム集合 に対して、それらの重さ(の推定値)の和を と表記しました。行儀が悪い表現ですがお許しください。
- 環境によっては数式が読みにくいと思います。下の記事などを参考にすると読みやすくなるかもしれません。
問題
公式の問題文と入力生成方法を参考にしてください。
この記事では などを問題文と同様に定義して使用します。
処理の流れ
- が大きいとき、クエリを消費しながらマージソートを行い、アイテムを重さ順にソートする。
- 個の集合を初期化する。
- 1~500個ほどの推定器(各アイテムの重さを推定するもの)を初期化する。
- 山登り法で改善する。具体的には以下の処理を繰り返す。
- 各推定器について、今までのクエリとの矛盾がなくなるように、反復法によって改善を行う。
- 時間に余裕がある場合、推定器を大きく更新し、再び反復法を適用する。
- 推定器の平均値を求める。
- 推定器の平均値を元に、2つの集合の間でいくつかのアイテムを入れ替える遷移でよさそうなものを列挙する。
- 推定器をサンプルとみなして各遷移のスコア改善量の期待値を求め、期待値が最も高いものを選択する。
- 選ばれた遷移によってスコアが改善するか否かをクエリで判定し、改善する場合にはその遷移を採用する。
- 残りの実行時間が十分短いとき、適当なクエリを投げてクエリを無駄に消費する。(TLE緊急回避モードです。基本的には実行されません。)
- クエリを合計で 回行った場合、山登り法を終了し、解を出力する。
各処理について説明します。
アイテムのソート
がおよそ3.0以上のとき、マージソートでアイテムをソートしました。
ソートを行う理由
後で重さを推定するときに、各アイテム間の順序関係がわかっていると非常に推定の精度が上がります。
例えば 0-indexed で 番目に軽いアイテムの重さを で推定するということが考えられます。
seed = 1 の場合、次のような推定結果になりました。
グラフにおいて、アイテムの真の重さの昇順にソートされ、重さの和が1になるように正規化されています。以降の推定に関するグラフにも同様のことが行われています。
比較回数の最小化
なるべく比較回数が少ないソートを選ぶことにより、山登り法でより多くのクエリを使用することができます。
私は比較回数が少なそうなマージソートを使用しました。
実装は簡単ですが、比較回数が で、実行速度は遅いです。 一般的に速いとされていますが、安定性はありません。(安定性をもたせる実装だと遅くなると思います。) 理想的な場合の比較回数はあまり多くないですが、実際には理想的に動くとは限らないため、比較回数はやや多くなります。また、ピボットの選択が乱択でない場合、計算量が になるケースを意図的に生成できます。 ソートを途中で止めた場合、いくつかのグループに分かれ、グループ間の大小関係がわかる状態になります。 軽いアイテムのソートを優先したり、逆に重いアイテムのソートを優先したりすることが可能です。 小さいもの(あるいは大きいもの)から得ることができます。 ソートを途中で止めた場合、軽いアイテム(あるいは重いアイテム)の順序関係を正しく把握できます。 安定性があり、比較回数は少ないです。 トップダウン方式は全体を半分ずつに区切る方式で、再帰関数を用いることで実装しやすくなります。 ボトムアップ方式は隣り合うグループをマージしていくような方式(Segment Tree をイメージするとわかりやすいかもしれません)で、通常は非再帰で実装します。 ボトムアップ方式はダブルバッファリングとの相性がよく、トップダウン方式よりも若干速い場合があります。 一方でトップダウン方式のほうが比較回数は少ないです。ボトムアップ方式だと のときに、最後に 32 のグループと 1 のグループに分かれ、単純にマージすると遅い可能性が高いです。 私が今回のコンテストで使用したのはトップダウン方式です。 途中で止めると、いくつかのグループに分かれ、グループ内でソートされた状態になります。クイックソートと対照的ですね。 比較回数の最悪ケースが少ないらしいです。よく知りません。 よくわからないというのが私の結論です。 直感的には重いアイテムのほうが影響が大きいため、重いアイテムの情報が重要そうに思えます。 一方で、山登り法で頻繁に動かすのは軽いアイテムであり、軽いアイテムの大小関係だけ把握するという考え方もあります。 ソートするかしないかの二択が離散的すぎて気持ち悪いという感覚があり、途中までソートすることを試したのですが、結局のところうまく使えませんでした。 今回はマージソートか merge-insertion sort を使うのがいいと思います。
ソートの種類について
代表的なソートアルゴリズム
バブルソート
クイックソート
ヒープソート
マージソート
merge-insertion sort
ソートを途中で止める場合に、軽いアイテムと重いアイテムのどちらの情報が重要か
ソート方法のまとめ
集合の初期化
ソートを行ったかどうかにかかわらず、アイテム をグループ に割り当てました
マージソートを行った場合、各アイテムの重さに関してある程度正しい推定ができ、初期解のコストを下げることが可能です。しかし、初期解をよくすると最終的なコストが増加しやすかったため、初期解は常に で設定しました。
局所探索の初期解はランダム性が高いほうがよいのでしょうか。私には理由がわかりませんでした。
(2023/10/30 追記: 初期解がよいとアイテムの入れ替え回数が減り、同一集合内のアイテム同士の比較が行われず、推定の精度が下がるからだと思います。)
推定
反復法
まず、今までのクエリ結果と矛盾しない(このことを制約と呼ぶことにします)重さを求めるための反復法について説明します。
推定の初期値は指数分布で生成し、ソートした場合には推定値もソートします。
以下に反復の流れを示します。
- 次の処理を最大30回行う。
- 今までの全てのクエリ について次の処理を行う。
- 集合 の和をそれぞれ求める。
- 求めた和とクエリの結果が矛盾している場合、重さの和が入れ替わるように の各要素の重さをスケーリングする(修正量をアイテムの重さに比例させる)。
- 重さが1.0未満のものは1.0にし、重さが 105 N / D 以上のものは 105 N / D にする。
- 更新が行われなかった場合、反復法を終了する。
- 今までの全てのクエリ について次の処理を行う。
クエリの結果が等号だった場合、重さの和が等しくなるようにスケーリングしました。稀にしか起こらないと思います。
不等式が満たされない場合に、重さの和が等しくなるように推定値を更新するときの修正量を「学習率が1.0である」と定義することにします。すなわち、学習率を とすると、 が になるように更新します。 学習率の値をいくらぐらいに設定するのがよいか考えます。 学習率が1.0未満の場合、満たされない制約が1つである場合などに更新を無限に繰り返すことになるため、不適切であると考えられます。(機械学習の文脈では基本的に学習率を1.0未満にしますが、今回は学習率の定義が異なることやデータが正確であることに注意してください。) 学習率が2.0より大きい場合、重さが負になる場合が考えられ、発散する場合もあるかもしれません。不適切です。 学習率は1.0以上2.0以下がよさそうです。パラメータ調整を行ったところ、学習率は2.0になりました。学習率2.0というのは重さの和を入れ替えるということになります。学習率を2.0にした場合、学習率を1.9にした場合よりもかなり性能がよく、学習率は敏感なパラメータだったと言えます。 連立一次方程式を解く際に、修正量を拡大して収束を加速させるという手法として、SOR法というものがあるらしいです。今回は制約が不等式のためSOR法ではありませんが、修正量を大きめに設定するという考え方は似ているかもしれません。ちなみにSOR法(かそれに近い何か)はトヨタコン決勝の懇親会でsaharanさんがAHC022(リクルートハーフマラソン)の文脈で教えてくださいました。ありがとうございます。
重さのスワップを行った経緯
重さの和をスワップすることの利点
が不変のため、アイテムの重さの和が保たれます。重さの和が保たれない場合、クエリに含まれないアイテムの値を相対的に変更することになり、あまりよくない感じがします。
クエリの比較対象が要素1個同士の場合、単純に2つのアイテムの重さを入れ替えるだけなので、初期値が指数分布であれば指数分布が保たれることになります。分布が保たれるというのは非常によい性質です。実際には比較対象が1個同士とは限らないため、分布は少しずつ崩れると思います。
ベイズ推定の考え方
ソートを行った場合に、全ての制約を満たす重さとして次の2つの解を見つけたとします。
事前分布が指数分布であることを踏まえると、右側の推定のほうが確率が高そうです。
制約を満たす解の中でも、指数分布に近いものを見つけたいというモチベーションが生まれます。
理想的には解析的に事後分布を求めたいですが、おそらくそのような計算は困難です。そのためサンプリングを行って分布を近似することを考えます。
MCMCの考え方
サンプリングを行う度に指数分布から値を生成し(ソートした場合はソートも行い)、全ての制約を満たすもののみをサンプルとして扱うという方針が考えられますが、制約が増えるにつれて受理率が非常に低くなることが予想されます。
そこで、既に得られたサンプル(特に直前のサンプル)から新たなサンプルを生成して使用することにします。既存のサンプルから新たなサンプルを生成する方法として多くのバリエーションが考えられています。
サンプリング
並列に 個ほどのサンプル(推定器)を用意します。
実行時間に余裕があるとき、直前のサンプルから新たなサンプルを生成します。
具体的には次のような手順です。
- 指数分布から 個の値を生成する。
- アイテムの大小関係が元のサンプルと等しくなるように生成した値を並べ替える。
- 反復法を適用し、制約を満たす解へ収束させることを目指す。
ソートを行っていた場合、アイテムの大小関係はサンプルによらないため、元のサンプルを無視して新たにサンプルを生成することと等価になります。
なお、実装上は反復法が収束したか否かはほとんど区別しませんでした。処理を収束したものに限定するよりもサンプル数を減らさないことのほうが重要だったようです。
ちなみに私よりも高得点だったwriterのwataさんは、ギブスサンプリングでサンプルを更新したそうです。ここで差をつけられた可能性もありますね。
サンプリング結果
ソートしない場合に、いくつかのアイテムの推定を大きく間違えていました。
山登り法
初期解を山登り法で改善します。
2つの集合の間でいくつかのアイテムを入れ替え、コストが減少したなら採用し、そうでないなら元に戻します。
コストが減少したか否かを判定する方法について述べます。
元の集合を とし、新たな集合を とします。 の間に共通するアイテムはないものとします。
の場合、 かつ ならばコストが減少します。 の場合は不等号が逆になります。
かつ または かつ です。2回のクエリで判定することができ、 で場合分けする方法よりも効率的に思えるかもしれません。 しかし、実際には場合分けを行ったほうがよいと思います。元のグループの大小関係はわかっている場合が多く、そのような場合は と の比較を省略できます。 で の場合に、 と の比較を省略でき、比較が1回で終わることがあります。 最大3回の比較を要しますが、集合間の大小関係を把握できるメリットもあるため、集合同士の比較も行ったほうがよいと考えられます。 不採用のときに比較を1回で済ませるために、、 のうち、成り立ちにくそうなほうから比較を行いました。
最初の条件は必要か
クエリの省略
結果がわかる場合はクエリを省略します。省略するパターンを以下に示します。
- 片方の集合が空のとき
- 既に同じクエリを投げているとき
- 集合の比較で、推移律から結果がわかるとき
集合の大小関係が となっていて、集合 を変更してコストが下がったとします。このとき、 に関して以下の関係が保存されます。
コンテスト上位の方の中には、より複雑な比較の省略を行った人もいたようでした。
入れ替え候補の列挙
2つのグループを選択し、重さの推定値が与えられるものとすると、partition problem に帰着されます。partition problem はNP完全で、擬多項式時間アルゴリズムやヒューリスティックな手法が存在します。
私は半分全列挙をベースとして partition problem を解きました。理想的には厳密解が得られますが、集合の要素数が多いときは長い時間がかかります。そこで、各集合の入れ替え可能なアイテムを、重さが小さいものを中心に 2 ~ 10 個に限定しました。
優先度には乱数をかけました。 具体的な優先度の付け方を以下に示します。「重さが小さいものを中心に」の補足
が小さいときは推定の精度が悪かったからか、変更を小さくしたほうがスコアが上がりました。入れ替え可能なアイテム数について
2つの全列挙された配列はソートされているため、尺取法の要領で最適な値を計算できます。要するに ではなく、 で計算できます。 解の復元は、全列挙パートで追加したときと逆の順序で行います。和が前の配列にあればその要素を使う必要がなく、そうでないときは使う必要があります。配列がソート済みであることに注意すると、値が含まれるか否かは二分探索でわかるため、復元は で行えます。 数値誤差に対処するのは面倒なため、重さは全て整数として扱いました。 関連する AtCoder Beginner Contest の問題
atcoder.jp 私の提出コード
atcoder.jp半分全列挙の実装上の工夫
2-partition problem しか解かない場合、山登り法の局所解に陥るケースがありそうだったため、3-partition などのより多様な近傍を使用することをコンテスト中に考えました。しかし、私は 3-partition の近傍でスコアを上げることができませんでした。 うまくいかなかった理由として以下のことが考えられます。3-partition problem
入れ替え候補の選択
以上のことを踏まえて、次のような流れで入れ替え候補の選択を行います。
- サンプルの平均値を計算する。
- 2つの集合の組を全列挙し、次の処理を行う。ただし、時間がないときは集合の和の差が大きいペアについてのみ処理を行う。
- サンプルの平均値を推定値とし、半分全列挙ベースの手法でよさそうな入れ替えを求める。
- 入れ替えることによる改善の期待値をサンプルから(擬似的に)求める。
- 期待値が最も高い入れ替えを求める。
全てのサンプルが制約を満たすとき、サンプルの平均値も制約を満たします。これは制約に線形性があることから言えます。
という制約があり、 が制約を満たすとします。 このとき、 の両辺を2で割ると が得られます。よって も制約を満たします。より一般的に、正の定数をかけても制約を満たすということが言えます。 さらに と の両辺を足すと が得られます。よって も制約を満たします。 解に正の定数をかけたり解同士の加算を行ったりしたものも解になることから、平均や加重平均をとってもよいということがわかります。 また、この記事においてグラフを描画するときに重さの和が1になるように正規化している理由は線形性があるからです。線形性の補足
私の実装では、サンプルの平均もサンプルとして扱っています。サンプル数を として、サンプルの平均は 個分のサンプルとして期待値を計算しました。加重平均の重みが普通のサンプルの 倍になっているということです。 サンプルの平均もサンプルとして扱うことで、サンプル数が少ないときに正則化効果が生まれたと推測しています。
期待値の求め方
その他
集合の表現方法
3つの方法を紹介します。
配列
アイテムの番号を整数として配列に保持します。最も単純な表現方法だと思います。
C++だと std::vector<int>
などです。
ソートしない場合、要素の追加は ですが、要素の削除や含まれるかの判定が で遅いです。
Index Set
tomerunさんのブログを参考にしてください。
topcoder-tomerun.hatenablog.jp
今回の問題では であるため、平衡二分木などよりも高速で便利だと思います。
bitset
C++における std::bitset<100>
です。
次のような利点があります。
- コピーが高速である。
- 集合の演算をビット演算で簡潔に記述でき、処理が高速である。
使い分け
配列と bitset を使用しました。イテレーションを回すことが多い場所では配列を使用し、そうでないところでは bitset を使用しました。
C++20 の bitset を配列に変換する方法
std::countr_zero
などを使用することで、要素数の線形時間で変換できます。定数倍が軽くはなく、 回ループを回したときと速度があまり変わらないかもしれません。vector<int> bitset_to_vector(const bitset<100>& l) {
ull low = (l & bitset<100>(ULLONG_MAX)).to_ullong();
ull high = (l >> 64).to_ullong();
vector<int> ret;
ret.reserve(l.count());
while (low) {
int v = countr_zero(low);
ret.push_back(v);
low ^= (1ull << v);
}
while (high) {
int v = countr_zero(high);
ret.push_back(v + 64);
high ^= (1ull << v);
}
return ret;
}
順位表の使い方
ACを一部のテストケースに制限し、自分が苦手なタイプのケースを特定していました。
assert(Q < 8 * N);
コンテスト終盤は が小さいケースに弱いことがわかっていたため、 が小さいケースを中心に改善点を探りました。
結局のところ、最後まで が小さいケースに弱かったため、サンプリングをうまく使えていなかったのかもしれません。
スコアの評価方法
各テストケースのコストの対数を求め、その和を最小化しました。
パラメータ調整
大雑把なパラメータ調整は実装したときに行い、細かいパラメータ調整はコンテスト最終日に行いました。
によって決定されるパラメータ調整は、関数の探索になるのでかなり面倒でした。
パラメータ調整は全て手動で行いました。Optuna のような自動最適化ツールは使っていません。
高速化の寄与
高速化によってどれだけコストが下がるかは、実行時間を長くすることにより、高速化を行う前に推測できます。
私の方針だと高速化は非常に重要で、参照渡しにし忘れていた部分を直しただけで0.8%ほど順位表のスコアが上がったことがありました。
提出コード
最後に
いくらか考察も書きましたが、そのほとんどは実装後やコンテスト後に考えたことです。実際には試行錯誤の繰り返しでした。
コンテストを開いてくださったAtCoder様、writerのwataさん、コンテスト参加者の皆さん、最後まで読んでくださった読者の皆さん、ありがとうございました。