/ 最近 .rdf 追記 設定 本棚

脳log[2022-02-27~]



2022年02月27日 (日) [AtCoder] 今日は ARC136 の日。Writer を見ればゼロ完も覚悟するんだよなあ。幸いにも A 問題でおもてなしを受けました。B 問題からはお察し(脳みその程度を察してください)。


2022年02月26日 (土) [AtCoder] 今日は ABC241(Sponsored by Panasonic)があった。結果は ABC の3完。40 分考えて D 問題「Sequence Query」が解けなかった。途中から E 問題「Putting Candies」に浮気してそちらは 20 分で解けたけどコンテストは終了していた>提出 #29711639 (AC)。これは ABC175-D「Moving Piece」と同じ問題だった(どちらかといえば易しいくらい)。そのまま F 問題「Skate」にとりかかって 25 分で解けたけどコンテストは終了していた>提出 #29714203 (AC)。これはやるだけの問題だった。3完だけど5問解けたのでヨシ!■D 問題>提出 #29718230 (AC / C++)。C++ だと multiset と lower_bound/upper_bound が使えますか、というだけの問題になるんだけど、Ruby で通してる人がいる以上 C++ は甘えなんだよなあ。Twitter で読んだけど ABC217-D「Cutting Woods」を Ruby でまじめに解いた人は対策ができていたらしい。自分はテストケースの悪意を読んだヒューリスティクスで Array だけを使って通したので対策はなかった>提出 #26804547。■C 問題「Connect 6」も実は遅い言語には厳しい制約で、盤面の大きさ 100 万に対して係数が 24(=6×4) は 3 秒でもさすがに通らないだろうと思われた。縦と横だけテキトーに高速化するのに 45 分かけて WA も一度出しているあたり、がんばりましょうという感じ>提出 #29690673 (AC / 2088 ms)。■E 問題と F 問題の軽さに対して C 問題が重く D 問題が重すぎた。どんな本でもはじがきと目次と1章から順番に読む以外の発想を持たない人間のことを考えて問題列を構成してほしいものだ(わがまま)。■■■さっき書いた。「Twitter で読んだけど ABC217-D「Cutting Woods」を Ruby でまじめに解いた人は対策ができていたらしい。自分は(略)なかった」 嘘だった。別解として BIT バージョンを通していた>提出 #28790707 (AC)。「対策」とは値から添字を逆引きする BIT のあまり一般的ではないメソッドのことであり、これを通したのがちょうどひと月前だってのに、どうして今日通せなかったの?■@2022-03-01 20220228で (30,60)-木を使って通したあとだけど、コンテスト中の最初の方針であった BIT を使っても D 問題を通したよ>提出 #29790983 (AC / 1944 ms / 後註)。Hash ベースの BIT でギリギリ間に合ってるのに最初の提出(Array ベースの BIT を使っていて有利)で RE/WA/TLE になったのなんでだろう。ともあれ、WA の原因は BIT の使い方に間違いがあったからなんだけど、貼り付けた自分のコードが信用できなくてサンプルを合わせるときに手を入れる場所を間違えたんだな。RE/WA だけならデバッグをがんばれたけど TLE もあったので諦めてしまった。□(註) さっきの提出のコメントに嘘があった。「アクセス可能な範囲(0..@n-1)なら」の正しい範囲は 0..@n-2。スクリプトは合ってる。コメントだけ嘘。


