/ 最近 .rdf 追記 設定 本棚

脳log[2022-11-04~]



2022年11月04日 (金) AtCoder Type Checker「ds14050 さんのスコアは 0.06 です。中間的なタイプです。/ds14050 さんの内部レート: 1438.00/計算に使用したコンテスト数: 182/ds14050 さんの平均順位率: 0.4461/内部レートによる補正値: 0.4455 (ds14050 さんと同程度の内部レートの人が取得している、平均的な平均順位率)」■得点が同じ人同士で比べたときに 100 人中 44 位くらいの位置(早さ)にいるらしい。その位置というのが自分と同レートの人の平均とほぼ同じなので、「中間的なタイプです」。Ruby を使っていてソースが短い(タイプ数が少ない)ことを勘案すると、考えるのもタイプするのもかなり遅い部類なのでは? 言語ブーストがあってやっと中間。再度「俺の脳みそのクロック周波数は常人の3分の1だ!


2022年11月03日 (木) [AtCoder] 精進。ARC004-C「平均値太郎の憂鬱」(青 diff)。以前に埋めようとしたときは B 問題までしか埋められなかった。この問題の鍵は N の範囲をどこに限定できるかということに尽きる。以前はそれが不十分だった。今日は上と下の両方を抑えることができた。こう (1+2+...+N-1)/N <= X/Y = (1+2+...+N-M)/N < (1+2+...+N)/N) 以前はそもそも上と下の両方を抑えようという意識が働かなかったと記憶している。雰囲気で片方を抑えてそれで?って感じ。ぼんやりしてら。■しかし罠が2つ。提出 #36180781 (WA×8)。考えられるすべての N と M を N の昇順に出力することが求められていたのに1組しか出力していなかった。提出 #36180916 (WA×5)。分子と分母にまったくどうでもいい数が共通に掛けられているケースに対処できていなかった。「ただし、入力は既約分数とは限らない」とはそういう意味。約分している場合もそのままの場合もあるというだけではなく、無駄に数字をふくらませている場合があった。■提出 #36181139 (AC)。テストケースがあればデバッグが捗っただろうけど、古い ARC のは公開されていない。


2022年11月02日 (水) 6年2組のマグカップにひびが入っていた。底から側面に筋が見える。大きさと形がちょうど良くて愛用していただけに残念だ。割れた陶器って研ぎ立ての刃物と同じくらい、つまり普段使ってる包丁よりずっと良く切れるからね(経験者語る)、中身をぶちまけたくもないし、今後は置物にするのがいいだろうなあ。■ちょうどいい大きさと形っていうのは、大きいところと、しゃれたところのない素直な形だってところ。よくある 330 mL (の8分目)では飲みたい一杯分より少ないし、口の広さも底の小ささも容量と安定を損なう。キャンバスとしての用を求めたマグカップが並の商品より完璧に実用的だった。■計ったらすりきりで 500 mL のものを8分目から9分目で使用していたらしい。このサイズ全然ないよね。■計量カップを使用した回数に比例して誤差が蓄積する。3回で計ると 500 mL だけど2回で計ると 400 mL とちょっとだった。普段の1杯は 400 mL ちょっとの8分目で 320 mL とちょっとというのを最終結論にしたい。■次に使うのは「となりのトトロ スペシャルコレクション マグカップ(たんぽぽ編)」。かわいいものが好きです。実物のサイズ感は不明だけど 400 mL 弱はまあまあ満足できる容量だと思う。サーモスの真空断熱マグが容量と形の面から最適で、さらに付加価値(断熱)まであって最初に目を付けたんだけど、ステンレス製は飲み口に不安がある。複合素材にしたらしたでそれ相応の面倒があるし、蓋なしの保温性は限定的。さらに電子レンジが使えないときた。もう何年も電子レンジがない生活だけどいつまでもないとは限らない。この用途には陶磁器が無難かなと。(サーモスのケータイマグはせんユニットやパッキンを交換しながらもう4年使ってるよ! 買い物バッグもレジ袋有料化前からサーモスの保冷バッグだよ! (謎フォロー))■届いた。肉薄(※肉厚の反対でニクウスのつもりで書いたけどこれはニクハクと読むらしく意味が違う。ここではニクアツノハンタイと読んでくれ)なので横から見るとコンパクトだけど上から内容積を見比べるとそれほど遜色がない。計るとスペック通り 400 mL 弱と強の違いがあって、その差 30-50 mL。これまで使っていたのよりおよそ 10 % 少ない。事前の予想通り「まあまあ満足できる容量」だと思う。


