/ 最近 .rdf 追記 設定 本棚

脳log[2023-09-23~]



2023年09月23日 (土) [AtCoder] 今日はサントリープログラミングコンテスト2023(AtCoder Beginner Contest 321) があった。コンテスト成績証自分のすべての提出。ABCDE の5完遅解き。今回のネックは C 問題と E 問題だった。それぞれ 21 分と 56 分(+ペナ5分)かけている。これは考えていた時間ではない。ひたすらに実装が下手だった。脳内イメージをコードにするプロセスがバグっている。ではふりかえり。■A 問題「321-like Checker」。はい。■B 問題「Cutoff」。制約が 100 以下とささやかなので素直に愚直解を書く。■C 問題「321-like Searcher」。K に1以上以外の制約がないことの意味をしばらく掴みかねた。だから文字列で答えを構築する必要があるのかなとか考えていた。そうとしても読み込む前に K が 64 ビット整数だとは知らせてほしい。なぜなのか。問題の不備なのか。最大の 321-like Number が 9876543210 だというだけのこと。全列挙すればいい。その列挙に 21 分かける自分のおつむに絶望するんですよ。言い訳をするなら、0 と空文字列が現れないようにきれいに列挙することができなかったという事情がある。無視すればいいだけなんだけどね。他所で読んだんだけど、321-like Number とは "9876543210" の部分文字列のことだった。そう捉えられたらもっとスムーズにコード化できただろうなあ。2の 10 乗通りの部分文字列に 0 と空文字列が現れるのも自然なことだとすぐわかる。■D 問題「Set Menu」。考える要素はどこにもない。ソートして P 以上になるペアを弾いて、残っているものの総和と P をいくつか足す。……という処理を一方の数列の各要素ごとに他方の数列に対して行う。両方の数列をソートしておくなら二分探索はいらない。AC まで4分。■E 問題「Complete Binary Tree」。セグメント木をイメージすればいい。ただし要素数が2べきに揃えられてはいない。K の上限が N-1 になってるけど、実際にありうる上限はセグメント木の高さ×2 なので 2log(N)≦2log(10**18)<120。10 万あるテストケースごとに K を変化させながら木を辿って構わない。あるノード k があるとき、これの d 階層下のノードは 2**d*k 以上 2**d*(k+1) 未満の番号を持っている。N と比較すればいくつのノードが該当するかは簡単に数えられる(はずだった)。与えられた X から根までさかのぼりながら、直前までいたノードと逆のノードの下にいくつ当てはまるノードがあるかを数えていく。根に辿りつくまでのあいだに K がゼロになったらそのノード自身をひとつ数えて終わりにする。やりたいことは最初から明確で大枠はすぐにできあがったけど、細部がひたすらバグっていた。最後まで残っていたバグは、「(根までさかのぼりながら、)直前までいたノードと逆のノードの下にいくつ当てはまるノードがあるかを数えていく」処理における「逆のノード」。直前までいたノードが N 以下なのはたしかだけど、逆のノードは必ずしもそうではない。d 階層下にばかり気を取られていて完全に盲点でチェックが漏れていた。ここでの教訓は「ステップも場合分けもまとめられるものはまとめた方が良い。式が3つあればバグは3か所に潜むし、場合分けにより実行パスがテストケースごとに分かれてしまうと、実行されないパスのデバッグ機会が限られてしまう」。d 階層下の処理とゼロ階層下の処理を分けたのが良くなかった。自分で書いたことなので当然わかってるんだけど、コンテスト中は時間に追われるからきれいに完璧に書くことの優先度が下がってしまう。それで AC が遠のいてたら本末転倒急がば回れなんだけど。■F 問題「#(subset sum = K) with Add and Erase」。残りのわずかな時間で考えていた。最初は O(N^2) だと勘違いして愚直に DP をするものを書いた。TLE だった。そうすると DP 配列を使いまわして巻き戻しをする必要があるなと、消去法のように考えた。でもそんなんやったことないし、できるかも知らない。残り1、2分くらいで書き直したものは引き算し過ぎでマイナスの数字(modulo に近い数ということ)が出ていた。


