/ 最近 .rdf 追記 設定 本棚

脳log[2020-09-05~]



2020年09月05日 (土)

最終更新: 2020-12-01T21:25+0900

[AtCoder] AtCoder Beginner Contest 175E 問題 Picking Goods

今週は ABC がないようなので精進である。D 問題が「コンテスト時間中には解けなかった」ので E 問題は問題文を読みさえしなかった。

 提出 #16526116 (AC / 1195 ms)

一行ずつ左から処理するにあたり保持するデータを vs = [0]*4 と定めたあとは、特に詰まるところはなかった。つまりそこで詰まったということであり、一番のお楽しみポイントだったということ。あるマスにおける状態と、状態から状態への遷移が、4要素の配列でまかなえることの発見が。

 Ruby によるすべての提出

今のところ2番目の提出より倍くらい速いみたい。だけど書き方による違いかもしれないね。

 (飛び道具*なしの) Python で一番速い 提出 #16010823 (ikatakos さん / 357 ms)

この人の名前は AtCoder を初めて日記に書いた 20190907 のこの部分(20190907p01.05)で初めて目にした。このときも Python で一、二を争うくらい速くて、同じくらい速い他の複数の提出から参考にしたと参照されていた。

参考にできるところがあるだろうか。

自分のスクリプトで気になっているのが r0[c] = vs.max と書いた部分で、長さ 4 の vs 配列のうち 1,2,3 番目は基本的に昇順ソート済みなのだけど、0 番目にイレギュラーが飛び込んでくるせいで vs[3] や vs[-1] とは書けずに vs.max と(4要素とはいえ)配列を走査するほかなくなっている。

up = dp[i - 1][j][3]
for w in range(4):
   dp[i][j][w] = max(dp[i][j - 1][w], up)

上のように、隣の行から値を引っぱってくるときに最大4要素を更新すればすべてソート済みであるとして末尾の要素を最大値として取り出すことができるんだけど……

 遅くなったよ! 提出 #16526544 (AC / 1480 ms)

もうわからぬ。

 kuma_rb さんの2つの提出

違いは入力 RCV を配列に記録するかハッシュテーブルに記録するかだけ。速くてメモリ食いが配列。遅い方がハッシュテーブル。要素数が少ないときはメモリ食いなのもハッシュテーブルの方なのであって、(メモリと GC が気にならない限り)いつでも配列を使っていきたいんだけど、この問題について言えば、R×C に比べて K がかなり少ないみたい。制約が「1 ≤ K ≤ min(2×10^5, R×C)」だから、最悪の場合が 900 万になるか 20 万になるかという違い。

ところで、いくつか見た感想なんだけど、作業配列は C+4 要素で十分だと思うんですよ。C×4 でも C×4×2 でもなく。入力を記録する R×C サイズの配列の前では霞んでしまう違いだけども、numpy の場合のパフォーマンス特性はわからないけども、要素の更新量は確実に減る。

 提出 #16528314 (AC / 934 ms / 36832 KB)

Python で一番速い提出 #16084621 を読んだ。コンパイル済みのバイナリを書き出して実行するなら Python である理由がないじゃん、と思ったんだけど、元になった Python のソースをちゃんと読めるようにしてくれている。コンパイル前のソースが Python なのだった。

長さ C の作業配列が昇順ソート済みだという特性が活用できていなかったことがわかったので、それを踏まえたコードに。あまり速くはならず。結局 R×C 回配列を更新するところは変わりがないから。

 提出 #16528556 (AC / 1813 ms / 188724 KB)

配列を昇順ソート済みにするための書き込みを省いて、配列の重複のない範囲から最大値を抽出するだけにすれば良くなると思った。倍遅くなってメモリ消費も激増した。むしろ逆で、予想外のメモリ消費がスローダウンを招いた? Array#[] か Array#max に何かある?

 提出 #16528834 (AC / 1038 ms / 46636 KB)

vs[0] = [vs[0],r0[c0..c].max].max

# r0 に関わらない処理

r0[c] = vs.max

だったものを

vs[0] = [vs[0],r0[(c0..c).max_by{|i|r0[i]}]].max

# r0 に関わらない処理

r0[c] = vs.max

に書き換えたところ、1つ前の異常なメモリ消費、異常な実行時間だったものが、2つ前よりメモリも時間もやや悪いという、予想の範囲内の結果に収まった。

