/ 最近 .rdf 追記 設定 本棚

脳log[2021-05-31~]



2021年05月31日 (月) クマのプーさん病理テスト」やった。結果はルー(77%)だって。知らないなあ。よく見ると、誰にも当てはまらないのが当たりなのか(はずれキャラしかいない)。もちろんはずれで何の悪いこともない。マイペースで几帳面だと解釈して何の問題もない。■質問の中には回答者自身よりも環境に答えが左右されるものがあった。それはどうなのか。自分は周囲の人間に恵まれてきたのでそれを反映した答えになるよ。あと現状の認識ではなく未来への願望を問う質問もあった。べつにどうにかしたいと思っていないので、当てはまらないという回答になるよ。


2021年05月29日 (土) [AtCoder] 今週 ABC ないの?ってツイートを見かけて、えっ直前になって消えたの?って atcoder.jp を確認したけど消えていなかった。明日ある。そのうち ABC が2回ある週が来るね。■ちなみに今日は ARC があった。ARC の AB 埋めをすべきときなんだよなあ(B 問題が解きたいです)。


2021年05月28日 (金) 好き。「【MV】GIRI-GIRI borderless world / LizNoir 作詞・作曲・編曲:Q-MHz【IDOLY PRIDE】 - YouTube」 特にこっち。「【IDOLY PRIDE】第11話 LizNoir「GIRI-GIRI borderless world」 - YouTube


2021年05月27日 (木) 全部で 10 程度しかチェックしていないのに何か所かでリツイートされていたパズル。「「Twitterでたまたま見つけた、日替わりのカレンダーパズル。 天才が作った臭がプンプンする。 なかなかに難しかったが今日の分をクリア。 https://t.co/j9blzcV2tV」 / Twitter」■興ざめなのは承知の上で、箱入り娘も解いたことだし(20210121)、このパズルもコンピュータに任せて解いてみた>a-puzzle-a-day.rb27。ひとつの日付に対して何通りも答えがあるみたい>num_of_answers.txt。特に難しそうなのは10月6日(7通り)と4月6日(8通り)。しかし、解くのはともかく、作る方は何を考えれば可能になるというのか。■「Makuake|「最近記憶力が落ちたかも…」そんな人に贈る毎朝1回のパズル習慣で楽しく脳に刺激を|マクアケ - アタラシイものや体験の応援購入サービス」 ここによると1つの日付につき答えが最低で7、多いと 200 以上あると書いてある。7と 216 だとしたらスクリプトは間違ってなかったっぽい。でも答えの合計は 25061 であり 12 万通りもなかった。表裏同型とか回転対称を区別してカウントすると、ってことでいいだろうか。まあ、マーケティング的な動機による? でも表裏同型が3ピースで、表裏を別とすると 25061×8=200488 通りになるから、キリよく「答えは 20 万通り以上」になるはずで、数え間違えてる? あり得ない日付(2月30日とか)を除外しても答えの合計は 24405 であり 195240 だから疑念は解消しない。月月、日日などカレンダーとしてはありえないけどとにかくピースが枠に収まる組み合わせかとも考えたけど、59787 通りであり半分以下。謎は解けない。バグか?■解のない日付が生じる別バージョンが紹介されていたのでそのボードもスクリプトに足しておいた(1 をコマンドラインオプションにして実行する)。その場合の解の個数>num_of_another_answers.txt。答えが0なのは3月14日、7月1日、7月3日、11月7日の計4日だと出た。■空き部分を埋める1マスのピースが2つあると考える。この2つを区別し、なおかつカレンダーとしてはありえないどの位置にきても構わないとする。そうすると先に挙げた 59787 の2倍、およそ 12 万通り(119574 通り)が解となる。そういう解釈でいいだろうか。(考えていたのは数字の意味ではなくて全探索に頼らない効率的な探索。少なくとも日付ごとに全探索する現状よりは、ピースを2つ加えて一度だけ全探索をする方が早いのでは?)