2023年09月21日 (木) [AtCoder] 精進。日曜日に ARC165 があったが不参加だった。調べれば前回の ARC164 からふた月以上ご無沙汰で、参加しないことに後ろめたさを感じなかったのと、レート収支が常に負の ARC にレートを捧げる心構えができていなかったのが理由。■A 問題「Sum equals LCM」。答えが存在しないケースはどういうケースか。和で N を作るのは簡単で、N を LCM を維持したまま分割したときに和が N 以下にできたら、あとは +1+1+1+1+... して N が作れる。問題は LCM を維持したまま N を分割してその和を N 以下にできるかどうか。素数の掛け算で作られる数より和で作られる数の方が明らかに小さいので、とにかく分割すればいい。ただし、ある素因数 P を複数の数に分散させても LCM には寄与しないくせに項を大きくしてしまう。というわけで、N を素数の累乗ごとに分割するのが和を最小にする。それが N 以下なら答えは Yes。だけど例外があって、「2 個以上の (相異なるとは限らない) 正整数」の和で N を作らなければいけないので、素因数が1種類しかないときには1の項を付け加える必要がある。■提出 #45760781 (AC / 150 Byte / 114 ms)。Ruby によるすべての提出を見ると不自然に1秒以上かかっている提出が複数あって、これなんでなんだろうね「AtCoderの新ジャッジ、Rubyの一部提出がメチャ遅い実行時間になっているのだけど require 'prime' があると遅くなるみたいだなー」。■B 問題「Sliding Window Sort 2」。操作について気がつくこと。辞書順最大の数列が欲しいのに、範囲を昇順にソートする操作というのは得をすることがない。良くて範囲内がすでにソート済みだった場合の現状維持。N も K も制約上限が 20 万なので、範囲に対して愚直に線形時間でソート済みかどうか確かめて O(N^2) にしてはいけない。問題名に sliding とか window とか見えるからスライド最小値を使うことを考えた。つまり、ある要素がその要素から始まる K 個の区間の最小値であるとき、その区間は少なくとも操作の候補ではある。操作をしても先頭の要素が置き換えられることがないので、その1点では損をすることがないから。ところが話はもっと簡単で、ソート済みの区間が見つからないときはできるだけ後ろの方で操作をすればいいんだよね(本当に?)。■提出 #45778696 (WA×2)。ソート済みの区間は累積和で探した。サンプルの3によれば必ずしも一番後ろで操作するのが最善ではないとわかるので、直前の項を調べて操作区間をちょっとずつ前にずらすことにした。そうしたらみごとに after_contest に殺された。■提出 #45780788 (AC / 476 Byte / 164 ms)。説明が難しいな。ソート済みの範囲が見つからないとき末尾 K 個を操作の候補にする。だけど、新しく繰り入れる部分が操作による影響を受けない場合に限り範囲を少し前にずらすことができる。またそうすることで範囲から外れる部分を操作の影響から外すことができる。ずらす幅は最大で K-1 個分(※ K 個ずらして問題がないならソート済みの区間を見逃してたってことだ)。繰り入れる部分が広義単調増加(ソート済み)の場合に限る。また、最初に候補とした末尾 K 個のうちまだ範囲内に残っているものの最小値が新たに繰り入れた範囲に(操作によって)漏れ出してこない場合に限る(※この条件が抜けていたのが after_contest にやられた理由)。自分で解かないと何言ってるかわからんよ。結局この部分にスライド最小値を使うことになった。セグメント木でもいいと思う。これが B 問題で水 diff ってマジなのですか。でもまあ、A 問題で水 diff だった Reverse and Count を思い起こさせる問題ではあったかな。そっちの方がひどいね。■計算量のことを考えないなら、操作区間の先頭と、操作により最初に置き換えが起こる位置のペアを考える。置き換えが起こる位置が最も後ろのもので、区間の先頭が最も前のものが答えだと思う。結局のところ、計算量を改善するアルゴリズムを組み立てる問題だった。ケチなことを考えると色々ミスが出るのはしかたないね。


