/ 最近 .rdf 追記 設定 本棚

脳log[2023-05-11~]



2023年05月11日 (木) 私は異なる人々にこの話をしてきましたが、プログラマは一様にこの話を聞くと 歓喜するのに対して、経営者は目に見えて不機嫌になりました。 いっぽう純粋な数学者は、なにが面白いのか理解できないようでした。」■難しい。反応をどう解釈していいのかよくわからない。プログラマは歓喜するらしいけど、高級言語しか使えないようなダメなプログラマは操車場のように低レベルな現場で巻き起こる騒動には考えが及ばず、当たり前のように2種類の車両が交互に向きを揃えて整列してると考えてそう。それは私です。経営者が不機嫌になる理由がたぶん自分と同じ期待を当初から持っていたからだと思う(「調査してみると、経営者の決定がきちんと操車場に伝わっていなかった」)。それなのに最終的な解決方法が現実的ではあっても理想に届いていなかった(「ささいな問題として……」)。数学者の興味をひくには、数学者の言であるとされる「あなたの話は具体的でわかりにくい。もっとわかりやすく抽象的に説明してくれませんか?」がヒントになりそう。話が具体的すぎた。最後に、ペアを考えることで解けた競プロの問題を嬉しそうに挙げておきますよ。灘校文化祭コンテスト 2022 Day1-D「Double Permutations」(20220504)


2023年05月08日 (月) [AtCoder] 精進。ARC102-D「All Your Paths are Different Lengths」(青 diff)。やることはまあまあすぐにわかる。数値の2進表現をグラフに直す。L と N の制約がそのような配分になっている。ビットごとに頂点を割り当てて隣接ビットへ1の辺(重み2べき)と0の辺(重み0)を張る。それだけだと L がフルビットでないときに困るけど、1のビットに対応してそのビットが最初に倒されるビットである場合を表す辺を張る。■提出 #41255174 (WA×7)。こういうジャッジスクリプトを使っていた>judge.rb27。入力される L の上限は 20 ビットある。そのときに N=21 となる答えを返していたのが WA の原因。N は 20 以下に制限されている。L のビット数+始点1+終点1くらいの頂点を使わせてくれてもいいと思うけど、L のビット数と同じだけしか許されていない。■提出 #41257168 (AC)。すごく苦しんだし、その過程では3進数でやろうかとも考えたけど、結局、始点と始点に隣接する頂点を機械的にマージすることで答えが合った。いらん苦労だったと思う。制約が無駄に厳しかった。あるいは上手い考え方があったのか。■提出 #41260968 (AC)。3進数でやった。たぶん最大ケースが L=531440(10)=222222222222(3) で、解答が N=13;M=57 になる。M が上限の 60 に近いがセーフ。あんまりややこしいので初めて秘密兵器(ノート)を使った。ノートを見れば明らかだけど、2進数であるか3進数であるかにかかわらず、自分が考えるとどうしても桁数+G(終点)の頂点を使ってしまう。MSB を S(始点)として使用してもだ。だから2進数でやったときに L のビット数+1を使ってしまって制約を1だけ超えてしまった。■3進数で真の最大ケースは L=885734(10)=1122222222222(3) だったかも。このとき解答は N=14;M=60 になる。上限いっぱいでぎりぎりセーフ。辺の制約(M)がキリよくおおざっぱなのに対して頂点の制約(N)がタイト過ぎて無駄に解答の様式(=ただの形。記述の癖以上のものではない)を縛ってると思うんだよな。