2022年10月31日 (月) [AtCoder] 精進。先週末あった ABC275-F「Erase Subarrays」(ぎりぎり青 diff)。本番中は区間 DP なのかなとか左右からの DP なのかなとか実は一方からの DP でいけるのではとか考えるもまとまらなかった。直前の要素から連続するのかそうでないのかでコスト計算が変わってくるんだけど、それをうまく扱えなかった。■AtCoder に関連して流れてきたツイートを読んだ。こちら「難しい問題だが、独力で解けた。連続部分列の DP は直前の要素を使用しているかをフラグとして持ってあげるとよいことが分かった。また、配列内の足し算は注意が必要(今更感のある知見だが。。。) 提出 #36113489 - AtCoder Beginner Contest 275 https://t.co/4ka1Ik7YoZ」 「直前の要素から連続するのかそうでないのかでコスト計算が変わってくる」ことがわかっていても「直前の要素を使用しているかをフラグとして持ってあげるとよい」と明示されることが問題解決のヒントになるのだなあ。■提出 #36122711 (TLE×4 / 2191 ms) のち 提出 #36123362 (AC / 1864 ms / 107396 KB)。Ruby によるすべての提出を見ると他の2つの AC 提出と比べてメモリ使用量が5倍以上ある。なんか違うことをやってんだろか。■提出 #36124108 (AC / 1452 ms / 45264 KB)。メモリ使用量の差は Hash か Array かの違いだと思ってまねしてみたけど、時間もメモリもなんか違う。それに AC 提出の片方のメモリ使用量を1桁読み間違っていたこともわかった。18 メガじゃなくて 180 メガだから自分のと大差なかった。だいたい同じことをやってるよ。


2022年10月28日 (金) [B! security] フォーム入力支援やサイト最適化サービスの改ざんについてまとめてみた - piyolog」■ブコメで「サブリソース完全性」について知った。関連>20220520。だけどこれ活用が難しいよね。ハッシュ値が提示されていなくて検証できません、というケースがほとんどだろうから。もちろん正しくやりたいところが正しくやる手段が用意されているのはいいことだけど、閲覧者の視点から正しさや完全性を求めると、やっぱりアクセス先とは異なるドメインから来るリソースは基本的に拒否することになる。それができるのは偏屈な人間だけだから、あいだをとって、検証できない外部リソースは基本的に拒絶されますよ、という世界が訪れることがあるだろうか。あと別のブコメが、スクリプトが読み込むスクリプトが改ざんされたら integrity 属性も役に立たないだろうと書いている。まあ、そうだよね。それだけの自由と信用を Web ページは埋め込む外部スクリプトに付与しているということだ。というか形式から言っても連帯責任のごとく一体のものと見なすのが妥当だと思うので、外部スクリプトが仮になにか悪さや粗相をしたらすべての責任がまず Web ページをサーブした者に生じると考えていいのでは。これは理想世界での事後の話。現実世界で事前にできることは。無責任の連鎖に巻き込まれたくないので自分はスクリプトを許可しないわけです。それで壊れるサイトには近寄らないのです。いつでもそうできるといいね!■■■「オリジン間リソース共有 (CORS) - HTTP | MDN」を読んだ。いくつかシナリオがあるっぽい。一番単純なケースでは、リソースをホストしているサーバーが Access-Control-Allow-Origin ヘッダを使うことで外部からの使用可否をコントロールできるっぽい。しかし、しかしだね、そもそもの目的がリソースただ乗りの制御にあるのではなくて、同一オリジンへのリクエストだけを許されたスクリプトに抜け穴を提供するために用意されたように見える。ブラウザは img タグなどを含むすべての外部リソースについて Access-Control-Allow-Origin を確認しているのだろうか。Web はいつの間にかそのようなものになっていたのだろうか。もちろん違うはずで、抜け道に対して「オリジン間 HTTP リクエストのリスクの緩和に役立てています」とはどういう皮肉か。■きっかけはこのツイートだったんだけど、「@chokudai AtCoder の API に Access-Control-Allow-Origin など CORS 指定がないのにはなにか理由があるのでしょうか? これがあれば、有志ウェブサイトが AtCoder の API を叩くためだけに Heroku などに依存する必要がなく、GitHub Pages などでの静的ホスティングが可能になると思うんですが…」、Heroku を利用することで何がどう可能になるのかがまだわかっていない。難しいね。Heroku の無料プランがなくなるんだっけ? そうすると有志ウェブサイトは何ができる?


