かんたん。
チェック段階でkとxを2回間違えてチェックした。
焦りすぎ。

もしかしてcount関数ってStringに特殊化されて文字列も数えられる？？？と淡い期待を抱いて実行したら普通にコンパイルエラー。
素直にループ回した。

考察実装5分next_permutationの使い方調べるの5分。
なんとなくnext_permutationは順列を扱えるくらいしか知らなかったが、知ってるのは強いね。
初めて使ってみて勉強になった。

unratedの根源。
わざわざ問題文にa[i]は偶数と書いてあったのに奇数が紛れていたらしい。

「最小公倍数は整数をかける場合の最も小さい公倍数なので、整数+0.5をかける場合の最小の半公倍数は最小公倍数の半分。半公倍数の間隔は最小公倍数。」
という考察をコンテスト中にしたが、半分間違っていた。
「最小公倍数は整数をかける場合の最も小さい公倍数なので、整数+0.5をかける場合の最小の半公倍数になる可能性があるのは最小公倍数の半分。半公倍数が存在するなら間隔は最小公倍数。」
というのが正しい。

というのも、最小の公倍数をZとおくと、Z / a[i]が偶数になるa[i]が存在した場合、最小の半公倍数となる(Z / 2) / a[i]が整数となってしまい、X = a[i] * (p + 0.5)を満たせない。
間隔となる最小公倍数のn倍を足しても必ず満たさないので、半公倍数は存在しないことになる。

ということで、基本的には(Z / 2) + nZ {n:0以上の整数}が半公倍数の数で、答えとなるM以下のものの数は簡単に計算できるが、Z / a[i]が偶数となるa[i]が1つでも存在したら半公倍数は存在しない。

コンテスト中はTLE+WAで、色々改善してTLEはなくしたが、後半15個のWAがなくならなかった。
途中で間違えてEに提出してしまったり、そもそもunratedだったりと、WAは入力ミスが原因だろうと1時間くらいで解くのをやめた。
しかしコンテスト終了後に提出してもWAだった。
改めて考察し直してみると、Twitterで偶奇が云々という記述をいくつか見ていたのもあり、最後の偶奇のチェックが必要だとすぐに気付けた。
unratedで解くのをやめていなければ自力で気付けたと思うが、ちょっと時間かかってたかも。
それでも十分時間内に間に合ったとは思うが。

F問題

やる気ない中でXORの文字を見つけたので読むのをやめた。

まとめ

1年がunratedで終わりunratedで始まるのはどうなんだAtCoder。
別に文句を言いたい気持ちは全然なくて、イメージ悪くない？大丈夫？という感じ。

明日明後日と3日連続でrated(予定)のコンテストがあるので参加したいのだが、いまいちモチベーションが上がらない。
ブログの移行が進んでいないのが大きい。
詰まった部分は大体解決していて、単純にやっていないからなので頑張ろう。

保存しましたで消えるの本当に頭おかしいから早く移行したい。
・・・本当に頑張ろう。

かんたん。

問題文読み間違えた。
問題文のGreedy Takahashiからして、高橋くんは自分も青木くんもクッキーを持ってる場合、青木くんのクッキーから食べにかかると思って実装してしまった。
普段BくらいまではACを見ずに次の問題に取り掛かるのだが、今回はCを提出した後に20/20の表示でまだジャッジ中だった。
遅くない？？？と思いつつもDに取り掛かり、途中でBがWAしてるのを確認。
問題の読み間違いに気づき、再度提出してDに取り掛かる。
しかしBだからと高をくくって詰めが甘くてまたWA。
今度はDを解いた後に気づいた。
最終的にACDBという珍しいAC順になった。
毎回毎回あほらしいミスを繰り返しているが、簡単なBで何度もやらかしてしまったのは反省点高い。

かんたん。
エラトステネスの篩張ったら終わった。

最近のDにしては複雑な問題だなーという感想。
K個前の値を保存してDPすれば良さそう・・・と思ったのだが、どう頑張ってもK個前の値だけじゃ遷移を進められない。
「K個前の値」じゃなくて「K個前までの全ての値」を保存しないといけないという考えから抜け出せなかった。
あるところでK個毎に独立してるのでは？と気付き、modKで分けてDPの方針が立った。
この時点で結構時間が立っており、これ以上ミスを重ねたくないとかなり安定志向の実装にしたつもりだが、modK毎のインデックスがすんなりいかずデバッグにかなり時間を取られた。