2023年05月05日 (金) [AtCoder][Ruby] 普段のコンテスト参加スタイル。AtCoder でジャッジに使われる Ruby が今のところ Ruby-2.7 なので C:\Program Files\Ruby27 にインストールして、コマンドプロンプトで ABC300.rb27 とか ruby27 ABC300.rb27 で実行できるようにしている。■方法は? ruby.exe の名前を ruby27.exe に変えるのはあまりうまくなさそうだし、ruby27.exe という名前のシンボリックリンクを他所に作っても x64-msvcrt-ruby270.dll みたいなライブラリにパスが通ってないと実行できないしで、~\Documents\PATH という名前のフォルダをパスの通ったフォルダとして用意して、ruby27.bat という名前のバッチファイルを置くようにしている。中身は次の2行だけ。@set PATH=C:\Program Files\Ruby27\bin;%PATH% @ruby %* 他にも ruby18.bat、ruby19.bat、ruby25.bat、ruby31.bat、irb27.bat、ruby27-prof.bat とかのファイルがある。Ruby-1.9 のあと AtCoder に触れるまで Ruby から離れていたことがわかりますね。原始的だけど面倒がない。■デスクトップに空の ABCxxx.rb27 ファイルを作成してサクラエディタで開いて、コマンドプロンプトも開いて準備完了。ブラウザとエディタとプロンプトを行ったり来たりしてる。あとアニメとかの動画をデスクトップいっぱいに最大化して再生してる。静かすぎるのも集中できないものらしいですよ。オートインデントだとか補完だとか整形だとか構文エラーの指摘だとか、機械に不随意に横から茶々を入れられるのが耐えられないのでエディタには多くを求めていない。■BIT とプライオリティキューとセグメント木と組み合わせの事前計算をイチから書くことはもうないので、そのときはエディタの GREP 機能(Ctrl+G)で過去ファイルを漁っている。プライオリティキューとセグメント木にはバグったものが混じっているのがわかっていて、うっかりしていると過去のバグを再現してしまう。■コードテスト勢(実在をやや疑っている)よりはよく準備してると思う。言語リファレンスはここ☞。できることは全部リファレンスに書いてある。専ら Array#insert の第一引数と第二引数のどっちがどっちだったかと、ビット演算子の優先順位を確認するのに使っている。他に競プロで使うようなものはだいたい覚えてるかな。Ruby だけだからね。C++ で書こうとすると cpprefjp が手放せない。■こういうお役立ち記事があるのは知っている。「RubyプログラマがAtCoderの環境をatcoder-cliとonline-judge-toolsで快適にしてみた - Qiita」。使われているのはどれも有名どころのコマンドで、AtCoder に限らず使う機会が多くあると思う。参考にしてまったく損はない。だからそうでない原始人スタイルもあることを書いた。


2023年05月02日 (火) [AtCoder] 精進。ARC100-D「Equal Cut」(青 diff)。最大値とか最小値とか見えるので二分探索で解きたい気持ちになる。何をボーダーにして判定するか。最初に考えたのは4つの部分列 B,C,D,E の和 P,Q,R,S が最低いくつ以上でなければならないか。そうすれば部分列の和は途中までは基準を少し超えたところで揃う。これの何が良くないか。たとえば前の方の部分列が基準を多少大きく超えた方が全体としては凸凹が均されるかもしれない。それは A 数列の配列による。他には部分列の和の差(つまり答え)が超えてはいけないラインを決め打って探索ができるか考えたり。でもまとまらなかった。■提出 #41124597 (AC / 339 Byte / 812 ms)。まず数列を2つに割った。これは総当たりで。次にそれぞれをできるだけ均等に割った。これは二分探索で。仮に2つに割った前半/後半が2等分できるときに、あえて差をつけた方が答えが良くなるケースがあるかをよく検討した。なかった。