2023年09月16日 (土) [AtCoder] 今日はトヨタ自動車プログラミングコンテスト2023#5(AtCoder Beginner Contest 320)があった。コンテスト成績証自分のすべての提出。ABCDE の5完遅解き水パフォは軽傷だけど先週(20230909)に続いてなのであまりへーきではない。すべては C 問題のせい。では E までのふりかえりを。■A 問題「Leyland Number」。計算するだけ。■B 問題「Longest Palindrome」。制約上限が小さいので候補となる文字列を実際にひっくり返して比較して大丈夫。文字列比較で楽をしつつちょっとだけケチなことを考えるなら、文字列は全体を1回だけひっくり返して、あとは比較範囲を適切に変換すればいい。■C 問題「Slot Strategy 2 (Easy)」。E までで最も難しかった問題。これに 50 分費やしたのが今日の負けを決めた。答えがあるなら3周期のうちに見つかる。制約が小さいので総当たりで大丈夫。だけど判定が書けなかった。まずどの数字を揃えるかを決めて、文字列を前から見ていって、どのタイミングで揃ったのか、判断する条件が書けなかった。泣きそうになりながらネストした if 式(全部で9分岐)を書いた>提出 #45624994 (AC / 868 Byte)。他の人の提出を見るとリールを止める順番(6通り)を総当たりしていた。あ、そう、なるほどね>提出 #45651218 (AC / 172 Byte)。■D 問題「Relative Position」。BFS。■E 問題「Somen Nagashi」。1番の人から食べられるそうめんを全部食べさせていった。N 番目の人は他の N-1 人の食べ漏らししか食べるチャンスがない。残っているそうめんの管理は SortedSet を使うのが素直だけど Ruby にはないのでおなじみ BIT で代用した。終了後に Ruby の他の AC 提出を7、8個見たけどどれもプライオリティキューを使っていた。どういう方針なんだろう。時間軸に沿ってシミュレーションしているのだろうか。キューには何を入れる? あとで考える。■F 問題「Fuel Round Trip」。残り 20 分で考えていた。DP だろうなと。だけど、往路でどのガソリンスタンドで給油したかを状態に含めて区別してしまうと、それはただの総当たりになってしまう。制約を見る。ガソリンスタンドの数(N-1)とガソリンタンクの容量(H)がどちらも 300 以下に抑えられている。ガソリンの量が状態空間の軸の1つなのは間違いなさそう。ところで、ガソリンスタンドに注目したときの選択肢は、往路で給油する、復路で給油する、給油しないの3択。往路と復路の DP を同時に進めて3方向に遷移するとすると、状態がガソリンの量(H)の2乗になるけど、全体で NHH≦(300 の3乗)はありえる数字。ただし Ruby にとっては想定解が TLE になるボーダーラインがちょうどここらへんにある。■提出 #45651923 (TLE×15 / AC×22)。Cyberpunk 2077 で遊んだあと寝る前に 35 分かけて書いて、とりあえず WA は出なかった。■提出 #45653214 (TLE×5)。じっくり入念に書き直して TLE は 15 から5まで減った。なぜまだ寝ていない。5つのうち3つは超過時間が 200 ms 以下だとわかるような打ち切り時間になっている。だけどもう無理よ。■E 問題。PQ 解法。たぶん、(復帰タイミング, 復帰者) ペアのキューと、そうめん待機者のキューの2本を持つんだな。できそう。……。できた>提出 #45664340 (AC / 1273 Byte / 805 ms)。■F 問題。提出 #45663250 (AC / 1379 Byte / 94 ms)。かつて C++ は甘えと書いたものだけど、C++ なら素直に書くだけのものを Ruby であれやこれや複雑怪奇にこねくり回すのは不毛に思えてきた。そんな Ruby スクリプトは書きたくないし、シンプルでも読みやすくもないし。というわけでこれは C++ での AC。最初に TLE になった素直なバージョンを C++ に翻訳したもの。unsigned int 型が使える C++ だと、初期値としてのテキトーに大きな値と、答えがないことを表す特別な出力(-1)に共通の値が使えるんだよね。というわけで -1 を乱用してみた。■■■F 問題。提出 #45760450 (AC / 734 Byte / 1970 ms)。すでに Ruby で AC を出していた kuma_rb さんの提出 #45673011 (1885 ms) と見比べて1つ1つ修正して違いを確かめた。ローカルとジャッジサーバーとでは傾向も Fixnum のビット幅も違うのでコードテストを使って。まず DP 配列を1次元化したのが良くなかった。そのせいで添字の加工が必要になっている。高々 300 個の Array オブジェクトなど作ってしまえばいい。そして配列参照の中間結果を変数にキャッシュすればいい。2つ目はループメソッド。自分は配列参照だとか添字にオフセットを加えたりだとかの明示的な添字の操作が嫌いで Array#each_with_index や Enumerable#with_index を積極的に使うんだけど、これを Integer#upto メソッドを使った添字のループに書き換えたら 200 から 300 ms ほど早くなった。嫌だなあ。TLE を回避するためにちまちまちまちま添字の操作をしたくないなあ。だって ABC の B 問題であっても「4×4×2=32 マスの黒白を愚直に確かめるだけ。そんなんでも添字の範囲を間違えたりしてたいへん」なんだから。