最初は出す手を数字と連想配列でうまく関連付けてシンプルな条件式にしようとしていたのだが、安定志向で条件式が長くなってしまった。
今回はミスしなかったが、長いとミスも増えるしどっちが良いのか悩みどころ。
うまく関連付ける内容は、詳しい部分は忘れてしまった。
もう去年の話だぞ。
記事書いてるのは徹夜明けの早朝6時過ぎだぞ。

最終的にACしたのが73分。
時間かかりすぎ。

聞くところによるとDPなんかしなくても貪欲で良いらしい。
ちょっと考えてみればすぐわかる話だ。
とりあえず勝てるなら勝てる手を出せば、他の順番と比べて同じ点数になることはあっても悪くなることはない。
最善が複数ある場合に貪欲で解けるっていうの慣れないとなと感じた。
これゲーム問題の分野かな。
ゲーム問題も解かないとなぁ。

F問題

なんかむずかしそー。
完。
まぁunratedだし？という気持ちが溢れてた。

まとめ

2019年最後がunrated！
まぁ助かった。

このコンテストは自分の苦手ポイントを自覚させてくれて得られるものが大きかったように思う。
ミスをするなというのは言わずもがな。
・modKで考える発想。
・必ずしも最善は一択ではなく、そのうちの1つが分かれば良いという発想。
・累積和やBIT等、配列的なデータ構造のインデックスに意味を持たせる発想。
この3つが足りないと感じた。
modKは最近の問題でも理解に時間がかかったばかりだ。
値を決め撃って二分探索する発想はかなり浮かぶようになってきたので、この感覚を参考にこれらの発想も定着させていきたいね。

今日は2020年初のコンテスト。
参加するなら新年初C++コーディングになる。
年末年始全くやっていないので心配だなー。

あけましておめでとうございます。
新年初記事。
年末に記事を書きたかったけど時間がなかったのでまずは2日連続のコンテスト参加記事から。

問題

順位: 1193

パフォーマンス: 1256

新レーティング: 1075

差分: -27

1完。
初めてAGCに参加したが、さすがに難しかった。
目覚めたらコンテスト開始してて、なんとか頑張って9:10過ぎから活動開始した。
結果論だが、Aは一瞬で解けて終わりなので最初から参加していればもっとパフォーマンス出てそう。
寝起きによる自身のパフォーマンスも含めて。

直近のABC148 Fとすごい似てるなーという第一印象。
偶奇があっていれば2人とも全て勝ち続ければ出会う。
偶奇を合わせるためにはどちらかが同じ場所に留まる必要があり、端でしか留まることができないので、端に近い人が端に行って1回留まれば良さそう。
普通にAC。
考察から実装まで5分ちょっと。
寝坊のせいで20分になってしまった。

この問題を2時間近く考えて結局解けなかった。
解析的に解け・・・ない。
二分探索でき・・・ない。(！)
二分探索に使うような関数で全問題に対して可能かどうか走査・・・いけそう？
というような流れで、計算量抑えつつなんとか実装できないか色々してたら解けなかった。
二分探索の発想に至るのにおそらく1時間以上かかったのはまだしも、そこからダメの判断を下したのは非常にbad。
単調増加であるという判断ができなかった。
PやVの値によって場合分けしていたのだが、場合分けしていることが問題を必要以上に複雑にしてしまった。

よく考えてみると、ある問題Xが可能であるとすると、問題Xよりスコアが大きい問題Yと問題Xの選び方を入れ替えると、Yを選ぶことが可能となる。
ただそれだけなのに、何点入れればある問題を選ぶことが可能で、残りの点数はどのように振り分ければ他の問題がある点数以内に収まるか、ある点数以内に収まるようにすると点数が余る場合はどのようにすれば良いか。
こんなことを考えていた。
ある問題を選ぶことが可能であるかどうか知りたいだけなので、M人全員が1点ずつ選ぶとして良い。
それに気付けなかったのが敗因。