2023年04月29日 (土) [AtCoder] 今日はユニークビジョンプログラミングコンテスト2023 春 (ABC300)があった。自分のすべての提出コンテスト成績証。ABCDE の5完水パフォ。C 問題からふりかえり。■C 問題「Cross」。ばってんの大きさを計って集計する。問題文がちょっと難しかった。✖印の判定条件の3つ目が「X 字の先端4点の延長にある4点のうち少なくとも1つは . である」という内容だった。理由はわかる。さもなければそれはより大きいばってんとして数えられるべきだからだ。でも本文中に「バツ印を構成するマス以外に # は書かれていません」「異なるバツ印を構成するマス同士は頂点を共有しません」という条件が書かれている。そうすると結局判定条件としては「少なくとも1つは .」だけど、実際に入力されるものは「4つとも . になっている」ということだ。別にそれで問題はない。ないんだけど、全体として過不足なく丁度になっていないことで考え漏らしがあるかと疑念が生じて考えてしまった。あとは「頂点」ってなんだ?とか。具体例を読めばグリッドの十字部分らしいとはわかるけど、推測ですよ。解答は X 字の右上がりでも右下がりでもいいので端点を見つけて長さを計る。ちなみに最初に考えた解法は UnionFind を使うもので、問題文を読むときも UnionFind が使えるかどうかを確かめながら読んでいた。でも判定が簡単そうだったので UnionFind は書かないで済ませた。■D 問題「AABCC」。来たよ、苦手な苦手な D 問題、数学(素数)、緑 diff(予想)。数字と友達になれないと TLE になるやつ。解けなかった ABC296-D「M<=ab」の反省から N の平方根の範囲で何かする制約だとはすぐに読み取った(この前はそれすらできなかった)。あとはやや長めの3秒制限を信じて打ち切りながら全列挙した。自分の提出は Ruby の中でも一番遅い部類。苦手なんだよ。■E 問題「Dice Product 3」。確率の問題。Ruby による他の提出を見ると一番早い提出がたぶんメモ化再帰で自分のと全然違っていた。自分の解法。まず、N が2と3と5の積に分解できなければいけないので因数を数える。4と6の目はひとまず無視して2と3を数える。1の目は最初からないものとして5面ダイスで問題を解く。その場足踏みはサイコロを振らなかったのと同じことなので。N が2と3と5に分解できたら6の目と4の目の数を決め打つ総当たりで、ダイスの目の並べ方を組み合わせで求めて確率を出す。解答の C 関数の定義がやや不自然だった。引数を n と rs から rs だけにして n は rs.sum で求めることにすると無駄がなかった。■F 問題「More Holidays」。解けなかったのでこれは精進。方針は、1つの x で区切られた長さ 0 以上の o の連続を、K 回連結することを考える。K はべらぼうに大きな数になりうるけど、仮に入力 S に含まれる x の個数が X 個だとしたら K/X と K%X を使ってうまく数える。罠がいくつかある。どの o の連続から数え始めるかを全探索するのだけど、後ろの方から数え始めて K 回連結したときにうっかり T の長さ NM を超えてしまわないこと。まだある。入力の先頭と末尾が o の文字で、操作回数 K が x の個数の倍数で、繰り返し回数 M が十分に大きいとき、末尾と先頭にある o の連続を一体で扱わなければいけない。


2023年04月25日 (火) クリアしたゲームに出てきた「古の民」というワードについて。これが自称として使われるんだけど、そういうことってあるのかなと考えてしまった。つまり、古い民というのはレトロニムなのであって、古い民しかいないときに古い民を自称したりはしないだろうと思った。新参、古参という言葉への色の付き方を考えれば、自ら古さを誇ることが全くないこともないかもしれないけど、可能性としては、古い民が自らを指し示す固有の文字があるとして(その時点で古い民と同じくらい古い民が昔はいたっぽい)、その文字に古い民という意味を割り当てた、古い民と対置される読み手が存在するのかなと。古い民というのは読み手の語彙なのであって、ゲーム内ドキュメントは読み手の目を通してプレイヤーに提示されているのかなと、考えたのでした。その読み手っていうのは実はゲーム開発者なんでしょとも意地悪く思ってはいる。■先住民族とか極東とか。交流があれば外からの見かたを取り込むこともあるのかな。「我ら先住民族」と名乗る人がいるかは知らないけど、自らを地図の右端(far east)に位置づける日本企業は知っている。


