/ 最近 .rdf 追記 設定 本棚

脳log[2025-06-14~]



2025年06月14日 (土) [AtCoder] 今日は CodeQUEEN 2025 予選 (ABC410) があった。問題の傾向として JOI に近いのだろうか。典型的な基礎知識が確実に身についているかを確かめる感じ。だからってそれが必ずしも簡単なわけじゃない。DP ひとつとってもいくらでも難しくなる。難易度はともかく、DP は必ず押さえておいてほしい知識のひとつとか、発想より実装みたいな傾向を感じた。結果は、まるで進歩が見られない。自分だけ前に進んでいないのだからそれは後退と一緒。■A 問題 G1。数えます。■B 問題 Reverse Proxy。シミュレートします。■C 問題 Rotatable Array。rotate をシミュレートする代わりに先頭へのポインタを動かす。添字の1始まりと0始まりの差を埋めるために N+1 要素の配列を用意してサンプルが合わずにグダってしまった。正しい対処法は、N 要素の配列を用意して、先頭へのポインタの初期値を N-1 にすることだった。■D 問題 XOR Shortest Walk。先々週の ABC408-E「Minimum OR Path」の OR が XOR だったら……という仮定がコンテスト後に見られました。期待に応えて? 閉路でどうなるかなと思ったけど、チカチカするだけだった。「だけ」といってチカとチカとチカの組み合わせは2のべき乗で増えていくのだけど、それとは関係なく頂点数 1000 に対して状態数が 1024 なので、全部やって間に合います。1<<10 を計算して確かめたので間違いない(あまり見慣れない制約なので 10 ビットとゼロ3つの対応が思い出せなかった)。■E 問題 Battles in a Row。体力の高さと魔力の高さはトレードオフの関係にあるので、体力に対して最大の魔力を記録する DP をした。2乗が間に合う。ところで、「体力に対して最大の魔力を記録する DP」のどこが「体力の高さと魔力の高さはトレードオフの関係にあるので」なのかは判然としない。本当は「HP が低くなるなら MP は高くならないといけないよ」という DP をしようとしたのだけど、実装が混乱したので一旦すべての HP をフラットに扱う素直な実装を書いて、それをそのまま提出したのだった。■F 問題 Balanced Rectangles。対角を決めれば中身は数えられる。問題は対角の選び方が2乗のオーダーになること。どうやって効率良く数えるのかわかりません。短い方の辺の2乗なら許されるとしても、長辺方向の累積和で何もうまくできない。■G 問題 Longest Chord Chain。ABC402-D「Line Crossing」、ABC405-F「Chord Crossing」から続く3問目。おかげで問題の把握は容易。まずある弦を選ぶ。その右側と左側に対してそれぞれ平行な(平行になるように移動できる)弦が最大何本選べるかがわかればいい。これは再帰的に DP で求められる。わからないのは、左右にあるどの弦が再帰の次のステップとして最適か。これを逐次的に選ぶのでは全体で2乗のオーダーになって間に合わない。次のステップの候補が連続してすきまなく並んでいるのならセグメント木に載せて最適解を対数時間で選べるが、左右を分ける弦と交差する弦をクエリ範囲から取り除かなければ誤った答えを選んでしまう。ということを今この日記に書いていて思ったのだけど、交差する弦をセグメント木から一時的に除外することが可能なのではないか。除外したり復元したりの回数は全部で 2N 回なのでは? この思いつきを実装しようとすると、弦に対して交差する弦のリストを作成すること、再帰の末尾に当たるどの要素からセグメント木を埋めなければいけないか、範囲の左右を分ける区切りとセグメント木の先頭末尾の区切りの不一致から扱う範囲が実質的に3つになることなど、気が遠くなるほど道のりが長い。2乗の解答を書くだけですでに疲弊しているというのに。しかもこの2乗の解答が (TLE に加えて) WA を出す可能性が6、7割くらいあると思ってるよ。それだけややこしいし、方針にも確信が持てない。■■■F 問題。この累積和の使い方、解いたことある。ABC338-G「evall」(「範囲の両端が + の内側にある場合の寄与は、これは累積和の問題として単独で D 問題あたりにでもなりそうな難易度の問題」)。次元がひとつ増えるだけでキャパシティをオーバーして、できることとできることの足し算ができないことになってしまうのでした。提出 #66801656 (TLE×20/AC×23)。ダメです。


