center = now #中心 とあるな。……使われてないけど。770 ms と自分の倍くらい速いのなんで？ 直径を構成する頂点のリストを用意して、U から直径までの距離を愚直に(１ずつ)数えてる。１回のクエリごとに高々半径と同じだけの遡行回数で直径に行き当たるだろうけど、それでいつでも大丈夫？ しかしこんなややこしいことをしていて早いし速いし間違えてないのすごいなー。■直径を幹として他のすべての頂点を幹から分かれた枝(※)と見る木のイメージはこれまで持ったことがなかったなあ。※枝の長さは分枝点から直径の両端までの距離のうち短い方より短いか同じ。■提出 #34582537 (tinsep19 さん / 1606 ms)。クエリ先読みもありか。そうか。まねまね>提出 #34647156 (AC / 1826 ms) うーん、遅い。■■■精進２。先週末あった ARC147-C「Min Diff Sum」(青 diff)。コンテスト中に三分探索を書いていたんだけど、そのときも今日も３分点を求める式を間違えていた。(l+l+r)/3 とか l+(r-l)*0.3 が書けなかった。もっとも、それが書けても不満度を妥当な計算量で求めるのがまた難しかったんだけど。この部分問題には ABC の C 問題と D 問題の中間くらいのポジションをあげてもいいと思う。■提出 #34655113 (TLE×23)。三分探索が書けて判定式が書けて不満度の計算ができても、ローカルで６秒かかっているのでジャッジサーバーでは３秒くらいかかると思う。TLE。■提出 #34656235 (AC / 746 ms)。ループの中の線形時間の処理を累積和＋二分探索に書き換えて AC。■提出 #34660104 (AC / 1739 ms)。整理していくと結局区間の左端の数と右端の数を数えるだけになって、三分探索も二分探索も不要になった。速くなるかなと思ったけど倍以上遅くなった。さっきの 746 ms がソート(NlogN)+累積和(N)+二重探索(log^2(N))で、今度の 1739 ms がソート(NlogN)+線形探索(N)。オーダーは O(NlogN) で変わってないけどね、だからこそこんなに差をつけられて、しかも負けてるのが納得しがたい。考察が進んで遅くなるとか……。ローカルで若干速くなってるものがジャッジサーバーでは２倍遅くなってたりするから、ジャッジが詰まりまくってた影響があったりする？ あとローカルでは入力の受け取り方を変えるだけで３秒が２秒になったりした。入力サイズがでかい。■提出 #34661754 (AC / 658 ms)。ちょこっと速くなった。二重探索に対して妥当な改善だと思う。あたうる限りの努力」という初めて見る表現があって、気持ち悪いなあと思った。それ以前から「
できうる限り」というあまり珍しくない表現も気に入らないと思っていた。だってね、「～しうる」という表現にすでに可能の意味があるのに、～するの部分にできるを当てはめるのは二重表現に思えてくどい。「できる限り」で十分なところでもったいぶって「できうる限り」なんて気取ってんじゃねーよ、という感想が先に立つ。■「あたうる限り」はどうか。これには「できうる限り」の「できる」にさらにもったいを付けて「あたう」に置き換えただけではない悪さを感じる。つまり、「～しうる」に接続するのに「あた(う)」でいいのですか、という疑惑。あたうの「う」と～しうるの「う」の音が同じだから、つい、くっつけちゃったんじゃありませんかという寸詰まりの据わりの悪さ。■「あたう(能う)」について ATOK で明鏡国語辞典を引いたら自動詞五段活用らしい。「～しうる」についても一応引いて、動詞の連用形とともに複合動詞を作ることを確認した。「あたう」の連用形とは何か。「あたい」になりそう？ ところで、明鏡で「あたう(能う)」を引いたときにそのものずばりこう書いてあった。「
「能う限り」を「能うる限り・能ううる限り」とするのは誤り」。２つの誤用例のうち「あたうる限り」の方は我が意を得たりでわかる。次に考え得るのは「あたううる」なの？ 「あたいうる」の扱いがないのがアリだからなのかそれとも想定外なほど完全にナシだからなのか判断できない。もちろん「あたいうる」が仮に合法でも、気取ってんじゃねーよ、という感想をもつだけだけど。■■■珍しくない表現と問題提起だったらしい。「「あたう限り」？ 「あたうる限り」？｜NHK放送文化研究所」「「できうる限り」か「できる限り」か | 毎日ことば」「首相演説の「能うる限り」は「能う限り」の誤りでは？ | 毎日ことば」 五段活用は五段活用でもワ行五段活用であるらしい。いくつかの活用形がないんだっけ？ 連用形がなさそう？
What does the expression SCHAR_MAX == CHAR_MAX evaluate to?」 char の符号が処理系定義なのは知ってたけど、処理系定義と未定義を混同した。だいたい符号付きにされるから成り立つ(1)のを正解にするってさ。それとあとになって気がついたけど、この問いに答えるには SCHAR_MAX と CHAR_MAX の型の異同について考えるだけでは足りなくて、int 型へ昇格されて比較された結果がどうなるかを答えないといけなかった。だってビットパターンは２つとも同じなわけだから(追記：嘘だよ。符号付き最[小]値と負号無し最[大]値の話になってるよ)、型が異なることが比較結果が偽となることを即座に意味しない。左のように書いてから疑いを持って検索したら、C++ のリファレンスではあるけどこう書いてあった。「
具体的な値は実装依存であるが、127（2^7 - 1）以上であることが規格で定められている。このマクロによって定義される値の型は int である。」 SCHAR_MAX の型は最初から int であると。そんな気がしたぜ。ちなみに UCHAR_MAX についても「具体的な値は実装依存であるが、255（2^8 - 1）以上であることが規格で定められている。このマクロによって定義される値の型は、 unsigned char の全ての値が int で表すことができれば int、そうでなければ unsigned int である」とあるので、基本的に int であると。UCHAR だけど char でもなければ unsigned でもないと。■「
Assume x has type int . Is the expression x<<0 ...」 負の数の左シフトはシフト数によらず定義されないそうで。■「
Assume x has type unsigned short . Is the expression x<<31 ...」 unsigned short の昇格先としてつい unsigned int を期待してしまったけど、int で十分だから int だった。C 言語の int 好きを十分頭に入れてクイズに臨んだのにほころびが。■「
Does evaluating the expression INT_MIN % -1 invoke undefined behavior」 最後の問い。選択肢が「Who knows」(不正解)しかない。他の選択肢があっても普通に答えが返ってくると思ってたから不正解で間違いない。これの結果を保証すると効率に響くという不都合な式らしいけど、コンピュータの気持ちで余りを計算することができないので INT_MIN の何がまずいのかわからず。ひょっとして
-INT_MIN が存在しないことが関係する？■■■近くにあったツイートでこちらが目に入った。「科学としてのソフトウェア工学研究の危険性。ほとんどの「定量的な結果」は非常に限定された条件下でのみ意味があるのに、ときにそれを金科玉条のようにして議論が進められる。この結果起こるのは、データに現れない心理的な部分の軽視である。 https://t.co/Shrb4HQn6G」■この手の指摘をつい最近オープンダイアローグの文脈で読んだ。この本『開かれた対話と未来』。オープンダイアローグの個別的な性質から成果を科学的に評価するのが難しいそう。難しいけどやってるみたい。■英語が不自由なので流し見だけどリンク先を読むと、新型コロナのときにも見られた「根拠はあるんですか」を戒める内容ぽい。つまり、有望そう妥当そうではあるけどまだ根拠がない論を「根拠は？」で潰して、安い根拠をそなえた愚策次善の策をありがたがるなよと、そういう雰囲気。私見ですけどね、データが必要なのは凡人と秀才だけで、馬鹿と天才にはデータの裏付けなんていらんのですよ。問題はデータがないと馬鹿と天才が見分けられないことで……。F = lambda{|a,p,k| } のシグニチャが見いだせたら９割解けている。それがなかなか解らなかった。シグニチャとは、親が p である(p の色は決定済みである)ノード a が取り得る色が k 種類のとき、a を根とする部分木を塗り分ける通り数。■提出 #34462566 (AC / 262 Byte / 313 ms)。こんがらかった考えをお風呂で整理したら、９行目の K-1,K-2 の場合分けが自然に出てきて、するするっと実装が完了しました。昨日から何度も解けた気がしては答えが合わないということを繰り返していたのにね。
.min だった部分を .then(&@m) に書き換えただけで通ってしまうのだなあ。あと細かいことだけど、コンストラクタに lambda を渡したのは失敗。ブロックが普通。b = a^x; (b&x)-(b&a) を書いた。これの間違いは A の方が X より大きな MSB を持つときに、それを操作(足し算)回数の節約には利用できないし、ましてや負の操作回数によって操作回数を貯金することもできないのにしてしまっているところ。■提出 #34171598 (WA×4 / TLE×10)。さっきの提出の修正版。BIT の添字の操作と同じように LSB を順番に取り出して、節約できる操作回数を正確に数えるようにした。WA が大幅に減って TLE が生じてるのはその結果。ではすべてが TLE になるのではなく依然として WA が４つあるのはなぜか。解を二分探索しているのだけど、MSB が異なる２つの解を比較したとき、ある要素 A にとって小さい方の解では無視されたビットが大きい方の解では操作回数の節約に利用できるという状況が起こりうる。判定に単調性がない。■……１時間経過。提出 #34178565 (TLE×1 / 5307 ms)。解の MSB が同じなら単調性があるわけなので高次のビットから 0/1 を決める方針。１ケースだけ 307 ms オーバーした。■終了後の提出 #34182184 (AC / 2052 ms)。判定が済んだ部分について入力のビットを折っておくことで時間の節約をした。そうすると決めて時間があれば書き換えはただの作業。■あわや緑落ちかというところまで下降しているレートにとっては１完でも +1 だったので、悪い日ではなかった。以下の操作を 0 回以上 N 回以下行うことができます」という制約が付いていた。一応ね、実装前にざっと制約を探しはしていた。でも制約セクションには入力の制約は書いてあっても出力の制約は書かれていなかったのだな。転倒数の総和の最大値はたぶん入力となる数列が逆順にソートされている場合で、0 から 2N-1 の範囲の和(=N(2N-1))になるから、入力次第で操作回数が N を超える。■次に考えたのは、入力の先頭を出力の先頭にとりあえず配置して、次に配置する要素を、出力の末尾との比較によって入力の前の方から貪欲に引っぱってくる方法。考えなければいけないのは、出力の末尾より大きい(小さい)要素が入力の中に残っていないときにどうやってジグザグを維持するか。たとえば出力の末尾２要素が O1,O2 で入力の残りが I1,I2,I3 のときに大小関係が O1<O2<I1<I2<I3 だったら、O2 より小さい要素を入力から選んでジグザグを作ることができない。解決するのは簡単で、入力の先頭を出力の末尾の１つ手前に挿入すればジグザグになる。O1 との大小関係も大丈夫。I1 が O1 より小さいせいでジグザグが壊れるならそもそも苦労していない。この解法のネックも操作回数で、2N の入力のそれぞれに対して 0 回から複数回の操作が必要になる。ランダム入力では N=100000 に対して 180000 回くらいの操作が必要になった。■次に思いついたのは(考えたって書くのやめちゃった)、さっきの解法の例で出した O1,O2,I1,I2,I3 の中で、O2,I1,I2 の大小関係にだけ注目してジグザグが作れるんじゃないかということ。３つの大小関係がどうであれ０回か１回のスワップで山ないしは谷が作れる。(O2 がスワップ対象だけど)スワップによる既成出力への影響はどうか。スワップが必要なのは真ん中の要素が山なら極大値、谷なら極小値になっていなければいけないのにそうではなかったときだから、山を作るためにスワップされたどちらかの端の要素はそれまでより小さくなり、逆に谷を作るためのスワップでは端の要素が大きくなる。山になる要素の隣は谷になるべき要素だから、スワップで小さくなってもジグザグは維持される。谷を作る場合も同じ。■提出 #34071956 (AC / 331 Byte / 212 ms)。N 回のループの各回で１回以下のスワップだから交換回数も大丈夫。精進だからこそトントントンと AC までステップが踏めたんだろうなあ。２番目のトンがなければ AC につながる３歩目のトンはなかったし、次の一歩が出てこないことも２歩目があさっての方向に向いていることもよくあることなので、５割以上の確率で０完になる AGC はリスキーすぎる。緑だったときにレート変動対象から外れて以来不参加だよ。■■■B 問題「Adjacent Chmax」は小さい P から順番に DP かなと思ったけど、何を記録するのかが(実装を始めても)はっきりせず。