2022年02月25日 (金) [AtCoder] 「すべての提出」ページの仕様が微妙に変わっていて、セミコロン区切りのパラメータが受け付けられなくなってる。ブックマークレットを修正した。URL を HTML(※CDATA にしていない SCRIPT タグの中も)に埋め込んだときに & を &amp; に置き換えるのが煩わしいから(そもそも、忘れていませんか?)最初はセミコロンを使うんだけど、使えないことはまあまあ、わりと、珍しくない程度にある。フレームワークが必ずしもお手本を実装していない。■「HTTP query string」で検索したら、標準はないとあちこちに書いてある。その中で英語版の Wikipedia「Query_string#Web_forms」から。「The series of pairs is separated by the ampersand, "&" (or semicolon, ";" for URLs embedded in HTML and not generated by a <form>...</form>. See below).」「This convention is a W3C recommendation.[6] W3C recommends that all web servers support semicolon separators in addition to ampersand separators[9] to allow application/x-www-form-urlencoded query strings in URLs within HTML documents without having to entity escape ampersands.」 W3C がってところが今となっては、かなあ。もちろん立場が違えばセミコロンが解釈できなくて話が通じない相手とはそれまでっていうのが自分のスタンスなんだけど、AtCoder には合わせるしかない。■@2022-03-07 最近 OpenBD のデータが、抜けているというより常に取得できてないなと気がついて見たら、セミコロン区切りのせいでクエリが失敗するようになっていた。ここでもなのか。


2022年02月23日 (水) [AtCoder] 精進。ABC010-D「浮気予防」(青 diff)。ABC239-G「Builder Takahashi」を解こうとして思い出したのが考えても解けていなかったこの問題。浮気予防を解くために浮気予防の解説を読むのは癪だけど、Builder Takahashi を解くために浮気予防の解説を読むのは許されるような風潮が、あるとは思いませんか(そもそも禁じられていない)。読んだら最小カットだって。聞いたことだけはある。蟻本を開いたらちょうどのページにしおりが挟んであった。TODO ということでありまだ理解できていないということ。190 ページのプログラムを Ruby に翻訳しただけ>提出 #29610100 (AC / 366 Byte / 89 ms)。ソースコードを見れば一目瞭然だけど、高橋くんのギルティは疑いようがない。本命の Builder Takahashi はわかりません。


2022年02月22日 (火) [Xperia 10] 購入前に悩んでいた(20190511)携帯手段について書いていなかった。端末と同時に買ったガラスフィルムとプラスチックケースを付けて布袋「日本製 スマホケース 帆布 手作り スマートフォン用ポーチ iPhone6/Samsung マルチケース Lサイズ (インディゴブルー)」に入れたものを前ポケットに突っ込んでる。カラビナにベルトを通して。Xperia 10 は長いからどうしても片方の角がポケットから出るし、たとえばトイレでズボンを下ろしてしゃがんだ時にはポケットの天地が逆向きになって落下しそうになってるんだけど、ボタンがあるので安心。位置的に車から降りようとして振り向くような動きをするときに角が削れそうになるのだけは注意かな。プラケースと筐体の左下隅が 1 mm ほど欠けてる。帆布製のケースは内寸が 16 cm 強で、Xperia 10 が 16 cm 弱だから、あつらえたように 5 mm ほど余裕を残して収まって無駄も不足もない。スナップボタンの裏側は裏地に隠れていて傷を付ける心配がない。もっとも、画面の側が太ももに向くように(そして逆立ちするように)しまうんだけど。この布袋を見つけたから今 Xperia が持ち歩けている。携帯できない電話ならいらねーんだ。これは今の Xperia の大きさや比率に不満があるということではなくて、むしろ電話らしいフォルムを保っていることが重要なファクターだった。人間の耳と口の位置は決まっているわけなので、短さや小ささが必ずしも正義ではない。スライド式(20071026p01)や折りたたみ式でないことが残念ではあるけど、それだって画面の広さや薄さをトレードオフとして差し出して得られるものなので、懐古趣味の無い物ねだりではある。