いや、悪くなってるのはがっかりなんだけど、1つ前の悪くなり方はやはり尋常じゃなかった。配列に最大値を聞くのではなく、添字の範囲を使って配列の最大値を求めるという回りくどいやり方より遙かに遅かったのだから。

素直なやり方で予測可能な結果が出るなら速かったりしないかなあ。

 提出 #16543158 (AC / 727 ms / 37188 KB)

困ったときのセグメントツリー。もう3回目の実装なので空で書いてバグも無し(でも一応内部データを目視するテストはした)(1回目と2回目は空で書いてバグだらけ)。メモリ参照の局所性なんて関係ないハードウェアから遠い言語でできる悪あがき。今のところのベスト。こんな作業ってアルゴリズムひとつで桁違いの差をつけて置いて行かれる類のものだ。楽しくはあるけどこれで終わり。

@l の利用場所すべてで @l+1 って書いてるから @l の定義から -1 を削っておけば良かった。

* コンパイル済みのバイナリ展開とか。


2020年08月27日 (木) 大阪・関西万博ロゴマークが「なんかこわい」とネットざわつく 発表後即「コロシテ」がトレンド入りする事態 (1/2) - ねとらぼ」■【速報】大阪万博ロゴ決定 ナイスデザインと話題に : 暇人\(^o^)/速報 - ライブドアブログ■「いのちの輝き - Bing News」■「キーワード検索 - コロシテ」■「触手を振り回す未知の怪物となって暴れるホラーメトロイドヴァニア『CARRION』レビュー」■すごく「らしくて」いいと思う。大阪だからね。不気味ちゃうで愛嬌やで。


2020年08月26日 (水) [Ruby] 当然あるだろうと、先にタイプしてから存在を確認するメソッドに Numeric#sign がある。ところが 2.7 にもないのである。zero?, nonzero?, positive?, negative? は存在している。でも -1,0,+1 のいずれかを返す sign メソッドはないのである。レシーバが -0.0,+0.0 の場合に何を返すべきかはすぐにはわからないけど、-1.0,+1.0 を返すのは罠になりそうなのでレシーバ自身が無難だろう。■「sign メソッド」で検索したらトップに出た>「Math.Sign メソッド (System) | Microsoft Docs」。ほらほら。■■■わかったぞ。i <=> 0 で代用できる。メソッドであってほしいものと演算子で十分なものと、なんかちぐはぐだね。■<=> (Spaceship Operator) についてビャーネさんが何か言いたそうにしていたのをどこかで読んだ。Ruby での存在意義はこの1メソッドを定義するだけでクラスを Comparable にできることだと認めてはいる。でも C++ では何を追加しても、互換性を保って追加をする限り、煩雑さを増すことにしかならないだろう。■Uniform Function Call が一番楽しみだな、C++ に導入されるとしたら。シンタックスの統一はテンプレートの適用を拡大するし、メンバ変数を使用しないアクセサリメソッドをグルーピングのためだけにメンバ関数にするような暴挙を阻止できる。

最終更新: 2021-10-24T17:45+0900

[AtCoder] 第二回全国統一プログラミング王決定戦予選 - AtCoderC 問題 - Swaps ()

読んだ眺めた>「競プロerのための群論 (swapと順列と対称群) - little star's memory

数学の用語で何か抽象的なことを言ってるなーということと、Swaps と Moving Piece の2問(だけじゃないけど)が取り上げられているということはわかった。

Moving Piece は先日解いたので(20200820p01)、以前解けなかった(20191111p01) Swaps も解ける気がした。

 提出 #16248329 (AC / 403 Byte / 283 ms)

もちろん今日も AC に至るまでに WA を出した。それも前回と全く同じ入力に対して同じように誤った答えを出した。前回書いたスクリプトはひとつも参考にしなかったにも関わらず、構成も結果も瓜二つなのは、書いた人間が同じだからですね。同じところに留まっている……。

 デバッグ

前回と違ったのはテストケースが利用できたこと>「atcoder_testcases > nikkeiqual_2019 > C

今回のような Yes/No 問題の場合、間違った方法ででたらめな答えが出ても2分の1の確率で AC になってしまいデバッグが捗らない。そのような場合に(テストケースなしでも)使える手法をひとつ思い付いた。

 提出 #16245274 (TLE)

