/ 最近 .rdf 追記 設定 本棚

脳log[2022-10-03~]



2022年10月03日 (月) [AtCoder] 精進1。第11回 PAST-H「2つのナップサック」。ブログを読んでデータの持ち方を教えてもらわないと解けなかった。ほんとうに、ほんのちょっとの応用力もない。■提出 #35384069 (TLE×2 / 2138 ms)。138 ms だけオーバーした。■提出 #35384125 (AC / 1045 ms)。デフォルト値を -1.0/0 から -10**12 に変えただけで劇的に改善した。意味的には無限大にしたいし遅いのを知りつつそう書いてきたんだけど、TLE になるほど遅くなるなら制約の範囲外の整数値を使うしかないなあ。■■■精進2。第11回 PAST-I「お片付け」。これも同ブログでデータの持ち方を教えてもらった。自分で書いた TLE 解では文字列化した盤面全体をキーにしていた。だけど記録すべき特徴というのはすぬけくんの位置と荷物の位置という2つの数値だけなんだな。なんでわからないんだろう。■提出 #35384851 (AC / 1950 ms)。制限時間4秒なのでまあまあ。


2022年10月02日 (日) [AtCoder] 今日は ARC149。B 問題「Two LIS Sum」(緑 diff) のみの1完だったのでそれについて書く。並び順が連動する A、B 2つの順列を好きに並べ替えて A の LIS と B の LIS の長さの和を最大化する問題。最初はソートの問題かなと思った。左下から右上に向かって点(A,B)を並べて、双方にとっていい感じに点を選んでいくのかなと。サンプルが合わせられないので次は DP かなと思った。ある点を選んだとして、次に選んで LIS を増加させられる点は第Ⅰ象限にあたる位置にしかないので。これも実は最初の解法と違いがなくサンプルが合わせられなかったので、次は先に A の LIS を最大化(N に等しい)したあとで B を最大化する方法を考えた。どうやって双方のバランスを取るかを考えているうちに、常にあちらを立てればこちらが立たずが成り立つことに気がついた。つまり、A のソート列を壊して(LIS(A)を1減らして)増やせる B の LIS もまた1が上限なのだから、手を入れる意味がない。A または B をソートした後で他方の LIS をすれば答えが出る。■提出 #35352966 (AC / 180 Byte / 501 ms)。今日はこれで終わり。解説を見たらすること自体は簡単なので、ネタバレ前に通せて良かった。■時間内には解けなかった A 問題についてはね……。XXXXXXX が M の倍数であるとはどういうことか、X、XX、XXX……と累積的に求めていった余りが0になることだ、ということがそもそもわからなかった。余りが0なら倍数だということがわからなかった。わからないはずがないと思うんだけど、M が素数か合成数かでなんか違いがあるのかなーとかぼんやりしたことを考えていた。そういう日もある(そういう日そうでない日の割合、つきつめて、そうでない日の存在については何も述べていない)。


