/ 最近 .rdf 追記 設定 本棚

脳log[2020-05-05~]



2020年05月05日 (火) もう何年にもわたって屋内では極力かかとを着けないように心がけている。屋内に限ったのは靴をはいてある程度以上の歩幅で自然に歩くことと両立できないからだが、屋外であっても、自転車のペダルとバイク(※アメリカンではない)のステップは土踏まずではなく拇指球でもって踏んづけるものであるから、そのときは同じような足の形になっている。それは大げさな身振りを伴わない抜き足差し足であり、かかとからドッスンドッスン着地しながら歩くことへのカウンターであり、ねこの足つきである。■日常にすぐにでも取り入れられるエクササイズのようなものとしていいことづくめだと思ってるんだけど、どうだろう。膝とかふくらはぎとか体幹とか。唯一の欠点は靴下の同じ部分がいつも一番に破れることか。■たしか Vibram FiveFingers が話題になったり、町中でジョギングする人が目立ってきた頃からだったと思う。結局あれはコストパフォーマンスが悪そうで買わなかったんだけど(唯一無二ではあるが高いよね? 耐久性高くないらしいじゃない?)。■屋内での歩き方を3通りに表現したが、もうひとつ思い付いた。滑る雪の上を歩くとき、ローラースケートをはいてるとき、スケートのとき、スキーのときの体重の乗せ方と共通点があるかも。雪の上では前に放り出してかかとから着地した脚をつっかい棒にするような歩き方ではこける。足が滑って前に逃げても着いて行けるような体重の乗せ方が必要になる。で、そういうのは膝を曲げて腰を落としたような歩き方になるから、「靴をはいてある程度以上の歩幅で自然に歩くことと両立できない」。


2020年05月04日 (月) 風俗嬢とカツオの刺し身の違いを論理的に説明して」■スーパーのカツオの記事は参考になるなと読んでいた。岡村風俗発言は下種いなと思っていた。共通項には考え及ばなかった。違うと思いたいし違いがあると思ったけど、決定的な違いを俺も教えてほしい。■商品の違いと、どこまで遡って言及しているかと、積極性の違いが人によって境目になるみたい。俺にも境目がある。「いつもと同じ値段でおいしい。ラッキー」「買うのは風俗落ちした素人ではなくカツオ」「買わないことが助けにはならない」というところで自分を許している。■風俗落ちというところに想像を超えたボーダーが俺にはある。すごく不幸なことに見える。これは俺の偏見。「~落ち」という表現にもそれが込められている。自分で想像できない背景を読み込んだ「コロナの影響でスーパーで買うカツオの刺身が美味すぎる。」という記事に感心して参考にしたのと同じように、岡村発言に一瞬「あ、そういうことがあるのか」と得心したのも事実。秘めておくべき深夜の男集団のノリだけども。


2020年05月02日 (土)

最終更新: 2020-05-29T19:43+0900

[AtCoder] AtCoder Beginner Contest 165D 問題 Floor Function

数弱さんには厳しい回だった。E 問題は読む時間さえなかったので今日の日記は D 問題。次の整数式を考察するだけ。

x*A/B - x/B*A

A を掛けてから B で整数除算するか、B で整数除算してから A を掛けるかという違いで生じる値の差について。その最大。

 1. x が大きいほど大きいんじゃないの?>提出 #12618779

違います。B を周期として第一項と第二項が一致します。A がその周期に与える影響はよくわかりません。

ちなみに B の上限は 10^{12} のため周期全体をテストすることはできません。>提出 #12633357

 2. x が B の倍数マイナス1のとき第二項の整数除算で切り捨てられる値が最大になるんじゃないの?

  • →引き算される第二項が相対的に小さくなる
  • →全体として大きくなる