2022年02月21日 (月) [AtCoder] 復習。おとといの、だけど前々回の ABC、デンソークリエイトプログラミングコンテスト2022(AtCoder Beginner Contest 239)-F「Construct Highway」(青 diff)。頂点数と辺の数から木であることを読み取り十分に利用しなければいけない。コンテスト中唯一の提出は終了3分前のこれ>提出 #29471962 (WA×18 / AC×11)。木である条件が十分に詰められていなかったし、効率にも配慮できていない(ループ中の find メソッド)。■数時間後の提出 #29479636 (TLE×7 / AC×22)。効率にも配慮したつもりだったけど当然起こりうる状況が想定できていなくて、24 行目の flat_map が予想外に非効率で TLE。単要素の配列が信じられないくらい大量に作られることになる。■さらに2時間後の提出 #29483013 (AC)。この問題のキーであるあと1本だけ辺が欲しい連結成分を特別扱いすることで効率を改善して AC。おまけにソートもなくなった。ところで、不可(-1)を出力して終了する no! メソッドの呼び出しが8か所もあるって多すぎだよね。■今日の提出 #29561496 (AC)。no! の数を5個に厳選してそれぞれに理由を示すコメントを付けた。保険のための余分な no! はもうないと思う。もっと減らしたかったけど 22 行目の no! if U[a,b] の no! を取り除くとダメになるケース(8 4/3 3 3 1 1 1 1 1/1 2/1 3/2 3/7 8)がある。この提出 #29483417 (WA×1) を阻んでいる random_21.txt が同等の(無駄な辺と森化による辺の必要数の減少が相殺する)ケースだと思う。■■■E 問題「Subtree K-th Max」。最近似た名前の問題がありましたね>「Prefix K-th Max」。一読して表現の微妙な変化に気がついたんですよ。ABC234で「K 番目に大きい値」という表現だったものが ABC239 では「大きい方から Ki​ 番目の値」になっていた。それが「中途半端な値は見ようによって大きい値でもあるし小さい値でもある。自分に言わせればそれは単に「大きい方から K 番目の値」なんであって、大きい値でも小さい値でもない」をうけての変化だとは思わないけど、自分が理解しやすい表現になっていたのは間違いない。それなのに AC 前の5分で 2 WA しました(WAWAAC)。読んで、表現の変化にも気がついて、でも結局間違えるんだ。手癖で書いてるってことなんだろうなあ。■「AtCoderの公式生放送「あーだこーだー」 第51回 - YouTube」を聞いていると E 問題「Subtree K-th Max」に関連して Wavelet Matrix の単語が何度も聞こえてきた。E 問題では K の上限が意図的に小さく抑えられていて、ここを突破口にして解けよ、というヒントがあからさまだったけど、さもなければ Wavelet Matrix を使って解くことになったらしい。Crystal では通ってるぽいのに Ruby で TLE になるの悔しいよね。通ってほしい。参考図書『[単行本] 岡野原 大輔【高速文字列解析の世界――データ圧縮・全文検索・テキストマイニング (確率と情報の科学)】 岩波書店』は持ってるだけは持ってる。WEB+DB PRESS vol.42 の記事を読んで著者の名前を覚えていた。


2022年02月20日 (日) [AtCoder] 今日は ABC240 があった。見たことのある問題が多かったかな(万年 ABC rated だからだよ)。■C 問題「Jumping Takahashi」。アルゴリズムと数学 演習問題集の 96 問目「Cooking」が ABC204-D と同じ問題で、すでに ABC で解いていたけどそのときの解法が思い出せなかったのでビット演算で解き直していた>提出 #29359695 (AC)。それが4日前。今日の提出もビット演算で>提出 #29519763 (AC)。気がついたけど、ほんのちょっと前の ABC-D が ABC-C として出たってことなのね。■D 問題「Strange Balls」。ぷよだと思ったけど連鎖がなくてちょっと物足りない。必要な情報をメモしてシミュレートするだけ>提出 #29524639 (AC)。■E 問題「Ranges on Tree」。問題文が難しい。3割くらい理解を投げ出しかかっていたけど、途中でもうオイラーツアーが見えていたのでそれをガイドにして(予想がついている内容が外れていないことだけを確認して)読み通すことができた。昨日の F 問題「Construct Highway」がコンテスト終了後とはいえ解けていて気力が充実しているのでなければ危なかった。適当なタイミングで数字をインクリメントするだけ>提出 #29531766 (AC)。こういう問題をもっぱらスタックを陽に持ったループで解くのは 20 万回の再帰呼び出しがローカルではスタックオーバーフローを起こしてデバッグも答え合わせもできなくなるから。ネットで読んだ方法が効かないのはなんでなの?■F 問題「Sum Sum Max」。加速度と速度と距離。それは3か月前に解いたこれ「ARC077-E「guruguru」(黄 diff)。それほど難しくはないかな。ABC-D+α という感じ。プラスアルファで悉くつまずいて AC に辿り着けないのが自分ではあるが。(略)。時間軸に沿って加速度と加速度の累積としての速度と速度の累積としての移動距離を記録して答えにする」。極大値が見えていなかったりとりあえず代入しておいた初期値を答えにしてしまったり、逆に開始点を答えの候補から漏らしてしまったり、答えを合わせるのに大変苦労した。「プラスアルファで悉くつまずいて AC に辿り着けない」とか「区間の左右端と節約回数の上下端が off-by-one エラーを誘発しやすい感じ(ドツボにはまった経験から書いています)」を今日も再現しておかしくはなかった。早々に愚直解とランダム入力を組み合わせてダメケースの発見に努めることができたのが運命の分かれ目。終了3分前の提出 #29545375 (AC)。これ水 diff なんだって。全く同じではないにしてもかつての黄 diff が形無しですよ。


