1. ナンプレマラソン
自分のやった事
@Mi_Sawa

2. 最初
●
Benchmark2をベースに改良.
– 原型(近くに少ない数字を入れる)は 11,900 点
– 1回だけじゃなくて100回くらい繰り返すようにする.
– 近くの度合い（マンハッタン距離, 縦横が合っているか)で
重み付けを変える.
● 11,900 点→ 45,019 点
● やった！ 4倍くらいになった！ これで勝つる!!

3. 気づく
● 試してなかったけど, 最初から入ってる所以外を規則的に
入れるのってどうなんだろう?
– (x, y) に (x+y)%9+1 を入れてみる.
● 45,019 点 → 117,544 点!
● なんてこった, さっきのはまだスタートラインでは
なかったのか.
● 規則的に入れる方針に変える.

4. きそくてき(横ベース)
● 規則的つってもどう入れればよいのか.
– まず, 横をなるべく規則的に並べてみよう.
– 縦と3x3は無視して, 適当にDPっぽく, なるべくいい感
じの規則で入れる.
●
117,544 点 → 122,873 点.
– 横だけ考えても, 自由度結構高いので, 縦でもいい感
じのを選ぼう. それを, 何度もやる.
● 122,873 点 → 123,779 点.
– 縦は殆ど効いてなかった.

5. きそくてき
● そういえば, (x+y)%9+1 って, 最適じゃないじゃん.
– 最適なパターン作るか. → 証明出来んけどこれだろ.
●
123,779 点 → 151,864 点
● 今までの努力とは一体なんだったのか…

6. 最適パターン
● 固定されている 1/6 って結構少ないんじゃね？
– パターンから”ずらす”代償は大きそう.
– パターンそのままが, 本当の最適解にかなり近いので
は!? (まちがい)
● 最適パターンは, 置換やずらしを含めると何通りもある.
– この中の最適解を, 適当に頑張って効率的に探索す
る.
– 151,864 点 → 153,568 点

7. MIP(1)
● そういえば普通に整数制約付きの線型計画問題として定式化できるよ
なぁ. まぁ普通に解くのは無理なのはいいとして, どんくらいヤバいんだろ
う?
– 明らかにヤバい, 超ヤバい.
●
lp ファイルが 954M ある.
● LP緩和も解けない.
● （余談) 9x9 の最適パターンは本当にアレだったのだろうか?
– こっちもヤバい. 対称性高すぎなのか, 全然解けない.
– 同じ解は見つかってるけど, 上界が全然下がらない.

8. MIP(2)
● まぁ, 丸ごとソルバに投げるのは無理.
– 現在の解から, 適当に切り出した場所を改善するとかは出
来るのでは?
– 3x3, 5x5 くらいならまぁ出来るっぽい. (ソルバによっては
もっと行ける?)
● 結局, この戦略を最後まで使っていた.

9. 大まかな手法
● 改善するマス p をヒューリスティックで選ぶ
●
p を中心に, DxD を変更し, 最適解を探す MIP モデルを生
成する.
● ソルバにぶち込む.

10. マスの選択
● そのマスを含む 1x9, 9x1, 3x3 のうち, 得点になっている矩
形が少ないやつが選ばれやすい.
● 何回も選ばれたマスは選ばれにくい.
● 変更したマスの周囲は選ばれやすい.

11. モデル(初期)
●
D=3, つまり 3x3 を更新して最適解を探索させる.
● 得点にヒューリスティックは入れず, DxD の周りの8周の情
報も全て突っ込んだ.
● 一箇所の更新に 1 秒とかくらいだったと思う.

12. モデル(後半)
● ソルバは, 「最適性の証明」にかなり時間をかけていて, 良
い解は割と早く見つかっているっぽい.
– なるべく「良い解を探すの優先」なオプションに.
– 優先度に応じて 3〜5秒程度で探索を打ち切る.
● 何度か最適解保証までソルバを動かして, 最適解自体
がどれくらいで出ているかを見た.
– 15x15 を更新して解を探索させる.
– 姑息な対称性の除去.
– 解が動きやすいようにする.

13. 並列化
● 点数はどんどん上がっていたので, 並列化する事に.
– ソルバもマルチスレッドになってるけれど, 数秒程度で
探索を打ち切っている為か, CPUを100%使ってい
る様子は無かった.
– 更新するマスを, 他のスレッドが全く参照していない所
から選ぶとかする.
– 8スレッドで動かして, 放置.
– 153,568 点 → 224,804 点 (最終提出)

14. 得られた知見(1)
● 保存大事
– 得点計算関数に投げると自動で保存.
– 数分毎に, プログラムの状態を保存して, 何かあっても
途中から再開出来るように.
– 数十分毎に, git commit.

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

16. 得られた知見(3)
● メインのアルゴリズムの実装が簡単に出来るよう, 補助の
関数とかクラスとかは積極的に書くべき.
– メイン部分 : 150行くらい.
– utils.cc : 600行以上.
– 新たなアルゴリズムを実装する気力が失せにくい.

17. 得られた知見(4)
●
Visualizer は, 適当に情報を表示しても意味ない.
– 全く思考の役に立つものを書けなかった.
– GUIめんどい.

18. 各バージョンの比較
● 各バージョンでの解を, 500x500の画像にした.
– R: そのマスを含む 3x3 の矩形のうち, ok な矩形の
割合.
– G: 1x9 (横)
– B: 9x1 (縦)
● 何も得点出来てないマスは黒.

19. Benchmark2 vs その改良
11,900 点 45,019 点

20. Bm2の改良 vs (x+y)%9+1
45,019 点 117,544 点

21. (x+y)%9+1vs 横ベースDP
117,544 点 122,873 点

22. 横ベースDP vs +縦, 繰り返し
122,873 点 123,779 点

23. 横DP+縦, 繰り返し vs 規則的
123,779 点 151,864 点

24. 規則的 vs 最もいい感じな規則的
151,864 点 153,568 点

25. いい規則的 vs 最終提出
153,568 点 224,804 点

26. 8/17 以降の得点
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
215000
216000
217000
218000
219000
220000
221000
222000
223000
224000
225000
日付
点数
並列化

27. 考えていた事
● ローカルな最適化では, 自由度が高い所がそれなりにあ
る.
– 得点に寄与しないマスがあり, それを動かせる. (マスa
とbのどっちかは得点に寄与出来ないみたいな)
● 自由度を寄せ集めたら, そこで点数を高く出来ないか?