たぶんその通り。だけど説明を端折った N との関係がわかんなかったのと、A と B の因数によって第一項と第二項で周期 B の位相がずれていくんじゃないかという気がしたので探索した。>提出 #12640433。でも錯覚。位相がずれるなら「B を周期として第一項と第二項が一致します」が嘘じゃんねえ。

Ruby で提出している他の人は、提出の早さも実行速度も優秀だった。>すべての提出 - AtCoder Beginner Contest 165

 B 問題 1%

実は B 問題で15分近く詰まっていた。瞬殺できないとあせる。最初は(もはやうろ覚えの) log を使って計算していた。

X = gets.to_i
p ((Math.log(X) - Math.log(100)) / (Math.log(101) - Math.log(100))).ceil

でも大まかにしか数字が一致しない。同じかちょっと小さい数字になる。俺が log を忘れているか浮動小数点数の誤差か(近い数字の引き算とか良くないのでは?)これの影響じゃないかと>「(複利、小数点以下切り捨て)」。複利の計算をするごとに切り捨てなければいけないのでは?

B 問題なので手続き的に解いても TLE にならないのはわかっていた>提出 #12601266

 C 問題 Many Requirements

実は C 問題でも30分近く詰まっていた。A 数列の総当たりでいこうと決めるまでに制約条件を総当たりしようとしていて、他の制約にまったく制約されない孤立した制約条件の扱いをうだうだ考えていた。

再帰をループにするとかの効率を考えずにちゃっちゃと書いただけなので、提出へのリンクはなし。

上手い人のゲームプレイ動画と AtCoder の解説 PDF のあいだの共通点。多様性のなさ。へたくその動画の方がバラエティに富んでいて見ていて面白くさえある。間違え方というのは本当に千差万別で、ありとあらゆる機会を逃さずに、そう来るかと予想もできない脱線をする。たったひとつのゴールに向かう限られたルートに収斂していくということがない。

当人にとっては面白くもなんともないので、B 問題、C 問題に詰まらないような世界線に乗っていきたい。

 あ、この問題ってそういう見かたができるのか。>小数部を分離

chokudai(高橋 直大)🌸🍆 Verified Account @chokudai

とはいえ、高度な問題を解く時に、「floorが出てきたら整数部と小数部に分離して式変形!」って結構大切な考え方なので、Dみたいなのを出さないと、後半問題で突然そういう数学力が応用状態で問われることになるので、そのあたりの塩梅がむずかしいよね。

x が固定小数点数で小数部が5桁なら、x - x/100000*100000 が小数部分になる。……という話ではない? D 問題を解くときの話?

以前にもはっとさせられたことがあった。

kを使った場合のコストは、k-1以下のすべてを使ったコストより高い

これって要は 100000 > 11111 (2進数) と同じことなんだけど、自分のような人間は「この一連の操作のコストは(書き換えた要素の数によらず)2^k である」という問題文を読んだだけではたどり着けなくて、上のように事実として示されて2進数で考えてみて初めて了解できることだったりする。

一を聞いて十を知る(20200508)」ってこういうことだと思う。賢い人は「いやそれって同じことだから一の内に入るのでは?」と思うかもしれないけど、全然違うのである。

そして自分が AGC022C 700点問題 にまるで歯が立たない理由には、列挙された要素の数とそれらを煮詰める段階の深さに関係があると思ってる。「理解が及ぶ広さ、深さ、早さに優れ(20200508)」という風に書いたけども、そうでない自分は頭の中で抱えきれないし、整理して外に出して部分ごとに解決することもできない。

アストロノーカやテラリアですでに知ってるんだけど、ツリー状にねずみ算式に倍々に増えていく要求リソースの全体を把握すること、並列に進行する精製過程をストールさせないように需給を絶えず調整すること、このサプライチェーンの階層がある程度以上になると(たぶん3くらい)完全にお手上げになってしまう。そういう能力がない。

たぶん3くらい」 深さが3、二分木なら葉の数8までしか脳内で扱えないんです。

 「アルゴリズム格言」