2023年04月21日 (金) 登記所備付地図データ公開の時に知ったんだけど、デジタル庁のアドレス・ベース・レジストリが自分のほしいものだなと。実際のデータを見るとわりと何番何号の座標が得られるんだけど、新しい区画のデータがなかったり、○○市△△がすっぽり抜け落ちていたり、かゆいところに手が届かない感じ。一次データを持っているところが素早く網羅的に使えるデータを公開すると、マピオンなどの使い勝手が上がることで恩恵があると思う。待ってるよ。■データ解説書(PDF/2,279KB)を読むと「地番のマスターデータは、未整備で、整備・公開のあり方について検討中です。」「2022年度の整備予定は以下とおりです。(略) 地番マスターデータの整備を実施します。ただし、一般への公開可否は未定です。」と書いてある。すっぽり抜けているのは地番形式の住所っぽい。地番っていうのは何丁目何番何号という形になっていない古い形式の住所(と PDF に書いてある)。登記所備付地図データをみると地番というフィールドがあって、抜けていた地名もあるから、補完できるみたい。デジタル庁の「登記所備付地図データ(地図XML形式)変換コンバータの公開について」というページをあらためて読むと「法務省がG空間情報センターを介して提供したデータを活用し、地番データや筆の形状データを取得・反映していく予定です。」「地図XMLのデータから、筆のポリゴンデータおよびアドレス・ベース・レジストリの整備に必要な属性のみ抽出・出力します。基準点、筆界点、筆界線は出力しません。」と露骨に書いてあったね。備付地図データの方では(何丁目)何番何号もハイフンで繋いで地番扱いみたいだから「地番」といっても同じものではないみたい。■フォーマットされた地番データと新区画のデータを待ってるよ。


2023年04月20日 (木) 新聞の将棋欄で「俗ながら妙手」という表現を見た。妙手なのに俗だと、なんとなく下に見るような雰囲気が感じられるのはどういう手なのか、気になりました。よくわからない価値観。指しやすい手がそのままうまい手、くらいの意味かなと思っている。あえて但し書きを付ける心理はやっぱりわからないが。


2023年04月19日 (水) 『スーパーユーザーなら知っておくべき Linux システムの仕組み』を読み始めた。良いか悪いかは別として、「スーパーユーザーなら」という煽りからは予想できないほどに、当たり前すぎる(と感じる)基本のキから丁寧に書かれている。もう少し薄くても良かったかな。1冊で間に合うと考えれば利点ではある。■印刷について。思わず他の本と見比べてしまったのだけど、意識しないでも気が付いてしまうほど明らかに質が低い。解像度が低く文字の輪郭がなめらかではない。黒色ではない。(解像度の低さと同じことかもしれないけど)影を付けたように滲んでいる。家庭用プリンタで印刷したのかな、という品質。眼鏡を外すまでは気が付かなかったのではあるけども。


2023年04月18日 (火) [AtCoder] 精進2。ABC146-F「Sugoroku」(水 diff)。Sugoroku という名前の問題は、調べて予想の倍あって驚いたんだけど、まであって、前回の ABC でもちょっと変化球で Unfair Sugoroku という名前の問題があった。いずれも確率と期待値の問題。だから初代が最短(辞書順)最小の手順を答える問題だったのが意外。■1手につき1から M マスまで進める。最短であることが第一だから、まずは M マス進めるときは M マス進んでしまう。無理なら M-1 マス、M-2 マス……。いっぱい進みすぎてしまうことで誤って到達不可と判断してしまうおそれはない。それはつまり M マス連続してゲームオーバーマスがあるということであり、どう手順を刻んでも結果は変わらない。次に、同じ手数のなかでは辞書順最小の手順を答えにしなければいけない。このために最短手順を求めるときはゴールから貪欲に最大歩幅で移動を繰り返し、最小手順を求めるためにはスタートから逆向きの移動を繰り返した。結局、最初の1手を最小限に小さく刻んだ後は最大歩幅での移動を繰り返すことになるのだね。■提出 #40753539 (AC / 203 Byte / 113 ms)。すんなり AC できたわけではない。最初は DP のつもりで各マスに最小手数と最小手数の中での最小出目の2つを記録していった。答えは合うけど TLE。次は各手数において到達可能な範囲を表す2つの数を記録していった。M が大きい場合に DP 配列を1マスずつ埋める手間が節約できたけど、これも2ケースは TLE が避けられなかった。最終的に各手数において可能な移動先の先端だけを記録するようにした。■■■精進1。ABC141-E「Who Says a Pun?」(水 diff)。これまでも何回か読んだことがある問題だけど実装には至っていなかった。■提出 #40750806 (AC / 218 Byte / 1688 ms)。N 個の各添え字について、長さ1のプリフィックスが共通するもの、長さ2のプリフィックスが……、と順番にグループを細分化していった。その過程で同じグループの中で最小の添字と最大の添字の差がプリフィックスの長さより大きいことを確かめる。■Ruby によるすべての提出を見ると最速は 87 ms なので 1688 ms は2桁遅い。見ると、添字と長さを0から開始して、見つかれば長さを伸ばす、見つからなければ添字を増やして再検索する、という手順を繰り返すみたい。じっくり見ても混乱するややこしさ。