2022年10月01日 (土) [AtCoder] 今日は京セラプログラミングコンテスト2022(AtCoder Beginner Contest 271) があった。結果は ABDE の4完。C 問題「Manga」の WA×1 が謎すぎる>提出 #35280504。解説を読んでも解決しない。他の人の AC 提出とランダム入力を組み合わせて答えを突き合わせても一向に不一致が検出されない。ひょっとして全 X 巻の X+1 巻目を読んだつもりになってやしないかと制約を確かめたりもしたけど、そういう落とし穴はなかった。ほんと謎。まだわからん。■違いが検出されないのは比較してなかったからだった! 直すと比較的簡単に違いが見つかったのだけど、たとえば入力が N=10; A=3,4,4,5,6,7,8,9,9,10 のとき、自分の答えが 7 で、AC 提出の2つが 8 を返している。あー!!! ほとんど同じ構成だけど事前に重複している本を処理していた tinsep19 さんの提出 #35285896 が処方箋だった。最初に見たときは自分も同じことをしてると思ったけど、同じではなかったのだな。■提出 #35324229 (AC / 224 Byte / 228 ms)。すがすがしいほどの完敗だよ。ローカルで小さいケースをいくつも作ってデバッグしていたんだけど(成果なし)、答えを用意する人間が間違っていてはどうにもならない。プログラムは完全に意図通りに動作していたが答えを間違えていた。どうでもいいことだけど提出したスクリプトの変数 read は過去分詞なので【réd】と読みます。どうでもいいね。■勇気づけられるツイート。「アライグマ「ABC271だったのだ! C問題は最初の方の巻から順に「読みたい巻なら読む。もう読んだ巻なら売る。読みたい巻より先なら、一番後ろの巻から2冊売って読みたい巻を買う」を繰り返せばいいのだ!」 フェネック「それだとA=(2,2,3,4)のときにWAだねー」 https://t.co/Jh41vbHFqP https://t.co/MLXPSXt5tm」 ちなみにこれに「じゃあ答えを二分探索するのだ!」というツイートが続く。この流れも想定の範疇にあった。別の解法なら落とし穴を踏まないのではないか二分探索ではどうかと考えていた。でもそういうときに意地になっちゃうんだよね。最初の解法を修正することに拘ってプランBが選べない。そういう性質だと知っているし開き直って受け入れている。■■■精進。今日の ABC271-F「XOR on Grid Path」(ぎりぎり青 diff)。半分全列挙の問題が半分全列挙だと教えられる前に解けたためしがない。強いて言えば制約の数字に特徴が現れるが、手掛かりがなさすぎる。■提出 #35327661 (AC / 477 Byte / 472 ms)。最初から半分全列挙だとわかっていればやることはほとんど愚直解法なので。やっぱり TLE だよね、というのを確認していたものを手直ししただけ。■TLE 回避のために半分全列挙でない問題を半分全列挙みたいに解いたことがあるけど、無駄すぎる>20220726。点数とパフォーマンスにつなげたい。


2022年09月29日 (木) [正規表現] 「正規表現:曖昧なパターンはエンジンによって動作が変わる(教訓) - Qiita」■これは ECMAScript の仕様がタコなんだよね。undefined(マッチなし)と空文字列(ゼロ幅マッチ)を同一視した結果。「@2013-11-09 ECMAScript(3rd&5th ed.)の、Rubyとは異なる、残念正規表現仕様


2022年09月28日 (水) 十三機兵防衛圏クリアした! すっごくえっちだった!■■■わき腹や太ももをひとなでするだけでもケレン味たっぷりでいやらしいのだ。東雲諒子さんが断トツ残念でかわいそうな人。なかなかハッピーエンドが見えないけど郷登クンは無限の愛情をもって保護監視下に置いてほしい。それで十分かはわからないけど、それ以外では想像できない。1985 年というセレクトがずるい。HI-C、ピクニックという小道具がずるい。スケバンのユキは名前がそのまますぎ。ピッタリだけど。年代固定というあたりで時間移動⇔空間移動は予想できる。技術を生み出した未来がすでに遠い過去とはわからなかった。第二世代機を生かすのが難しい。待ち時間が長すぎて敵に近寄れないし攻めるにも守るにも攻撃機会を逸しがち。汎用性があって耐久性が1番だというけど、ダメージを食らうとランクが下がるので耐久性は長所ではないし、汎用性に関しては第一世代が“万能”すぎて霞む。テレポートフィールドとの連携が必須。それでも戦局に置いていかれがち。第四世代は支援に徹すると敵撃破による回復がないために EP が枯渇しがち。そして意外に E.M.P. 兵装を持っていない。戦闘は STRONG でもサクサク S ランクを取って進んでいけるのだけどラストステージの1つ前で S ランクを取るのが難しかった。ターミナルに陣取っていても極太レーザーを食らうのに、いつでもタイミング良くターンが回ってきて回避したりシールドを張ったりできるわけではないので。何回かやって全員2桁ダメージに抑えたときに S ランクを取った。最終ステージが熱かった。だんだん消耗戦の様相を呈してきて、EP が尽きる HP が尽きそう次々回復にまわって戦える機体が減っていく、まだ終わらないのかもう限界だというまさにその時に決着がついた。時間とは違う指標で終了を決めたのかと疑ったレベル。鞍部家のテレビが若干謎の存在だった。インタラクトできるから必ず消していたけど(うるさいいらない騒音源。『家族八景』を読むといいよ。調べたら 1970 年あたりの連載らしい。さらに古いなあ)、なぜ消せるのか、なぜそれで問題ないのか。他に選べなくなるまで鞍部十郎のシナリオをプロローグのまま放置してたんだけど、そのおかげで柴くんの特異さが際立っていた(そういえばこんなキャラいたなあ。でも他の人のシナリオでは見なかったなあ)。果たして……。関ヶ原と冬坂のノーヘル二人乗りに現実感がなくて、検索したら 1985 年にはもうヘルメットの義務化がほぼ完了してたみたいなので、昔はシートベルトいらないヘルメットいらない免許いらないという話ではないと思う。過渡期だったかもしれず実態が必ず規則を反映していたかはわからないけど。過熱状態の説明が作中に一切ないのはどうかと思った(なかったよね?)。