2021年05月26日 (水) アクセシブルじゃないクリックイベントを発見する」←これはキーボードで操作できない onclick ハンドラの話だけど、最近ラジオボタンに関するブラウザ(Firefox ESR 52.9)の微妙な反応の違いに気がついたよ。■「ラジオボタン スタイル」で検索すると <input> を隠して <label> で装飾する方法がいくつものサイトで紹介されてるけど、隠し方次第で問題が出る。出た。紹介されていたのはどれも <input type="radio"> を display: none で隠す方法。これだと自分が使っているブラウザではキーボードを使ってグループ化されたラジオボタンの間でフォーカスを移動させることができなかった。ラベル要素をクリックすることでしか切り替えできなかった。これも「アクセシブルじゃないクリックイベント」のひとつ。■ラベル要素はクリックに反応してラジオボタンにフォーカスを移すけど、それ自身がフォーカスを受け取ってキー入力を処理することはない。しかしでは当のラジオボタンは……。規格は知らないけど、非表示(display:none)のラジオボタンは無効(disabled)ではないからチェック状態の設定・参照が問題なくできるけど、フォーカスを受け取らないから操作に支障が出る、という理解でいいだろうか。結局 opacity: 0 で隠した。これならキーボードで操作できる。透明で見えないけど存在している ⦿ のために生じる微妙な空間は無視できる程度だったのでそのまま。■だけど今時は(7から顕著なのを知っているが)、Microsoft の Windows でもキーボードアクセスが蔑ろじゃない? 括弧で囲われたアクセラレータキーはどこ行った? その一方で「Windows 10 の起動時に自動的に実行するアプリを追加する (support.microsoft.com)」方法に shell:startup と入力させる手順があるの、ほんとバカだと思う。


2021年05月22日 (土) 怖くて見てなかったけどこの前の ARC (20210510)のパフォが 300 台だった! えー、つまり灰パフォ? これが初めてではないし、むしろ大体そうなんだけど、ARC の傷を癒すには ABC1回では足りないぜ。なんなら ABC の D 問題にだってたまに……ときどきやられる。■明日の ARC (20時から!)のお誘いメールが来ない……。A 問題から 400 点なのはたいへん厳しい。ARC の 400 点は五分五分だ。

最終更新: 2021-06-08T14:41+0900

[AtCoder] エイシングプログラミングコンテスト2021(AtCoder Beginner Contest 202)E 問題 Count Descendants

解けてしまった問題とまるで歯が立たなかった問題は、日記にならなくて困るという点で共通する。E 問題で Ruby の AC 提出をざっと見たら他の人の解法が異なっていたのでそれを。

ちなみに F 問題の提出(Ruby)はなかった。ゼロだった。まずね、凸包がよくない。それは自分の人生とは一切関わることのない専門用語(だということにしてこれまで無視してきたもの)なので。

話は E 問題。こちらはやること自体は明白で、読めばわかる。木が与えられて、深さを調べるのも、親を辿るのも、基本操作だ。この問題の問題は制約にあって、ノード数もクエリの数も、上限が20万だというところ。定数時間でクエリに答えたい。

 クエリ(U,D)に答える方法1

  1. ある深さ D にあるノードのうち祖先に U を持つものを選ぼうか。
  2. 実装したことはないけどダブリング(要は繰り返し二乗法でしょ?)で効率的に親を辿る?
  3. (ほぼ)全ノードがフラットに並んでたらダブリング関係なくクエリ(N)×ある深さのノード数(N)で死ぬ。

 クエリ(U,D)に答える方法2

  1. あるノード U の子孫ノードを深さごとに数えておこうか。
  2. 深さを調べる深さ優先探索のついでにそれはできるけど、子ノードが記録した配列をマージするのが大変。ほぼノードの数だけマージ操作が必要。マージテク
  3. 実装しなかったのでこれがアリなのかわからない。子ノードのうち底が深くないものから深い方へ、順番に足し合わせていくとどうなるか。

    一直線の木で Σk 個の要素を処理するような実装でなければアリなのか。

 提出 #22827097 (TLE×27 / AC×3)

これはマージしないでいいように1つの深さ記録配列を共有する実装。ただしノードごとに Array#dup した配列をスナップショットとして持っている。配列の要素数の合計がギガ単位になるけどどうかな、と期待して出したけど全然ダメだった。AtCoder の入力マジえげつない。上限は飾りじゃないのよ。

 提出 #22832306 (AC / 708 ms / 285,364 KB)

基本形はさっきのと同じ。クエリを先読みして必要なものだけ記録するようにした。TLE から 22 分経過していてコンテスト終了まで残り 10 分。あぶなかった。

 クエリ(U,D)に答える方法3