ちょっと検索したら「銀の格言」としてこんなのが列挙されてる。

  • 攻めは銀、受けは金
  • 銀は千鳥に使え
  • 桂頭の銀定跡なり
  • 銀は成らずに好手あり

つまりはこういうことなんでしょう?

chokudai(高橋 直大)🌸🍆 Verified Account @chokudai

「この問題だったらこうするだろ」って感じに無意識にやってることってめちゃめちゃ多くて、その「無意識」を言語化して列挙するだけでもめちゃめちゃ有効だと思うのよねえ。

chokudai(高橋 直大)🌸🍆 Verified Account @chokudai

「chokudaiのアルゴリズム格言1000」とか作って、こういうのをひたすら列挙しまくると、格言の組み合わせだけで良い感じに解ける問題がたくさんできそうだな、と思っていて、アルゴリズム名とは別レイヤーで浸透させたいな、ってちょっと思ってる。

解説なんかだと、正しいルート以外はすっ飛ばされちゃう」というのがまさしく今日書いたことで(20200502p01.04)、解説PDFよりも「競技プログラミングの強みと「典型力」について - chokudaiのブログ」という思考の跡が見えるブログ記事の方が自分には有用となる理由。アルゴリズム格言に期待する理由。


2020年04月28日 (火) AtCoder から精進する者に報いようとする意思を感じる。解説 PDF でさっさと復習するか。■以前一度だけ読んでみたことがあって、「こうやったら解けるんですよ、簡単ですね」とは書いてなかったけど、「何でそうやってみようと思うのか」とか「そうやったものが答えになるのがわからん」みたいな感想を持った。■まあ、そういうのは慣れてから理解が追いついてくるのを待ってもよいのではないか、というのが今の心境。先を見れば問題文が頭に入ってこないレベルの問題がまだまだ控えている。解説読んだってわからんぜ、ていうか読めないだろうな。

最終更新: 2020-06-15T20:02+0900

[AtCoder] AtCoder Beginner Contest 164E 問題 Two Currencies

日付のあたりに書いた通り解説PDFを読んで実装した。だけどあれ全然答えじゃないね。Chokudai さんのブログで以前読んだような、ちょっとひねってあるのをいかにして典型問題に落とし込むかというタイプの問題だったらしい。ある意味そこまで含めて典型では。でも一度も実装したことのないパターンだから「(現在の頂点, 所持している銀貨の枚数) を状態としてdijkstra 法を適用すると、(略) 解くことができます。」とだけ書かれても、~を状態とするってどういうことですか?

 提出 #12489199 (TLE / 2206 ms / 19760 KB)

Wikipedia の「ダイクストラ法」を読みながら雰囲気でPDFに書いてあった方針で実装しようとした。一応答えは出たがサンプル入力ですら一瞬の間を感じさせる激遅スクリプト。

N 個の頂点と銀貨の枚数を組み合わせて状態にするといっても、訪れなければいけない地点は依然として N 個のままなわけで、そのあたりの状態を集約する手つきが具体化できなかった。最終的に提出したスクリプトで「すべての地点を一度でも訪れた時点で完了」としたところとか、「銭なしの再訪に用なし」とコメントしたあたりがそうだと思うんだけど。

苦しんで何度か書き直すうちに原型を失いつつもすっきり書けて、プロファイルをとりながらの実行もすっきりだったから「どうだ!」と提出したら、AC の中1つだけが TLE で脱力。これ以上は無理ですよ。

この段階で他の人の提出を見た>「すべての提出 - AtCoder Beginner Contest 164」。

Ruby での全提出は1ページに収まるほどで、AC していたのは2人だけ。TLE 仲間の提出を覗いてみれば、自分が TLE になった入力(とサンプル)だけ AC していたりして、line_2.txt が何と癖の強い入力であることか。

 提出 #12498094 (AC / 205 ms / 14528 KB)