2022年02月19日 (土) よーわからんが、unsignedの2数の平均だったら、2で割ったものを足すだけでいいんじゃないの? 1ビット分誤差が入るからダメって?」 / Twitter」■これ文脈が二分探索なのでは。統計処理ではなくて。整数型なのには意味がある。このトピックが定期的に取り上げられるのはオーバーフローが原因となって言語(ライブラリ)が修正される事例がある上に、知らなければ最初に書いてしまう式だからだと思う。誰もが通る道。1ビットの誤差について、仮に二分探索で左が 3 で右が 5 のときピボットが 3/2+5/2 == 3 になってしまうと 4 がテストされる前に探索が終了してしまう。それは誤り。2数が1の場合でも UINT_MAX の場合でも誤差が1なら「1ビット分誤差が入るからダメって?」に対するツッコミにならないのでは?という疑問には、それはそうと思う。誤差が大きすぎるという納得はわからない。


2022年02月18日 (金) 3000ミリ秒近くかかっている。 なお Perl で同じコードを実行してみたところ、5ミリ秒で終わった。 Ruby では 22 秒(ミリ秒ではない!)かかった。 正規表現の実装が、ぜんぜん違いそうである。」 / Twitter」■へー。たしかに Ruby だと 30 秒くらいかかる。よくある * や + を入れ子にしてバックトラックが~というのではなく、単純にマッチ開始位置とマッチ失敗までのスキャンとがともに入力に比例する N^2 時間かかってる雰囲気。マッチテスト開始位置をずらしたときに「おや、ここはもう通った道だ」と気が付ければいいんだろうか。文字列内の位置とエンジンの内部状態が一致するならすでに出ている結論を流用できる、的な。テキトー言ってるけども。シチュエーションを限定しないとどんだけコストがかかるか想像できないけども。■「正規表現の脆弱性 (ReDoS) を JavaScript で学ぶ


2022年02月17日 (木) [AtCoder] 精進。先週末の ARC135-C「XOR to All」(水 diff)。XOR なのでまず考えたのはビットの分離。最大で 30 ある各ビットが A 数列を通していくつ立っているかを数えた。その数が N の半分より多いならそのままで、半分より少ないならビットを反転させたとして最大値を計算してみた。サンプルの1が合わない。どうやらビットごとに好きなビットを立てたり下げたりすることはできなくて、ビット間に拘束条件があるらしい。しばらく具体的に考えてみた。Ai を作用させてみて、Ai を作用させた Aj を作用させてみて……、そうすると Aj を作用させた段階で最初に作用させた Ai の効果が消えるなあ、と。提出 #29378726 (TLE×31)。これがコンテスト終了1分前の提出でなければ効率を考えて清書することができた。TLE の背後に WA が隠れていたりはしなかった。■提出 #29378726 (AC / 253 Byte / 1197 ms)。提出 #29378845 (AC / 202 Byte / 990 ms)。■以前日記にこう書いた。「コンテストの時に限って頭ヨワヨワの神経衰弱になること、あると思います」。この問題に当てはめるとそれはこう。「制約に Ai が 2^{30} 未満ってあるけど、Ai が取り得る値は 30 ビット符号無し整数の範囲だろうか、それとも 29 ビットだろうか。2^{30} は 1<<30 だろうか 1<<29 だろうか。(1<<30).bit_length は 31 かな、30 かな。Ruby で Integer#[] メソッドを使って整数の右端のビットを得るときの引数は(たぶん) 0 だから、引数の範囲は 0..29 だろうかそれとも 0..30 まで必要だろうか。ぐるぐるぐるぐる」 添字と序数とサイズと左シフトの回数がそれぞれ微妙に異なっていたり一致していたりするのに答えが出せなくて、無為に時間が過ぎていく現象のこと。