2022年09月26日 (月) [AtCoder] 精進。第11回 PAST 過去問-O「面積クエリ」。最近 2022091020220518 で書いたように外積や複素数が関係する問題 ABC268-F「Best Concatenation」と ABC266-C「Convex Quadrilateral」と ABC251-G「Intersection of Polygons」が続いていたので、することはまあまあわかる。求める面積は外積だし、外積の式を見れば X と Y の2つの累積和があれば点を足し引きすることで増減する面積をまとめて計算できることがわかる。■提出 #35186967 (AC / 933 Byte / 3695 ms)。だからってするすると書けるわけではないけど。点を一列に並べて計算した累積和を点と原点が成す直線のあちら側とこちら側で分けるために(あちらとこちらでは面積の符号が異なるので)、点と点の原点対称の点を使って3つの部分に分けた。■この回の PAST は HIKLMN がまだ解けていなくて受検していたらたぶん初級だった。これまではだいたい中の上にいて上級をうかがっていたつもりなんだけど……。■■■精進。「偏角ソート」で検索して見つけた問題。ABC139-F「Engines」(ぎりぎり黄 diff)。ソートして尺取りか累積和で半円分のベクトルを合成していくのだろうとはすぐわかったんだけど、ときどき微妙に答えが合わなかった。なぜか。半円の角度を入力されたエンジンの1つによって決めてはいけなかったのだと思う。つまり、あるエンジンを1つ選び、それの左右 90 度(あるいは左右どちらかに 180 度でも)に含まれる他のエンジンを合成するという方法では最適解を取りこぼす。合成した結果が右に傾いてるなら左にぎりぎりいっぱいのベクトルを足すのは損になり得る。ってことは半円じゃないのか。■提出 #35208506 (AC / 387 Byte / 61 ms)。N<=100 なので累積和で効率化とか考える必要がなかった。愚直に長さが長くなる限り合成し続けるので十分だった。