ややこC。
問題文とドミノの配置を理解するのに相当時間がかかった。
偶数(偶数は色々便利そうと考えた)で一番小さい4×4について手作業で考えてみようと思ったが、それすらちょっと考えただけでは分からなかったので、その先は無理だろうということでBに専念。
ただ実際には、苦労してでも4×4を実装することが本筋だった。
マス目が小さい値でクオリティが同じものを構成すれば、後はそれらを組み合わせて対角線上に配置すれば、全ての行列でクオリティを保ったままになる・・・なるほど。
2の場合は不可能、3の場合はクオリティ1を作成でき、4, 5, 6, 7の場合はクオリティ1は作成できないが、クオリティ3のものを作成でき、4, 5, 6, 7があれば8以上は全て作成できるのでこれで考える必要のある構成は全て。

相当パズル要素強い。
競プロの大部分を占めるであろう数学系とかシミュレーション系しか解いたことがないので、こういった問題は面白いと感じるが、さすがに引き出しがなさすぎるからその方向に考えを移行できない。
もっと余裕持って問題解きたいね

見てまーーーーーせん。
ABCなら解けなくてもコンテスト終了後に解説見て云々あるのだが、解説すら見ていない。
ちょっとレベルが違いそうで解くのはいつになるやら。

まとめ

初めてのAGCだが、一応レートは上がったので変な苦手意識を持たずに済んだ。
B問題はdiff水色だし解けても良かったなー。

また原因を寝坊に求めることもできるが、そもそも最近まともに頭働いていない状態からコンテストに参加することが多くて反省している。
起きてから本稼働開始までに3,4時間かかる人間なので、本来ならもっと早く起きておくべきなのだが、年末だしねということでひとつ。

年内目標だったブログの移行はまだ少しかかりそう。
水色もブログの移行も年内無理だったかぁ。

順位: 1671

パフォーマンス: 1053

新レーティング: 1048

差分: -2

5完
5完なのにレート下がるなんてそんな・・・。
全体的に簡単が過ぎる・・・。
E問題もうちょっと早く解けても良かったのと、F問題の考察進める速度が遅すぎた。
生活習慣ゴミだったので、ほぼ徹夜明け+テレビ見ながらと、コンディションはなかなかに悪かったのが言い訳になりそう。
M-1見たかったからね。

かんたん。
実装楽にするためにどうしようかちょっと考えた。
ハッシュ化すれば簡単そう、いやハッシュ化できるならそのままでも・・・、という流れで6-A-Bじゃんとなった。

かんたん。
B問題でこんなに簡単なの久しぶり？

かんたん。
C問題でこんなに簡単なの初めて？
前回のbit全探索見習って。
最小公倍数のライブラリ作ってて良かった。

貪欲でいけそうと比較的すぐ気付いたものの、実装で手間取った。
素直にforの中でif使えば良いものの、連続要素数える時と似てるな、ということでwhileなんて使うから1WA+タイムロスを生んでしまった。
15分かかってしまったが、5分で解けても良かった。

なんだこの数列は・・・。
制約すごいからLogかけられそうということで行列累乗を試してみる。
式は作れたものの、変数が出てきてしまってうまく繰り返し二乗が使える形に持っていけない。

最初のいくつかをシミュレートして数式辞典で調べてみるとそれ知ってるよーと教えてくれた！
二重階乗というらしい。
なんならn!!とか記号までついてる。
名前も記号も初めて見たんだが？
一般項もあったが、どう頑張っても誤差出ますよーって見た目してる。
それに多倍長でも無理だろって桁になりそう。

諦めて0が何個続くかに重点を置いて考察していくと、10作るなら2×5しかないと気づく。
・・・これどこかでやらなかった？？？
2は山程あるから5だけ数えれば良いってすごいどこかでやった考え方。
どこでやったのか全然思い出せなかったし、今も分かってない。
とりあえず方針は立ったが5の数え方はすぐに出てこなかったので、いくつか書いてみたら5^nごとに1回ずつ出てくるというのが分かった。

その通り実装するも、ここで恒例の凡ミス。
forの更新式でi*=5で5^nを計算していきたかったのだが、i*=iとしてしまって答えが合わない。
考察25分+凡ミス10分で35分くらいかかった。