2023年09月09日 (土) [AtCoder] 今日は ABC319 があった。コンテスト成績証自分のすべての提出。ABCE の4完だけど水パフォで軽傷だからへーきへーき。以下 E までの精進とふりかえり。■A 問題「Legendary Players」。えっと、冠の説明いりませんよね。知らなかったので役に立つ情報ではあったけど、余計な時間を使ったぜ。前にも書いたけど(20230729)、これはコピペ活用術が問われている。ヒアドキュメントで埋め込んで行単位でスプリットしてできた2要素配列の配列を to_h した(後知恵だけど、フラットな偶数要素の配列を Hash.[] メソッドの引数リストに展開して呼び出してもよかった)。残念なのは丁寧に整形した人よりも提出が遅かったところ。■B 問題「Measure」。読んでも理解できないので書いてある通りに実装した。ささやかな工夫は N の約数 j をループの外側で列挙したこと。■C 問題「False Hope」。正解者数が D 問題より少ないみたい。制約付きの順列数え上げなんだけど、全列挙して許されるサイズなので考える前に全列挙した。制約は多くても8個で、ある列にある数字が重複ありで AAB の2種3個のとき、A→A→B という風に同じ数2つを最初に出してリーチを演出すると高橋くんをがっかりさせてしまう。そういうケースを除外した。■D 問題「Minimum Width」。解けなかった。二分探索なのはわかる。その中で累積和を二分探索したのが良くなかった。累積和を前から順番に調べることで log を落とすことができる。これは Pairs の教訓(20230725)。しかし生かされなかった。そして実は累積和いらなかった。余計なことして無駄な時間を使って TLE を出したのみならず AC を逃した。つらい。■E 問題「Bus Stops」。Ruby で時間内に通せたのは1人だけ。それは自分ではない。クエリに対して線形時間ないしは対数時間で答えが出せないといけないがどうするか。X+Y+T.sum は必ずかかる固定の時間。停留所で生じる待機時間をどうやってすばやく数えるか。太字でこれみよがしに書かれている「ここで、1≤Pi​≤8 が制約として保証されます」がどう活用できるのか。最初は8×8の 64 通りに qi+X を分類して答えを求めておけばいいかと思った。でも足りなかった。1から8までの LCM である 840 通りであれば足りた。だけど 840×N≦8400万は Ruby にはつらい数字。D 問題に続いて E 問題まで答えは出せても TLE というのは残念すぎるので、先日の精進(20230831)にならって C++ で提出したら 624 ms で AC だった。制限時間は3秒。Ruby でも2秒を切れるみたいだけど、どんな考察が求められているのかまだわからない。■F 問題「Fighter Takahashi」。薬を飲む順番を総当たりして許される制約。敵はポーションのまわりに集約できる。ポーションは直列と並列に並べられる。あとは効率良く総当たりしたいけど、うまく書けなかった。DFS でやるんかな。■■■F 問題。すでに飲んだ薬の集合をキーとして、倒せる敵をすべて倒したときの強さの最大値を記録したものを状態とする。次に飲む薬を選び、倒せる敵をすべて倒し、記録する。これでいけると思う。DFS だと飲んだ薬の集合ではなく薬を飲んだ順番を区別してしまうので、計算量が危険? 10 の階乗はだいたい 370 万やからいけるやろって思ってたんだけど、案外遷移に時間がかかる? つまり、倒せる敵を倒しつくすのに(※薬の倍率が1以上なので薬を飲む前に倒せる敵を倒さない選択肢はありません)。プライオリティキューを使って、敵の数×log(敵の数)<5000。あっ、これはいけない。状態数を 1<<(薬の数) (1024 以下) に抑えてやっとなのだな。■ところで、Ruby ですでに AC になっている提出 #45433698 を答え合わせに使ってデバッグをしていたのだけど、こういう No ケース (4つの頂点が1列に並んでいて、1の直接の子が強さ9の敵) に Yes が返ってきて困ってしまった。答えが2択だとこういうこともあるかな。こちらは大丈夫みたい>#45434962 (require があって実行がやや面倒)。■提出 #45461169 (AC / 1755 Byte / 94 ms)。通った! こんなに不安だった提出はそうそうない。Octopus (20230902) とか? 提出をためらっているあいだに変数にコメントをつけたりなんかして。しかも2桁 ms なのが嬉しい。1.7 KB も文字を打った甲斐がある。ちなみにプライオリティキューは使ってないよ。敵は木構造を持って整列しているので線形時間のマージ操作を書いた。敵を倒すときも線形時間で走査する。これは5問目の橙 diff AC。ABC の高難度評価は当てにならないらしいけど、相対的に十分難しいのはたしか。