スクリプトの真ん中に sleep (※引数なしなら永眠)を仕込んで、前半部分の Yes/No 判断に誤りがないかを確かめた。結果は TLE と AC のみだったので、前半部の判断は間違っていない。

 提出 #16245473 (WA)

予想外の WA (TLE なし)だった。これは後半部の No を sleep に置き換えたものなのだけど、1つも TLE がなかった。1つもないというのは(入力とバグり方がコラボした)偶然の結果なのだけど、偶然でもなんでも無条件 Yes は明らかなバグだ。

こんな感じで TLE(sleep) や RE(ヌルポ、0除算、変数名タイポ)が Yes/No ではない第3、第4の答えとしてデバッグに利用できると思った。こういう(アナーキーな)考え方ってゴルファーが得意としてそうだよね。常識だと思ってそう(違うんですよ)。

 バグ

わかってみれば些細なことで、思えば去年もインデックスの扱いに確信が持てずに試行錯誤をしていた。どうして B 数列が予めソート済みではないという、そのひと手間で穴にはまるのか、何度でも。

つまり、A 数列の初期配列と B 数列の初期配列。A 数列のソート済み配列と B 数列のソート済み配列。A, B 両者の扱いが対等なこれら4つは脳みその中に居場所が確保されていた。しかし、B 数列の初期配列をソート済みとする、と条件を整えたときに A 数列の初期配列がどうなるか(ソート済みではないし、元の初期配列とも異なる)、という概念が脳みそからすっぽり抜け落ちていた。A, B の対称部分に気持ちを良くして、差異に向ける目がなかった。去年も、今回も(初めは)。

 去年の借りを返す 提出 #16278383 (AC / 445 Byte / 199 ms)

「去年の WA」を完成させたもの。必要以上に慎重だった(見極めが甘く無駄だった)二分探索がないぶん、冒頭の AC 提出より速い。

 考察(おまけ)

前回の日記に全部書いてある(あれで全部だった)。ひとつだけ付け加えるなら、「逆の例は、B 数列に重複する値が存在する場合や、B 数列の最小要素以下の要素が A 数列に複数ある場合など」の「など」でごまかした具体例の3つ目。

ソート済みの B 数列に異なる値を持つ隣接要素 B[i] と B[i+1] があって、B[i] < A[k] <= B[i+1] となる A[k] が存在しないときも、A 数列のすべての要素にあるべき位置が存在するとは言えなくなる。(A 数列がソート済みなら B[i] < A[i+1] を確かめるだけでいい)

最終更新: 2021-08-15T23:54+0900

[AtCoder] 第二回全国統一プログラミング王決定戦予選 - AtCoderD 問題 Shortest Path on a Line

余勢を駆って前回2つの WA であっさり引き下がっていた D 問題に再挑戦した。これも C 問題と同じ 600 点問題。

 提出 #16254983 (AC / 387 Byte / 402 ms)

実は区間の片端に着目した貪欲法で解けるんですよ、というのが目から鱗だったスケジューリング問題そのままだった。どこにそう書いてあったかは忘れた*

前回の WA 提出 #8424473 を見ると、今と同じことは考えていたことがわかる。C 問題の場合にも言えるけど、そこで結果を分けたものが何か。考えたことを過不足なく言い換えることと、バグなくコードに置き換えること。それができるかどうか。

それはどうやったらできるようになるんですか? という問いは、どうしてそこで間違えたんですか? という問いと対になる。わかりませんよ。ワーキングメモリが足りないんじゃね?(テキトー) こういうとき脳筋は手を動かして慣れるしかない。そうすればより少ない脳のリソースで解けるようになったり、型通りの手法で解けるようになったりして、うっかりや見落としで間違えることがなくなる(という期待)。

 去年の借りを返す 提出 #16288240 (AC / 319 Byte / 375 ms)

区間のどちら端に着目するか。冒頭の AC 提出では L のソート順に処理していたが、「前回の WA」では R でソートしていた。それを完成させてみたら、冒頭の AC 提出で使用していた Array#slice! と Array#insert という、配列に対して呼び出すにはやや気が引けるメソッドが、Array#pop と Array#push という配列に相応しいメソッドに置き換わっていた。二分探索も3回から2回に減っている。Swaps の場合もそうだったけど、AC に至りさえするなら部分的には過去の方が優れてるのなんでだろう。

 解説記事を読んでもわからないので自分で書く。

