ナンプレマラソン自分のやった事

@Mi_Sawa

最初

● Benchmark2をベースに改良.

– 原型(近くに少ない数字を入れる)は 11,900 点

– 1回だけじゃなくて100回くらい繰り返すようにする.

– 近くの度合い（マンハッタン距離, 縦横が合っているか)で重み付けを変える.

● 11,900 点→ 45,019 点

● やった！ 4倍くらいになった！ これで勝つる!!

気づく

● 試してなかったけど, 最初から入ってる所以外を規則的に入れるのってどうなんだろう?

– (x, y) に (x+y)%9+1 を入れてみる.

● 45,019 点 → 117,544 点!● なんてこった, さっきのはまだスタートラインでは

なかったのか.

● 規則的に入れる方針に変える.

きそくてき(横ベース)

● 規則的つってもどう入れればよいのか.

– まず, 横をなるべく規則的に並べてみよう.– 縦と3x3は無視して, 適当にDPっぽく, なるべくいい感

じの規則で入れる.● 117,544 点 → 122,873 点.

– 横だけ考えても, 自由度結構高いので, 縦でもいい感じのを選ぼう. それを, 何度もやる.

● 122,873 点 → 123,779 点.– 縦は殆ど効いてなかった.

きそくてき

● そういえば, (x+y)%9+1 って, 最適じゃないじゃん.

– 最適なパターン作るか. → 証明出来んけどこれだろ.

● 123,779 点 → 151,864 点

● 今までの努力とは一体なんだったのか…

最適パターン

● 固定されている 1/6 って結構少ないんじゃね？

– パターンから”ずらす”代償は大きそう.

– パターンそのままが, 本当の最適解にかなり近いのでは!? (まちがい )

● 最適パターンは, 置換やずらしを含めると何通りもある.

– この中の最適解を, 適当に頑張って効率的に探索する.

– 151,864 点 → 153,568 点

MIP(1)● そういえば普通に整数制約付きの線型計画問題として定式化できるよ

なぁ. まぁ普通に解くのは無理なのはいいとして, どんくらいヤバいんだろう?

– 明らかにヤバい, 超ヤバい.

● lp ファイルが 954M ある.

● LP緩和も解けない.

● （余談) 9x9 の最適パターンは本当にアレだったのだろうか?

– こっちもヤバい. 対称性高すぎなのか, 全然解けない.

– 同じ解は見つかってるけど, 上界が全然下がらない.

MIP(2)

● まぁ, 丸ごとソルバに投げるのは無理.

– 現在の解から, 適当に切り出した場所を改善するとかは出来るのでは?

– 3x3, 5x5 くらいならまぁ出来るっぽい. (ソルバによってはもっと行ける?)

● 結局, この戦略を最後まで使っていた.

大まかな手法

● 改善するマス p をヒューリスティックで選ぶ

● p を中心に, DxD を変更し, 最適解を探す MIP モデルを生成する.

● ソルバにぶち込む.

マスの選択

● そのマスを含む 1x9, 9x1, 3x3 のうち, 得点になっている矩形が少ないやつが選ばれやすい.

● 何回も選ばれたマスは選ばれにくい.

● 変更したマスの周囲は選ばれやすい.

モデル(初期)

● D=3, つまり 3x3 を更新して最適解を探索させる.

● 得点にヒューリスティックは入れず, DxD の周りの8周の情報も全て突っ込んだ.

● 一箇所の更新に 1 秒とかくらいだったと思う.

モデル(後半)

● ソルバは, 「最適性の証明」にかなり時間をかけていて, 良い解は割と早く見つかっているっぽい.

– なるべく「良い解を探すの優先」なオプションに.

– 優先度に応じて 3〜5秒程度で探索を打ち切る.● 何度か最適解保証までソルバを動かして, 最適解自体

がどれくらいで出ているかを見た.

– 15x15 を更新して解を探索させる.

– 姑息な対称性の除去.

– 解が動きやすいようにする.

並列化

● 点数はどんどん上がっていたので, 並列化する事に.

– ソルバもマルチスレッドになってるけれど, 数秒程度で探索を打ち切っている為か, CPUを100%使っている様子は無かった.

– 更新するマスを, 他のスレッドが全く参照していない所から選ぶとかする.

– 8スレッドで動かして, 放置.– 153,568 点 → 224,804 点 (最終提出)

得られた知見(1)

● 保存大事

– 得点計算関数に投げると自動で保存.

– 数分毎に, プログラムの状態を保存して, 何かあっても途中から再開出来るように.

– 数十分毎に, git commit.

得られた知見(2)

● 使える物は使う.

– 簡単に定式化出来そうなら, とりあえずソルバに投げてみるのは悪い手では無い. (大抵のコンテストでは使えないけれど, それでも, 試すのは悪くなさそう)

得られた知見(3)

● メインのアルゴリズムの実装が簡単に出来るよう, 補助の関数とかクラスとかは積極的に書くべき.

– メイン部分 : 150行くらい.

– utils.cc : 600行以上.

– 新たなアルゴリズムを実装する気力が失せにくい.

得られた知見(4)

● Visualizer は, 適当に情報を表示しても意味ない.

– 全く思考の役に立つものを書けなかった.

– GUIめんどい.

各バージョンの比較

● 各バージョンでの解を, 500x500の画像にした.

– R: そのマスを含む 3x3 の矩形のうち, ok な矩形の割合.

– G: 1x9 (横)

– B: 9x1 (縦)

● 何も得点出来てないマスは黒.

Benchmark2 vs その改良

11,900 点 45,019 点

Bm2の改良 vs (x+y)%9+1

45,019 点 117,544 点

(x+y)%9+1vs 横ベースDP

117,544 点 122,873 点

横ベースDP vs +縦, 繰り返し

122,873 点 123,779 点

横DP+縦, 繰り返し vs 規則的

123,779 点 151,864 点

規則的 vs 最もいい感じな規則的

151,864 点 153,568 点

いい規則的 vs 最終提出

153,568 点 224,804 点

8/17 以降の得点

17 18 19 20 21 22 23 24 25 26 27 28 29 30 31215000

216000

217000

218000

219000

220000

221000

222000

223000

224000

225000

日付

点数

並列化

考えていた事

● ローカルな最適化では, 自由度が高い所がそれなりにある.

– 得点に寄与しないマスがあり, それを動かせる. (マスaとbのどっちかは得点に寄与出来ないみたいな)

● 自由度を寄せ集めたら, そこで点数を高く出来ないか?