2022年10月22日 (土) [AtCoder] 精進1。今日あったキーエンスプログラミングコンテスト2022(AtCoder Beginner Contest 274)-F「Fishing」(黄 diff)。解答の方針はすぐにわかった。幅 A の区間で魚を捕るときに中途半端な範囲を選ぶ理由がないので、ある魚が x にいるタイミングで x+A までの範囲で魚を捕る。ある魚と他の魚の関係は、(初期位置の前後)×(速度差)=(追いつく、追いつかれる、逃げられる、逃げ切る)の4通り。魚ごとにタイムラインを再生して区間内にいる他の魚を管理する。■提出 #35895537 (WA×8)。時間内の提出はこれ。WA の原因は3つ(!)あって、1つは 21 行目 t = (A+dx).fdiv dv。これは「追いつく」関係のときに追い越してしまって幅 A の区間から出てしまうタイミングを計算する式。正しくは t = dx.fdiv dv。2つめは 11 行目と 19 行目 でハッシュのキーに 0 を使っているところ。0 と 0.0 をソートしたら結果が不定になった(Ruby 2.7 の場合)。それではハッシュを入る方と出る方の2つに分けた甲斐がない。実数で閉区間は扱いにくいんよ(どうして区間を x+A 未満にしてくれなかったのか)。キーが 0 であれ 0.0 であれ入る方を必ず先に加算しなければいけないのにできていなかった。3つめは「追いつかれる」ケースの処理を忘れていたこと。■提出 #35903826 (AC / 712 Byte / 2942 ms)。これだけミスがあって時間もかかるなら解けた喜びしかない。なんにも惜しくない。■■■精進2。同じ ABC174-E 問題「Booster」(水 diff)。時間中は F 問題にかかりきりで読まなかった。ブースターを使う使わないを総当たりしてダイクストラ法かなと考えたりもしたけど、どうにもはまらない。むしろ巡回セールスマン問題(TSP)だった。■提出 #35902406 (AC / 674 Byte / 1847 ms)。これまで2問くらい TSP(roblem) を解いてるけど久しぶりすぎて忘れていた。ワーシャルフロイド法と同じ見た目をしていることを思い出すのに時間がかかり、何とか書き上げても TLE を2回食らった。以前にタイムを詰めに詰めてこれが決定版と言えるものを作ったんだけど、内容を覚えていないしどの問題かも思い出せなかった(そのときに競ってアイデアを提供してくれたアカウントは覚えている。精進中に見かけた名前を最近またコンテストで見るのは嬉しいものだけど、逆もあって寂しい)。唯一思い出したのが 12 行目の 1,0 = (N+M).times.partition{|b| 0<vs[b] }。これで TLE が解消した。