ダイクストラ法に立ち返らないといけないかと思っていたが、diff をとらないと判らないレベルのチューニングでなんとかなった。不思議。

要修正その1
M.times.map の .map がいらない。
.each の短縮形として .map と書くことがあるみたいだけど、.times (ブロックを受け取る)があるのでここではただの無駄。定数 E で map を受けていたときのなごり。
要修正その2
PQ#deq の変数名 max は min の誤り。
プライオリティキューが必要になるたびにこのとき(20190916p01)の max-heap を使った実装を書き換えて使ってるせい。必要になるのはほぼ min-heap。符号を反転させてそのまま使うのと手間はどっこいどっこい。

 ところで、Python (3.8.2) で今一番速いのがこれ>提出 #12430772 (140 ms)

すっごく読みやすいんだよなあ。何をやっているのか手に取るようにわかる(笑)。配列総なめが嫌だからって冗長なカウンター変数を用意するところまで。

自分に欠けていた工夫が2つあって、

  1. ある頂点から出る辺を予めソートしておいて、除外条件に一度引っ掛かれば以降の辺をまとめて無視してる。
  2. 効果のないちまちました両替をひとまとめにしてる。(ソートした辺がここでも役に立っている)

特に2番目は効果が大きいんじゃないかなあ。キューへの出し入れがボトルネックだから、エンキューをひとつ節約するごとにそこから波及する複数のエンキューが節約されるのは大きい。

それはそれとして、Python は AC だけに限っても5ページの提出があるのがうらやましい。傾向として判で押したように似たような提出が多くはあるが。理由のひとつはヒープ(データ構造)とかダイクストラ法とか、名前のついたアルゴリズムが簡単に利用できるところにある。

 Ruby (2.7.1) のこの提出>提出 #12467639

読めない記述がある。この行

  (v = V[n]&.&SM) ? (next if v>=s || v>2500) : R << [n,t]

演算子(に見えるがメソッド)をドット記法で呼び出せる(それが結合規則を変えるのでゴルフに使える)というのは読んだことがあって、たとえば 1&31.&(3) は同じ意味になる。でも &.& をどう解釈すればよいか。SM はただの数値変数だからブロック引数化の & ではないと思う。

他にもアロー記法だとか、暗黙のブロック変数(_1, _2 とか)だとか、Ruby 2.7 を読むには知識が足りない。ローカルにインストールしている Ruby 2.5 ではまだ使えない記法だったりする。まだ gem コマンドを一度も使ったことがないから、デフォルト添付ライブラリ(prime とか)の gem 化は歓迎できない

ブロック変数には悩ましいところがあって、.map(&f) とか .map(&:to_i) とか書けるときには積極的に書いていきたいんだけど、.to_i ではなく .to_i(2) を適用したくなると途端に .map{|_|_.to_i(2)} と書かなければいけなくなる。.to_i に 2 (と self)を予め束縛した関数がサッと(記述コストと実行コストなしに)利用できるといいんだけど、なかなかそうもいかないらしく、とりあえず .map{_1.to_i(2)} と書けますよ、ということ。たぶん。まだ試したことない。

 メソッド呼び出しで `.' の代わりに `&.' を使うことができます。この形式でメソッドを呼びだそうとすると、レシーバが nil の場合は以下のように働きます。

  • 引数の評価が行なわれない
  • メソッド呼び出しが行われない
  • nil を返す

&.& が何だったかと言えば、nil テストを含んだ & 演算だったと。Swift とか C# にあるやつじゃない? どっちも使わんしよう知らんけど。

 提出 #12550661 (AC / 154 ms / 14520 KB)

51 ms 縮まったけど本質的な改善ではないと思う(配列4とか比較が雑で適応が限られるし、ない方がいいかも)。シンプルさも失われていいことない。しかも Python (140 ms) に負けてる! Ruby のバージョンが 2.3 から 2.7 になって、実行前のオーバーヘッドが 40 ms ほど大きくなったと思うんだよなあ(それでも勝ちたい。ユーザー数で負けても質で勝ちたい)。

 参考にされた!>提出 #12916854 (146 ms)

