|| とか)が省けるかを考える。今日は c==?i||c==?j (c は各文字) を一度書いてから 'ij'.index(c) もありだなと思ってからの 'ij'[c] で提出した。■B 問題 Music Player。珍しく長い変数名 playing と volume を使ったものだから、タイプしながら volume は長すぎるせめて vol にすべきだったと後悔していた。他の人の変数名が気になります。■C 問題 Peer Review。エルデシュ数とかベーコン数をイメージしながら UnionFind の雰囲気を感じていたけど、直接の利害関係しか関係がなかった。Hash を使って重複を除いたけど、制約で予め除かれていたので無駄だった。Hash を使うだけで目に見えて実行時間が増えるので、本当に必要なとき以外は使うべきでない。必要なときでもある数までは配列の線形スキャンの方がましなのである。■D 問題 Swap and Range Sum。隣接項の交換なら累積和を２点更新するだけだと思って書き始めたら、実は１点更新だということがわかった。添字で間違えないように{参照/更新}する可能性のある項をすべて列挙してから実際の処理を書いた。順番に並べて前後の位置関係をヒントにすればたぶん取り違えないだろう。■E 問題 Laser Takahashi。「すなわち、モンスターは大きさを持ちません」 偏角ソートして累積和の差分を答えるだけなんだけど、角度を逆引きする関数をリファレンスから探してきても誤差で殺されそう。私はもう Rational を使う楽ちんさを知っています。傾きを分数で持つ。分母がゼロの場合を irb で確かめると例外が飛んだ。じゃあその場合だけ小数の無限大で (Float と Rational の比較は Ruby におまかせできる)。求める累積和の区間が円環の切れ目を含むと面倒なので例によって２周分の累積和を用意した。傾きが等しい点を累積和でうまく扱えるように座圧(傾きを傾きの序列で代替)もした。サンプルが合わない。デバッグ出力を見てよく考えると Rational で表現した傾きでは原点で対称な点を区別できない。どうする、今からベクトルの扱いが思い出せるか？ どの象限にあるかという数字と傾きのペアでソートすることでなんとかなった。でも WA×5。象限によっては X=0 のときの値を負の無限大にしないといけなかった。これの修正に６分。全体では 25 分(+ペナルティ５分)かかった。■F 問題 Diagonal Separation 2。5000 の２乗は嫌な感じ。でも他には 600 点の G 問題しかないのでやるしかない。行単位で DP をするのかと思ったけどサンプル２が合わない。k の値を前の行から引き上げるとき、列方向の制約によって追加コストが必要になるのだった。そして日記を書いている今どうしてもサンプルが合わなかった理由がわかったのだけど、コストは追加されるだけではなく削減されることもある。１時間残していても問題を理解するのに足りなかったんだな。■■■F 問題水 diff 下位マジ？ なら解けたなあ、とは思えない。
P...P+100 と Q...Q+100 の範囲と比較する (３点ドットは半開区間)。■B 問題 Two Languages。難しかった。まず読み取るべきは「wi は高橋語か青木語のどちらかの単語」という制約。そうすると単語が高橋語のアルファベットで構成されているか、青木語のアルファベットで構成されているか、あるいは共通部分で構成されているかを判定すれば良い。
共通部分 ? 'Unknown' : 高橋語 ? 'Takahashi' : 'Aoki' という論理。ところが実際に問題を解いたときはそんなにすっきりとした区分けができていたわけではないから、入力を加工して共通部分を用意するということをしなかった。その場合は 高橋語ではない ? 'Aoki' : 青木語ではない ? 'Takahashi' : 'Unknown' という否定混じりの論理にならざるを得ない。それは難しい。■C 問題 Sake or Water。B 問題より素直。カップ数を最小化しつつある程度以上のお酒を飲みたいのだから、ソートして量の多い方から、最悪の場合を想定して飲んでいく。■D 問題 Paid Walk。出次数が４以下で、L が 10 以下。スタート地点は 1 で固定。4 の 10 乗が 100 万程度だったから、全部試せばいい。過去２回拍子抜けした経験からもうわかってきたけど、D 問題で DFS をやるときは、DFS 自体が課題という判定なのか高速化の工夫が求められない傾向にある。今日のこれは DFS に限らず BFS でも良かったのかもしれないけど、DFS で書きたくなる問題ではあったと思う。■E 問題 A > B substring。問題文に嘘が書いてありました。「S の空でない連続する部分文字列は N(N-1)/2 個ありますが」と書いてあって、これは S から 2 つの文字を選ぶ組み合わせだから、１文字だけの部分文字列がカウントされていない。半開区間で文字列を表すなら末尾の次の位置までをありうる区間として、空でない部分文字列の数は N+1 から 2 つを選ぶ組み合わせだから、(N+1)N/2 になるけども N(N-1)/2 にはならねーな。空でない連続する部分文字列の数をあらためて考えると、始点ごとの終点の数が 1 から N までだからその和で N(N+1)/2 になる。指を使って N=5 の場合を２回数えたから間違いない。ということをたどたどしく念入りに確かめてからリロードをしたら、目の前でしれっとマイナスがプラスに変わりました。やめてほしい。これでやっと問題に取りかかれる。A を +1、B を -1 としたときの累積和が正になるものの数を数えたい。Hash 表を使って愚直にカウントすることが許されない制約なので BIT を使うことを考えた。できそう？ できた。BIT で負の添字を扱うために N 程度の下駄をはかせてゼロの位置をずらした。その添字の操作を何度も繰り返すと間違えるので BIT 操作を関数でラップする丁寧さを見せた。■F 問題 Must Buy。DP です。N+数回 DP をすることが許されるならなんとかなる。ところが１回だけの DP をするのにも 5000 万のオーダーの処理になってしまう。時間制限を見るとちょい長めの 2.5 秒。Ruby だと苦労して工夫しても不可能な可能性があります。G 問題を読みましょう。■G 問題 Takoyaki and Flip。誤読をしていた。タイプ３のクエリではたこ焼きの合計を答えるのだと思っていたが最大値だった。図解で max とばっちり書かれていたけど、最初の実装を終えるまで見なかった。まだ誤読していた。タイプ２のクエリによって各お皿は１回だけ裏返されるのかと思っていたがそうではなかった。問題を正しく理解してからも、遅延セグメント木に何を乗せるか、不足に気が付いては足すということを繰り返した。区間演算について。たこ焼きを足すだけではなく裏返しもある。そして裏返しの裏返しは何もしないことではない。たこ焼きがゼロになっている。最終的に「表になっている面に足す」「裏返して０にする」「(裏の裏で)そのままの面で０にする」という３つの状態を考え合わせることになった。セグメントに保存する値について。裏向き無効と表向きの最大値のいずれかだけではなかった。ある範囲に表向きの皿と裏向きの皿の両方がある場合は、裏返しても裏返しても有効な最大値がある。最終的に表向きの無効値最大値と裏向きの無効値最大値を記録した。nullable integer のペアを記録したということ。提出 #72566496 (TLE×38/AC×27)。でも TLE です。しかも TLE の中に WA が隠れているのがほぼ確実。でも全然しっぽを出さなくてやっかい。■G 問題。レアなバグの原因がわかった気がする。Op::Abs2 と Op::Abs1 をセグメントに適用するときに、一度でも裏になったことのある面の最大値を、最大値がある場合はゼロにリセットするのを忘れている。どうせ TLE だから高速化のアイデアが出るまで再提出はしない。■E 問題。解説に O(N) 解答があるらしい。それは考えてみたい。■B 問題。昨日は大まじめに書いていたんだけど、解答の論理は否定も共通部分セットも使わずに
高橋語&&青木語 ? 'Unknown' : 高橋語 ? 'Takahashi' : 'Aoki' でも良かったのだな。横着して１文字あたりの判定を線形時間で書いて、判定結果を変数に保存もせず、だけど同じ判定を２回繰り返すまでは横着しきれなかったと見える。■■■動画を見ていたらブラウザからのコピペで Takahashi という風にスペースがくっついていたけど AC だったという話が聞こえてきた。これは自分もコンテスト中に気が付いていて、以前にそうならないようにした設定が失われているなと思ったのを思い出したので、改めて設定をし直した。Firefox で about:config を開いて space を検索するとまず editor.word_select.delete_space_after_doubleclick_selection = false という設定が見つかって、でもこれを true にしても期待した効果を発揮しなかったので下にスクロールしていくと layout.word_select.eat_space_to_next_word = true という設定が見つかって、これを false に変更すると期待通り余計なスペースが選択されなくなった。めでたし。異化：複雑な物質をより簡単な物質に分解し、エネルギーが放出される過程。代表例に呼吸や発酵がある」「
消化：細胞内や消化管内で、炭水化物・脂肪・タンパク質などが吸収可能な段階まで分解される過程。エネルギーは放出されない。」■さらに Wikipedia「異化 (生物学)」。「
異化は次の三段階がある。(略) この段階は消化管の消化酵素や細胞内のリソソームの酵素によって行われる。消化によって糖質、脂質、タンパク質はそれぞれの構成単位である単糖類、脂肪酸、グリセロール、アミノ酸に変えられる。」 分解して ATP を作るまでが異化で、その第一段階のうち消化管内で行われるものはもちろん消化だろうけど、異化の第一段階は細胞内でも行われている。■もうひとつ Wikipedia「消化」。物理的消化と化学的消化という分類があるな。消化に注目すると今度は咀嚼までがスコープに入ってくる。■異化と消化は現象というよりは目的や機能に付けられた名前であり、一部にオーバーラップがあるということで良いだろうか。異化の目的(最終段階)は ATP を生み出すことです。消化の目的(最終段階)は食べ物を細胞内に取り込むことです。その過程でどちらも物質が単純化されます。■消化について書いているときに、不用意に「体内」という言葉を使うと誤解しか招かないなと思った。口から食べておなかの中にある食べ物は体内にあるかないか。一般的な感覚では体内。人間を管に見立てれば体外。さっきコピペしたように、消化の文脈では消化管内と細胞内が対比されていた。どちらも体内としてしまうと意味ありげな区別が失われてしまう。
最終更新: 2026-02-05T02:10+0900
フリクション式のシフターがリアディレイラーのバネとの綱引きに負けてるのかな？
渋めに調整してもあんまり
スプロケットの台座であるフリーボディがぐらぐらしてる！
実は以前からハブ周辺を洗ってもすぐに赤茶色の錆が湧いてくる状態だった
直近では乗り出し直後に限ってだけどフリーのツメが引っかからなくて順方向に漕いだペダルが空転していた
新しいホイール (SHIMANO WH-RX010)
リムブレーキ非対応！！！
一応書くと、ホイールは中心からハブ-スポーク-ニップル-リム-タイヤといった部分で構成されていて、V ブレーキはリムを挟んで止めるリムブレーキの一種。ブレーキシューの当たり面の銀色がリム側面になかった
ホイールをゴミにするか後ろブレーキをディスクブレーキにするか
前ブレーキは 2014 年にすでに V ブレーキから油圧ディスクにしているが、後ろをディスクにする積極的な理由が何もないまま 11 年が過ぎていたのだった
以上のものがセットになってオイルも充填済みのものがシマノから出荷されているらしい。J-kit とかいうのがそう？
160 mm ローター用。軽量タイプ。
フレームのディスクブレーキ台座が IS (インターナショナルスタンダード) なので、ポストマウント式のキャリパーを取り付けるためにあいだに挟む。
フロントでは同じものの 180mm を使っている。シマノの３層構造のローターがよく鳴いてうるさかったので交換したら良かったので、後ろも同じに。
ローターもスプロケットもハブの両サイドで同じようなロックリングで固定されるけど、ローター用のものはスプロケットのロックリングより径が大きく厚みもあるので、スプロケットのロックリングが余っていても代わりにはならない。ならなかったんです。単体で買うと千数百円もする。とても高い。たぶんシマノのローターにはロックリングが付属していたはずで、それが今フロントで使われているのだけど、BBB のローターには付属しておらず、まさかこれがないために完成が一週間以上遅れるとは思わなかった。外セレーションタイプのロックリングもあって、ローターにどのタイプのロックリングが付属しているべきかわからないところもある。でもじゃあホイールかハブにロックリングが付属していてもいいんじゃないでしょうか！
フロントのブレーキは SHIMANO SLX のレバー (BL-M675B) とキャリパー (BR-M675-MF) が付いている。2014 年当時最も安価で導入できる油圧ディスクブレーキとして SLX グレードが人気だったように記憶していて、それにならったのだった。
相対的に前より重要ではないリヤブレーキに前よりお金をかけるのはもったいないのだけど、SLX のレバーにはないフリーストローク調整というものを試してみたかった。
SLX と DEORE XT のどちらのレバーにもあるのが握り幅調整というもので、指で回せる大きなネジでレバーとハンドルのあいだの距離(初期位置)を調整する。たとえばパッドが減ってくるとオイルを補充しない限りレバーをより大きく引かなければいけなくなる。オイルを補充するとパッド交換のときにピストンを押し戻すと補充した分のオイルがあふれることになるので、オイルは補充せずに済ませたい。そうするとレバーの初期位置をハンドルから遠ざけることで、レバーを大きく引いてもレバーとハンドルのあいだに指が挟まることがないようにすることになる。これが握り幅調整。だけどね、レバーの位置は手の大きさによって決まる一定の位置が最適です。フリーストローク調整というものでパッドの減りに伴う引き代の増加に対応してみたかった。
試しにいじってみたところでは、ものすごく微妙な変化が、あるようなないようなという感じ。それに自分は効き始めが早い方が好みなので、一番締め込んである初期状態が一番良い。そこからの調整は引き代が大きくなる調整しかできない。まあべつにいいよ。
最終更新: 2026-01-08T15:56+0900
エディタの内部文字コードに対応して \x20\x00 というパターンでスペースが検索できる。
覚えてないけどそうすべき理由を改めて調べた結論。消されてますけども。
@brief Perl互換正規表現 BREGEXP.DLL をサポートするクラス DLLの動的ロードを行うため、DllHandlerを継承している。 CJreに近い動作をさせるため、バッファをクラス内に1つ保持し、 データの設定と検索の２つのステップに分割するようにしている。 Jreエミュレーション関数を使うときは入れ子にならないように注意すること。 本来はこのような部分は別クラスとして分離すべきだが、その場合このクラスが 破棄される前に全てのクラスを破棄する必要がある。 その安全性を保証するのが難しいため、現時点では両者を１つのクラスに入れた。
このコメントに応える動きかなと思う。
しかし温存された CBregexp と一部の役割(検索手段とマッチ結果へのアクセス)が重複していることと、新しく生えた CBregexp::GetPattern が CBregexp を形骸化させていることが気になる。CBregexp の存在意義が曖昧。
include を見ると CBregexp.h と CBregOnig.hpp が循環依存していることからも現状はいびつ。
DLL ファイルとしての側面から生の公開関数と実装補助を提供していた CBregexpDll2 (あらため CBregOnig) に対して、CBregexp は正規表現 API の側面から DLL の差異を吸収する統一メソッドを実装していた。パターン＋マッチ情報クラスという、正規表現寄りで高レベル・一般性のあるものを生やすなら CBregexp の方では？ なんで「CBregexp::CPattern を CBregOnig に移動」したのかはわかりませんが。