2025年06月12日 (木) 舞洲万博P&R駐車場の待機場における自動運転バス車両のコンクリート擁壁接触事故の原因と今後の対応について|Osaka Metro」■「[B! 事故] 万博・自動運転バス事故『原因=車両が受信できない速度(500kbps)でデータ送信していた』大量のエラーデータで必要なブレーキ情報伝わらず…大阪メトロ | MBSニュース」■電動(?)パーキングが作動するための条件の1つであるフットブレーキ操作の記録が押し流されて確認できず、結果としてパーキングブレーキが作動しなかった。アクセルブレーキハンドル操作は普通にできる状態だったが、パーキングブレーキに穴があった。「当該車両の運転士が車両のパーキングブレーキシステムをオンにし、待機場停車時にフットブレーキ操作を行ったにもかかわらず、パーキングブレーキが有効に作動しなかった」ときにどんなフィードバックがあったのかなかったのか。これはブレーキをかけることとブレーキがかかることが一致しなかった例。自分は古い人間なのでこの2つがワイヤーで直結している(力学的)システムが好きです(大型車両で補助動力がうんぬんはおいといて、自分が乗る車は)。ちなみに自動運転のエラーではなく手動操作中の事故。しかし原因は(車内の?)通信ネットワークにある。


2025年06月07日 (土) [AtCoder] 今日は AtCoder Beginner Contest 409 があった。■A 問題 Conflict。縦に見て ○○ を探す。■B 問題 Citation。1回間違えて愚直二乗解法で書き直した。与えられた値の中に答えがあると思い込んだわけではないのだ。それも想定して、でも反例が出てこなくて間違えた。とても難しい問題。以前から書いてるけど、否定で定義される MEX みたいな問題が苦手。問題名は引用かなと思ったけど意味がわからない。調べたら召喚状、出頭(罰金)命令書、賞状といった意味が出てきた。意味があまりにとっちらかっている。形式に対する名称なの? なんにせよどれもしっくりこないような。■C 問題 Equilateral Triangle。円周 L を3等分して L/3 個の三つ組の掛け合わせの和。■D 問題 String Rotation。まず先頭に近い方から前後ペアを見つける。どのような。前後が大小の順番で並んでいるペア。次は見つけたペアの大きい文字をどれだけ後ろへ送るかを決める。より大きな文字の前か最後尾。■E 問題 Pair Annihilation。焼きなまし?(問題名←それは annealing こちらは対消滅) F 問題より考えた。最小全域木的な操作や重み付き UnionFind を考えたけど、うまくない。葉からの DP (with マージソート)を考えたけど、うまくない。実は葉から貪欲にペアを作っていくのが最善だった。それがわかればあとはがんばって書く。■F 問題 Connecting Points。2乗が通るのでやるだけですか? TLE×3 だった(#66577100)。もうええやないですか。通してください。できることはもうやってるんです。プライオリティキューに無駄要素が詰まりがちだから、値が重複しないように気をつけました(プライオリティキューにはユニークな距離の値だけを入れ、距離に対応した頂点対リストは Hash に入れた)。新頂点を追加するときに点間距離ではなく連結成分対新頂点の最短距離をソートによらず選び出すことでさらにキューに入れる要素を減らそうとしたら、これは遅くなりました(TLE×7)。お手上げ。


2025年06月05日 (木) CD2WAV32 for Windows11 Revision 4.00jpをリリースしました – 新しい経験の日々の記録」■4月に6年ぶりに CD を買ったので旧バージョンを利用したところ。2月に Vista から 11 に移行したので 11 対応はいいタイミング。次 CD を買うのが何年後か知らないけども。


2025年06月04日 (水) 前々から予測していた危険がみごとにその通りになった。戸を開けて包丁をしまうときにね、今落とすと(先に見えている)足があぶないなとスリッパを履いてる方が安全だなと思っていたのだった。今日は靴下も履いていなかった。ゴツッと親指の付け根の骨にぶつかって皮一枚だったのが幸い。手を滑らせたこと、ぶつかったこと、当たったのが峰でなかったことが不運。回転していたし赤い筋も見えなかったので幸運を期待したのだけど。


2025年06月03日 (火) [AtCoder] 精進。ABC096-D「Five, Five Everywhere」(水 diff)。提出 #66415672 (AC / 85 Byte / 212 ms)。サンプル以外のケースが2つしかないのね。N=55 とあとはなんだろう(N=5 はサンプルにある)。解答のマジックナンバーも5だった。タイトルに偽りなし。解けてみたらこれ以外にないという感じだけど、解けない。この問題は何度も埋め損ねて残っている問題のひとつだった。N が小さいし候補となる素数の数も知れてるし、実際に組み合わせてみてフィルタするうまい方法がないかを最初は考えた。でも 50 の 5 乗に近い組み合わせは考えられない。その次に、特定の余りの組み合わせが特定の余りに限定されるということがあるなと思って、2とか3とか4の余りについて考えていた。2の余りによる分類は偶数奇数ということでほぼ意味がない。2以外の素数はすべて奇数なので。問題が5個の組み合わせでなく偶数個の組み合わせだったら、奇数を組み合わせてできあがる数は2より大きい偶数(≠素数)だということで簡単だった。次に3の余りを考えたけど、ポンコツだったのは、3で割って1余る数は必ずしも偶数ではないんですよ。3の倍数も奇数に限らない。それが偶数だ奇数だと勘違いして無駄に時間を使った。次に4。4で割った余りによる分類は偶奇偶奇と分かれるので、それで3で割った余りを勘違いしたんだろうなあ。4で割る理由は奇数の素数を2派に分けられるから。でも分けて嬉しいことはなかった。次が……。


2025年05月31日 (土) [AtCoder] 今日は AtCoder Beginner Contest 408 があった。D 問題に全部持って行かれた。全部ではないな。E と F の点数 950 点と D の点数 400 点を持って行かれた。難易度が F<E<D の順で逆転していた。■A 問題 Timeout。今日は A 問題から不調を感じていた。+0.5 秒がまじで嫌い。長老が寝る瞬間に長老は起きているのか寝ているのかという問題が生じないためであるのはわかる。目的はわかるけどそれを処理する頭がない。だから嫌い。今日はごちゃごちゃ細かいことが考えられない。■B 問題 Compression。uniq、sort. ■C 問題 Not All Covered。端から順に見ていってそこをカバーしている砲台の数を数える。■E 問題 Minimum OR Path。単純パスというのは考えなくてもいい。寄り道をして得をすることがないので。ラベルのビットには明確な序列がある。1<<k を含むラベルを使わないで済むなら、1<<k 未満のラベルはすべて使ってしまって構わない。この論法で最上位ビットから決めていく。UnionFind で 1 と N の連結非連結を確かめながら。TLE を1回出した。マスクしたウェイトに基づいて辺をソートしてから UnionFind をしたのが原因。ソートがいけない。ソートするより一辺一辺使用するかしないかを判断する線形時間の処理の方が軽い。■F 問題 Athletic。セグメント木が使えますかという問題。高橋君のいる高さは狭義単調減少なので、高さの低い方からあと何回ジャンプできるかを求めてセグメント木に乗せていく。高さが近すぎるとジャンプできないので、求めた回数をすぐにはセグメント木にセットせず、キューに入れて遅延させる。それだけ。■D 問題 Flip to Gather。ある1の島を、残す1の左端にすると決める。そうするとそこより左にある1の数だけ操作が必要。同じことを右側についても求める。左端と右端を決めたら左右の消すべき1の数と真ん中の消すべき0の数がわかる。2乗の解法は許されないからどうする。尺取り? あのですね、人間のワーキングメモリには個人差があって、自分は頭が働くときでも3段4段の処理は脳内スタックからあふれてしまう。DP をするときだって in-place で書き換えたり保持するものを前後の2系列に限ったりすることで添え字が3つ以上にならないように工夫している。というかそうする方が楽だし解きやすいので自然そうなる。1+1+1+1 = 4 ではないんです。3までは線形に増えていってもその次はスタックオーバーフローで実行が完了しないんです。こういう限界の低さをふまえて出題してもらいたい。D 問題に解けない問題を置かないでほしい。■■■A 問題。嫌いな嫌いな +0.5 秒問題。自分について理解した。たとえば問題文が「最後に肩を叩かれてから S 秒後まで長老は起きています。(最後に肩を叩かれてから) S+1 秒後には寝ています」だったらすんなり頭に入ってくる。次からこう読めばいいと理解した。S と S+1 という2つのパラメータを S というひとつの値で表すために +0.5 秒というやっかいものを導入して、「あとはわかるな」で済ませるから話がややこしくなるのだ。きっちり文章にしてくれないとわかりません。


2025年05月25日 (日) [AtCoder] 今日は AtCoder Regular Contest 198 (Div. 2)。■A 問題 I hate 1。こういうのをギャグというのだろうか。AtCoder で一発ネタを見ることってない。たとえば2を追加するとすべての奇数が追加できなくなる。一方で、2の倍数は余りが0なので追加することができる。なので S の要素は素数の倍数が良さそう? ほぼ半数を要素にできる2の倍数以上にすぐれた選択肢ってある? 問題の難しさを認識することさえできなくて過度に単純化した結果 WA を出すというのが ARC あるあるだしなあ、でも 300 点問題だしなあと数分逡巡してから(反例となる素数の組み合わせも見つからなかったので)提出して AC だった。■B 問題 Rivalry。問題を読んで具体例を確かめていくと、01100[1]2[1]0 しか作れないとわかる。2の両隣の1はオプション。0 はいくつ連続で並べてもいいので、11[1]2[1]0 で区切るイメージ。まずは消費の仕方が限られている2を消費したい。2を消費するのに十分な0の数は2と同数。これは数列が環状に循環しているから。次に1を消費したい。2の両隣の1はオプションだから、2の倍の数までは何も考えずに消費できる。余りは 11 として2の島と同様に同数の0で区切る必要がある。余りの1が奇数個の場合が面倒。2の隣の1をひとつ持って来られるなら良し。持って来られない(2がゼロ個)なら即座に No。実装ミス(A = A-B-BA -= B-B とした)と勘違い(ひとつのことを実装しているあいだにもうひとつのことが曖昧になっていくせい)で2ペナ。■本日の ARC は終了です。時間をオーバーして C 問題の実装を終わらせたけど、シャッフルした順列をソート済みに並べ替えようとすると最後の2要素が一致しない。操作対象が2要素だけだと自由度がなくていけない。1要素を加えた3要素を手で操作してなんとかできないかやってみたけどどうにも完成させられなかった。えっ? 全体の和が一致していても不可能なケースがある?(ないよね) N=2 だけでなく N=3 も場合分けが必要?


2025年05月24日 (土) [AtCoder] ABC407。死亡。E 問題、2乗の DP を、やらせてください。F 問題、2乗の解法で、勘弁してください。どちらも許されないもよう。今日は A 問題からドキドキで WJ を眺めていたし、B 問題はなんとなくで総当たりの解法を見つけただけだし、C 問題と D 問題でやっと普通にやるだけだと感じられた。そして EF で死亡。■■■驚きました。コンテスト成績証。1391 水パフォで +8 レートだった。これで上がる自分のレベルの低さに驚きました。


2025年05月22日 (木) プログラマーの性格が悪く見えるのは日常生活をRFCやソースコードとして解釈しているから説 - hitode909の日記」■「日常会話、RFC説」おもしろいなあ。俺も言いたいことがあるよ。結果に関して明らかに MUST を要求してきてるのに、コストに注目して「それは MUST ですか」って聞くとそうは言っていない (MUST じゃない) (MAY だ) っていう人が、だけど要求は下げない人が、いるんだよ。「自主~」を要求するみたいな国はそういう人間でできています。■■■「68行目にごちゃごちゃやってますが、これはNと111...(下から数えて0埋めしたい桁数)...1を&演算してNの下digit_from_bottom桁を抜き出し、Nからこれを引いて下digit_from_bottom桁を0埋めした数字です。もっとスマートにやる計算方法があるのでしょうか? 誰か教えてください」 自分だったら masked_max_m = max>>digit_from_bottom<<digit_from_bottom って書くかなあ。特に罠もないと思う。符号は罠にならないし(非負だよね?)、シフト数の罠(明らかなシフトしすぎは未定義)は書き方によらないし (Rust の罠は知らないよ)。あと、20250517 に書き足したことだけど、以下と未満の差を埋めるのは n に予め1を足しておくだけでいいみたい?


2025年05月18日 (日) Xperiaの名がなかったのはなぜだろうか? その主な要因として挙げられるのが、激化する価格競争で十分に優位に立てなかったことだ。特に円安が追い風となり、Xperiaのハイエンドモデルの価格は年々高価になり、競合のAndroidメーカーが次々とコストパフォーマンスの高いモデルを市場に投入する中で、優位性を示せなかった」■「円安が追い風」 円安はネガティブ材料なのだから、向かい風や逆風がふさわしい。関係あるようなないような話。真逆と書かれていればそれが作家の当て字でも早い者勝ちルールでマサカと読むことにしている。■■■「大学院の講義が英語化された結果、日本人学生はリスニングができないので話を聞かずレジュメを眺め、一部積極的な留学生がたまに質問するようなスタイルになった - Togetter [トゥギャッター]」■相変わらず趣旨には触れないんだけど、~が原因となってみたいな意味の「ひいては」を漢字にすると「延いては」になるみたい。意味を考えるとまあそうかなという感じ。延長線上に何があるかを示すという意味で。「引く」という動詞があまりにもたくさんの意味を持っていて、「引いては」と変換候補にも出てくるから、うっかり選ぶこともあるかな。(それがなんか違う気がしたので ATOK で辞書を引いた)


2025年05月17日 (土) [AtCoder] 今日はパナソニックグループ プログラミングコンテスト2025(ABC406)があった。■A 問題 Not Acceptable。やります。比較方法はいろいろ。配列で比較してもいいし、3回比較してもいいし、単位を揃えて比較してもいい。■B 問題 Product Calculator。どうやって桁数を知るか。Integer#digits を使ったけど、10**K と比較するのが無駄がなかったみたい。他の人の提出で知った。■C 問題 ~。にょろ。each_cons(3) で極大値極小値の座標をメモして、each_cons(4) でその座標4つから答えを数えた。たとえば、i<j<k<l が連続する4つの極大値極小値の座標だとすると、左端の候補が i から j-1 まで。右端の候補が k+1 から l まで。掛け合わせたものが j,k の位置に山と谷を持つ連続部分列の数。これでサンプル3の答えが過大になって困ってしまった。デバッグプリントで確かめてもバグがなかったので問題を読み直してみると、「A1​<A2​ である」という条件を忘れていた。P[i]<P[j] を確かめて解決。ところで、波ダッシュにはこういう話題がある。「UnicodeのWAVE DASH例示字形が、25年ぶりに修正された理由」。自分は何事も雰囲気でいい加減な人間なので、チルダも波ダッシュも全角チルダも同じようなものだと思ってるし、波が上がってから下がるかも下がってから上がるかも全く区別するつもりがない(できない)。この問題もそうであったらデバッグのための5分10分が節約できたのになあ。■D 問題 Garbage Removal。列の情報と行の情報を分けて管理する。罠がいくつか。グリッドが H 行 W 列。(i,j) は上から i 行目で左から j 列目のマス。(Xi,Yi) は i 番目のゴミの座標。説明がまわりくどくて無駄に文字が増えてるうえにその文字がかぶってる。(i,j) の説明は省いて (Xi,Yi) が上から Xi 行目で左から Yi 列目のマスだって説明すればいいじゃない。X と H、Y と W の対応もいやらしい。管理する情報はゴミの行から列、列から行と、すでに片付けられた行と列。同じ行(列)を何度も片付けようとすると TLE になるので(なったので)、片付け済みかどうかをまずチェックする。片付け済みフラグを管理する代わりに行から列、列から行のデータを削除可能な集合にして、リンクさせて管理するのが素直な解法だったっぽい? 最初にそれを配列にしてしまったから対になるデータを同期するのが無理だと思ったんだよね。■E 問題 Popcount Sum 3。たとえば問題が 0b1111111111 以下の整数 x についてだったら数えやすい。実際に与えられる N はそうではない。過去問を解くときに十分に苦しんできたので、どうすれば漏れなく重複なく数えられるかは知っている。倒すビットを1つ選ぶ。それより上位のビットは N のものをそのまま維持し、それより下位のビットは 00...00 から 11...11 まで好きに選んでも N より小さくなる。固定された上位のビットと好きに選べる下位のビットの組み合わせで答えを数える。「N 以下」なのでビットを1つも倒さないケースも忘れず勘定に入れる。その方法だけど、N のケースを個別に数えるんでなく、N に予め1を足しておくだけで良かったっぽい?(「例の20は1足して21にすると考えやすいです」) ビット表現に即して考えているときにその表すところである数に意識を切り替えるのは難しい。ところで、数えるものは個数ではなかったんだよね。サンプルが合わないから読み返したら太字で総和って書いてあった。ちょっとひとひねりという感じなので、冷静にひと手間かければ個数を総和に変換できる。ひとひねりでてきめんにやられるのが自分ですけどね。ひと手間というのは、好きに選ぶ各ビットの寄与(1少ない桁数から1少ない1のビットを選ぶ場合の数)を考えること。■F 問題 Compare Tree Weights。HLD なのかな、平方分割チックに木をブロックに分割するのかなと考えるもまとまらなかった。スター型の木と直線の木を同時にうまく扱う方法がわからなかった。X でオイラーツアーと BIT だと複数見かけたけど、まだピンと来ていない。■G 問題 Travelling Salesman Problem。ABC273-F「Hammer 2」みたいな雰囲気を感じます。考える意味のない無駄な動きを除外してうまくやりたいけど、うまい動きがどういうものかはっきりしない。ちなみに ABC273 は3年前のパナソニックのコンテストでした。偶然ではないとしたら本当に似た問題なのだろうか。Hammer 2 は右左右左と往復を繰り返すことで効率良く解ける問題だった。制限時間が3秒だけど Ruby で 62 ms で解ける。……むしろ今日の C 問題?■■■精進。F 問題。提出 #65938315 (AC / 976 Byte / 1291 ms)。ひと晩寝るまで何がわからなかったか。ある区間の和を得るには端からの累積和の差を取るという、BIT(累積和)の使い方を忘れていた。オイラーツアーで木の頂点を DFS の行きがけ順に並べたら、ある頂点の子孫がある区間に連続して並ぶ。では子孫の重さの和を得るには、というときにどういう操作をするのかがわかっていなかった。なんでわからなくなるのかがわからなくもない。頂点を一列に並べてそれを BIT に乗せるとき、列に木の構造を見るばかりに BIT の各要素に過剰に意味を見つけようとしてしまうのだろう。だけど累積和の各値に木の構造を反映した意味はありません。差分を取って初めて意味が出てくる。だけど意味がわからないから差分を取るところまで行けなかった。数弱ですからね、すべて意味と具体で納得しながらでないと前に進めない。


2025年05月10日 (土) [AtCoder] 今日は AtCoder Beginner Contest 405(Promotion of AtCoder Career Design DAY)があった。結果はまあまあ。ペナルティ2つがしょうもない。■A 問題 Is it rated?。こういうのは仕様をそのまま書きます。仕様はコードではなくデータで表現するのがおすすめ。コードはなんでもできすぎる。■B 問題 Not All。Array#tally で種類数を管理しながらシミュレートした。■C 問題 Sum of Product。すべての組み合わせの積の和。Ai に対して Aj (j=i+1,...,N) の和を掛ける。■D 問題 Escape Route。あまりにも実装が下手だった。全部で 25 分かけて TLE も1回出した。グリッド BFS を書くのが下手(そんなことある? 驚きました)。この TLE だけど(#65661930)、31 行目を分解すると倍速くなった(#65666427)。グリッドの移動部分もアンローリングするとさらに倍速くなった(#65668293)。手を抜いたわけではないのです。早過ぎる最適化は悪なのです。■E 問題 Fruit Lineup。4つの果物を並べる3つのルール。きれいに整理できそうでできなくてでもやっぱりできた。バナナとブドウを混ぜて並べたあとで、最も左のブドウの位置に応じて、ブドウの左にあるバナナとリンゴのあいだにオレンジを並べる。■F 問題 Chord Crossing。ABC402-D Line Crossing で多く観察された誤読バージョンが期待に応えて登場。今回も誤読しました。時間をオーバーしながらとりあえず実装を終えたけどサンプル2が合わない。ノートをひっぱり出してきて図示して気がついたのだけど、線分どうしが共有点を持たないといって、そのありようにはバリエーションがある。2と4、6と8、10 と 12 を結ぶ3本の線分もたしかに共有点を持っていないが、こんなケースを全く想定していなかった。奇数の頂点を2つうまく選ぶことですべての線分を必ず貫くことができると想定していたのだけど、それは間違いだった。じゃあクエリの区間のあいだに出入りする線分をうまく数えてなんとかしたいね。最初はこの線で考えていたんだけど、すべての線分を平行に並べ直せるならより簡単に解けると思って、でも勘違いだったんだよなあ。■精進。F 問題。提出 #65700291 (AC)。クエリ区間のあいだに外から入って来る線分と外に出て行く線分を数えて、区間の内部で出入りが完結する線分を無視するために、何を管理すればうまくいくか。ABC402-D を誤読したときに誤読したまま解答までたどりついていれば今日は考える必要がなかった。残念ながらそうではなかったので、今日たっぷり考えさせられることになった。クエリ区間が始まるときに、すでに頂点を出発していてクエリ区間中に着地する予定の線分を BIT で数える。クエリ区間が終了するときには、頂点を出発していてまだ着地していない線分のうち、クエリ区間開始時にはまだ出発していなかったものを数える。これだけのことなんだけど、何をメモしてそれをどう足し引きするかということがものすごくややこしかった。■時間内に解いている hmmnrst さんの提出 #65685391。セグメント木を使ったあまりにもすっきりした解答。自分の頭の中のこんがらかり具合を反映して、ぐだぐだと順を追ってあれを数えこれをメモしてやっとのことで答えを出している解答との差よ。