2023年04月15日 (土) トヨタ自動車プログラミングコンテスト2023#1(AtCoder Beginner Contest 298)があった。自分のすべての提出コンテスト成績証。C 問題に提出しようとして失敗したときにサーバーの異変に気が付いた。数分間リロードを繰り返しているうちに正常に戻ったのでそのまま続けた。C、D、E、F と AC を得て気楽な気分で G 問題を読んでいたのが終了 10 分前で、普段読まない質問ページを開いたのもこのとき。DDoS の影響で unrated だってさ! こんなに残念なことはない。俺が6完するのは珍しいんだぞ。今回は B 問題から重めの問題だったので振り返りも B から。■B 問題「Coloring Matrix」 問題文に書かれている回転の定義を読み解くのがまず難しい。2つの行列を照合する方法は2通りあって、Array#transpose と Array#reverse を組み合わせて行列自体を回転する方法と、添字を変換する方法。添字を変換する方法でやることにした。その方法だけど、90 度回転する変換と 180 度回転するものと 270 度回転するものをそれぞれ定義しようとして苦労して、(あまりに苦労したからどこかで間違えているに違いないと考えて)デバッグのために3行3列の変換結果を表示してみたけど、それが合っているかどうか読み解くのが自分には難しいということが明らかになった。問題文を読んで回転を脳内再構成することから難しいのだからそりゃそうだ。考えることをやめて「A_{i,j}​ を A_{N+1-j,i} で置き換える」という添字の変換をそのまま実装して2回3回と繰り返し適用することにした。AC まで 18 分。照合という語を使ったことについて補足。判定条件が論理パズルみたいでちょっと面白かったよね。A の要素が 1 のとき B の要素が 1 でなければいけない。ということは、A=0 のとき B は何でもいいし、逆に B=1 のとき A は何でもいい。A=1⇒B=1 (もしくは B=0⇒A=0) を確かめる式は A==0||B==1 になる。これって有名なパズルで、人間は未成年の飲酒を見つけるためならば確かめるべきを間違えないけど、ただの記号の組み合わせだとルール違反を見つけるのが途端に難しくなる。■C 問題「Cards Query Problem」 D 問題に出てもおかしくないような、下手を打つと TLE になりそうな制約と操作。あなたは std::set と std::multiset が使えますか、と問う問題かなと思うけど、Ruby にはない。カードごと箱ごとにソート済みの列と未ソートの列を1本ずつ持つことにした。答えを出力するタイミングで未ソートの列をソートしてマージする。出力する数の合計が 20 万以下に制約されているから、ソートする要素数も、マージ操作のコストも同じレベルに抑えられているはず。AC まで 28 分。方針を決めるまでにすこし考えたし、実装量もそこそこ多かった。実は実装に手間をかけなくても、1つの配列につっこんで出力の直前にソートするだけで十分だったっぽい。出力の総数が制約されているとはそういうことだよな。■D 問題「Writing a Numeral」 これは簡単。各桁の数字と全体の mod を記録していく。クエリ2で引き算をするために 10 の冪乗の余りも並行して記録していたけど、たぶん都度 pow メソッドを呼んでも大丈夫だった。■E 問題「Unfair Sugoroku」 確率の問題。確率とか期待値の問題って方針を決めるところに難しさがある。正解方針が引ければ答えが合うけど、答えにたどりつけない方針を引いてしまいがち。当てもんをやっている。「Boy or Girl paradox」とかモンティ・ホール問題とか、知らなければ避けられない、ヒトが傾向的に陥りやすい誤りがある。方針に迷って F 問題に手を付けるも一時退却してきたときにひらめいた正解方針がこう。高橋くんがサイコロを振って進んだ先のマスに場合の数を書き込みます。各回において高橋くんが初めてマス N に到達した場合の数と青木くんがマス N 以外のマスにいる場合の数から勝ちの確率を求めます。そうして各回で勝つ確率の総和が答え。制約が小さかったので愚直に配列をスキャンして数字を出したけど許された。助かる。■F 問題「Rook Score」 なんかやるだけに見えるけど、やや長めの制限時間3秒が気になる。たぶん想定される落とし穴は、0 以外の数字が書いてある N 個のマス (r,c) のどれかを答えの候補にして他を考えないことだと思う。しかし答えの候補は N 個の r と N 個の c の組み合わせから選ばなければいけない……ような気がする。しかし O(N^2) が許されない制約。どうする。貪欲にやって見込みがなくなったところで打ち切るようにしたら間に合った。それでいいのか?■「アライグマ「F問題は、行和+列和が大きい順にN+1個チェックすればいいのだ!」」 言われてみればそれはそう。そこまで見極められていなかったから、自分の提出(一応 AC)では貪欲さが足りなかったし、だから tinsep19 さんの提出 #40680322 のようにより厳しい打ち切り条件も採用できなかった。あと、セグメント木で解けるというツイートを2つ見たけどよくわからなかったので考えた。たとえば1行ずつ考えるとして、セグメント木には列ごとの合計値を記録する。行を移るときに同じ数字を二重に計上しないようにセグメント木上の数字を足し引き補正して、それから最大値を尋ねるのだと思う。ST でやったら WA×9 と微妙に間違えた。なぜ? ST クラスの内部配列のサイズを2べきに揃えるときに埋める値がよろしくなかった>AC。■ACL などまともなライブラリのセグメント木を使ったことがあれば単位元がパラメータ(の1つ)だということがわかったはずだ。この動画を見ていたら op と e の2つをテンプレートパラメータとして渡していて、「あっ、そうなんだ」とお勉強になりました。で、あらためて Wikipedia を読むと「定義……結合律…….単位元の存在……を満たすならば……モノイドという。」と書いてあるわけ。だけどね、痛い目を見るまではそういうお約束的な決まり事って無視しちゃうよね(イケナイ)。■これまでで 15 番目に良い順位だっただけに unrated の無念もひとしお。一入はありふれた漢字の組み合わせで難読。一目で覚えたい。