2022年09月25日 (日) [AtCoder] 精進。昨日あったトヨタ自動車プログラミングコンテスト2022(AtCoder Beginner Contest 270)-F「Transportation」(青 diff)。すごく正統派の応用問題という感じで、解けて嬉しい。教科書で最小全域木を学んだあとで、さあ解きましょうと与えられるのにふさわしい問題だと思う。■道路と空港と港を使って最小コストで全域をつなぐ。2島間をつなぐ道路だけなら普通に UnionFind でクラスカル法をする。それに加えて、空港を造った島どうし、港を造った島どうしなら互いに行き交いできるとするとどうなるか。■港(空港)の建設コストが特殊なのは2点を結ぶ辺のコストではないというところ。1島だけが港を造ってもどことも繋がらないし、A 島と B 島が港を造って繋がるコストというのは、それだけにとどまらず A 島と C 島、B 島と D 島が港で繋がるためのコストの一部でもある。■原理的には、道路だけを使って最小全域木を構成する各ステップにおいて、各連結成分ごとに港の建設コストが最小の島に代表として港を造らせる、あるいは空港を造らせる、という仮定を置いてコストが計算できれば、道路と港と空港のベストバランスが発見できると思う。これは全探索なので非現実的な時間がかかる。どうにかして道路港空港の各手段を一列に優先順位をつけて並べて後戻りなくコストを調べたい。■頂点の偶奇を区別して同時に扱うために頂点数を倍加して UnionFind をしたりする。「おしゃれ解法@chokudai」の例もある。4つの平行世界を扱うために4倍の頂点を扱うことができる。4つとは、道路だけで繋がる世界、道路と港で繋がる世界、道路と空港で繋がる世界、道路と港と空港で繋がる世界(結果的に同時に扱う必要はなかったので4倍ではなく4回繰り返しただけだった)。港を必ず使う、空港を必ず使うと想定することで、港(空港)の建設コストを辺のコストへと変えられる。どういうことか。さっき書いた原理的な話において、港を使って繋がるとは、連結成分ごとに建設コスト最小の島に代表させて港を造ると書いた。全体を通して建設コストが最小の島は、どの連結成分に属していても必ず港が造られることがわかる(コスト最小が複数ある場合はどれでも1つだけ選んで決めて大丈夫)。1つを除いた他の島における港の建設コストとはコスト最小の島と繋がるための辺のコストと見なすことができる。■頂点4倍はコンテスト中に考えていた。全体で最小の建設コストが必須コストだということは終了後に考えていた。それでも昨日は答えにたどりつけなかった。サンプルの3が合わなかった。どうしてか。道路の建設コストの昇順に UnionFind を行うクラスカル法をベースにしていながら、道路をつなぐと同時に最初に仮に造っておいた港をなしにしてコストを節約するスペシャルな処理をしていた。これはクラスカル法だろうか。辺を処理する順番は島どうしをつなぐ真のコストの昇順になっているだろうか。変なところでオリジナリティを出してアルゴリズムの根幹を歪めては間違える。問題をアルゴリズムにあてはめる思考も必要。■提出 #35161366 (AC / 613 Byte / 1956 ms)。答えにつながる正解の方針がなかなか引けなくて四苦八苦していたのだけど、正解の方針はクラスカル法で決まっていた。珍奇な処理をでっちあげるより既知の処理に落とし込む方法を考えるべきだった。■港でつながる N+1 番目の島、空港でつながる N+2 番目の島を追加する解答を見た>提出 #35151300。スマートだなあ。何度か見聞きしてるけど頂点を追加する解法を自分で考えついて書けたためしがない。■イコール1文字のミスで二分探索を無限ループ化させてしまって TLE に終わった E 問題については書くまい。99% 解けていた問題より F 問題に時間を使う方がおもしろかったんだから。でもあれが通ってたら 50 分(+2ペナ)5完だったのになあ。自分のすべての提出。■■■E 問題。「E二分探索なんて頭いい事しなくても愚直スレスレの掛け算祭りで通るやん。rubyなのに」 二分探索はいらなかったらしい。自分の提出だけど、こっち(#35144735)がソート+累積和+二重二分探索で 151 ms。こっち(#35204328)がソート+線形探索で 138 ms。ソートのウェイトが大きいので大差はないけど、log^2 の有無で 10 ms ほど得をした、という感じ?