ここまで57分。
時間は余裕というわけではないが、なんか解けそうな雰囲気。解けなかった。
考察が全然進まなかったが、コンテストの時間内では最終的に、「u, v間の最短経路を通って高橋くんが青木くんにギリギリまで近づき(近づいた後の頂点をaとする)、その近づいた際に通ったルートの各点から(各点をbとする)、青木くんのいない方にできるだけ頂点がある道に進み、その頂点数+aとbの距離が逃げられる最長距離。偶奇によって±1がありそう。」という考えになった。
考察にかなり時間がかかった上、実装も結構ややこしかったのでタイムアップ。
実装に取り掛かったのは30分後くらいだと思うが、考察も続けながらなので厳しかった。
さすがにまだDFS2回はスラスラ書けないねー。

方針はあってそうなんだけどなーと思っていたので、コンテスト終了後も自力で解き続けてみた。
実装を進めていくと、近づいた際の各点bからのルートは、近づいた最終の頂点aからのルートに含まれていることに気付いた。
つまり、「u, v間の最短経路を通って高橋くんが青木くんにギリギリまで近づき、近づいた後の頂点から青木くんのいない方にできるだけ頂点がある道に進み、その頂点数が最長距離。偶奇によって±1がありそう。」とかなり実装が簡単になった。
順調に実装を進めて提出するとWA。
よく考えると偶奇の処理が正確でなかったので直してAC。
コンテスト終了後の所要時間は15分くらい。
解説見ずにF通せたのは初めてかもしれない。
diff水色だけど。

まとめ

E問題diff茶色ってマジ？おかしくない？
バッドコンディションが脳死行列累乗に繋がって、それに時間かけたのはかなり悪手だった。
とは言え茶色に時間かかるのは苦手問題ってことなのかなぁ。
それよりは単純にFの考察をもっと短く正確にというのが本筋か。

-2とは言えレート下がってしまったので、年内水色難しそう。
しかもブログの移行関連で面白そうなものを見つけてしまい、そればかりで全く問題を説いていない。
今日はAGC明日はABCと一応出るが、今日の初AGCがどうなるかで決まる感じがある。
AGCは過去問すら1問も解いていないので不安しかない。
なんとか頑張っていきたいところ。

ブログのシンタックスハイライトは直ったみたい。
やっぱり悪いのは忍者ブログだった！
直ったからブログの移行はまぁいいやとしても良いのだが、前述の通り面白そうなのを見つけて結構時間をかけているから移行はする。
色々考えた結果デザインが1から自分でになったのがつらすぎる。
こっちも年内目標。

順位: 785

パフォーマンス: 1446

新レーティング: 1050

差分: +73

4完
ご飯を食べながらちょっとゆっくり参加。
Cが難しいというかややこしかった。
Eは途中で頭おかしくならなかったらかなりワンチャンあった。

かんたん。
bustってブラックジャックで普通に使うのかな？

反転した文字列用意したら分かりやすくなるというテクニック。
別にいらなかったね・・・。

ややこC。
制約がbit全探索だけど貪欲的にも解けそう・・・？
でもbit全探索の方が確実だからそっちで。
C問題でbit全探索なんか使うか？とかなり訝しんだが、bit全探索なら解けるという絶対的な自信があった。
Cにしては相当に実装が重かったのも訝しみポイント。
直近で解いたABC112 C Pyramidを思い出した。

正直者を決めた場合、正直者が正直者と示した人のみを確認すれば良いと思ったのだが、サンプルが合わない。
そうじゃなくて、正直者が正直者と示した人がさらに正直者を示して、と繰り返す必要があった。
それを実装しようとしてキューに正直者入れるかと考えたところでbit全探索じゃなくなった。
bitが指し示す正直者を使おうということでbit全探索に戻ってきた。危ない危ない。

この実装でミスしてしまったのが、bitが立っているかどうかと正直者かどうかの一致判定。
普段bitのi桁目のビットが立っているかどうかを調べる際、if(bit & (1 << i桁目))と書くのだが、これはifの条件式が0以外をtrue(=1)にキャストすることを踏まえており、i桁目のビットが立っていた場合に取り出される値は(1 << i桁目)である。
これをそのままif(0or1 == (bit & (1 << i桁目)))としてしまったため、1桁目のビットが立っていても(1 == 2)の比較が行われてfalseになってしまう。
1にキャストされるから普段の書き方で良いというのは間違いなく頭に入っていたのだが、ふとしたところでミスる。
これからはif((bit >> i桁目) & 1)の書き方に統一します・・・。

