CODE FESTIVAL 2018 Final (Parallel) 参加記録&解説(A~F)
オープンコンテスト8位でした。
A~Fについて書きます。この記事を書いている時点で解説が公開されていないため、Twitterなどで見た他の参加者さんの解法を大いに参考にしながら書いています。
A - 2540
解法
長さが と の2本の辺で、ちょうど1つの端点を共有するペアを数えればよいです。ただし、重複しないように注意する必要があります。
私の方針は以下です。
- 頂点 と辺の長さ ごとに、「頂点 から伸びている長さ の辺の本数」をmapで管理する。
- 辺を1本ずつ見ていく。そのとき、
- その辺の端点それぞれについて、その時点でのmapを使ってこれ以前に見た辺のうちペアになるものの辺の本数を数える。
- その後、辺をmapに追加する。
このようにすると重複なく数えられます。
ACコード
- (Ruby)Submission #3609891 - CODE FESTIVAL 2018 Final (Parallel)
- (C++)Submission #3623681 - CODE FESTIVAL 2018 Final (Parallel)
B - Theme Color
解法
要求されている答え方が特殊ですが、まずは普通に確率の求め方を考えます。結論を書くと、求めたい確率は
になります。この計算は、 の場合は「反復試行の確率の公式といろいろな例題」に説明があり、これを「多項定理の例題と2通りの証明」に書かれている式のように の場合に拡張したものです。
さて、求めたいのは を満たす最小の整数 です。指数の形を除去するため、両辺底が10の対数を取ります。対数を取ると積は和になるので、
という式になります。この式から求めたい整数 は
となるので、 を の範囲で前計算しておけば を計算できます。
ACコード
- (Ruby)Submission #3610055 - CODE FESTIVAL 2018 Final (Parallel)
- (C++)Submission #3623786 - CODE FESTIVAL 2018 Final (Parallel)
Rubyのコードは多項定理ではなく二項定理の組み合わせで書いているので少し無駄な計算が入っていますが、やっていることは同じです。
C - Telephone Charge
解法
制約が特殊です。それぞれのプランで、通話時間 の時に料金が他のプランより安くなるということは、グラフで描くと以下のような関係になっているはずです。
色が各プラン、太線になっているところがその区間での最安のプランを示しています。このグラフから、例えば図中の の位置であれば、 プラン3またはプラン2が最安になることがわかります。
解法としては、プランを の値でソートしておき、各 についてどの の間に位置するかを二分探索などで特定し、その2つ(端なら1つ)の値を両方試して安い方を採用すればよいです。
ACコード
- (Ruby)Submission #3624012 - CODE FESTIVAL 2018 Final (Parallel)
- (C++)Submission #3610426 - CODE FESTIVAL 2018 Final (Parallel)
D - Three Letters
解法
本番は解けませんでしたが…
文字列の中から文字列の並びを探す時に、文字種とインデックスのどちらでループを回すかによって計算量の見積もりが変わってきます。今回の場合、「1文字目と3文字目は文字種で、2文字目はインデックスで」という少しトリッキーな考え方が必要になります。
ある文字列 について、2文字目のインデックスを左から右にずらしていきます。このとき、「左側に各文字がそれぞれ何個あるか」「右側に各文字がそれぞれ何個あるか」は、累積和のように計算することができます。
このようにすると、
- 2文字目は、文字のインデックス全てについて全探索(全文字列合わせて最大 )
- その2文字目に対して、1文字目と3文字目を文字種全てについて全探索()し、ともに1個以上あるかチェック
として、3文字の文字列の存在を判定することができます。
ただしこの数え方をそのまま行うと、ある に対して同じ文字列を重複して数えてしまう可能性があります。それを防ぐため、3文字の文字列パターン全てにおいて「その文字列が最後に発見されたのはどの か?」という値を管理しておきます。こうすると重複カウントを防ぐことができます。
※計算量について、単純計算すると となるので、これがもし想定解ならばかなり厳しい気がしています。ただコンテスト終了後のTwitterの書き込みを見た感じ、高速な言語を使ってこの解法で通した人が多そうです。
ACコード
実装においては、配列のインデックスなどに文字を使うためにアルファベット52文字を0~51の整数に変換しています。アルファベット大文字と小文字の間はASCIIコード上で連続していなかったりするので地味に注意です。
E - Tough Journey
解法
高橋くんが町 にいるとき、手持ちの水が合計何本になるように買うべきか考えます。もし距離 以下の位置に今いる町よりも水の安い町がある場合、町 ではその町に行けるだけの水を買って、安いほうの町で新しく水を買うべきです。
そのため高橋くんが町 にいて、次に訪れる町 より水の安い町が町 であるとき、
- ならば、町 では手持ち 本になるように水を買う。
- ならば、仕方がないので町 で上限の 本まで水を買う。
このように水を買うのが最適となります。
あとはこれを効率的に解く実装を考えればよいです。実装方法もいくつかあると思いますが、私の方針は
- 町を水の安い順にソートする。
- セグメント木を用いて、ソートした町に対して以下を順番に行う。今考えている町を として、
- それまで見てきた町から、 よりインデックスが大きいものの中で最もインデックスが小さいものを求める。
- 町 をセグメント木に追加する。
としました。具体的な実装はコードを参照してください。
ACコード
F - Dinner Planning
解法
まず単純に考えると、順番に食事をしていくことを仮定しながらグルメ度の変化を見ていって、
- グルメ度が を超えてしまった場合、それまでに行ったレストランの中で最も美味しさが低いものをキャンセルする。
- グルメ度が を下回ってしまった場合、それまでに行ったラーメン屋の中で最も美味しさが低いものをキャンセルする。
ということをしたくなります。
ただし、これでは困るケースが出てきます。例えば以下のグラフのように、「グルメ度が を超えたので過去のレストランをキャンセルしたら、そのせいでグルメ度が0未満になる日が出てしまった」というケースです。
こうなっては困るので、キャンセルすべきは「最後にグルメ度が0になった日以降で、美味しさが最も低いレストラン」となります。グルメ度が0を下回った場合は全く逆のことをします。
※これを毎回貪欲に選んで大丈夫なのか?後々の選択と合わせるとより良い選び方があるのでは?という疑問が浮かびますが、ちゃんとやると証明できると思います。記述がかなり長くなりそうなのでここでは省略します…
ということで、求めたいのはそれまでのグルメ度の推移を全て計算しておき
- 最後にグルメ度が0(または )になったのはいつか?
- ある区間におけるレストラン(またはラーメン屋)で一番美味しさが低いのはどれか?
を求めることです。これだけならどちらもセグメント木を用いて求めることができます。グルメ度に関してはある日から現在までの区間最小値が0かどうか(または最大値が かどうか)で二分探索です。
ただしグルメ度に関してはそれに加えて「過去に遡って、食事をキャンセルした日以降のグルメ度を1変化させる」という操作が必要です。そのため区間に対する操作を行える遅延評価セグメント木を用いれば、必要な全ての操作が可能になって解くことができます。
ただ、これまた想定解ではなさそうですね…。