2022年09月18日 (日) [AtCoder] 昨日あった UNICORNプログラミングコンテスト2022(AtCoder Beginner Contest 269) のふりかえり(精進でも復習でもなく)。コンテスト成績証 - AtCoder自分のすべての提出。AC までの所要時間は A=1分半、B=4分、C=4分、D=16分、E=19分、F=40分。30分6完なら黄パフォもあったみたいだけど、自分は1時間半かかりました。E は取りかかるまでに数分考えたし、F は考えながら実装して詰まって考えて実装再開してまた詰まって飛ばした E 問題をチラ見してひらめいて完成させるまでに思いのほか時間がかかっていた。■A 問題「Anyway Takahashi」。自分の提出言語で入出力と四則演算ができますかという問題。参加賞。謎の Takahashi 推しだと思ったら(今日になって見た)問題名が自覚的だった。■B 問題「Rectangle Detection」。配列やループが使えますかという問題。どうとでも書くことができてかえって方向性を定めにくいかもね。B 問題を解くのに短く書くとか効率良く解くとかは邪念と変わらない。■C 問題「Submask」。ビット列の部分集合を列挙する問題。昇順で答えるところを見逃してはいけない。何桁目のビットが立っているかを列挙して、0個選ぶ組み合わせ、1個選ぶ組み合わせ、2個選ぶ組み合わせ……を考えるのが正攻法。いや違う。入力に1のビットが k 個あったとして 0 から (2^k)-1 まで繰り返すのが一番しっくりくる。昇順に答えが見つかるので順番に出力していける。この方法はつまり、入力から0のビットを取り除いて1のビットだけで 0/1 の2択を k 個組み合わせ(2^k 通り)、答えるときに取り除いた0のビットを再度補っていると考えられる。ちなみに知っていれば0のビットを取り除いたり補ったりする手間をかけずにそのままビット演算で列挙できる。この場合は降順に答えが得られるので逆順で答える。蟻本と典型90問で取り上げられているので知っている人は知っている。■D 問題「Do use hexagon grid」(茶 diff)。ハニカムグリッド上で UnionFind をやる問題。6個の隣接ノードが問題文に書いてあるので、文字通りにやるだけ。……なんだけど、考える前に手が動く性分なのでノードや辺がうまく見えなくて UnionFind が書けなかった。座標平面を1列に延ばしておよそ4メガの点列を探索した。←の提出は他の提出に比べて桁違いに遅かったので、方針は同じながら効率に配慮したものを再提出した(314 ms → 67 ms)。■F 問題「Numbered Checker」(ぎりぎり青 diff)。だいたいいつも E 問題と F 問題は同時に開いて、F 問題を先に読んでパッとは解けないことを確認してから E 問題に取りかかるんだけど、昨日の F 問題はあからさまに簡単だったのでそのまま取りかかった。チェス盤に連番が書かれていてクエリで指定された矩形領域の白マスに書かれた数字の和をおおよそ定数時間で求める問題。連番でも1つ飛ばしでも式は等差級数の式で変わらない。Wikipedia で「等差数列」を開いて2種類の式の使いやすい方を写すだけ。……だと思ったんだけど1行目の和を求めたあとで3行目5行目を含めた和を一括で求めるのに詰まってしまった。自分はこんなあからさまに単純な法則で増加する数字をまとめて数えることもできないのかと不甲斐ない思いをしたよね。各行先頭の白マスを見比べて 2M ずつ増えているなと数列の和の式を2階建てで適用したら、サンプル1に含まれる6つのクエリのうち最後の1つ以外は正解した。え、なんで1つだけ合わないとかそんな中途半端がありえるの? E 問題を読んだのはこのタイミング。「インタラクティブ」の文字が目に入るやそっ閉じした。インタラクティブ問題は、問題形式そのものの難しさゆえか解くべき問題は易しめに手加減されていると感じることが多いんだけど(実際 E 問題だけど緑 diff だった)、やっぱり問題形式に難しさがある。初めての人が標準ライブラリの入出力がバッファされていることフラッシュの必要があることを理解できなくて TLE になるのは通過儀礼。そこを抜けてもデバッグに手間がかかる。昨日の E 問題は返すべき答えを人間が用意するのに難しさはないからまだましだけど、デバッグのためにサーバープログラムを書くとなると時間がかかる。F 問題の方が早く解けそうだった。結局3行目5行目は 2M×列数 の割合で増えていたのだった。■E 問題「Last Rook」(緑 diff)。N×N のチェス盤に N 個目のルークを置く問題。ルークは飛車。どちらがわかりやすいかどっちもわからないか。矩形を指定してクエリできるので、領域を4つに分けながら絞っていくのかと最初は考えた。行と列が入り乱れて死ぬ未来しか見えない。最小2×2の盤面でクエリをシミュレートしてみたら、結局縦と横で2回のクエリが必要になるのであって、1つのクエリで盤面を4分の1に限定できるわけではないことがわかった。縦と横で独立して調べるとして、2の10乗はいくつか(クエリ総数が20だから縦と横にそれぞれ10回しか使えない)。1024。2の10乗と10の3乗の対応は覚えておいて損はない。10ビット20ビット30ビットがキロメガギガに(ほぼ)対応する。サウザンドミリオンビリオンでもいいけどね。制約は1辺 1000 以下。制約からも方針の正しさが示唆されるのであとは実装するだけ。以前の日記に「二分探索を使った解法でかつて最も衝撃を受けたのは Vacant Seat というインタラクティブ問題に対する提出 #2057817 と #2064531 だった。bsearch メソッドから呼び出されるブロックの中でクエリを行っている。いやね、自分も提出 #7970588 の中で二分探索を使って答えを出してるんだけど、そのことと、対象となる具体的なソート列がないまま空中で二分探索を行う、順序はクエリで動的に決定するということの間に、どれだけの隔たりがあることか」と書いたくらいなので、今回は自分が bsearch メソッドの中でクエリを行うターンだと当然考えたのだけど、制約が1回のクエリの無駄も許さないと言っているので、ブラックボックスの Range#bsearch メソッドを信頼することができなかった。今回も二分探索を手書きした。提出前に気がついたけど、手書きした二分探索は複数バグっていた。■結果は 85 分でノーミス6完の青パフォ。まだかつての Highest に届かない。