もう1つ書きたいことが、ビットの数え方のお話。
実は競プロをやってみようかなと思い立ったきっかけがビット関連の演算。
ビットを立てたり消したりMSBとか立っているビットの数え方とかすごい鮮やかだなぁと。
別に競プロでしかビット使わないわけではないが、意識するのは組み込み系か競プロだろう。
立っているビットを数える関数は2年くらい前に作っていて、たぶんそれ以来初めて使った。
分割統治でO(log64)なのでほぼO(1)の実装。
他のビットを数える系も大体分割統治でO(log64)でできるのだが、LSBはde bruijn sequenceとかいう闇の数字を使って真にO(1)で計算できることを最近知った。
O(N)のRMQに使っている。
立っているビットを数えるのも真にO(1)でできたら良いなぁ。

ここまで50分。
相当きついと思いながらのD。
C解いてる途中に質問タブが(1)となっているのに気づき、見てみると「Xor Sum 4」の文字が。
EかFかなーうわー・・・、と思っていたのにD問題開いたらまさかの。

見た感じ桁毎に分けられそうだしXor Sumだし、ということで桁ごとに分けて考える。
どのAiも使われるのはN-1個なので、Aiを固定した際の合計を計算できれば良し。
Aiのd桁目が1なら他のAi以外のd桁目が0のときにその桁が1、逆も然りと、普通にカウントしたら良いのでは？
Xor Sumにしては簡単だけどなぁと思いながら実装するも普通にサンプル通ってAC。
Cの遅れを少し取り戻せた。

ここまで63分。
単純そうで難しそうだという第一印象。
色々考察して、80×80のサイズと、ABも80までなのでその差も80までというのが鍵っぽい。
差が80以内を使うということは、差の合計を0にするように足していく場合、差の合計の最大値は80×2くらいまでに収まることが保証できたりする？
とりあえずDP使って解けそうだなぁ。

ここまでかなり良い感じの考察だったのに、ここで頭がおかしくなる。
こういう右か上かしか行けないABC145 D Knightでやったなぁ。
確か全通りは、と思い出すより早いと解説PDFを見に行く。
[右と上を選ぶ回数の合計]C[右を選ぶ回数]の簡単な組み合わせだ！
つまり160C80 = 160*159/2 = 12720だ！

？
ちょっと頭に思い浮かべたのが3×3のマスで4C2 = 4*3/(1*2)となり、なぜかそのノリのまま計算してしまった。
そこから全通り調べて最小値調べれば良いかなぁと。
この時点で頭おかしくなってるので次もおかしい。
最大80だし(?)、通った|Ai-Bi|を大きい順にソートして、合計が正ならマイナス、負ならプラスで合計して行けば必ず最小値になるのでは！？
そんなわけない、貴様ナップサック問題知らずか。
で実装して間に合わなくて、コンテスト終了20分後くらいにそのままの方針でTLE出して終わり。
5,5,4,3,3とかの場合、5+5-4-4-3=0にできるが、上から順にプラスマイナスの方針だと5-5+4-3-3=-2になってしまう。
ということで色々だめ。

良さそうな解法は、最初の考察を進めて、差は80以内になるなら全部プラスで計算しても80*160=12800になるので、DP[x座標][y座標][現在までで作れる合計値]でDPしていく。
80*80*12800=81920000 < 10^8でたぶん間に合う。
あんまり解説読んでないけどたぶんこれで行けると思うので、後で改めて解いてみる。
実際全部プラスなんてことはないので、間に合わなければ少し節約できそうか？

Eと一緒に問題を眺めて、シンプルな問題で解けそうな解け無さそうなわからなかったので、順位表見たら圧倒的に難しそうだったのでパス。
シンプルな問題は簡単かやべーか二択だな。

まとめ

Cで時間溶かしたのは反省だが、間違いなく今回のCは難しかった。
Eは解けても良かった。
今までの解けても良かったよりかなり強めの解けても良かった。
全通り調べても良いなんて意味分からないことを考えなければ、次に進めるのは最初の考察の続きなので、80*160しても制限に収まると気づく可能性は十分あっただろう。

レートは順調に伸びてるものの、次も4完なら水色は厳しそう。
年内はAGCが1回予定としてあるが、ABCはもうないのかな。
AGCも参加する予定だが、できれば後1回ABCで余裕持たせてほしい。