2023年09月04日 (月) 【悲報】妻「7万円の脱毛器買った」夫「どんな仕組みなの?」妻「ギャオオオオン!!」 → 叩きつけてフローリングと脱毛器を破壊 : 暇人\(^o^)/速報 - ライブドアブログ」「この怪談、38年生きてきた中で一番怖い。 - Togetter」■おもしろかった。ちゃんと的確なリプライがついてるし、そういう読み方をさせられるもともとの「怪談」がよく書けている。何がハラスメントかって、夫は購入に「OK を出す」立場で、7万円を「返せ」と請求できる立場で、「社会で頑張って稼ぐ男性」という立場であるということに疑いを持っていないあたり。最後にいたって全女性に喧嘩を売ってるんだからわかりやすすぎる。そういう人間がどういう仕組みで効果があるのか質問することの意味。それは実質的に審査(の続き)であるし、夫が疑っておらずしたがって妻が受け入れているらしい上下関係からくる圧で説明を回避することもままならなかったのでは。いやべつにおもしろい話ではなかったな。こうして書いていてフラストレーションがたまってきた。この「怪談」にはカタルシスが欠けている。釣り針だけで釣り宣言がない。


2023年09月02日 (土) [AtCoder] 今日は THIRD プログラミングコンテスト 2023 アルゴ(AtCoder Beginner Contest 318)があった。トップページの煌めく Kaggle Grandmaster の文字がおしゃれですね。CSS Animation で2秒のうち一瞬だけ可視不可視を切り替えてるっぽい? そういうの初めて見た。あ、任意色も任意の色をまとってアピールしてる! コンテスト成績証自分のすべての提出。ABCDE の5完は前回と同じ。同じなんだけど、前回は早解き失敗でまさかの緑パフォだったのに、今回は早解き成功で青パフォ。何この天国と地獄。あと1問解ければ解決だね(できるならね)。以下 ABCDE のふりかえりと F の精進について。■A 問題「Full Moon」。制約を見てだめな気がしたから計算で解いたけど、全探索することもできた。でもミスが怖いという点では大差ないかも。A 問題の提出にドキドキはいらないんで、もうすこし容赦してほしい。■B 問題「Overlapping sheets」。Tangency of Cuboids を覚えていますか? 私は覚えています。でもあちらは E 問題 (黄 diff) でこちらは B 問題。もうすこし容赦してください。でも今日のは灰 diff だなあ。3次元と2次元という以上の落差が謎。■C 問題「Blue Spring」。ふりかえり中に気がついたけど、アオハル=18切符ってことね。ソートして高額区間を優先して貪欲にシミュレートした。■D 問題「General Weighted Max Matching」。つい最近 ABC313-B「Who is Saikyo?」と ABC317-C「Remembering the Days」で制約が小さいからと雑に DFS を書いて TLE を出したことを覚えています。雑に書いた DFS の計算量には階乗がでてくるみたい? AC 解答も順列の全探索だったから階乗でいけないことはないと思うんだけど、Ruby では書き方によりダメということか。今日はきっちりメモ化再帰を書きました。D 問題ならそれくらいはね。■E 問題「Sandwiches」。同じ数ごとに添字を集めて昇順または降順で添字の和と添字の個数をメモしながら数えた。添字の和と個数がわかれば作れるサンドイッチの数がわかるし、添字の個数がわかれば除外すべきサンドイッチの数がわかる。■時間内に解けたのはここまで。それぞれの問題に費やした時間が A=3分、B=4分、C=7分半、D=6分半、E=10分。■F 問題「Octopus」。解答の方針は立ったけど1時間以上あっても解けなかった。このややこしい問題が時間内に解ける未来が見えない。方針はこう。X 座標の左端からスタートして右に向かって移動するタイムラインを再生する。時刻の幅が広いので局面が変化するタイミングで刻んでお宝をつかんでいる時間を数える。局面の変化っていうのは距離で並べたお宝が入れ替わること。つまりお宝の順番を固定して考えられるように時間を刻んだということ。お宝の並びが決まれば対応する腕の長さが決まり、お宝をつかんでいられるたったひとつの区間が求まる。それら N 個の区間と現在の時間の区切りの共通部分を答えに計上する。サンプルの2が親切だけど、タイムラインのスタート地点はよく考えよう。X.zip(L).map{|x,l| x-l }.min が十分。Ruby だから関係ないんだけど、制約が 61 ビット使うといっているので 10 倍 100 倍してテキトーに小さい数を初期値にすることをためらってしまった。それが WA の理由のひとつ。もうひとつが等距離にあるが右にあって近づいてくるお宝と左にあって遠ざかっていくお宝の扱い。近づいてくる方を短い触手に割り当てる方がお宝がつかめる可能性を高める。いやいやいやそんなんわかりませんて。ランダム入力を何十回試してもそれによる不一致は出てこないんだよ。まあ、無限ループなのでいずれ見つかるんだけど。■今日の日記にここまででタコの腕とタコの触手が出現しているけど、問題文ではタコの足になっている。実際のところタコのあれはなんなんだろう。「タコの足の本数は何本?タコの足の数はなぜ8本なの?腕が再生して96本! | BIJOH [ビジョー]」を読むと腕と足は間違いではないが触手には言及がない。触手について「無脊椎動物の体の前端や口の周辺にある糸状またはひも状の突起。先端に多くの感覚細胞が分布し、触覚や捕食の働きをする」と明鏡国語辞典に書いてあるのを読めば当てはまるような気がするが、違うと言われれば糸でもひもでもないからかなあとも思う。でもそんくらいしか違わないよね。ナチュラルに触手ってワードが出てくると、すわエロアニメによる刷り込みかという警戒心が働くのだけど、別に不自然な言葉選びではなかったのではないか。でもそれをここにこうして書くのはダメだと思う。