2022年10月20日 (木) [Ruby] 以前に max_of メソッドの不在について書いたけど(20210715)、もうひとつ、ことあるごとにリファレンスを探してみてはないなあとがっかりするメソッドが Bignum#flip (Integer#flip)。Bignum って性質としては数値より文字列に近いはずで、だからインスタンスを無駄に大量に保持したり使い捨てにしたりするのが MLE (メモリ使用量過多) や TLE (実行時間過多) の原因になると考えている。いきおい1つのインスタンスを大事に使い回しする使い方になるんだけど、だけど、インスタンスへの作用のさせ方が big |= 1<<k とか big ^= 1<<k になる。|=^==|^ を使ったシンタックスシュガーだとしたらそれも残念だけど(でもそうだよね?)、1 ビットに作用させるためだけに Bignum の一時インスタンスを作成して、桁数に比例したビット演算をさせているのが(たぶん)、もったいなくて仕方がない。リファレンスを漁るけど flip メソッドが見つからない。bitset みたいな特別な道具としてではなく普通の整数で多倍長のビット演算ができるところが、速度で不利になりがちな Ruby が強みにできるところであるので、機会を逃さず Bignum を酷使していきたいと思っている。これは昨日の日記(20221019)への言及。


2022年10月19日 (水) [AtCoder] 精進。先週末にあった ABC273-F「Hammer 2」(黄 diff)。当日は終了直後にプライオリティキューを使った愚直シミュレーション解を投げて TLE を食らっていた>提出 #35695089 (TLE×28/AC×74)。実は TLE の背後に WA が隠れている。今日はもうちょっと手をかけて効率的にシミュレーションをするようにしたところ AC が出た。■提出 #35789620 (AC / 1898 Byte / 63 ms)。方針はこう。スタート地点から左右2手に分かれて駒を進めていく。右へ進んだ駒が壁にぶつかったら、その壁に合うハンマーを手に入れるのにどれだけ移動する必要があったかを左に進んだ駒に尋ねる。ハンマーにぶつかったら、逆に左に進んだ駒に教えるために現在の移動距離(+原点に戻るまでの距離)を保存する。左右どちらの駒もそれ以上進めなくなるまで交互に進めていく。工夫のしどころは壁の並びに合わせてハンマーに序列をつけることと、序列順に並べたハンマーの揃い具合をキーにして移動距離を保存したところ。揃い具合というのはビットフラグそのままではなくて、手前から何番目の壁まで漏れなく対応するハンマーが揃っているか。事前準備もいろいろやった。まず、ゴール(X)より後ろにある壁と対応するハンマーはないものとする。壁と対応するハンマーがスタート地点から見て同じ側にあって、ハンマーの方が手前にあるときもないものとして良い。ゴールより手前にある壁であって、対応するハンマーがその壁の向こうにあるものがあれば到達不可(-1)。このような事前準備をする意味は、壁もしくはハンマーにぶつかったとき、それは必ず反対側に進んだ駒に関わるものだという状況を作ることにある。一部例外はあって、ゴールと反対側にある絶対に通れない壁(とその向こうにあるハンマー)は判断を保留して残したけども。これが嘘解法だったらもう知らない。計算量のオーダーが狂っていて非常にありそうではあるけれど。左右への移動回数の合計が N 以下で、その中にあるループで書き込む移動距離の総数も N 以下。でも Bignum の桁数が N 以下だから結局 O(N^2) になるのかな。■「アライグマ「F問題は区間DPなのだ! DP[L][R][f]=いままでにいったことのある左端がLで右端がRでいま(f?右端:左端)にいるときの移動距離の最小値 とすればいいのだ!」」 わからないのだ! F 問題あたりにあって DP っぽいけど解けないなーって問題がだいたい区間 DP だと最近気がついたのだ。■自分の解法の O(N) の部分を上手くやる方法がないかなあ、ないかもなあとちらちら考えている。それというのは、ランダムなビットを立てていく、だけど決まった順番で立てていくときに、そのときどきで最も右にある 0 のビットの位置を知る方法。今は N 桁(≦1500)のビット演算でやっている。これをやる LIS のような、あるいは BIT を使った上手いやり方がないものかなあ、と。ビット演算で上手くやる類の問題だということがショートカットの不在を暗示しているような気がしている。……。いやいや、普通に右端の 0 の位置を覚えておいてその 0 が埋まるたびに次の 0 を探すようにすればループ全体で長さ N をなぞるだけになる。■提出 #35802156 (AC / 1813 Byte / 63 ms)。元が Bignum の定数倍の良さに助けられてほとんどインタープリタ起動のオーバーヘッドのみの時間だったので、63 ms から良くはなっていないけど、O(N^2) から O(N) になったのではないかと思う。あとは嘘解法でなければ。■解説放送「パナソニックグループプログラミングコンテスト2022(AtCoder Beginner Contest 273) - YouTube」で 区間 DP から先の考察をやっていた! 壁すら取っ払って必須の(折り返ししなければいけない)ハンマーを左右交互に取るところまで突き詰めていた! それを前提にしてさらに先へ行こうとしていた! でもこういうのって聞かされても理解できはしないんだよなあ。■提出 #35802759 (AC / 1819 Byte / 62 ms)。String#index メソッドに第2引数を渡し忘れるミスで O(N^2) になっていた。今度こそ本当に O(N) のはず。タイムも間違いなく誤差だけど 1 ms 縮んでいる。■あ、事前準備でソートが避けられないから O(NlogN) にはなるのか。解説放送(まだ見てる途中)でも O(N) だとは言ってなかったしな。