これは他の人の AC 提出を読んで知った方法。二分探索を使うらしい。オイラーツアー?

  1. 深さ優先探索で深さを調べると同時に、あるノードに降りてきたタイミングと上っていくタイミングを記録しておく。
  2. クエリがきたらノード U の両タイミングの間に処理をしたノード(=子孫ノード)のうち、ある深さ D にあるノードの数を答える。
  3. タイミング配列をなめて深さを確かめる線形時間の処理は許されない。どうする?
  4. (3つの提出を読んだのに思い出せない) どうする?
  5. タイミング配列を深さごとに分けておくのかな。
  6. クエリが指定する深さのタイミング配列を取り出して、そこからクエリが指定するノードの子孫にあたる範囲を二分探索で切り出すと、答えがわかる……かな? 実装して AC をもらってないので不確か。

確かなことはこのあたりの提出を読めばわかる。(提出の早い順)

メモリ消費にけっこう差があって、自分の提出は最も多い部類。正直どこが原因なのかわからない。


2021年05月18日 (火) 1より小さい正の整数は1より大きい - 西尾泰和のScrapbox」■間違えたし意味がわからなかったし、しまいには1と10の大小関係がわからなくなってきた>「3が1より小さいなら、3は10より大きい」。命題(P ⇒ Q の Q)があからさまに偽だからこの偽の命題を成り立たせる(P 以外の)隠れた条件は何か、という風に逆転した論理を自動的に考えてしまうのだと思う(生存戦略。ヒトは全知全能の神ではないが、無知の知ぐらいはある)。そうなるともう何もわからない……。■種明かしを読めば Ruby で空配列に対するクエリ [].all? が(どんなブロックを与えても与えなくても) true を返すのと同じだと理解できる。■これには疑問>「最後の「3が偶数なら、4は奇数である」が正解多数だから1の"P が偽ならば、Q の真偽にかかわらず「P ならば Q」が真である"は理解してる人が多い」。 偶奇って正負、陰陽、表裏、左右と同じでペアのそれぞれにアイデンティティがあるわけではないので、「3が奇数なら4は偶数だし、3が偶数なら4は奇数」というように納得して正解の選択肢を選ぶことができる。しかしこれはさっき書いた逆転した論理。自分のように偶奇の性質によってたまたま正解が選べただけの人がいるのでは?■■■@2021-06-23 今日読んでいた本『『詭弁論理学』(野崎 昭弘 (著) / 中公新書)』の 171、172 ページにちょうど書いてあった。「『もし Q ならば、Pである。』と『P でない。』とは、どちらも正しい(ことがありうる――Q でないことが結論される)ので、矛盾とはいわないのである。『もし Q ならば、P である。』と『もし Q ならば、P でない。』とも、Q が起こりえない状況においては、『Q でない』ことが確認されるだけで、矛盾ではない。


2021年05月10日 (月) [AtCoder] 昨日の ARC118。A 問題で Float を使ったら WA が出て、雑に .round(5) を呼び出したら AC になった。これが良くなかった。B 問題も同じ流れで Float を使って答えを出したら 5 WA。この WA が消せなかった(round の呼び出し方が間違ってたんだけど、それを直しても、引数を大きくしても、1 WA だったのを後日確認している)。今日になって解法はそのまま整数でやり直したら AC。A 問題の時点で良くない流れができていましたね。C 問題は Coprime (緑 diff) が解けるなら解けても良かったんじゃないかな。自分はまだ克服していない>「Coprime はまた解けなかった」「Coprime の単語が見えた瞬間にあきらめた。完全に苦手意識を持っている」■一応サンプル出力を素因数分解して考えはした。C 問題。素数(の累乗。0乗はダメだよ)の組み合わせで A の要素を作る。上限に注意する。A の各要素は組み合わせに使用する素数のどれかが必ず欠けている(setwise coprime)。A の要素それぞれについてそれを構成する素因数を見たとき、A 数列の全体を各素因数を含む複数のグループに分類できる(pairwise not coprime)。N の上限 2500 に対して A 数列の要素の上限 10000 が低く見えるのが難しいように思った。実際に作ってみて確かめようと思ったが、AC 目前の B 問題を先に片付けようとして、でも B 問題でつまずいたまま起き上がれなかったんだよなあ。