グラフとか最短経路とかコスト0の辺を張るとかわからへんねん。

R でソートするバージョン(#p02.02)。

  1. RC を、ある地点(R)に到達する最低コスト(C)を記録したリストとする。R が同じならコストの低い方を記録する。R についても C についても昇順(2要素の比較において R が大きければ C も大きい)。リストは最初空で、R の昇順に伸長していくこととする。
  2. 区間 [L,R] から R までをコスト C で繋ぐ場合を考える。
    1. RC を二分探索し、最初に L かそれより後ろに到達する要素を見つける。より遠くに到達する要素はより高コストなので「最初」を見つける。

      見つからない場合は断絶があるということでありパスする。R の昇順に RC に要素を追加しているのであり、今後 [L,R) の区間に到達する辺は現れない。R に到達する辺があとから追加されることはあるが、C が負ではないのでパスで良い。

    2. 見つけた要素のコストを加算して C′とする。辺を追加することによりコスト C′で R に到達できることになる(始点は問わない)。
    3. RC に記録されている C′より高コストの要素は用済みであり取り除く(RC がコストの昇順であることを利用する)。処理時点で R が最遠到達地点であり、それより近くに高コストで到達することに価値がないから。
    4. ペア [R,C′] に記録する価値があるなら RC の末尾に追加する。
  3. ということの繰り返し。

ひょっとしたらこれも DP (動的計画法) の一種かもしれないけど、わからんけど、自分が頑なに DP の用語を使わないのは、それを言ってもメリットがないから。

一行ずつ左から処理するにあたり保持するデータを vs = [0]*4 と定めたあとは、特に詰まるところはなかった。つまりそこで詰まったということであり、一番のお楽しみポイントだったということ。あるマスにおける状態と、状態から状態への遷移が、4要素の配列でまかなえることの発見が。

これもそう。DP の核心は何を記録して遷移するかであり、それがわからないのに、「あ、これ DP だ」ということを言っても問題が解けない。むしろそれを言うことで何かわかったつもりになることが目眩ましになって問題に集中できない。過去に何度かそういう失敗をして、DP だということは言わないことにした。dp という変数名も自分にとって何も説明していないので使わない。

DP の一語でなく、配る DP、集める DP まで区別できるとまた違うのかもしれないけど、自分はそれらを識別しない。

 @2021-08-15 ARC026-C 蛍光灯 が同じ問題だった。

どちらがどちらと同じと言うかはまあいいや。

 提出 #25085547 (AC / 295 Byte / 269 ms)

速いでそ>「Ruby によるすべての提出」 それ以前に提出が少なすぎる……。

* 蟻本(初版第1刷)の43ページ「区間スケジューリング問題」だった。


2020年08月25日 (火) 【第104回インディ500速報】佐藤琢磨がディクソンの猛追を抑え2017年以来2度目の快挙を達成 | 海外レース他 | autosport web


2020年08月24日 (月) 日本人が間違えやすい英語表現シリーズ」■Congratulations! の s は見れば必ず付いてるよね、バック(bag)とか細かいところをいいかげんにする人を除いて。think の目的語に対応する疑問詞が what なのは中学生のときに(塾で)くどいほど……。「納豆食べられる?」は日本語が文字通りの意味でないせいでわかりにくいのかなと思う。能力的な話をすれば胃ろうをしているような人でなければ食べられるのは間違いのないところで、「食べられる?」が実際に聞いているのが「あなた納豆食べる人?(納豆をお出ししても大丈夫?)」であるあたりが逐語訳を誤らせるのだと思う。「日本の首都はどこ?」はどうだろう。Where's my bag? がありなら Where is the capital of Japan? の答えは「このでっぱり(房総半島)の左(東京湾)に面したこの小さいエリアがそうだよ」になりそうではある(なんの問題が?)。know of の of は何か距離を感じさせるね。話には聞いたことがある、という感じ。still five の誤りはエンドレスエイトを想像させるところにありそう。今5時でさっきも5時だった、みたいな。「still⇔まだ」ではない。still のイメージは静止・停滞だと思ってる。留まり続けていることに対して、まだそこにいるのか、という印象を still で表現することはあっても、すべてのまだが still になるわけではない(と思うんだよ)。only five はちょっと出てこないな(覚えておこう)。


2020年08月23日 (日)

最終更新: 2020-08-26T10:30+0900

[SakuraEditor] 上書き禁止と排他制御と編集禁止

 CDocLocker とは

ある時点でのファイルへの書き込みアクセスの可否を保存し、エディタの「上書き禁止モード」を体現するクラス。CDocLocker::IsDocWritable が第一義。

  1. 書き込みアクセスができた
  2. CDocLocker.IsDocWritable(); // true
  3. 上書き禁止モードではない

 上書き禁止モードと排他制御

排他制御を行うのに書き込みアクセスは必須ではない。しかし書き込みアクセスができることをエディタは条件にしている。自身が書き込みできないファイルに対して「お前らこのファイルは俺のものだぞ。勝手に読んだり書いたりするなよ」と主張することのナンセンスを考えれば納得できる。

書き込みアクセスがないなら排他制御はやめとこか、くらいの温度感なので、CDocLocker.IsDocWritable() に基づいて判断を下している。今現在の瞬間の書き込みアクセスを条件にしているわけではない。

 上書き禁止モードと編集禁止(※編集禁止は状態としてはビューモードと同じ)

「上書き禁止検出時は編集禁止にする」というオプションによって、上書き禁止モードがより制限の強い編集禁止状態へと格上げされる。

(別のファイルとして保存するために)上書きできなくても編集はしたいという考えも、上書きできないのなら編集できても意味がないという考えもどちらもあるだろう。そこはどちらでもいい。

 上書き不可の検出タイミングについて考えたい

これは CDocLocker.IsDocWritable() の値が変化しうるタイミングと同義。次のようになっている。

  • ファイルを開いたあと
  • ファイルを開き直したあと
  • ファイルを保存したあと
  • 排他オプションの設定(しない/上書きを禁止する/読み書きを禁止する)を変更したとき
  • ビューモードのオンオフを切り替えたとき
  • タイマーで外部からのファイル更新を監視するついで(※)

※ 最後だけは「書込禁止の監視を廃止(復活させるなら「更新の監視」付随ではなく別オプションにしてほしい)」というコメントとともに無効化されている。

上書き禁止モードの変化が排他制御を試みるかどうかと編集禁止モードのオンオフに影響するのはすでに書いた。

  1. 排他オプションを変更したときに上書き可否を改めて検知しているのは理に適っている
  2. 「上書き禁止検出時は編集禁止にする」にチェックを入れたときに上書き禁止モードのオンオフを改めようとしないのは、排他オプションの場合と比較してちぐはぐ。
  1. ファイルを開き直したあとの上書き禁止モード改め時には「すでに編集できない状態ならファイルロックのメッセージを表示しない」という再メッセージ抑制策がとられている。
  2. ビューモードをオフにしたときには、何度でも「ファイルがロックされている(上書きが禁止されている)」というようなメッセージが出る。モードの切り替えとファイルの開き直しを比較して、メッセージ抑制策の有無の分かれ目とは?

2組の比較を挙げたけども、どうにも扱いがちぐはぐで行き当たりばったり感がある。上書き禁止がいつ検知・再検知されるのか、すっきり説明できるようにしたい。

 再検知により上書き禁止モードがオフからオンになることについて

オプションにより編集禁止モードと連動する。ファイルを開いたときに上書き可否を検知し編集が禁止されるのは、ユーザーの選択でもありなんの問題もない。

しかし一度編集を開始したファイルに対して、アンドゥバッファが溜まり更新フラグが立ったファイルに対して、先ほど挙げた再検知タイミングを挟んで、上書き不可が検知され編集が禁止される事態が起こりうる。これはユーザーの望む動作であろうか。いたずらにユーザーの操作を制限しているだけではないのか。

ビューモードをオンオフするタイミング次第でエディタが編集可能になったり不可能になったりするようなことを誰が望んでいるのか。結局のところ編集禁止の根拠となっている上書き禁止モード、つまりは書き込みアクセスができたかどうかは、過去のある時点ではそうだったというだけなのに。

 上書きができないことと上書き禁止モードの差

ファイルの保存をしようとしてその直前のテストで書き込みアクセスが拒否されたところに、こういうコメントがあるのがおもしろい。「たとえ上書き保存の場合でもここでの失敗では書込み禁止へは遷移しない

上書き禁止モードを体現する CDocLocker.IsDocWritable() の値が変化しうるタイミングをいくつかすでに挙げたけども、実際に上書き保存をする直前というタイミングがそのリストから明示的に除外されていることになる。

実際上の理由はわかる。最初の上書き失敗を理由にして2回目以降のトライを勝手に諦めてもらっては困るからだ(上書き禁止モードで上書き保存は選べない)。

上書き禁止モードが何ではないのかがよくわかるコメントではないか。

 ビューモードと上書き禁止モード(と編集モード)の差

  • ビューモードはユーザーがオンオフできるが、上書き禁止モードは自動で発動する。

なお、自動で発動する上書き禁止モードをビューモード相当の制限に格上げすることができる(「上書き禁止は編集禁止」オプション)。

 上書き禁止モードをユーザーがオンオフできてもいいのでは?

上書き禁止モードを仮にユーザーがオフにしたところで、上書きできないときには上書き保存に失敗するだけのことだ。ついさっき挙げた、この失敗から上書き禁止に遷移はしない、というコメントの状況が発生するだけのことだ。

ビューモードほど強い制限でなく、ファイルシステムからの要請でもなく、ユーザーが自分の意思でこのファイルには上書きしないと宣言するモード(上書き禁止モード)があってもいいのでは?

 ビューモードをオフにする行為とは?

派生して、ビューモードをオフにするタイミングで書き込みアクセスの可否を再判定して、上書きモードのオンオフを更新する現在の挙動についても再考する。

上書き禁止モードは結局のところエディタやユーザーの選択の結果でしかない。書き込みアクセスが拒絶されたとて、そうあらねばならないモードではない。

ビューモードのオンオフ、上書き禁止モードのオンオフという操作によりユーザーが3つのモードを自在に行き来する状況を想定すれば、ビューモードのオフは編集モードへの移行であるべきでは?

 上書き禁止は編集禁止、あらため、上書き禁止はビューモード

ファイルを開いた際にユーザーの便宜のために自動で上書き禁止モードやビューモードを適用する機能があっていい。今は何が違うかというと……

  • 上書き禁止モードへの移行を拒否できない。
  • 上書き禁止モードが任意でオフにできない。
  • 「上書き禁止は編集禁止」オプションが文字通りの意味であり、上書き禁止モード(編集は可能)が上書き禁止モード(編集も禁止)によって上書きされている。
  • 上書き可否検出タイミングが場合により不合理(一度テキスト編集を開始したあとで編集を禁止されることになると……)。

 サクラエディタでファイル(テキストファイル等)を開くとファイルの更新日時が変更されてしまいます。

せっかくなので理解した内容を長々書いてきたけどもそちらは本題ではなく、そもそもは標記の現象のための作業をしていた>コード。それで何か嬉しいことができたかというとそういうことはない。現在のステータス……

  • 書き込みアクセスの要求が原因だとは決まっていない。
  • 予備的に書き込みアクセスを要求しないようにコードを修正しても、排他制御の判断と、上書き禁止は編集禁止オプションと、文字列展開のためにはやっぱり必要。
  • 書き込みアクセスを確認する、より穏当な代替手段を探しては?
  • ファイルを保護するというお節介ソフトの挙動をそういうものだと受け入れては?

2020年08月21日 (金) 歯磨きをするときに事前にお茶を飲んでみるのはどうだろう。前歯の裏側の際など、いつまでもいつまでもざらざらした感触が舌の先で触れられるのがわかる。このざらざらが感じ取れなくなるまで磨く。奥歯の一番奥の側面(U 字の先っちょ)もそう。いつまでもいつまでもざらざらしているものを、つるつるするまで磨く。全体でだいたい10分かそれ以上かかる。風呂場でしぶきが飛ぶのを気にせず磨く。歯磨き粉をつけてガシガシ磨くと知覚過敏というのか冷気が染みるようになったので、歯磨き粉は最後の仕上げとしてサッと使う。夕食の魚の油を落とすのが使う一番の理由。毎日でも隔日でも使うと染みたのがブリリアントモアで(毎日飲む紅茶の茶渋を落としたかったのだ)、今はチェックアップを使っている。こちらは唇に染みる刺激物も歯を削る研磨剤も控えめのようで、毎日使っても大丈夫。歯ブラシはエビスの6列だとか7列だとかの堅めを使っている。堅めでガシガシ遠慮なく磨くとはいえ、口をすすぐお湯で軟らかくなるし大型ヘッドで圧力は分散するし研磨剤も使わないしで、バランスは取れている。だいたい1か月もつ。それくらい経つとブラッシングに時間がかかるようになるので、新しいのに替えた方が効率が良い。さらりと大事なことを書きました。磨くというのは決まった時間ブラシを動かすことではなく、ある状態へ至ることを指しています。■この日記を書いたのは「ADHD者が日常で駆使する呪術|mentane|note」を読んだから。そこの見出しのひとつ「見えないものは存在しない」とは先日そのままを書いたばかりで(20200811)、なにか嬉しくなったから歯磨きについても書いた。食材についても書く。スマホのホーム画面にメモ帳ウィジェットがあってそのひとつが食材リストだ。購入した日にレシートをもとに入力する。買ったものは責任を持ってせっせと使い切り、リストから消す。リストから消す行為は解放される喜びと結びついている。ろくに料理をしないので成り立っている側面はある。冷蔵庫に入れる際にひと目見ておけば賞味期限とともに存在を覚えていられる程度しか扱っていない。


2020年08月20日 (木)

最終更新: 2020-08-24T19:08+0900

[AtCoder] AtCoder Beginner Contest 175D 問題 Moving Piece

コンテスト時間中には解けなかった。昨晩から苦しんで夕方に初の AC をもらった>「自分の提出

 最初の提出 #15953114 (RE / TLE)

バグが2種類あったけど方針は間違ってなかった。

 バグ1:K が各巡回グループ(配列 A の要素)の要素数より大きいときの端数(K%A[i].size)の扱い。

巡回グループの部分列(スコア数列)の和が最大となるときを考える。部分列の最大長が K%A[i].size 以下となる範囲で和の最大を求めるより、一周少なく回って(A[i].sum 1個分のハンディを背負って) K%A[i].size 以上 A[i].size 以下の長さで和の最大を求めた方が得する場合がある。

RE の直接の原因は、最初はゼロ除算を疑ったのだけど、Array#take の引数 k-1 が負になることだった。その値の出所が K%A[i].size。

 バグ2:1以上 K 個以下の連続する部分数列のうち和が最大となるものの求め方。

バグというよりパフォーマンス問題。Array#product で総当たりをしたので、間違いはないが時間がかかりすぎた。バグらせずに時間内に求める方法が最後までわからなかった。

 最初の AC #16057773 (729 Byte / 77 ms)

やっとバグ2がとれた。総当たりの方の、間違いではないが時間のかかる方法と答えをつき合わせてデバッグをした。

こうやって振り返ってもさっぱり参考になることが書いてないね。実装が難しかった、しかない。

 Ruby によるすべての提出(実行時間昇順)

現在の2番目のタイムが 95 ms。区間の最大値ということでセグメントツリーの使用は一応考えたんだよ。だけどこのときのこれが頭を離れなかった>「追加する要素との大小関係によって、待ち行列の末尾から、永遠に最大要素(最小要素)としての順番が来ない要素を追い出す」。おかげで 77 ms。

理想的にはこんなふうにすっきり鮮やかに解きたいね>提出 #16033967 (581 Byte / 175 ms)

普通に累積和の配列から k 要素を切り出して最大値を取り出してる(ss[_1 + 1, k].max)。回路長の3倍の長さの累積和配列を用意してるのがよくわかっていない工夫か(ss = (1 .. 3*l).each_with_object([0]){|j, o| o << o.last + Cs[lp[j%l]]})。

ss[l] が回路全体のスコアの和。0...l の範囲の1点を始点にして長さ k(+1) の部分列を切り出す。k = mi[K, l + K%l] だから、最大で [l-1+(l+l-1)+1] の要素にアクセスする。長さは 3l 必要。 ma[0, ss[l]] によって回路全体のスコアの和が正か負かの場合分けを省略している。

Array#max を分岐と見ることもできるかもしれないけど、場合分けをしてそれぞれに固有のスペシャルな式を書くより、Array#max, Array#min を含んでいようとも1つの統一された式を書きたい。実に自分好みのスクリプト。「if 文が嫌いである。(20181029)

そうだそうだ、自分は長さ k の部分列の始点を負のインデックスにすることで仮想的に配列の長さを倍にしたのだった。小賢しい。まあ、それでは長さ 2l にしかならないから、3l が必要な「場合」は配列の加算(a+a)をしている。このやり方をとる限り場合分けを解消できないね。


2020年08月18日 (火) ソニーストアはXperia SIMフリーモデルのご購入をしっかりサポート!」だってさ。とても良い。アマゾンで香港のストアからグローバルモデルを買うしかなかったけど故障したときが不安、というのに応えてくれるといい。Xperia 10 から買い換えるときまでやっていてほしい。


2020年08月14日 (金) 『なぜ左利きはボールペンが書きづらいのか』を図解「ボールペンってこういうものなのかと思ってた」「どいつもこいつも右利き用」など共感の声 - Togetter」■つい数日前に銀行でふと見かけたぎっちょの人が、手首を鉤のように曲げて書いているのを不思議に思っていたところ。紙を削っちゃうからそうなるのね。


2020年08月13日 (木) 知り合いとか知り合いの知り合いくらいの人がなるべく多くの人に届けたいであろうツイートはRTしているが、「拡散希望」って書いていると一気に絶対やらないという気になる。なぜかはよくわからない」■自分は YouTube 動画の冒頭末尾の定型文句は様式美として嫌いではないけど、たぶんブックマークしてる投稿者の人柄込みでそういう評価なんだけど、拡散希望から受ける印象はまるで異なる。発端となったツイートの事例からはあなたに知ってほしいという利他の気持ちが伺えるが、拡散希望からは邪悪な意思を読み取る。邪悪というのはたぶんに主観的な評価で、数を募る、数を頼みにする、数を力に変えようという意図が、自分の価値観とは決定的に相容れない。だから拡散希望は邪悪。


2020年08月11日 (火) [Xperia 10] だいぶ後回しにされていたが今日 Android 10 が降ってきた。あまり変わってなくて満足(←そういう評価)。さしあたり気がついた相違点は3つ。■1.いたわり充電が学習に基づいたブラックボックス動作のみから、手動でパターンを設定できるようにもなっていた。20190518p01.06に書いた通り。誰でも考えるってことだ。■2.STAMINA モードを「常用」していたのだけど、そうすると勝手にダークモードになるようになった。ダークモードは常用しないので STAMINA モードもオフになった。バックライトの強弱と比べて画面の黒白にユーザーの好みを上書きして正当化されるほど意味のある差があるか? 有機EL ではなく液晶だぞ。■3.Android の仕様だと思うけど、画面上部に常駐するステータスアイコンが飾りになった。何のアイコンなのか説明しないし反応もしない。場所を占めるだけの模様になった。20200513にスクリーンショットを貼り付けた画面にアクセスしにくくなったし、そもそもバッテリー画面からあの残量遷移グラフがなくなっていて有用性が下がった。点々メニューの中にはあるのか知らんけど、見えないものは存在しない。隠して平気な顔をしていられるなら最初からいらないものだったんだ(必要だから最初から見せろと言っている)。■エキスパートモード(一部の設定やメニューを隠すこと)は役に立たないとマイクロソフトの人が書いている。結局のところそれらは必要があるから存在しているのだし、何が必要かは人による。何を隠しても誰かを欺くし、ある意味で誰もが何らかの項目が見つけられなくて欺かれる。■4.アラームの通知が制御できなくなった。持ち主の意向を無視する何の特権があるってんだ。どうでもいい通知が紛れてくるなら、あらゆる通知がどうでもよくなる。通知なんてそんなもんだ。ただのきっかけを与えるに過ぎない。しかしそれは極論であって、あると便利な通知もある。だが制御できないならすべて視界から消えろ。■5.色彩がきつくなった。もともと妙な強調はオフにしていたのだけど、そのオフの設定での色調がきつくなった。


2020年08月04日 (火) 1年目に片付けて9年間その状態を維持するのと、9年間散らかしたままにして10年目に片付けるのと、かけた労力と最終結果が同じでも9年間の QOL がまるで違う。これが(改心した)片付ける者の考え。散らかり度合いの上げ下げで労力を計り、時間軸の積分で QOL への悪影響を計る。一方で片付けない者に片付いた状態は永遠に訪れないので、比較が意味を成さない。■右折でどこかに入りたい車が対向車線を塞いでいる状態もこれに似ている。1台目が譲るのと100台目が譲るのでは、譲った側の車線のスローダウンが同じでも、対向車線がストールしていた時間がまるで違う。職業ドライバーは自分が苦労するからか全体最適をよく考えていると思う。