2023年04月14日 (金) 20230309 にも書いたけど『人はどこまで合理的か?』(スティーブン ピンカー)をまだ読んでいる。今は下巻。基準率(base rate)という単語をこの本以外でも見かけるようになったけど(つい先日もツイッターで)、単に本で読んで知ったから目に付くようになっただけで、以前からあったのかもしれない。過去に読み始めたものの頓挫してる『データ解析のための統計モデリング入門 : 一般化線形モデル・階層ベイズモデル・MCMC』(久保 拓弥)を思い出させる内容もあって、なかなか厳しい。読み物ではあるけども。■またしても言葉について。下巻の 194 ページから、対立軸を例示して「たとえば階層主義か平等主義か、自由主義か共同体主義か、王冠と祭壇か啓蒙主義か、部族主義か世界主義か、悲劇的ヴィジョンかユートピア的ヴィジョンか、名誉を重んじる文化か尊厳を重んじる文化か、集団志向の道徳的基盤か個人志向の道徳的基盤かなど。」とあるが、名誉と尊厳の対立がよくわからなかった。これって同じ側の言葉に見える。思いつく原語は honor と dignity あたりなんだけど、日本語の意味が十分に掴めていないか、日本語にするときに重要なニュアンスが消えてしまっているか、なんにせよ理解が曖昧な部分があるとわかって気になってしまった。雰囲気で違いをでっちあげると、名誉は外から贈られるもので、尊厳は内から出てくるものかなと思ったけど、これまでそういう風に考えたことはないし、それが対立する状況も想像できない。こういうのに答えるの、ChatGPT が得意な分野という気がする。実際の使われ方から意味にあたるものを抽出すること。■■■@2023-04-26 別の本だけど『ファスト&スロー』(ダニエル カーネマン)の上巻 102 ページから、プライミング効果に関する内容だけどそのことではなくて例示されたものについて。「世界には、ひんぱんに尊敬を思い起こさせる文化もあれば、神を思い出させる文化もある。また、「親愛なる指導者」の大きな写真を使って、服従というプライムを国民に与える国もある。」 先々週(14日)に書いたように名誉と尊厳の対比はよくわからなかったけど、この本に書かれている2者+1は、人を上に置くか人の及ばないもの(神)を上に置くかという違いで理解してもいいだろうか。尊敬という一語だけで対象を人に限定してしまう用法に違和感があったけど、明鏡国語辞典によれば「「尊敬」は多く人間とその行為に限られるが、「敬う」は、尊い存在として敬意を払うべき高位のものに及ぶ(恩師[祖先・神仏]を敬う)。「崇める」は、敬うべき絶対的な存在に向けられることが多い(釈尊[神仏・太陽]を崇める)。」とあるのでむしろそういうものらしい。ひょっとしたら2つの本は同じことを指しているのかもしれないと思った。名誉=尊敬、尊厳=神威。無理か? それはそれとして、人と神の対比は、神格化される人がいたり神を代弁する人がいたりして曖昧に感じる。それよりも、人であるか神であるかにかかわらず自分の上に他者を置く心性、分を弁え身を修め奉仕する心のありようが共通していると思った。日本人が外国人に対して「無宗教です」と伝えるつもりで「無神論者です」と伝わってしまってやべー奴だと誤解されてしまうというエピソードがしばしば語られるけど、無神論者のやばさって、そういう心性の欠如として理解すればいいのだろうか。アナーキストに近い概念だと説明されることがあるけど、無宗教・無神論に対するイメージが実はよくわからない。無というよりは反で、反宗教的な活動家、みたいな?