嬉しい! 自分で解釈して手を動かして理解してる! 立派! 自分で好き勝手書くより他人の考えをトレースする方が難しいものよ。

タイムが縮んでるのはホットスポットである PQ#up_heap (PriorityQueue#update_heap_to_up) で配列アクセスを減らしてるからなんだろうか。キューが長くなるほど効果があると思う。

あと自分は意味まとまりのある変数群を一行で定義するために多重代入を多用するんだけど、実は字数が減るわけではないし、多重代入式に対応する配列値が作り捨てられているとしたら、もったいないことをしてる。

地味に変数の定義位置をずらして無駄な計算を減らしたりもしてる。自分は変数の定義をひとつにしたいがために効果のない値([0,0] とか)を使用して効果のない加算を実行してたりするんだけど、贅沢ではある。関連>20181029

 改善点みっけ

(自分の提出だよ)

	z, y = 2[v]+a, 3[v]+a # z < y
	if z < s
		c, d = s < y ? X[v][s-a,3[v]] : [0,0]

X[v] が返す関数が受け取る引数2つ(s-a3[v])はその差だけに意味があるから、両方に a を足して、X[v][s,y] とすると引き算1つと配列アクセス1つが省略できる。そもそもが引数が2つある冗長性から生じた無駄であるな。

こういう楽しみがあるのはスクリプトならではなんだよなあ。C++ コンパイラにかかると本質的でない差異は全部同じにされてしまう。そこに性能を犠牲にせずに読みやすい表記を追求する余地があるとも見られるんだけど。

 即セルフツッコミ「C++ コンパイラにかかると本質的でない差異は全部同じにされてしまう。」

もう一度asmコードをよく読むと不要なはずの配列の初期化が走ってる模様. デフォルトcstrは空のはずなんだけどと自分のコードを見直すと、FpDblクラスだけ配列の初期化が入っていた.

うっかりいれちゃっていた模様. 削除するとgcc-7.5で13%高速化. おおこいつのせいだったのか. それでもclang-8より4%ほど遅いけど気がすっきりした. でも配列の初期化で1割変わるというのは(clangは速いだけに)何か変なことしてるのかな.

プログラマに指示されたらコンパイラは無視できない(こともある? clang の場合をどう解釈する?)。結果に影響しない表面上はささいに見える違いが思わぬペナルティを生むことも。

 実装比較。この件>>20200428p01.07

  • 提出 #13001464 (1349 ms) 自分のプライオリティキュー実装を利用した richvote さんの提出。
  • 提出 #13001205 (1273 ms) 自分のプライオリティキュー実装を基にした? yappy0625 さんの実装を利用した richvote さんの提出。

プライオリティキューの実装が違うだけで、メインループは共通して richvote さんのオリジナル。

richvote さんの提出は、自分が最初唯一の TLE を食らった line_2.txt という入力が際立って他のケースより速いため、明らかに異なる部分に着目して探索の優先順位を決めている。

それはさておいて、俺の目には2つのプライオリティキュー実装に違いがあるとは見えないんだけど、俺の書き方の方が遅いという傾向が間違いなくあるようだ。

loop{} と書くより while 0; end と書く方が速いというように、気をつけておくと得する書き方がまだあるみたい。だけどわからん。

 多重代入と代入
require 'benchmark'

N = 10_000_000
Benchmark.bm{|x|
	x.report('多重'){ N.times{ a,b,c = 1,2,3 } }
	x.report('代入'){ N.times{ a=1;b=2;c=3 } }
}

これを Ruby 2.5 で実行してみた。

> ruby25 a.rb
       user     system      total        real
多重  1.591000   0.000000   1.591000 (  1.585992)
代入  0.967000   0.000000   0.967000 (  0.969697)