2021年05月09日 (日) 「あなたが20歳だとします。ある初対面の40歳の人Xがいて、その人が初対面の60歳の人に対して話す時とは明らかに異なる口調態度であなたに話しかけて来た場合、その人Xとの関係は今後どうなりますか?」 / Twitter」■ニュートラルでありたいけど目の前で使い分けられるともやもやするかも。年齢差関係なくタメ口の人に対する第一印象には「馴れ馴れしいな」「侮り?」「不作法?」「輩系?」という警戒心が混じる。あ、これニュートラルではない? タメ口を抵抗なく受け入れるための能力的、人柄的なハードルは高め(礼儀正しさという美徳をすでに捨てているわけなので)。超えられないなら困った人であり、敬遠するかも。立場、役職の違いはハードルを越える助けにならない。たぶん年齢差も助けにならない。年齢差にふさわしい何か(それが人柄や能力、ふるまいなど)があって初めて敬意が抱けるのであって、年齢差そのものがマイナスを押し上げるプラス要因になるわけではない。■ともあれ、相手によって対応が変わるのは当たり前のことであり(関係って相互的なものだ)、要はうまくやれているかどうかだと思う。■差別的な口調態度というのをタメ口に限定して書いてきたけど、高圧的態度、聞く耳を持たない態度だったならそれは論外です。死ね。


2021年05月07日 (金) [Git] 「これは神! GitHubが、クリックするだけで親リポジトリと同期できるようになったらしい!」■しかしですね、こういうひねくれ者もおります。「自分の GitHub リポジトリにコピーブランチはいらない。ローカルの作業リポジトリで git fetch --all して <remote>/master などと参照すればよい。」■「マンガでわかるGit 12話「本家リポジトリに追従する方法」 | リクナビNEXTジャーナル」にある「最後にプッシュして完了」の手順が必要ですか、っていう話。それをしないとできない操作は何ですか、っていう。■■■たぶん基本的な考えとして、ブランチ作成/プッシュ/プルを GitHub の自分が所有するフォークリポジトリに対してのみ行うというフローが想定されているのではないか。つまりローカルリポジトリは自分が所有するフォークリポジトリのクローンとして作成し、origin (フォーク。自分の GitHub リポジトリ)を起点に作業をする。にも関わらずこれまでは本家リポジトリに追随するという目的のために、ローカルリポジトリから本家リポジトリを参照する必要があった。今回の GitHub のアップデートによりローカルと本家の繋がりを断つことができ、origin を中心とした作業フローがより完全なものになるとか?■自分は git checkout -b myBranch 本家/mastergit push -u myGitHubRepo myBranchgit rebase 本家/master [myBranch] というフローで作業をするために、「自分のではないリモートリポジトリへのプッシュをできなくする」「新しく作成したブランチが自動的に設定する、分岐元との繋がりを断つ(--no-track を既定値にする)」という下準備をローカルリポジトリで行っていた。そもそも「(クローンしたなら)リモート名 origin を削除する。余計な自動化も自分が管理しない名前もない方がまし」という考えによってリモート名 origin が存在しなかった。■だって origin ってリポジトリ名なの? ブランチ名なの? 本家なの? フォークなの? そういう曖昧なものの上で作業をしたくない。ましてそれ(origin)が他人(git)のお膳立てなら、助けではなく余分な複雑さを持ち込むようにしか思えない。定型のタイプの繰り返しに倦んできた頃に提案してくれたなら考えないこともない……かな? それでもやっぱり自分は pull は使わないので(許容できるのは checkout や add までであって、自動で merge/rebase は乱暴だ)、origin もいらないんだよな(本家リポジトリにはその代わりにわかりやすい名前を付けます。「ブランチ名とひと目で区別できるように、リモート名は @ を付けたり大文字にしたりしようかな」)。■自分にとって3つのリポジトリの関係は「本家―ローカル―フォーク」として捉えられている。でもひょっとしたら「本家―フォーク―ローカル」の想定もあるのかもな、と考えてみた次第。でも自分で GitHub にフォークリポジトリを持たなくても「本家―ローカル(フォーク)」の2者間でもフォークは成り立つので、中心に GitHub 上のフォークリポジトリを置くのは、GitHub の中の人の立場としてならともかく、個人としては順序が違うと思う。メンタルモデルはひとつで十分だ。そのとき GitHub 上のフォークリポジトリは3番目に位置するオプショナルな存在となる(だから意識しなければこれを忘れる>「フォークする。プルリクエストを出すためには GitHub 上でフォークしたという事実が大事」 新規作成した空のリポジトリにプッシュしても PR は出せないのである)。■しかし GitHub のアップデートによって今後は、GitHub と origin を必須の前提として作業フローからリモートの区別・存在感を消すのがある種最適な選択になるのかもね。本家とフォークの2つのリモート名を使い分ける必要がなくなるのなら、単純化がなされるのなら、割り切りによる制約がむしろメリットと感じられる人もいるだろう。さもなければ無駄に複雑化して面倒なことをしているなと自分は思います。