2023年09月01日 (金) [AtCoder] 精進。ABC131-F「Must Be Rectangular!」(青 diff)。最初のステップは誤読への気付き。どういうわけか角が1つ欠けた四角形があるときに「3点を消して」欠けた一角に点を打つのが操作だと勘違いしていた。そうするとグラフ構造が生じる。ある1点がどの4つの四角形に属すると考えて操作するかによってその後の操作回数が変わってくる。今日また問題を読んでみたら点を消すとかどこにも書いてなかった。次の1手は X 座標でも Y 座標でもいいからソートして順番に処理してみること。処理に方向性を与えることで考えるべき次元が下げられる。たとえば X 座標でソートして昇順に処理すると決めると、現在の Y 座標グループ(同じ X 座標を持っている)とすでに処理した Y 座標グループの関係を考えるだけで良くなる。そのようにお膳立てして考えてみて気が付いたことは、2つの Y 座標グループのあいだで操作を行うために必要なことは、2つのグループが同じ Y 座標に点を持つことだとわかった。それだけなんだ。2つの X 座標(x0,x1)と1つの Y 座標(y0)があって2つの XY 座標((x0,y0),(x1,y0))に点があるとき、(x0,y) に点があるなら (x1,y) に点が打てるし、(x1,y) に点があるなら (x0,y) に点が打てる。そうしてすべての操作が完了したとき2つの Y 座標グループは全く同じになる。2つのグループをマージしたのと同じ状態になる。ここまでわかればあとは UnionFind が火を吹いて終わり。■提出 #45108485 (AC / 668 Byte / 341 ms)。点を Y 座標で括って X 座標をグループ化する。点を X 座標で括って X 座標が属するグループに点を打っていく。あるべき点の数から実際にある点の数(全部で N 個)を引いて答え。■UnionFind を使うにしても二部グラフが見えてる人と見えてない人(私です)がいるみたい。UnionFind を使わない提出 #6097246 もあった。