多重代入遅いなあ。(bm メソッドを bmbm に変更してリハーサルを行っても同じ結果)

あと最近驚いて、確かめてみたら Ruby 1.8 の昔から一貫して同じ挙動だったんだけど、多重代入の評価順って、単純に右辺から左辺とか、カンマで区切られた左から右ではないみたい。次のスクリプトの実行結果に驚いた。

i, a = 0, [0,1,2] # 準備
i, a[i] = 2, i # どうなる?
puts "i=#{i}; a=#{a.inspect}" #=> i=2; a=[0, 1, 0]

最初に右辺を評価して、それから左辺の評価と代入を左から順番に実行していく感じかな? 右辺の一時記憶が必要?

多重代入は遅くて時々評価順が難しい、というのが現在の評価。

 2.6 でデフォルト gem 化というのを読んだんだけど、普通に require 'prime' できる。gem 化されなかったのか、gem 化について勘違いしているのか。


2020年04月26日 (日) 面倒になった。もういいや。何も考えていないわけではなく何かを見ているようではある。俺は「おれたち(のコード)」なんて言われたら身震いするほどの嫌悪を感じるし、即座に「弱者の群れ」「ムラ社会化」「政治化」みたいなワードから負の面を想像するけど、そうやって覆うことで俺が見ることのできないところに何かを見ているようではある。■俺の視点。論理的な対話ができない、間違え続ける矛盾が「おれたち」を主張する「チーム」は雑談グループ以上のものにはなれないと見ている。判断を誤るし、有効な手を打てないだろう。有害無害を問わない何かではない、有効な手を。合意形成のプロセスも、知恵を集めるような議論も機能しないのだから、それなのに「おれたち」を語る者が他人に干渉し、また独善で物事を進めるのだから、船が山を登るようなことになるだろう。いや、山を登ってしまえるのはある意味個々が遺憾なく力を発揮した結果だからかつての姿かもしれない。まあいい。そういう、俺が呼吸できない混沌とした場でも労を惜しまない者、能力を発揮する者が内外にいるみたいだから、2割くらいの確率で命脈を保つ目があるかもしれない。知らんけど。俺は信じてないけど。■引っ込みがつかないように書いておく。もう口出ししない。自分が面倒くさい人間であることは嫌気が差すくらい知ってる。日記にも個人的なこと以外は書かない。つまり、不当な中傷が目に入ったら反論せずにはいられないから。でもそれだけ。GitHub のウォッチも解除した。俺は他の暇つぶしと自分だけのおもちゃを見つけた方がいい。■■■


2020年04月20日 (月) 3方向の流れが順に青信号になる交差点でのこと。自分が属していた流れは感知式になっており、感知したことを示すインジケータは「調整中」として隠されていた。■先日起こったこと。自分が信号待ちをする間もなく先頭の車が交差点に進入し、あとの2台がそれに続いた。信号は赤だ。俺はどうする? よくよく注意して信号無視をした。■2通りのシナリオを考えた。自分より前から待っていた車は青信号になる順番を飛ばされる経験をしており、感知式信号が機能していないことを知っていたかもしれない(といっても待機場所の問題だった可能性が高い)。あるいは、たまたま現在青信号の順番に当たっている流れに車がおらず、また「調整中」という信号の不調を匂わせるワードが見えていたために、先頭の車が青信号になるのを待てずに独断専行したのかもしれない。■流れを堰き止める勇気!(流れを読まないより難易度高い!)


2020年04月18日 (土) Git をアップデートしたら .ssh/config に指定した IdentityFile が invalid format だとかで蹴られた。-----BEGIN RSA PRIVATE KEY----- 直後の空行と -----END RSA PRIVATE KEY----- 直前の空行を詰めたら受け付けた。なんで空行があったのか、それで大丈夫だったのかは知らない。■「Gitに危険な脆弱性が見つかった - orangeitems’s diary」■git update-git-for-windows というサブコマンドはなかった(アップデート後にはあった)。