2022年02月14日 (月) [AtCoder] 精進。第九回 アルゴリズム実技検定 過去問I 問題 直通エレベータ。考えてもわからなくて飛ばしていた問題。解き直すきっかけはこの前の ABC に関するこれ「時間はかかったけど昨日は直線の上にグラフが見えた」なんだけど、実はこちらの問題は ABC の方より見た目がグラフっぽくてダイクストラ法を使うことは見えていた。見えていなかったのは、エレベーターを使う場合と使わない場合の隣接ノードのみをキューに追加すればいい、ということ。遷移先の候補が多すぎて困っていたのだけど、実はエレベーターを使った移動先と、上下にある一番近くのエレベーター乗降階のみを考えるだけで良かった。提出 #29245963 (AC / 1134 Byte / 703 ms)。


2022年02月12日 (土) GetWindowLongPtr 関数の第二引数(nIndex)について不思議に思った。これはウィンドウごとに割り当てられた値を取得する 0 を起点としたオフセット値だという。正の値はウィンドウクラスで指定して確保させた余分なバイトサイズ分だけ有効。マイナスはポインタサイズだけ有効。その他に Windows が内部で利用するために確保している領域もあり、それらのオフセットは GWLP_XXX として定義されている。GWLP_WNDPROC(-4)/GWLP_HINSTANCE(-6)/GWLP_HWNDPARENT(-8)/GWLP_ID(-12)/GWL_STYLE(-16)/GWL_EXSTYLE(-20)/GWLP_USERDATA(-21)。■第一の疑問。オフセット値はバイト単位なの? たとえば 6 バイト余分に確保させたとして、有効な正の範囲は 0-5 になると書いてあるけど、5 を指定して返ってくるポインタサイズの整数(LONG_PTR。32ビット/64ビット)の中身はどういうものになるのか。有効な値は 1 バイト分だけで残りはこちらのあずかり知らぬゴミになるのかどうか。■第二の疑問。これも同じ。オフセット値がバイト単位だとして、予め定義された定数が必ずしも 4 バイト単位でなく半端な値なのはどういうことか。GWLP_WNDPROC(-4) と GWLP_HINSTANCE(-6) と GWLP_HWNDPARENT(-8) で返ってくる値は 2 バイトずつオーバーラップしているのではないか。GWLP_HINSTANCE(-6) の肩身の狭さよ。GWL_EXSTYLE(-20) と GWLP_USERDATA(-21) も 1 しか違わない。GWLP_USERDATA(-21) から始まる 32ビット/64ビット がプログラマに開放されているなら、GWL_EXSTYLE(-20) のための領域はどこにあるのか。■第三の疑問も同じ。単位がバイト単位だとして、GWL_XXX という GWLP_XXX の下位非互換定数が #ifdef _WIN64 という分岐によって #undef されているのに対して、GWLP_XXX 定数が _WIN64 によらず概ね 4 バイト単位の単一定義なのはなぜか。GWLP_WNDPROC(-4) を -8 と定義しないでもいいのはどういう理屈か。■第四の疑問。マイナスの値はポインタサイズ分だけ有効と書いてあるけど、そのあたりの値は GWLP_WNDPROC(-4)/GWLP_HINSTANCE(-6)/GWLP_HWNDPARENT(-8) によって予約されているように見える。だとすれば、「有効なオフセットは 0 以上でウィンドウクラスで指定した cbWndExtra のサイズ分だけ有効。それ以外の値を取得するにはオフセットとして以下の定数を……」と書けばいい話で、あえて「負の値はポインタサイズだけ有効。それ以外の値を取得するには……」と負の値を括り出す理由はないように思える。■1つ2つの勘違いがないと説明がつかないように思う。どこを間違えている? GetWindowLongPtr のソースコードを読ませてくれ。■SetWindowLongPtr(hwnd, 0, 0x0123456789ABCDEF) と SetWindowLongPtr(hwnd, GWLP_USERDATA, 0x0123456789ABCDEF) した結果がどう読み取られるかを cbWndExtra とオフセットを変えて調べてみた。cbWndExtra7.png, cbWndExtra8.png, cbWndExtra9.png cbWndExtra16.png。オフセット値は 1 バイト単位であり、取得できる値はオーバーラップしている。ただし LONG_PTR サイズの読み取り枠が cbWndExtra のサイズ内に収まっていなければいけない。64ビット環境の場合はつまり、cbWndExtra が 8 未満の時に値の設定と取得はできない(0 が返ってくる)。8 バイトを確保しているときはオフセットとして 0 のみが有効。GWLP_WNDPROC(-4) と GWLP_HINSTANCE(-6) は 2 バイト(0x14a0) を除いて値が共通しているが共通部分の値がシフトしているわけではない。GWLP_USERDATA(-21) の値(8 バイト)がどこに保存されているのか謎。cbWndExtra の使い方はわかったけど既定のオフセットの意味はやっぱりわからない。負値はオフセット扱いじゃないんかな。じゃあ負のオフセットは LONG_PTR サイズまで有効とか書くなって話なんだけど。■わかった!!!Valid values are in the range zero through the number of bytes of extra window memory, minus the size of a LONG_PTR」を読み間違えていた。有効な値は 0 から cbWndExtra までと 0 からマイナスポインタサイズまでではなく、0 から「cbWndExtra マイナス ポインタサイズ」までだった。えええええ、そこにカンマを入れる? そしてカンマひとつでここまで勘違いをひきずるか>自分。■オンラインでは見つけられなかったけど PC 内に日本語訳を見つけた。「nIndex 取得する値に 0 から始まるオフセットを指定します。有効なオフセットは、0 から拡張ウィンドウメモリのバイト数 -8 までです。たとえば、拡張メモリが 24 バイト以上ある場合、16 を指定すると、3 番目の整数値が取得できます。その他の値を取得するときは、次のいずれかの値を指定します。 」 具体例まで追加していい仕事してますよ。見つからんかったけど。