2021年05月05日 (水) うんこの生産効率が高すぎる。毎日3回まで!


2021年05月04日 (火) 「洗たくマグちゃん」効果に裏付けなし 消費者庁が措置命令 シリーズ累計500万個売れた人気商品 - ITmedia NEWS」■何日か前に家で見た。どうして王道を避けてあえてスピリチュアルでロハスな選択をしてしまうのか、不思議に思っていたところ、間を空けずに ITmedia で二度目のご対面となった。■で、スラド。「消費者庁、洗剤を使わずに洗濯しても十分に洗浄できると表示していた「洗たくマグちゃん」に措置命令 | スラド サイエンス」■消費者庁が言っているのは、実際に洗濯してみるなど、効果をうたうのに十分な合理的根拠がないことを問題にしている。販売元は一応の資料を提出したらしいが、たぶんマグネシウムに関する間接的な試験結果だったりしたのだろう。はっきりさせたいのは、消費者庁は効果がないことを証明したわけではないということ(消費者庁に効果がないこと(翻って効果があること)の証明を押しつけられるならお得だ。もちろんそうはいかない)。スラドのコメントを読むときはそこのところをはき違えた、たとえば「使ってみた」系の記事に対する揶揄などが、印象に基づく根拠のない中傷だということに注意しよう。消費者庁に駄目出しされてもしかたのない見事なブーメランコメントだ。コメント主の家にも洗たくマグちゃんが転がっているから恨み千倍なのではないか。そういうタイプの人間だよ(書きすぎ)。噂にふりまわされたり思い込みで馬鹿なことを言ったりしてないで、使ってみた系の記事を見習って自分でも効果のあるなしを確かめてみたらいい。それが迷信から足を洗って科学を始める第一歩ですよ。まだ遅くないからがんばりましょう。■関連。20151214■■■@2021-05-31 より詳細に。テストのしかたにも言及がある。「「実質的にはただの水洗い」洗たくマグちゃんは無意味だと言える"科学的な理由" 「アルカリで洗う」はウソだった | PRESIDENT Online(プレジデントオンライン)」 予想された内容。だけど結果論で正当化はできないよ。


2021年04月29日 (木) 【速報】飯塚幸三被告「アクセルを踏んでいないのにエンジンが高回転しパニック状態になった」 : 暇人\(^o^)/速報 - ライブドアブログ」■これに対する「反省してない」「嘘つき」という反応が本当に嫌い。実際のところは当人しか知らないけど、この人の主観においてアクセルを踏んでいないというのは普通にありうる。自分だってゆっくりバックしてるときに踏んでるペダルがアクセルかブレーキか、混同することがある(そして一瞬踏んだ後で認識を改める。その前にパニクって暴走して事故を起こしたらどうなるか)。主観的事実に基づかない供述をして潔く罪を認める姿勢を示すことこそが嘘であり、己の信念に反する行為だとして受け入れがたい、というのが自分という人間。たとえ弁護士に罪を認めた方が心証が良くなって刑が軽くなる可能性がありますよと助言されたとしても、従うかどうかはわからない。そのことと、起こった事故に関して車のドライバーとして所有者として被害者遺族に対する責任を果たすこと、判決を受け入れて罪を償うことは矛盾しない。この人がそうだと言っているわけではないが。■「反省してない」「嘘つき」という反応は、これが特殊な反応ではないと思うからこそ看過できなかった。反省するとは嘘をついて、真実を飲み込んですべてを己で引き受けることなのか。「そうだ」という反応はありそう。「それが大人だ」という雰囲気を感じなくもない。自分とは異なる人間。それって場の和を守るためのスケープゴートを求める姿勢と何が違うの? 演出された予定調和なんてくそくらえ。被告の主張とは無関係に証拠を固めて罪を問えばいい。自分が被告の立場でもそう思ってる。