2020年04月13日 (月) 最近心が浮き立つような買い物をしてないなと思ったので、何か必要な物を、今使えている物を用済みのゴミにしてしまわない物を、と考えて、少し前に物色するだけして決めきれなかった長財布を今度は決めた。「PARLEYクラシック 長財布プレミアム」 今使ってるのは遅くとも1998年には使っていたものであるし(20140609)、そろそろお札に折り癖がつくのが残念に思えてくるお年頃なのである。色は以前にはなかった3色目、スリップダメージを食らいそうな色、プレデターの血の色。■「桜花鏡面仕上」という中二心をくすぐるスペックの包丁も頭を過ぎったが収納場所がなかった。■その人にとって本当に価値ある物は、ここでは物に限るけども、必要な物でも実用的な物でもないにもかかわらず手元に置いておきたい物だと思う。お人形さんとかね>DSC00652.JPG。髪を梳かす行為には強力な精神安定作用がある。慈しみの心が生まれてくるよ。グルーミングか。■■■36時間後にはもう手にしていた。とても良い。そして良い物だ。■2つ折りだった前の財布と体積的にはほぼ変わらないかややかさばるくらいなのは誤算。柔いのは嫌だったので、形状的、素材的にしかたのないことではある。くたびれてきた頃に期待。■表面にブランドの主張がないのがまた良いところなのだが、裏表を間違えて開かないように何かワンポイント自分の印を付けたい。■中仕切りなどの親指をひっかける部分を補強しつつこういう機能(「金属バネのスイッチがオンオフを切り替えるように節度が生じて、仕切りの奥が開くか手前が開くかがパタパタと切り替わる」←物色してたのは2年ちょっと前だったか)を持たせられないか検討中。くたっとしない芯を持たせたうえで圧縮力を加える方法を。


2020年04月07日 (火) 最近のことではないけど、風邪をひかない秘訣を聞かれたことがある。答えたのは「人に会わないこと」。一般的に無理なのはわかっている。ひきこもりでなければ社会生活も家庭生活もある。■部屋に空気清浄機と窓に付ける換気扇とアヒルの容器のウェットティッシュと70数%のアルコールスプレーがある。あとアルコールがもったいない場面のためのファブリーズW除菌。これも最近に始まった話ではない。アルコールの予備はあるがアヒルちゃんがなくなりそうでドラッグストアに行ったが、詰め替え商品も何もなかった。時期が悪い。■何が言いたいか。不要不急の外出など元から存在しなかった。たとえ必要があっても出歩きたくない。人に会う用事など考えただけで気鬱になる。実に健康的!■ここで強引にこの前の仮定法の話につなげよう>20200401。「考えだけで気鬱になる」と「考えだけで気鬱になる」のあいだに違いがあるか、あるならどのように違うか、という話だ。俺はあると思っていて、「る」の方からは具体的な用事が目前に迫っている様子が感じられる。実際に気鬱になるようなことを考えているのだ。たぶんね。


2020年04月05日 (日) AtCoder で提出できる Ruby スクリプトのバージョンが 2.3.3 から 2.7.1 に上がるらしい。Array#sum が使えるぞー(それしか知らない)。あと(たぶん 1.9 から?)遅くなっていた文字列操作が速くなったのは 2.3.3 より後なのかな、前なのかな。忘れたけどびっくりするほど遅い、特性の違うバージョンがあったのは知ってる。どんなに簡単なスクリプトでも実行時間に 46 ms のオーバーヘッドがあるようで、これは実に面白くない。これまでは 7 ms だった。