2022年02月11日 (金) Excel の罠。表データをフィルタしてから重複データの削除を実行したんです。俺は重複の削除もフィルタの一種だと思ってるし、フィルタを適用する順番には意味があるつもりでいるんだけど、Excel くんはフィルタされて見えていない行を含む全件データを対象にして重複を削除してしまったんですな。そうするとフィルタを通して見えていたデータが重複行であるとして消されてしまうことがある。2行や3行が1行にまとまるのでなく、ゼロになってしまうことがある。Excel を使う人の 10 人に 5 人がこの罠にはまって煮え湯を飲まされた経験があると、俺は思うね。これが SQL なら WHERE 句と HAVING 句を間違えるような真似はしないんだけど、Excel には知識も経験も不足している。■条件範囲という Excel ならではの絞り込み条件の指定方法を学習した!■ユーザー設定のビューという機能の存在を知った!■■■衝撃の事実。「今回のエントリーの中で一番の目玉がテーブル機能です。歴史は意外と古くExcel 2000(コメントより修正しました)より登場したものです。テーブルという名前からわかるように、Accessのようなデータベースのテーブル形式にしてExcelのシートを使う機能であるため、使いこなせれば非常に楽に作業を進めることができます。しかし、Excelをただの画面レイアウトの方眼紙程度にしか捉えてない人だと、その仕組に挫折することがあるようです(Accessで挫折する人が出るのも同じ理由だったりします)。」 テーブル機能が表計算ソフトの基本機能ではなかったことがある。どこを探せば欲しい機能が見つかるか目星がついてきた。