2022年10月18日 (火) 高速道路の PA で手を洗おうとトイレに入ったけど、自分が持ってる洗面台の概念とあまりにかけ離れていて他の人の行動を観察してしまったよ。なお、使い方を知るまでに複数人の観察が必要だったもよう(素通りする人がいた)。不特定の人間が利用する場所で知ってる前提の奇抜なデザインやめてくんない。なんかね、傾斜のついた2枚の黒っぽい板が高さを変えて向かい合っていて、UCC の缶コーヒー(茶白赤のやつ)くらいの長さ太さで銀色の円筒が奧から突き出ていた。蛇口だということがわからないしセンサーの存在がわからないし2枚の板がつくるスリットが排水溝だということがわからない。鏡はあったかな、あったとは覚えていない。文字と絵はなかった。以前にダブルクリックというのは確信を持っていないとできない操作だと高校生時分の実感を書いたけど(小学生の頃はマウスが一般的ではなかった。中学生の頃は PC がそばになかった)、この洗面台もそう。用途を明らかにして手を差し出すターゲットを見せてくれ。俺は実験室に未知の道具とともに放り込まれたサルじゃねーんだ。


2022年10月17日 (月) 「百合太極図」覚えた。これはいい命名。「OPのこのスレッタちゃんとミオリネが回ってるような構図を百合アニメでよく見るなって思っていましたら中国で「百合太極図」という名称が付いていてまた一つ勉強になりました。 #水星の魔女 https://t.co/xFNBxdECxL」 アニメじゃないけど『ハーモニー』のシライシユウコさんバージョンのカバーもそう。ジャケットで選んで J コレクションの本を買ったよね。


