脳log[20201107] AtCoder Beginner Contest 015／D 問題 高橋くんの苦悩

最終更新: 2021-05-07T15:06+0900

♪ [AtCoder] AtCoder Beginner Contest 015／D 問題 高橋くんの苦悩

DP の基本形といっていいほど典型的な DP。見え見えの誘いに乗りたくなくて他の解法を考えてみたけど思い付かなかった。それに心配しなくても Ruby ならではのお楽しみポイントがちゃんとあった。

実行時間の変遷が見どころ。

 提出 #17933561 (TLE×7 / AC×40)

N×K×W のループは上限が2500万回であり、Ruby で TLE を避けようと思ったら桁を１つ減らさないといけない。予想された結果。

 提出 #17934141 (AC / 1033 ms)

N のループが K 回に達するまでは K のループを K 回まわす必要がないよねっていう節約作戦で AC になった。制約は K <= N <= 50。

 提出 #17934762 (AC / 554 ms)

提出一覧が 1000 ms を超えるグループと超えないグループに分かれていたので中を見たら、添字と値が入れ違っていた。

• 遅い方 - Array[K][W] = sum of B (K<=50, W<=10000)
• 速い方 - Array[K][sum of B] = W (N<=50, B<=100, sum of B<=5000)

B の値域が(W にくらべて)かなり狭い範囲に限定されているのがポイントで、速い方はループで走査する DP 配列のサイズがおよそ半分で済む。

 提出 #17935118 (AC / 111 ms)

２番手以降の集団をダブルスコアで突き放す zazaboon さんの提出 #11417636 (150 ms) を調べた結果。

• DP 配列のサイズを制約上の上限ではなく、テストケースに応じた必要最小限のサイズにする。
• B を小さい順に処理することにより、ループの初期に更新する DP 配列の範囲を限定する。
• 答えを見つけたら即終了する。

以上の点を真似したのに加えて、考えられるこちらのアドバンテージが

• Ruby のバージョンが上がっている。(2.3 → 2.7)
• 最初に簡単なチェックで N を減らした。
• 初期値を整数にした。(「とりあえず大きな数としての初期値に Float::INFINITY を使うと、10**9 のような整数型を使うより比較にコストがかかる」)
• 演算子を極力書かないようにした。(vsum+1 は美意識とボキャブラリに起因する例外)
• 配列参照を極力書かないようにした。特に二重のものはひとつも書かなかった。
• 見た目がださくても a = [a,b].min と書くより a = b if b < a と書いて代入を省略できる方が速い。(だけど本当は宣言的な変数定義がしたい。操作ではなく結果について書きたい)
• よくわからない処理を真似しなかった。41 行目の if と 44 行目。

前後のリストを比べると後ろは問題と関係のない比較的どうでもいい内容が並んでいるね。

 Python のこの提出 #287540 (AC / 66 ms)

いまのところの Python 最速。AB 配列を幅対重要度比でソートしてからの DFS なんだけど、すごいのが _greedy_by_width と _greedy_by_num という先読み関数で探索の打ち切りを判断しているところ。それでペイするんだってところと、１枚のスクリーンショットを刻む発想が(だって刻んだ画像の価値はゼロですよ。常考)。

使う使わないの二択だと比率がちょっと悪くても残った隙間にぴったり収まる方が重要度を高められることがある。先読みでその可能性を取りこぼしては答えを誤る。だからあくまでも比率のいいスクリーンショットから使う。ぴったり収まらないなら切り取って収まる分だけ使う。そういう考え。

最近別の問題を自分が DFS で解いたときのことだけど、「さっきの TLE 提出を微修正したら AC になった。事前に XY 配列をソートするだけ。二択による手戻りを最小限にするために、選択肢の優劣が明らかで覆りにくいものを最初に選ぶようにした」なんてぬるいやり方よりずっと突き詰めている。すごいなあ。