2023年04月13日 (木) [AtCoder] 精進。20230409 に書いたように ABC123-D「Cake 123」(水 diff)。難しかった。ABC197-E「Kth Takoyaki Set」と似ているということで解法の見当がついた状態で挑んだけど、ひとひねりあって考えてしまった。制約を比較すると N の上限が 10 から 1000 へと増えている一方 K が 20 万から 3000 に減っている。列が3本あるのも違いだけど、それは最初に2本を組み合わせてソートして 100 万のソート列と 1000 の「値を増加させるプロセス」に転換できる。O(NK) が通る制約なのは同じだから、ここから同じ解法で答えが出る。じゃあどこに考え込む要素があるのか。プログラミングをする者の思考として共通部分を見つけて括りだしてまとめる傾向があると思う。100 万のソート列と 1000 のプロセスを組み合わせて K 個の値を大きい方から作り出す本処理を書いたとき、前処理で行った 1000 の列を2本組み合わせて 100 万のソート列を作り出す処理にも応用できないかと考えてしまった。一見できそうに思える。なんなら本処理よりも簡単にできそうに思える。というのも本処理では 100 万と 1000 を組み合わせるので迂闊に全体を一括して扱うと 10 億になって手に負えなくなる一方、前処理では 1000×1000 = 100 万なので雑に組み合わせて全体を一括処理して構わない。それなのに本処理と同じやりかたを前処理に適用しようとして N の3乗 TLE になりそうなことに気がついて、なんでそうなってしまうのか考え込んでしまった。■提出 #40551459 (AC / 267 Byte / 748 ms)。前処理と本処理を共通 M (マージ)関数にまとめることはできなかった。■Ruby によるすべての提出を見ると2桁 ms の AC がいっぱいある。自分の解法は ABC297-E の制約を見て考え出されたものであって、ABC123-D 向けには別の解法を採用すべきだったということ。ちなみに ABC297-E には他にプライオリティキュー解法と二分探索解法が存在している。自分が過去に ABC123-D で WA を出した解法は二分探索解法だった。もうすこし考えねばならぬ。■前処理で作成するソート列の長さを制限することができる。そうするとさっき書いたことに反して共通のマージ処理を使うことができる。2桁 ms の提出は長いものと短いものに二分できるみたい。長いものはプライオリティキュー解法で、短いものはソート済みであることを踏まえて賢く打ち切りながらの全列挙だった。