2023年08月31日 (木) [AtCoder] 精進。ABC191-F「GCD or MIN」(黄 diff)。最初のとっかかりとしてまず gcd を無視して min を考えた。min だけのとき最後に残るのは A 数列の中の最小値。ここに gcd がどう関わってくるか。gcd(a,b) は必ず min(a,b) 以下の数になる。そして最小値は最後まで残すことができる。まとめると……。A 数列の最小値を M とする。M は最後まで残すことができる数のひとつであり、その中では最大のもの。gcd(A[a], A[b], A[c],...) によって作ることができる M 以下の数はすべて最後まで残すことができる。その種類数が答え。■提出 #45084618 (AC / 725 Byte / 1974 ms / 5332 KB)。DP をした。それも頭の良くない DP を。まず A[0] を配列の先頭に配置し、以降 A[1] から A[N-1] について、配列の全要素とのあいだで gcd を計算してそれら gcd と A[i] そのものを配列に追加した。重複がないとすると伸びていく配列のサイズは 0,1,3,7,15,...,2^N-1 という感じで成長していって、N≦2000 だから2の 2000 乗はやばいんだけど、実際は gcd が1になったり重複したりすることが多いのでそれなりに大丈夫。でも Ruby では4から5秒かかって大丈夫ではなかったので C++ の犯罪力に頼りました。実は C++ であっても2秒を数百 ms オーバーしてしまったので、GCC ではなく Clang を選んだり、set ではなく unordered_set を使ったり、2つ使っていた unordered_set を1つに減らしたり、初期にあまり配列を伸ばさないで済むように A 数列をシャッフルしてみたりした(※逆にソートすると悪化した)。それでも2秒を 50 ms ほどオーバーしてしまったのだけど、unordered_set に大きめの初期サイズを与えると 100 ms 弱縮んでようやく AC の目途が立った。Ruby で通してる人は素因数分解をしたりしてるんだろうか。Ruby でも3桁 ms で AC がとれるらしいんだよね。自分にはわからんけども。■ブログを2つほど読んだ。約数を列挙してそれが GCD になりうるかどうかを調べるといいらしい? さっき書いた素因数分解~云々がそうなんだけど、素因数の指数部分を減らしてみて、共通部分を持つ他の要素を(1つ以上)見つけて、非共通部分の GCD が1になるかどうかで答えの候補になるかどうかがわかる。でも計算量的にそうした方がいいという判断ができなかった。■Ruby で約数を列挙してさっき書いたようにして答えを出してみたら、many_divisors_00.txt というケースが最長で、2秒を 121 ms オーバーした。ましにはなったけどまだ考えが足りないらしい。提出 #45095866 (AC / 628 Byte / 192 ms / 9844 KB)。Ruby では TLE 間違いなしなのでこれも C++ だけど、1974 ms → 192 ms で 10 倍ましにはなってるんだな。このうえさらに Ruby で通すのつらすぎるぜ。■提出 #45096878 (AC / 259 Byte / 1762 ms)。これは Ruby。AC と TLE の分かれ目はまさかの約数列挙ループだった。while b*b<=a; if a%b==0; c = a/b end b+=1 end なら AC で、while b<=c; if a==b*c; end c = a/b+=1 end なら TLE。AC の方では足し算1、掛け算1、剰余演算1が毎回で、約数が見つかったときだけ割り算が1。TLE の方は足し算1、掛け算1、割り算1を毎回やっている。剰余と割り算のコストが同程度なら剰余を求めないで済んでる分得かなと思うんだけど、そういう結果ではない。違うんだ? ループ回数は同じだと思うし、どこで差がついてるのか本当にわからない。■3桁 ms の2つの提出(#20120433, #20414187)を読んだ。約数列挙に工夫があった。最初に素数を列挙している。たしかに1ずつ加算して割り切れるか確かめるより、素数について指数を調べる方が効率が良さそう。


2023年08月30日 (水) 株式会社キョウプロ」 毎週末コンテストを開いているとかいないとか。


2023年08月29日 (火) 犬と散歩するときはルールを守りましょう→この写真がなぜか一万いいねされる「通知欄がスーパー肛門フェスティバルの会場と化してしまったので通知を切ります」 - Togetter」■マナーがルールによって上書き訂正されている看板。いろいろな受け止めができると思う。それはつまり効果的な看板ではないということ。まず文言。マナーがルールになったことで「ルールを守るのは当たり前のことやん、当たり前のことにわざわざ『犬と散歩をするときは』と条件を付けるということは、それ以外ではルールを守らんでいいということか」と勘ぐる余地を生み出してしまっている。ルールではなくマナーだったらぎりぎり不自然ではないかなと思う。■次が本題。この看板が何を訴えているのか、それがわからなくなった。マナーであれば、犬のうんこは持って帰ろうねとか、リードは必ず使いましょうってことかなと想像するけど、ルールとは何か。どこにどういう内容が定められているのか、自分は知らない。ルールを守ろうね、では当たり前すぎて何も伝えていないし、~が決まりですと書くのが効果的だと思う。ルールは知っていて当然(だからあえてここでは書かない)という態度は嫌いだな。もし決まりがないんだったらそれこそ意味不明な看板だけど、実際のところどうなんだろう。もともとマナーに訴えていたんだからなかったと思うんだけど。あるいは飼い主なら当然知っておくべき犬の散歩に適用されるグローバルなルールがありますか。