2022年10月16日 (日) [AtCoder] 今日は ARC151 があった。終了3分前にノルマの2完達成。自分のすべての提出。1完も珍しくないのですごく嬉しい。開始9分1完(早解き)と終了3分前2完(遅解き)のパフォーマンス差がないに等しいとしても、とても嬉しい(昨日書いた通り>20221015)。■A 問題「Equal Hamming Distances」。ハミング距離って初めて知った(たぶん聞いたことはあるけど興味がない)。定義をよく読む。i 文字目の不一致を数えた数らしい。S,T から等ハミング距離にあって辞書順最小の文字列を作る問題。先頭から見ていって、S[i]/T[i] が一致しているなら 0/1 どちらを選んでも(ハミング距離が増えるにしても増えないにしても) S,T 双方からのハミング距離は変わらないので 0 を選ぶ。S[i]/T[i] が異なるときはどうするか。一方を選べば他方からのハミング距離(だけ)が増えるのでバランスを取らなければいけない。そこで不可能(-1)を出力するケースが理解できた。S,T の不一致が奇数文字のときはバランスが取れないので不可。偶数のとき、その半分の回数だけ S[i] を選び、同じく半分の回数だけ T[i] を選ぶと S,T 双方からのハミング距離が等しくなる。もちろんできるだけ S[i]/T[i] のうち 0 の方を選ぶ。■B 問題「A < AP」。解説のように対称性に気付けるわけがないので、先頭から見ていって見ている文字で初めて A<AP になるケースを数える方針で考えた。そのために4つの場合分けを長らく、1時間以上考えていた。4つというのは、A[i] と A[P[i]] のそれぞれが初出の場合と既出の場合(k<i として A[P[k]] としてすでに参照されているかどうか)。既出の要素というのは A[k]=A[P[k]] という拘束条件があって独立して M 通りの値を割り当てられるわけではないので、それをまず知る必要があると思ったのだ。A[i] と A[P[i]] がどちらも未出の場合は簡単で M*(M-1)/2 通りの割り当てパターンがあり、その他の未出の要素それぞれにも M 通りの割り当てがある。しかし既出の要素の扱いに困った。値が連動する既出の要素は……。まず、既出の要素であってもほぼ自由に M 通りの値を割り当てられるということがわからなかった。k<i となる k において A[k]=A[P[k]] という拘束条件があり、A[P[k]] = A[i] であることも A[P[k]] = A[P[i]] であることもあるけど、A[i] と A[P[i]] に関わらない限り連動するその値は M 通りから好きに選べるとわかっていなかった。なにか拘束条件が連鎖して階段状の大小関係があると思っていた。既出の要素でもほぼ未出の要素と同じように M 通りから選べるとわかったときに答えの計算方法がわかり、既出要素のグループを見出して UnionFind を持ち出すところまで時間はかからなかった。B 問題は難しい問題なのではなくて、隅々まで理解するのに時間がかかる読み手に問題があった。まあ、そこが難しさなんだけど。