2022年09月11日 (日) [AtCoder] 今日あった ARC148 のふりかえり。自分のすべての提出。■■■A 問題「mod M」(茶 diff)。2以上の好きな数で割った余りの種類を最小化するのだから、答えは1か2。それを見分ける問題。ある数 M があって、A 数列のすべての要素が割り切れるときは種類数1。ある数とは GCD。ところでこの他にも、定数 B を使って A 数列のすべての要素がある数 M の倍数+B で表せるときも種類数は1になる。サンプルの3がこれ。■提出 #34784727 (WA×5)。A 数列の GCD を使う代わりに隣接2項の差の GCD を使えばサンプルの3も通る。WA は gcd メソッドが0を返す場合があることを知らなくて判定条件を間違えた。■提出 #34785321 (AC / 96 Byte / 177 ms)。■■■B 問題「dp」(緑 diff)。DP は解けないので貪欲法でやろうとした。先頭から見て最初の p は必ず反転させなければいけない。L が決まる。R の候補をすべてリストして1文字ずつふるいにかけた。■提出 #34791453 (WA×18/TLE×1)。AC が 60 個あるからそれほど悪くない。終了後の提出 #34804071 は WA 無しの TLE×1 なんだけど、10 行目の L+1L に変更しただけなんだな。off-by-one エラーってやつ。TLE である 04_corner_11.txt はどんなコーナーケースか。ppppp....ppppp だろうことは想像に難くない。■提出 #34804490 (AC / 64 ms)。連続する p を一塊で扱うようにした。一番後ろの p を使わないで得をすることがないので。■■■C 問題「Lights Out on Tree」(水 diff)。与えられた頂点集合の上下関係を知るためにダブリングを書いたり、深さの偶奇が関係するかと思って深さを記録したりしたけど、実は直接の親子関係しか関係しなかった。ボタン操作の基本は「表向いてる親を裏返して、つられて反転した子孫ノードを裏向きに戻すために直接の子を再度裏返す」なんだけど、直接の子が最初に表向きだったノードなら操作回数が節約できる。■提出 #34798597 (TLE×18)。クエリのたびに子ノードのリストをたどる愚直解。■提出 #34799643 (AC / 422 ms)。子ノードは数だけ数えておいて一律に操作回数を計上し、子から親を調べることで足しすぎた分を引く。終了 12 分前に2完のノルマ達成。■■■B 問題と C 問題の配点が同じだから AC の2完遅解きは AB の2完遅解きと同じであり、2完遅解きは A の1完早解きに毛が生えたパフォーマンスしか出ない。-27。ARC にはレートを吸われてばかり。上昇したレートだけ数えたらもう赤なのではないか(頭がパー)。未来のレート上昇を演出するために現在のレートを捧げるのだ。