2023年08月25日 (金) [AtCoder] 「提出結果ページのソースコードが見られない」のつづき。Ace という名前の何かを提出結果ページと提出ページに採用したらしく、機能性を追加しつつ以前のようにコピーボタンや縦スクロールバーのオンオフや行番号表示が機能している。ま、提出ページでは貼り付け&送信しかすることはないけども。コピーボタンは AtCoder 謹製なのかな。必要にして十分ですよ。自分の提出をアップデートしたいときにちょいちょい使ってる。でも今回エディタ部分があまりにきっちりできあがってるので、Ctrl+(A、C) で全選択&コピーもできる。■カーソル行強調と対括弧強調がうるさいので消したのだけど、すごく頭の良さそうな(←語彙力)つくりになっていた。ソースコード領域は複数のレイヤーが重ねられていて、テキストレイヤー、マーカーレイヤー、カーソルレイヤーが主だったところ。マーカーレイヤーを非表示にしたらうるさい強調は全部消える。でも範囲選択も消えたので個別に消した。■インデントレベルを示す薄灰色の縦線が目障りだなと思ってこれも消そうとして気がついたんだけど、折りたたみ機能があるんね。でも Ruby の場合、縦線で結ばれていても折りたたみできないことがある。この提出(#38427641)の 17 行目の左シフト << をおそらくヒアドキュメントの開始と勘違いしているせいで、lb メソッドと BIT クラスが折りたたみできなくなっている。直前に数値(1)があることは認識できてるんだから、ビットシフトと解釈するのが自然だと思うんだけどな。数値と文字列をそのまま並べるような文法はないのだから。■インスタンス変数 @aace_variable ace_instance とクラス分けしているあたり、完璧ではないけど Ruby のことを知ってそうな雰囲気はある。■レイヤー分けの弱点がこういうところに現れたのだろうか。「AtCoder の新エディタに使われている Ace、多バイト文字の扱いがたまに怪しいので、 「※」などの全角記号を使うとカーソルの位置がズレる (※は「なでしこ」の行コメントの1つ、「プロデル」のプリプロセッサとして使われている) https://t.co/YwDlWqNNjf」。ひらがなとか漢字を使ったくらいでは問題ないので、あまり気にすることはないかな。それを確かめるためにさっきリンクした(日本語変数を使っている)提出をいろいろ調べていた。■もう昨日だけどこんなんがあったらしい。「新エディタテストコンテス」。A 問題難しくない? 前回の ABC-G に似た雰囲気を感じる。


2023年08月24日 (木) [AtCoder] 精進。ABC158-F「Removing Robots」(黄 diff)。この問題が黄色になってるのは、前に置かれていた E 問題の diff がやや下の青色だからという理由が大きいと思う。普通に一直線の DP だった。■提出 #44882536 (AC / 216 Byte / 408 ms)。ロボットを X でソートして順番に場合の数(起動した場合1 + 起動しなかった場合1 = 2)を記録する。そのとき、移動範囲内にあるロボットの場合の数を、起動した場合の数に併合しておく(掛け算)。最後に残るのは連結成分ごとの場合の数なので、掛けて答え。■えっと、併合するのは起動しなかった場合であって、常に1だけ加算して記録するのが起動した場合の数なのでは? どちらの初期値も1だから答えは合うけども、試行錯誤しているうちに理解がねじれていた。


2023年08月23日 (水) おしっこ(真面目な話)」■この話題は、なんでダメだ我慢しろという意見が主流になるのかわからない。出せばいいよ。別に汚くはないし、汚いというなら体の表面からはがれ落ちるものも同じくらいに汚いよ。お風呂はそういう場所でしょ。どちらかというと液体の方が面倒がないよ。もちろん他人がいないという前提での話。人前ではふるまいを考えよう。■増田は条件付けされると似た条件の他所でも漏らすからやばいと感じている。でもお風呂で感じる尿意は条件反射というよりは排尿反射の一部なのではないかと疑ってる。一度出始めたおしっこが途中で止められないように、水(お湯)による尿道への物理的刺激が尿意を誘発しているのではないかと。尿道炎になりかねない(と警告されそうな)のでおすすめしないけど、シャワーの水を注ぎ込んでみればトイレに行った直後でも尿意を引き出すことができる。■規則正しい生活をしていれば毎日寝る前の決まった時刻にトイレに行くことができる。そうしたら寝てるあいだには漏らさないよ。増田は自分で書いているように、自律神経がおかしくなっていたのが主因だったと思うな。■増田の趣旨からは外れるけど、お風呂→おしっこの条件が成立することは、お風呂入ろうかな→おしっこしたいな→先に出しておこうという行動につながるのでいい条件だと思う。■規則の話。自分は起きているあいだはほぼ3時間で1回分のおしっこがチャージされる。だから8時11時14時17時20時(寝る直前までちょっと我慢して)25時の1日6回が基本サイクル。どうでもいい話でしたね。