/ 最近 .rdf 追記 設定 本棚

脳log[2025-11-08~]



2025年11月08日 (土) [AtCoder] 今日はトヨタシステムズプログラミングコンテスト2025(ABC431)があった。■A 問題 Robot Balance。頭でっかちはダメです。■B 問題 Robot Weight。N 種類のパーツを付けたり外したり。なんかせこい方法ないかなって考えて思いつかなかったから 01 配列を別に持ったんだけど、重さの値を -1 倍しながら足せば良かったんかな。■C 問題 Robot Factory。A 問題の発展。重いボディ K 個と軽い頭 K 個の一意な組み合わせ。これを実装するにあたり、ソート列から重い K 個と軽い K 個を取り出すメソッド(shift/pop)を取り違え、頭と体を比較する演算子の向きを間違えるのが自分です。■D 問題 Robot Customize。B 問題の発展。DP をしたいけど状態をどうするか。頭の重さに対して頭に取り付けたパーツとボディに取り付けたパーツの嬉しさの合計の最大を記録した。頭に取り付けなかった時点でそれはボディに取り付けることが決定しているのでその嬉しさを即座に合算してしまって総合的な優劣を比較すれば良い。しかしこれは TLE×3 だった。計算量を見積もってみると、N=500, sum(W)=500*500 のとき、ループ全体で 500 の3乗(=1億2500万)。頭の重さの最大が sum(W)/2 なのでざっくり半分にして 6250万。これは Ruby には厳しい。ここで見かたを変えて、ボディに取り付けた場合の嬉しさはただで手に入る嬉しさであり、頭に取り付ける場合は重さにハンデを抱えるけどボディに取り付けた場合の嬉しさにさらに嬉しさを付け加える行為だと考えた。そうするとボディに取り付ける場合の嬉しさは必ず得られるベースラインなのでいちいち計算して比較する必要がなくなる。頭に取り付ける場合の嬉しさはボディに取り付ける場合よりどれだけ大きいかで評価されるので、そもそもボディに取り付けた場合より嬉しさが低いなら頭に取り付ける理由がないとわかってループが省略できる。よく知らない用語を雰囲気で使って説明すると、2か所からもらう DP をしていたものが1か所からもらうだけで済むようになった。実際の計算量は入力の傾向に依存するような気もするけれど、これらでおよそ半分に時間が節約できて AC になった (#70786365)。他の言語では必要のない苦労だったかもしれない。入力の傾向に関係なく状態空間のサイズ(と遷移)に応じた決まった時間で答えが出るのが DP であるので、何をやってもそれは定数倍の改善か入力依存のアドホックな改善でしかない。■E 問題 Reflection on Grid。同配点の F 問題も一応読んだ。トポロジカルソート的な感じで場合の数を数えたいけど「徒競走」に比べて制約が大きすぎる。見込みがないと思って E 問題に専心した。その E 問題。重実装の気配がビンビンしています。それどころか実装に取りかかれない。これは頭を使う必要があるなと一度立ち止まって考えることにした。盤面のマスの数が多すぎるので1マス1マスああしてこうしてと試行錯誤することができない。1か所変更してみた結果青木君に光が届くかが即座にわかると仮定してみたら答えられるだろうか。たとえば初期盤面の経路の1マス目を変更して結果を見る。ダメなら1マス目はそのままにして2マス目を……。これの何がダメか。盤面の外に飛び出さない限りおよそどんな経路を選んでも青木君にはたどりつく。ただし操作手順が増える。操作手順の少なさが問われているのに手数を度外視した解法はいけない。方向を加味して盤面を4倍した状態を持つということは考える前から決まっていた。BFS をしたいですね? 手探りで書いているこれは 01BFS ですか? 提出 #70805678 (AC)。1時間あっても完成しなかったからこれは終了後の提出。鏡の向きの変更を記録して考慮しないでいいのはなぜか。一度鏡の向きを変更して進路を変えたマスに紆余曲折の末再進入するケースを考える。鏡の向きを変更することで3方向どれでも好きな進路を選べるわけだけど、過去に左から入ってどこかへ出て行っていた場合、再進入して左以外のどこかへ出て行くケースは紆余曲折を省いて最初の進入時にそこへの進路を選んでいたことにすればいい。左側に出て行きたいときは? 他の経路を通って初めての進入が左側以外になったときに考えましょう(そのように取り扱えるようになっています。そしてどんな紆余曲折をたどっても U ターンして左方向へ出ていく経路はないのでこれ以外のケースは想定しません)。


2025年11月04日 (火) 楽園 Le Paradisが刊行停止を発表、2026年2月発売の次号第50号が最終号 - コミックナタリー」■悲しい。4号から買い始めて全部持ってる。雑誌で読みつつコミックスも買う作家さんも、コミックスを買うタイプではないけど雑誌では面白く読む作家さんも(すまない)、ほぼすべての連載陣がどちらかであって、奇跡的なコストパフォーマンスを誇る雑誌だった。匹敵する漫画雑誌をコミックエール!しか知らない(そちらは 12 号で終わってしまった)。刊行ペースを上げずに無理せず長く続いていると思っていたけど、50 号で終わりかあ。


2025年11月01日 (土) [AtCoder] 今日は AtCoder Beginner Contest 430 があった。■A 問題 Candy Cookie Law。人間は記号で記述された論理よりも法律やら違反やらの意味で具体化された論理の方が答えやすいらしいですよ。だからといって違反しているときに Yes と答えさせられるのはちとやっかい。前提条件をそのままに判定をひっくり返す。もしくは問題文の通りに判定して No を出力する。■B 問題 Count Subgrid。いつもやっているように指を使って数えたにもかかわらず記述を (N-M+1).times (0 から N-M までの繰り返し) から [*0..N-M+1] (0 から N-M+1 までを値とする配列) に書き換えたときに off-by-one エラーを仕込んでしまって合わないサンプルに困ってしまった。デバッグプリントで解決。■C 問題 Truck Driver。しばらくわからなくて目の前に沼が広がって見えた。今日はここまでかと。2つの条件に合う範囲をそれぞれ二分探索で求めて考え合わせる。気がつけばこれだけ。■D 問題 Neighbor Distance。お隣さんがわかれば差分更新できる。SortedSet がないから BIT で管理するんだけど X の値が大きいので座圧が必要。今でこそ座圧なんてやるだけ面倒なだけに見えて制約で手軽にいじめられてるなこのひと手間必要でしたかなんて考えてしまうけど、「座標値(-10^9 以上 10^9 以下の整数)でなく座標値の序列(N個以下とM個以下)でグリッドを作るって発想が出てこないんだよなあ」なんて初々しい感想を書いていた時期が自分にもありました。座圧ができれば橙 diff の F 問題「. (Single Dot)」が解けた時期が AtCoder にはありました。WA になった最初の提出まで 24 分かかってるんだけど、実装に取りかかる前に強制うんこ休憩に襲われて急いで E 問題を読んで駆け込んだのだった。なお E 問題のロリハ方針が決まってもまだ出られなかったもよう。WA の原因は番兵が小さすぎたこと。番兵との距離が1しかないならいないはずの番兵との距離を答えに計上して間違える。修正に2分。■E 問題 Shift String。入力が素直に2進数に見えるのでハッシュ値を比較するのもハッシュ値を差分更新するのも自然に行えると思う。マルチテストケースであり問題の見た目から基数に2が選ばれやすいだろうから、ありがちな素数の組に対してハッシュの衝突が狙いやすいと思ったけど、AtCoder で最も有名な2つの素数を使っていても大丈夫だったみたい。■F 問題 Back and Forth Filling。50 分弱残して解けなかった。似た設定でこれより答えやすい問題を見たことがある。自分の左右に最低いくつ最大いくつの数があるかを DP で求めて BIT で区間 add をすれば答えの C 数列が得られると思ったけど、サンプルが合うところまでいかなかった。■コンテスト成績証。737 位、1502 水パフォ。■■■F 問題。昨日はこう書いた。「左右に最低いくつ最大いくつの数があるかを DP で求めて……」。最大でいくつの数が置けるかを管理する必要はないのだった。最低限必ず置かなければいけない数がいくつあるかだけで良かった。前から4変数、後ろから4変数で DP をしていたものを、前から2変数、後ろから2変数に書き換えたらするっと答えが一致した。BIT もいらなかった。変化量の累積和で十分。提出 #70649443 (AC)。■■■@2025-11-11 ABC431 の結果が消えていて、ABC430 の結果は順位が同じまま 1587 パフォに上がっている。何があったんだろ。


2025年10月31日 (金) [AtCoder]「初参加者の内部レートを変更いたします - AtCoder」 ABC-rated 層では2年間で +200 程度の影響があるというのはどういうことなのか。ご新規さんを養分としてレートを吸い上げるにあたり、その養分量が 1.5 倍でうまうまとかそういう話なのだろうか。もちろん相当する実力を見積もっての変更なのだから、どちらがどちらの養分になるかは決まっていないわけだけど。


2025年10月30日 (木) [AtCoder] PAST20 の過去問の J「グリッドの禁止パターン」。どれだけの人がマス(i,j) が上から i 行目、右から j 列目のマスだと気がついただろう。そして気がつかなくても左右の区別に何の意味もないのだった。動揺させられて余分な注意を払った自分があほを見ただけ。次の K 問題「良いグリッド」もグリッドの問題だけど、これはスクリーン座標系で普通な左上が原点の設定だった。なんなん?


2025年10月29日 (水) [B! 決済] 「PayPay」命名は地獄のプロセス 候補に挙がった別案とは」■言語化について。却下するにしても理由を言語化してほしいというのはもっともな要望だけど、整えて並べられた理由よりも先に感覚的な良否の判断があるのだから、言語化が間に合わないことがあるのもしかたのない話。それに、言語化に伴って削ぎ落とされる部分というのも小さくても無意味ではなくて、結局全部をひっくるめてこそ究極の判断ができる。定石だけでは勝てないみたいなことがあるんじゃないの? そこには単純化と条件の理想化がある。PayPay はそんなにかっこいい決まり方ではなかったみたいだけど。


2025年10月25日 (土) [AtCoder] 今日は Polaris.AI プログラミングコンテスト 2025(ABC429) があった。解けるはずのものを解いただけという感じだけど 1614 の青パフォだったのは変な沼にはまらずにスムーズに AC できたから。40 分残して F 問題が解けなかったのがいつも通りのダメさ。AI が猛威をふるっていたついこの前まではこのいつもが望むべくもなかった。■A 問題 Too Many Requests。HTTP ステータスコードなのかな。番号になじみはないけど問題名は聞いたことがある気がする。400 番台がクライアント起因のエラーだということとも合致している。■B 問題 N - 1。特定の値が A 数列の中にあるかどうか。ループの外で計算してすべての仕事を Array#index に投げるのはケチだから。■C 問題 Odd One Subsequence。数列から(位置が)異なる3つの要素を選ぶ方法。Array#tally で集計して計算する。同じ数字を2つ選ぶ方法は nC2 で、残りの数字の選び方は N-n。■E 問題 Hit and Away。難しいから 425 点になっている D 問題と、E 問題だから 450 点の E 問題。解きやすいのも解いて得するのも明らかに E 問題なので D 問題を読まずに先に E 問題を開いた。最初は危険な頂点を起点にしてじわじわ広げていく陣取り的な操作を考えた。UnionFind かな、重み付き UnionFind かなと考えていって、いつもの UnionFind を書いたりもしたんだけど、詰めていくと、安全な頂点を始点にして始点により区別されるパスに先着2つまで訪問を許す BFS になった。■D 問題 On AtCoder Conference。実数 x で定義されるけど実際に求めるのは M 未満ゼロ以上のすべての整数についての合計。M が大きい。そうすると N 人の人の立っている地点と地点のあいだをすべてひっくるめて処理する必要がある。隣り合った人と人のあいだを始点とする X はどれも同じ値になるので。人と人のあいだと日本語で書くときはいいけど、実際に書く処理ではどちらかを含まない半開区間にする。どちらかっていうか、仲間はずれは区間の右端なのでそれを含まないようにする。A 数列は M を足した2周目を加えて倍加して計算しやすくする。複雑だけど 17 分でサンプルがあったから提出したら TLE×3 (#70444180)。手元でいくつかの種類の最大ケースを作ってみたけど再現できず。たぶんだけど C 人先の人が C-1 人先の人と同じ値のときはもう一人先を見る、という繰り返し処理を毎回律儀にやっていたのが良くなかった。尺取りなんだけど一端を進めたときにもう一端を(添字に C を足して) C 人先にリセットするとそれが手戻りになることがあり重複処理がかさんで TLE になっていたのだと思う。6分で修正して AC (#70446347)。■コンテスト成績証


2025年10月20日 (月) [Win11] お役立ち情報。「Unicodeフラグ、ZIPファイルの文字化け問題」■Windows 11 の送るで圧縮フォルダを作ると日本語パスが必ず化けている。Hamana で見ても LHMelt で見ても化けてるから Windows 11 の問題か Web 由来の中国系の読めない文字が混じっているせいかと思っていたけど、後方互換性を無視した Windows 11 のせいだった。たしかに Windows 11 自身に解凍させると化けないもんな。しかしこの PC ではお前が異端だ。Windows 11 がすべて悪い。■しかし、これまで化けなかったのは全部 CP932 だったからなのか。UTF-8 で保存したいのは、それはその通り。文字集合の大きさが全然違う。


2025年10月18日 (土) [AtCoder] 今日は AtCoder Beginner Contest 428(Promotion of AtCoderJobs) があった。21 時数分前にスタンバイしてよそ見をしているうちにページ右下に表示される待ち時間が 30 分ちかくに増えていた。どうやら Codeforces ではよくあることらしいが AtCoder では初めて。■A 問題「Grandma's Footsteps」。これを書いている今問題名を読んでいる。おばあちゃんの足跡?足音? 問題文中のゲームの説明を読むとだるまさんが転んだぽいので「だるまさんが転んだ 英語」で検索するとイギリスでの言い方らしかった(「だるまさんがころんだって英語でなんて言うの? - DMM英会話なんてuKnow?」)。A+B 秒のかたまりがいくつあるかと余りと A の少ない方。かたまりには A を掛けて、両方に S を掛ける。AtCoder では秒と分を混ぜたような問題は出さないし、答えに単位も要求しない。■B 問題「Most Frequent Substrings」。何を答えるのかがとても難しい。わかれば全部分文字列を切り出してカウントするだけ。■C 問題「Brackets Stack Query」。( を +1、) を -1 として総和がゼロである必要があるんだけど、途中で負になることがあると壊れているので、累積和と同時に負になった回数もカウントした。■E 問題「Farthest Vertex」。最近 ADT で木の中心を扱う問題を解きました。これ「Diameter set」。過去に解いているにもかかわらず WA を4回も出して、それは直径を求めたあとで中心を求める手順が誤っていたのが原因だった。たぶん以前に解いたときも同じ間違いをして苦しんでいたような気がしないでもない。今日は3度目の正直で間違えなかった。直径の一端から遡る途中にあるのが中心。うっかりミスで WA を1回出しながら 50 分かけて実装したんだけど、解説には実装を簡潔にするアイデアが2つ書いてあって、前半はさすがに自分の提出と同じ構成だったけど、後半がとてもシンプルな実装だった。1つ目のアイデアが1未満の極小の長さを持つ辺と頂点を付け加える方法で、値が同じ場合に添字の大小で順番を付けるときに (値,添字) でペアを作ってソートする方法に似てる。実装で示された2つ目のアイデアは直径を探すときに N から逆順に端点を探して最初に見つかったものを優先することだった。ループの向きだけならどちらでも良くて、昇順にやるならあとから見つかった同等以上の頂点で上書きする。■D 問題「183184」。とても難しい。解法もよくわからないし、計算量がどうやって抑えられるのかもわからない。事前に平方数を列挙してプリフィックスで分類する? 間に合わない。ルートで区間内にある平方数の個数を数える? 区間が連続してないんだよね。プリフィックス(C) が邪魔だし、プリフィックスを取り除いたとき D+x の部分がゼロで始まっていてもいけない。E 問題を通したあとで桁数を固定することを思いついた。下限の桁数で区間の下限を、上限の桁数で区間の上限を特別扱いしたら、それ以外の区間では下限を C10..0 とし、上限を C99..9 とできる(たぶん)。テストケース数 30 万に桁数を掛けてルートの計算量を掛けると計算量が不安だけど他に手はない。上限と下限にイコールが付くかどうか、それに合わせて上限と下限に +1、-1 する必要があるかどうか、WA を出しながら修正して3度目の正直で WA が1減ってまだ WA×3 (#70271576)。マルチテストケースで7割 AC は 99 % 正解では?


2025年10月16日 (木) ワンタイムパスワード離れが世界で進む、証券口座乗っ取りで多要素認証に脚光 | 日経クロステック(xTECH)」■記事の内容はまともっぽいけど見出しがワンタイムパスワードもパスワードに加えた2要素目であり多要素認証の一種だということを反映しておらず嘘になっている。意味のある区別を伝えていない。最近はよく知らないパスキーというのを見かけるので自分の理解を。多要素認証であってもワンタイムパスワードはフィッシングに弱い。何要素あっても本人が正しい認証キーを偽の、フィッシングサイトに入力するからそれを中継することで認証を突破されてしまう。グーグルがスマホに送ってくる確認メッセージも、それが何に対する確認なのかをタイミングで判断するからログイン操作を中継されるとフィッシングサイトにアクセスを許してしまう。パスキーは使ったことがないけど、Windows や Android が PC やスマホのユーザー認証によって Web サイトの認証を代行し、入力先の検証も人間がアドレスバーを見て判断するのでなく機械が自動で入力先とパスワード(※異議は後半を読んでから)のマッチングを行うのかなと理解している。それだったらインターネットブラウザのパスワードマネージャーでも同じことができていると思うので自分がパスキーを使う理由はまだない。■ブラウザのパスワードマネージャーの脆弱性にこんなのがあるらしい。「約4,000万以上のパスワードマネージャー ブラウザ拡張機能で機密情報が漏洩する脆弱性|セキュリティとITのニュース-セキュリティ対策Lab」。記事によればパスキーなら問題なしとなるわけではない。最近のブラウザはユーザーの1クリックなしではパスワードの自動入力を行わないけど、不可視のパスワード要素とクリックを誘発する広告などでユーザーに意図とは異なるクリックをさせてパスワードを補完してから外部のサーバーに送信することでパスワードを窃取するという。スクリプトで DOM を操作するので XSS とかブラウザ拡張によって可能になる手段。パスワードなるものの送信先を現在窓口になっている(アドレスバーに表示されている)ドメインに限ることで困らないんじゃないの思ったけど、「シングルサインオン」機能が死ぬからできなかったりしそう。認証に専用のドメインとサーバーを用意したいですか。とりあえず今の理解ではパスキーはいらずブラウザのパスワードマネージャーで十分なのかなと思っている。パスキーならではの利点ってなんだろ。■検索しました。「iOS・Androidも対応「パスキー」とはなにか? パスワード時代の終焉 - Impress Watch」。パスワードの代わりに鍵のペアを使用することと、ユーザー端末間で鍵の同期ができることがパスキーの利点らしい。弱いパスワードを使うより安全だし、強いパスワードを用意する面倒がないし、いちブラウザのパスワードマネージャーに閉じるよりも便利。なるほどなあ。ところで自分がパスキーに感じたことのある違和感というかかすかな不安は、自分が認証情報を管理していないというところにある。機械(自分のデバイス)にお任せは大いに結構だとしても、Google や Apple や Microsoft といった大きな存在にお任せしておけば万事オーケーですよという仕組みでは素直にうなずけない。Google アカウントも Apple ID も Microsoft アカウントも持っていないので、やっぱりパスキーはまだいらないな、ならではの利点はないなという判断になる。■サービスの旧ドメインに立てられたフィッシングサイトがサービスの新ドメインに認証情報を中継することを防ぐ仕組みはなんだろう。サーバー証明書? それの何で判断するんだろう。証明書を更新するだけで過去の認証状態がクリアされると不便だし、人間ならアドレスバーに表示される企業名で判断している……と思ったけど、「運営者 検証され信頼できる運営者情報はありません」にもかかわらず「安全な接続 このサイトとの接続は安全です。認証局: DigiCert Inc」って表示されるな。誰も接続先の確かさには興味がないまま無責任なことを言っているみたい。ユーザーが無事に新ドメインにアクセスしたときも、ユーザーが認証情報を管理していないのだからどうすることになってるんだろう。■ユーザーがパスキーを管理する例。「パスワードの代わりにパスキーでログインする - Google アカウント ヘルプ」のページに「パスキーを削除 / オプトアウトする パスキーを作成したデバイスを紛失したり、共有デバイスでパスキーを誤って作成したりした場合は、Google アカウントで使用するパスキーを無効にする必要があります」とあって、Google アカウントでの操作が案内されている。それで紛失したデバイスや共有デバイスからのアクセスをブロックできるとしたら二段階認証の段階で可能なことに思える。逆にそうでないとパスキーとは盗聴のための仕組みなのかと、自分が関知しない通信をどこへどれだけ行っているのかと疑う。パスキーはあくまでも1要素目(パスワード)の代替ということでよろしい? そしてやっぱり思うのは、認証情報のデバイスをまたいだ一元管理とオンライン同期は別の話であって、Google に一元管理させる一手はない。管理主体は自分自身以外ありえないし、それができない仕組みなら欠陥がある。■第三のサーバー。「パスキーの仕組み・設定方法・注意点などを知る (キヤノンMJ セキュリティ on ASCI)」。自分はこのページの図の9番に対応した FIDO サーバーの存在を認知していなかった。現在のパスワード認証でも外部のサーバー(Google、Apple、Yahoo とか)に当たり前のように認証を投げていて、口座情報や住所を押さえていて自分にとってよりクリティカルな地位を占めているサービスが第三者のお墨付きを鵜呑みにするのでいいのかと思わないではないし利用しないんだけど、してみるとパスキーはこれの延長上にあると見える。クレジットカードもそうだけど、無駄にプレイヤーが増えて関係が複雑になりコントロールが容易に自分の手から離れていく状況は避けたいと思っている。便利さならシンプルさのために捨てていい。次から次へと、未だパスキーの全貌が把握できたと思えないので、自分がパスキーを使うのはまだ早い。一見安全だろうが一見便利だろうがよくわからないコントロールできない長いものに巻かれたくはない。


2025年10月15日 (水) 10 年以上前に iPhone のホームボタンシール(立体丸形)を買ったことがある。たとえば青色 LED がまぶしすぎるモニタのフラットな電源ボタン(丸)に貼って透過率を下げる。おとついの日記(20251013)を踏まえるとこれは 16 年ちょっと前の話で、これが最初の使用例だった。たとえば USB 端子が中央からやや外れた位置にあって位置決めが難しい電子書籍端末の表面に目印として貼る。BOOX Max2 は物理ボタンあり額縁ありなので貼る場所には困らない。最近では電源マークが青色に光って浮き出るミニ PC のフラットな電源ボタン(角)に貼った。散乱する青色光を抑えるだけでなく、軽すぎて本体が動いてしまうところをピンポイントでボタンだけ押さえるためにでっぱりが役に立つ。5、6種類の柄が入っていたのがもうなくなりそうなんだけど、同じようなのを探すのが難しくなったなあという話。


2025年10月13日 (月) ポインティングデバイスに Logicool の TM-150 を使っている。2009 年から 17 年目。きっかけを考えると 2009 年頃に WUXGA のモニタを使い始めたはずで、たしかに MDT243WG も 17 年目だった。話がそれている。デフォルトでは進むが割り当てられている小さいボタンの1つを W10Wheel.NET というソフトウェアでホイール操作に割り当て直しているのだけど、ここのところホイールの動作が安定しなかった。押しているあいだはポインタの移動がホイールの操作に置き換えられるはずなのに、ホイールの操作が途切れがちだった。またスイッチの分解清掃が必要なのかなと思って開けたところ、スイッチを指で直接押したときにはきっちりボールの回転がホイールの操作に変換されているようだった。今回はスイッチが取り付けられている基板の固定が甘くなっていたのが原因で、スイッチを押した状態が維持できていなかったのだった。基板の後ろにやや厚めの紙(具体的には 3M の白い両面テープ)をあてがってガタを解消した今は快調。こういうこともある。■一時期再販されていた時期もあるらしいのだけど、知らないうちに販売が再開していて知らないうちに販売が終了してしまっていたのだよね。何度目かの再販を待っています。予備機の用意がないのです。右利きだけどキーボードの左に置いて使っています。他の形は受け付けません。


2025年10月12日 (日) [AtCoder] 今日は AtCoder Regular Contest 208 (Div. 2) があった。前回の ARC (Div.2) があったときは緑に落ちていたので Unrated で参加したが、今日は水色なので Rated で参加した。配点が 5-6-7-7-11 なので、欲張れば2問解きたいところだけど、1問も解けない可能性も十分にある。■A 問題「Bitwise OR Game」。Nim とか Grundy 数とか理解できないんです。どう落とし込むかを考えるところにすら立てない。■B 問題「Sum of Mod」。最初は mod の左右の項を取り違えていた。同じか小さい数で、同じか大きい数の mod を取るのが正しい。前の項にいくつプラスしたかの合計を K にしたいが、前の項の大きさマイナス1までしかプラスできない。前の項が小さすぎると、プラスできる上限が低くて、結果として数列の長さが伸びる。早く +K を達成してしまった後は同じ値を並べて項数を水増ししつつ末尾の項の値を増やさないでいられるので、問題はどれだけ遅く N 項以内で +K を達成できるかに限られる。そしてそれは初項の大きさのみに依存する。二分探索で。■C 問題「Mod of XOR」。結果を書くと、3通りの方法で答えの候補を探し、該当がなければなしと判断した。n^C mod n = X とはどういう意味か。とりあえず X<n が必要だけど、これは別に答えを規定しない。n^C が n より小さくなるとき、n^C = X であり、n = X^C。これが答えの候補の1つ。では n^C が n より大きくなるとき、n^C = n+X であり(本当? n+n+X は? 知らない)、当然のこと X<=C であるはず。X<C の場合は知らず X==C のときはテキトーに大きなフルビットの数((1<<31)-1 とか)^X が答えの候補になる。これが2番目。これが ABC の問題や 300 点 400 点の問題ならもう提出してしまうけど、700 点なのでまだ手を尽くす。数ビット程度のランダムケースと愚直解を眺めていると、他にも答えの候補があるが見つけられていないとわかる。いくつかのケースでどうすれば C と X から N が導き出せるかビット列をずーっと眺めていたら、C-X が偶数のとき、つまりこれが X<C のケースなのか、(C-X)/2 にテキトーに大きなビットを補ったものが答えの候補になるらしかった((1<<30)+(C-X)/2 とか)。これが3番目。残り時間が5分だったので時間切れにならないように注意しながら数分を使って愚直解と答えを突き合わせてももう未知の答えはないらしかったので提出して AC だった。A 問題が全く望み薄だったおかげで B と C に使う時間が十分に確保できたのが良かった。■コンテスト成績証。1803 の青パフォでした。