2022年09月10日 (土) [AtCoder] 精進1。今日あったユニークビジョンプログラミングコンテスト2022 夏(AtCoder Beginner Contest 268)-E「Chinese Restaurant (Three-Star Version)」(青 diff)。やることは即座にわかった。ズレの大きさと回転に応じたズレの変化量。制約が大きいので変化量の増減を記録してその累積で変化量を知る。変化量の累積で操作後のズレを知る。N の偶奇に注意が必要なこともわかっていた。でも完成させられなかった。■提出 #34765127 (AC / 487 Byte / 200 ms)。結局終了後2時間近く時間をかけることになった。一発 AC は嬉しい。類題を2問知っている。ABC240-F「Sum Sum Max」(水 diff)と ARC077-E「guruguru」(黄 diff)。■尺取りで変化量を増減させても良かったみたい>ツイート。ややこしさは変わらんけど、特徴点とその取り扱い方はもうわかってるので、最初から整理して書けるはず。あとでやってみよう。■いや、だめだ。頭が爆発する。もう考えたくない。(ゲーム実況見てる)。提出 #34779383 (AC / 513 Byte / 236 ms)。尺取りです。二重累積和とどちらがわかりやすい? どっちももう見たくねー。■■■精進2。同 ABC268-F「Best Concatenation」(青 diff)。制約の大きさと制限時間が特に長くないことから、1回通り過ぎるだけでスコアが求まるのがわかる。そうするとソートが問題。最初は X が多い順かつ数字の和が小さい順でソートした。これは、X が多いけど数字も大きい文字列の配置を間違える。X が多ければ配置は前だけど、数字の大きさを優先すれば配置は後ろだ。■提出 #34767243 (AC / 308 Byte / 742 ms)。ヒントを見ました。「アライグマ「F問題は変なソートなのだ! 2つの文字列のどっちを前にした方が得か考えてソートするのだ!」 フェネック「どっちを前にした方が得か考えてソートするのはDPの前処理でよく出るから覚えてねー」 https://t.co/rr67x9BfRi https://t.co/BlGbkt3aBV https://t.co/NkWMSVs5Yu」 すでにわかっていたことに確証を与えただけにも見えるけど、「2つの文字列のどっちを前にした方が得か考えてソートするのだ」というのが無意識に作用していた。二項関係だけでソートしていいんだと、知らずに気付かされていた。推移律はどうですか? よくわかりませんよね。祈りながら提出したら AC だっただけです。■ゴルファーの提出(#34766963)を見てると複素数を使ってるんだけど、そういえば自分が書いたソートのための比較関数が外積と同じ式だった。この前の外積を使う問題(ABC266-C「Convex Quadrilateral」)を自分は複素数で解いたから(#34376180)、なにかしら関係があるのだろうか。ソートからどうして複素数が出てくるのか飛躍がありすぎてさっぱりわからんけど。「(解説を見て)なるほどこれ「Xの個数/1の個数」の降順にソートしてたのか」という声もあるけれど、こちらもさっぱりわからない。俺にもなるほどさせてくれ。


2022年09月09日 (金) 職場に絶対一人はいる、言い方がキツかったり棘がある人の周囲からの評判あるある『あれでも昔よりは丸くなった』 - Togetter」■あのね、「言い方がきつい」も「棘がある」も、問題の所在に疑問がある。「私はあほで無能だから本当のことを言われると傷つくのです。配慮して下さい」と訴えているのだろうか。「お上品な育ちなので強い言葉を使われると萎縮してしまうのです。配慮して下さい」と訴えているのだろうか。看過、受忍できない理由はなんだろうか。自分の基準は主として正誤にあるが好悪も人間として必ずある理由。もちろん嫌われるまでには経過があっただろう。自分なら「ひがみっぽくて被害者意識が強い」とか「何に対しても皮肉っぽい」とか「あえて言わなくていいことまで言う」ような人とは付き合いにくいし味方にもなりにくい。でもこの Togetter に同調するのも、嫌いな人間の揚げ足をとるような振る舞いであり、公平な態度ではないと思う。「職場に一人はいる」という表現で一人対その他の構図を設定するところが卑怯だし生理的に受け付けない。