2020年04月03日 (金) PS4 でスタンバイ状態からゲームを再開する。画面上部に帯が出てゲームが開始できない。お前はゲーム機以外の何なんだ? 電源を入れた最初のフォーカスアイテムもそう。ディスクでなく、最後にプレイしていたゲームでなく、What's New みたいな押し付けがフォーカスを奪う。それに興味がないとは言わん。でも一番ではないし、俺の選択ではない。■ログアウト状態でトロフィーが確認できるようになったのは大した進歩だけど、(もちろん皮肉。トロフィー獲得はオフラインを想定して一番に端末に記録されるはずなのに、当初はそれが確認できなかった)、毎度毎度ログオンを促す画面をキャンセルしてからでないと確認できないの、本当にうざったい。そういうのは公平なオプションではない。ログオンの強要には断固抵抗する。


2020年04月02日 (木) Logicool / Logitech のサポートとブランドの死の話 - たのしい人生」■自分は MX610 (2005年12月購入) だとか TM-150 (2009年1月購入) だとか、スイッチの分解清掃をしながら未だに使い続けているが、Logicool は保証期間がかなり良心的で、MX610 なんかは5年保証だったんだけど、そのわりに1、2年でチャタリングが起こりだすという話をよく聞く。そこでサポートに連絡をするとすぐに代品が送られてくるというのもよく聞いた話。MX610 の後継同等品はボタンの数が減っていて嫌だというのは別の話。そういうおおらかなやり方では立ちゆかなくなってきたということなのでは? ブックオフで通販したゲームソフトが読み取り不良だったときもかつてのロジクールと同じように代品の発送だけで片がついた。ついたんだけど、まんまと同じ商品を2点せしめる意図がなかったことを証明するために、半分にした円盤を撮影してメールで送った、自主的に。ロジクールの要求は筋が通ってると思う。でもステアリングコントローラーを破壊するような大事(おおごと)をはっきりと要求されてしまうと、うっせー、めんどくせー、着払いで送ったるからそっちで始末せーや、と思わんではない。かつてのやり方は善意に基づいていて双方に合理性があるものだった。今は不信に基づいていてユーザーが自身の主張を証明する手間を押し付けられている。今でもユーザー側のメリットをロジクールが挙げることはできるだろう(「製品をお送りする必要もなく交換手続きを行えます」)。でもそれはユーザーが求めたものではないし、引き換えに面倒を押し付けられるくらいなら、やっぱり着払いで送らせろってなもんだ。■とはいえ、MX610 も TM-150 もサポートに全くお世話にならずに今に至っているわけで、TM-150 の質が変わらないまま販売が続いていくならそれで良い。GT FORCE Pro も新しくしたい。■「Logicoolブランド、無料保証の交換手続きの際に「故障品を破壊する動画」が必要に | スラド ハードウェア


2020年04月01日 (水) 英語圏での留学では仮定法には気をつけましょう。I would do it. と上司/教官が言ったら、やるのはあなたです。自分は留学直後に I would order the test. と指導医に言われ、上司自身がオーダーを入力するものと勘違いして痛い目にあったことがあります。」■こうやってはっきり教えてもらわないと確信が持てない表現だなあ。■過去形にして時制をずらすことで現実からの距離が表現されるのだという。日本語でも「~だったらなあ」のように言う。これは現実味のない仮定。それとは別に距離をとった婉曲表現が敬語や丁寧な呼びかけとして働く。ここではどれか。■would であることで暗に(それともはっきりと?)話者である私はやらないと言っている。will(意志)ではないし、あり得べき未来ではない。では誰が? わかるでしょう? という風に連想するんだけど、はっきり自分だとはわからんなあ、こうやって教えられなければ。■■■マーク・ピーターセンさんの『日本人が誤解する英語』の第4章がまるまる仮定法の話題。トピックのひとつが「will と would の埋められない溝」なのだからそのものズバリ。日常的に不可欠な表現なんだとさ。それほどよく使われるし、はっきりと区別されている。■この本を読んでおきながらはっきりとはわからんなあなんて言ってるんだからぼんくらもいいところ。