2022年10月15日 (土) [AtCoder] 今日はパナソニックグループプログラミングコンテスト2022(AtCoder Beginner Contest 273)があった。コンテスト成績証 - AtCoder自分のすべての提出。F 問題に黄色の壁があったからなのかなんなのか、2度目の黄パフォは棚ぼた以外のなにものでもなかったな。AC までにかかった時間が A=1分半、B=3分、C=8分(うち問題文が理解できるまで5回以上読み直すのに体感10分)、D=14分、E=8分なのだから、単に解ける問題を早く解いただけ。せめて時間があるときは壁を越えたい(早解き遅解きでパフォーマンスに報いがないとしても)。■いいパフォーマンスだったので気分良く振り返っていこう。■A 問題「A Recursive Function」。他の人の提出にある factorial という関数名を見て、階乗を求める関数だったと気がついた。N が 1 ギガとかでもなければ定義の通りに実装するだけです。Hash のデフォルトプロックを使って実装した。再帰関数と比べると…… 1.(今回は不要だったけどフィボナッチ数を求める場合などに)自動でメモ化される。2.再帰の停止条件が関数の外に書けてすっきりする。3.(デメリット)呼び出しが遅い。■B 問題「Broken Rounding」。他の人の提出で知ったんだけど、Ruby の Integer は高機能な round メソッドを持っていてそれが使える。そういうメソッドは小数にしか期待していないので知らなかったな。K 回割って K 回掛けて答えを出した。■C 問題「(K+1)-th Largest Number」。問題文が理解できないしサンプルの解説が理解できないし何を出力するのかもわからなかった。嫌がらせなの? 5回以上読み直したし2回は飛ばして D 問題へ行こうとした。問題の輪郭がやっと見えてきても大きい数が K 個なのか K 種類なのかという罠があり、ほんと嫌がらせなの? ひとたび理解できれば Array#tally で得られる数字がほぼ答えだし、足りない 0 を補えばそれが答え。それだけのことをよくも難しく文章にしたと思う。■D 問題「LRUD Instructions」。グリッド問題は制約を一番に見る。すべてのマスをなぞれるのかどうか。今回はできない。壁の数(の上限)がおなじみ 20 万個だから、グリッドはメモリ上に実体を確保せず仮想的な存在にしておき、壁の位置を扱いやすく蓄えてそれを処理対象にする。行ごと列ごとにソート列として持っておいて二分探索をする。変数名について。他の(複数の)人の提出を見ると、ある行にある壁の座標(列番号)列を蓄えるのに R や R の付く名前を使っていた(列に対しては C が付く名前)。こういうデータとアクセス方法になる。R[r1] = [c1,c2,c3] Ruby の AC 提出を順番に見ていったけど、独特な例外を除いてほぼそういう、自分と逆の命名なのがおもしろいなと思った。どう読むんだろう。walls_of_row[r1] という感じで、添字の r1 が変数名の row を修飾すると読むのだろうか。それは良い。でもそれを縮めたときに何を残すのか。R[r1] や row[r1] にすると、「行 r1 (のデータ)」しか読み取れない。すべてがワーキングメモリに収まる競プロではそれで十分ではある。しかし……。自分が C[r1] = [c1,c2,c2] という名前を付ける気持ちは、C(olumns) of r1 = c1,c2,c3 というもの。利用するときは cs = C[r1] という形で名前が揃う。名前を揃えるのが「間違ったコードは間違って見えるようにする」原則に沿うと思うからそうしている。行に対して列以外の別次元の情報が1種類か2種類付け加わったときにどうするかを考えてみてもいいと思う。■E 問題「Notebook」。4つの操作を読んでデータがどういう形に育つかを考える。必要なのは末尾の1字。ただし ADD の履歴が必要。DELETE & ADD により分岐して先が分かれる。ノートはポインタ。ノートの存在によりすべての履歴が最後まで参照できなければいけない(データを使い捨てにできない)。自分は逆向きのリンクリストだと思ったけど、Git のデータ構造を連想した人はさすが。2009 年出版で今ではもう古い部分もあるかもだけど根幹は変わらないだろう、『入門 Git』(著:濱野 純(Junio C Hamano))にそういうことも書いてある。Git は名前の変更を追跡していないヒューリスティクスでやっているということは書いてなかったかな。その疑問にはっきり答えてくれたのは GitHub ブログ「コミットはスナップショットであり差分ではない」。コミットがスナップショットなら名前の変更(スナップショット間の関係)のありかが気になるというもの。きちんと答えてくれていた。■F 問題「Hammer 2」は DP かなと思ったけど頭のいいことが思いつかないのでプライオリティキューで素直にシミュレーションをした(そもそも頭の良さは思いつきの良さではないという説)。結果は (TLE×28/AC×74)。まあそうでしょう。後日>20221019■解説放送「パナソニックグループプログラミングコンテスト2022(AtCoder Beginner Contest 273) - YouTube」で E 問題に関連して木構造の Undo/Redo の話題が出ていた。それは TATEditor のことか。履歴の見せ方が難しいだろうなあとは思う。


2022年10月14日 (金) [AtCoder] 精進。日曜にあった ARC150-B「Make Divisible」(水 diff)。何か所かで (B+Y)=(A+X)*M の X と M のどちらかを全探索すればいいと読んだ。当日は X だけを全探索する TLE 解を書いていた>提出 #35546704。M を探索すればいいというけれど、いつ M を探索すべきなのか、M の範囲をどこに限れるのか、M を決め打ってから X と Y を求めるプロセスは、どれもよくわからない。■提出 #35646915 (AC / 276 Byte / 108 ms)。M の範囲は Y が B を超えないように選んだつもり。X と Y の求め方については、A*M が B 以上の時は X=0 として Y=B-A*M。A*M が B 未満の時は不足分を X*M で補って B を超えた分が Y とした。答え合わせをしながらたどりついたのであって、ヒントがあってさえよくわからなかった。