2022年09月06日 (火) [AtCoder] 精進1。先週末あった NECプログラミングコンテスト2022 (AtCoder Beginner Contest 267)-F「Exactly K Steps」(青 diff)。木があって任意の頂点から任意の距離にある頂点(の1つ)を高速に求める問題。■提出 #34603482 (WA×14/TLE×2)。木の中心と、中心から出る頂点のうち2つの頂点について考えた(すべてを考えると星型の木で死ぬ)。与えられた頂点 U と中心と中心から出る頂点のうち U を含まないものがわかれば答えが出せる。距離 K が U の深さより大きいなら、中心から出る頂点のうち U を含まないものを根とする距離表を定数時間で引く。距離 K が U の深さより小さいなら、ダブリングで U の親をたどる。WA だった原因は中心を正しく求められていなかったことで、TLE の原因はダブリングのためのデータ作りで配列の比較を繰り返していたことだと思う。■提出 #34645281 (AC / 1549 ms)。WA の原因が誤った木の中心にあることを突き止めているあいだに、そもそも木の中心がいらないことに気がついた。木の直径の両端にある2頂点のどちらかを根とする木において U から K 個上の祖先をダブリングで求めれば良い。無駄にややこしくして無駄にバグらせていた。■いやしかし Ruby 最初の AC 提出 #34576790 の 41 行目に center = now #中心 とあるな。……使われてないけど。770 ms と自分の倍くらい速いのなんで? 直径を構成する頂点のリストを用意して、U から直径までの距離を愚直に(1ずつ)数えてる。1回のクエリごとに高々半径と同じだけの遡行回数で直径に行き当たるだろうけど、それでいつでも大丈夫? しかしこんなややこしいことをしていて早いし速いし間違えてないのすごいなー。■直径を幹として他のすべての頂点を幹から分かれた枝(※)と見る木のイメージはこれまで持ったことがなかったなあ。※枝の長さは分枝点から直径の両端までの距離のうち短い方より短いか同じ。■提出 #34582537 (tinsep19 さん / 1606 ms)。クエリ先読みもありか。そうか。まねまね>提出 #34647156 (AC / 1826 ms) うーん、遅い。■■■精進2。先週末あった ARC147-C「Min Diff Sum」(青 diff)。コンテスト中に三分探索を書いていたんだけど、そのときも今日も3分点を求める式を間違えていた。(l+l+r)/3 とか l+(r-l)*0.3 が書けなかった。もっとも、それが書けても不満度を妥当な計算量で求めるのがまた難しかったんだけど。この部分問題には ABC の C 問題と D 問題の中間くらいのポジションをあげてもいいと思う。■提出 #34655113 (TLE×23)。三分探索が書けて判定式が書けて不満度の計算ができても、ローカルで6秒かかっているのでジャッジサーバーでは3秒くらいかかると思う。TLE。■提出 #34656235 (AC / 746 ms)。ループの中の線形時間の処理を累積和+二分探索に書き換えて AC。■提出 #34660104 (AC / 1739 ms)。整理していくと結局区間の左端の数と右端の数を数えるだけになって、三分探索も二分探索も不要になった。速くなるかなと思ったけど倍以上遅くなった。さっきの 746 ms がソート(NlogN)+累積和(N)+二重探索(log^2(N))で、今度の 1739 ms がソート(NlogN)+線形探索(N)。オーダーは O(NlogN) で変わってないけどね、だからこそこんなに差をつけられて、しかも負けてるのが納得しがたい。考察が進んで遅くなるとか……。ローカルで若干速くなってるものがジャッジサーバーでは2倍遅くなってたりするから、ジャッジが詰まりまくってた影響があったりする? あとローカルでは入力の受け取り方を変えるだけで3秒が2秒になったりした。入力サイズがでかい。■提出 #34661754 (AC / 658 ms)。ちょこっと速くなった。二重探索に対して妥当な改善だと思う。


2022年09月05日 (月) 今日読んでた本に「あたうる限りの努力」という初めて見る表現があって、気持ち悪いなあと思った。それ以前から「できうる限り」というあまり珍しくない表現も気に入らないと思っていた。だってね、「~しうる」という表現にすでに可能の意味があるのに、~するの部分にできるを当てはめるのは二重表現に思えてくどい。「できる限り」で十分なところでもったいぶって「できうる限り」なんて気取ってんじゃねーよ、という感想が先に立つ。■「あたうる限り」はどうか。これには「できうる限り」の「できる」にさらにもったいを付けて「あたう」に置き換えただけではない悪さを感じる。つまり、「~しうる」に接続するのに「あた(う)」でいいのですか、という疑惑。あたうの「う」と~しうるの「う」の音が同じだから、つい、くっつけちゃったんじゃありませんかという寸詰まりの据わりの悪さ。■「あたう(能う)」について ATOK で明鏡国語辞典を引いたら自動詞五段活用らしい。「~しうる」についても一応引いて、動詞の連用形とともに複合動詞を作ることを確認した。「あたう」の連用形とは何か。「あたい」になりそう? ところで、明鏡で「あたう(能う)」を引いたときにそのものずばりこう書いてあった。「「能う限り」を「能うる限り・能ううる限り」とするのは誤り」。2つの誤用例のうち「あたうる限り」の方は我が意を得たりでわかる。次に考え得るのは「あたううる」なの? 「あたいうる」の扱いがないのがアリだからなのかそれとも想定外なほど完全にナシだからなのか判断できない。もちろん「あたいうる」が仮に合法でも、気取ってんじゃねーよ、という感想をもつだけだけど。■■■珍しくない表現と問題提起だったらしい。「「あたう限り」? 「あたうる限り」?|NHK放送文化研究所」「「できうる限り」か「できる限り」か | 毎日ことば」「首相演説の「能うる限り」は「能う限り」の誤りでは? | 毎日ことば」 五段活用は五段活用でもワ行五段活用であるらしい。いくつかの活用形がないんだっけ? 連用形がなさそう?