一般に、サンプルの平均値は分布の平均値に確率収束するという法則が知られています (確率収束というのは、収束しない確率が0に収束する、という意味です)。 これは大数の法則という極限定理として定式化されています。 だから、いつだって平均値は計算できるし、その結果には意味がある、 そんな風に考えていた頃が俺にもありました… それどころか、平均値の従う分布まで判っているぜ、そんな風に(以下同文
これは同じ分布であってもいわゆる平均値がどれくらい違うか、という実験です(計算の対象となったサンプル数は1000)。
縦軸を対数表記にしないとグラフが視覚表現として意味を持たない、というぐらい、どんだけ違うねん、というぐらい違います。 なんとなく有限の値にそのうち落ち着きそうな気もするけど、 ひょっとして、足してサンプル数で割っても、 意味のある結果になってないのでは？という疑惑も生じます。 大数の法則どこ行った！責任者出せ！てなもんです。 そこで別のほうから攻めてみましょう。
最低値 \(x_0\) のときの確率密度関数 \(c (\frac{x}{x_0})^{-a} \)とすると この分布の期待値は次の通りです $$ \frac{c}{a-2} $$ じつはこの分布の巾は -2 だったんすわ。 a=2 の場合は無限大に発散しとるやんけ！それを先に言わんかい！責任者(以下同文
そないじきにキレんと、ちょう待ちや。 サンプルは常に有限の値をとり、その個数も有限なのでいつでも全部足して個数で割る事はできますから、 常にその演算は実行可能です。 しかしこの例の場合、その結果は意図した値、欲しい結果とはかけ離れたものです。
少し一般化して考えてみましょう。 コードの中に平均値を計算している部分があります。 入って来るデータの分布によっては、 コードは期待されたように動きません。 この不具合はバグというよりもアルゴリズムの誤りです。 ですが、まさか全部足してその数で割るという、小学校で習う操作自体が間違っているとは思わないわけで、 この種の誤りに気づくのは難しいわけです。 ここでのぞましいプログラムの動作は無限大を返すべきか例外になるべきか、 用途によって違って来ると思いますが、 これが相応しい動作でないことは間違いないでしょう。 でもそれを実現するとなると、今の処理系ではけっこう大変ですよね。
統計的に動作するアルゴリズムが一般的になるにしたがって、 こういった不具合が増えるかもしれません。 あるいは、分布を推測しつつ動作して、処理の正当性を検証できる処理系が 求められるような時代が来るのかもしれません。
echo $[100+200] 300
上は普通に足し算
これは i に足し算
i=0; echo $[i+1] 1
これは i に j を足し算したのを k に代入
k=$[i+j]
ちなみにこっちもたまに使うけどたまにしか使わないので毎回忘れてる、 値の文字列操作
${i/pattern/replacement}
変数 i の pattern 部分を replacement に置換します。 sed の s/pattern/replacement/ 的な処理。
しかしこの変数にアクセスするのに参照のほうが引用より記法が長い、 というのはどうなんすか。引用することはあっても参照しねぇだろ普通、 みたいな感じなんすかね。 普通、逆のような気もするんですが。
pdftk というのがあるらしい
pdftk *pdf cat output cat.pdf
pdf を 50個くらい個別に印刷してからこのコマンドに気づいた。上のようにまとめておけば、 一個印刷するだけで終了ってわけです。 ちなみにマニュアルを読んでも解りにくくて、なかななか上のコマンドが書けません。
pdfinfo というのもある。ページ数とかをコマンドラインから数えるのに便利である。 複数ファイルのページ数を合算するとか、コマンドの中でこれを使うと良いわけです。 grep -o は与えられた regex matching part を全て一行ずつ出力するオプションです。
i=0; for f in *pdf do i=$[i+`pdfinfo $f | grep 'Pages' | grep -o '[0-9]+'`] done; echo $i 107
こういうコマンドをいちいちシェルファイルに書いてたらあきまへんで。 他にも pdf 関連はいろんなものがインストールされていて、ほとんど使ってない。 時々コマンドラインで無茶なところから補完してみるのもいいかもしれん、と思った。