サーバーが重くて困っちゃうかんじなので、はてなダイアリーに行きます。続きはそちらでどうぞ。
http://d.hatena.ne.jp/amarui/
Processingがとうとうベータ版を脱出し、バージョン1.0となりました。インストールもドラッグ＆ドロップで一発だし、いや、めでたい。
思い立って、果実酒を漬けはじめました。梅酒やカリン酒がメジャーですが、ちょっと不思議（今まで飲んだことない）かつ即戦力になりそうな（早く漬かる）もの、ということで、ドライフルーツのマンゴーとクランベリーを焼酎甲類で漬けることに。できあがりの予想としては、クランベリーは赤く染まったきれいなお酒、マンゴーは白濁色になりそうです。両方ともソーダで割って飲むのがおいしそう。一週間くらいでできるかな？
写真は漬けてから12時間後くらい。どちらも糖分が染み出て白濁色っぽくなってきています。マンゴーの方がまだクリア。
LISP/Python/RubyをGoogle Trendで比較してみました。2006年頭くらいにRubyとPythonが入れ替わっていますが、これはRuby on Railsの影響なのでしょうか？ 2005年10月頃にPythonが一気に言及されたのも気になります。GuidoがGoogleに入社した頃だったかな。
LISPは常にRubyやPythonの10分の1くらいを推移しているように見えますが、実際には2004年から2008年にかけてずっと下り調子で、3分の1に減っています。Practical Common Lispが出版されたのに、ダメなのかー？
これがサッポロビールから現在発売されているビール・発泡酒などの全部だそうです。（ヱビス除く）
ロジットしか使ったことなかったのですが、プロビットも同じ目的で使えるのですね。どちらも独立変数が連続値で従属変数がブール値のときに、シグモイド関数を重回帰分析ではめる分析手法です。SPSSのページによると、違いは「ロジスティック関数を使うか正規累積関数を使うか」だけみたいです。ロジスティック関数はパラメータ変数が使えるので、関数の傾きや切片が制御できるのが便利かな、というところ。
x = linspace(-4, 4);
y1 = 1 ./ (1 + exp( -x )); % logit
y2 = normcdf(x); % probit
plot(x, y1, 'b', x, y2, 'r');
legend({'Logit', 'Probit'}, 'Location', 'Best');
set(gca, 'ylim', [0 1]);
set(gca, 'fontsize', 14);
grid on;
print -dpng logit_probit.png
いやはや、夜になると目の焦点が合わなくなるほどモニタを見ている生活になっています。新しいめがねに変え、大画面テレビに変えたのに、テレビに表示された字幕が見えなかったり。コンピュータ使いすぎ。睡眠時間削りすぎ。こういう日々が続くと精神的にも落ち込んでいきます。そうなる前に休まなきゃ。幸い3連休が控えているので、休めそうです。
ほっしくんに指摘されたので、間違った情報を修正すべく、プログラムを書きました。残響時間（RT60）は、「信号のエネルギーが60dB減衰するまでの時間」と定義されています。ISOではその定義を発展させて？現実の測定に即した形にしてあるようです。-5dB〜-35dBの部分に直線をあてはめて、そこから外挿して-60dBに相当する時間を求めるやり方が使われるのだとか。プログラムは以下の通り。
function rt = reverb_time(x, fs) %REVERB_TIME Compute Reverberation Time (RT60) % Compute RT60 from T30 (least square fit between reverberation % envelope at -5dB and -35dB). % % 2008-11-17T1 = -5;
T2 = -35;
T3 = -60;re = reverb_envelope(x);
mm = max(20*log10(abs(re)));
t = ([0:length(re)-1]/fs)';
z = 20*log10(abs(re))-mm;
ind = [sum(z >= T1) sum(z >= T2)];p = polyfit(z(ind(1):ind(2)), t(ind(1):ind(2)), 1);
rt = polyval(p, T3);
僕はpolyfitで近似曲線を作ってpolyvalで外挿してますが、-5から-35までが30dBぶんの減衰なので、その時間を2倍しちゃってもいいようです。ただ、残響曲線に直線的な減衰が始まるのが-5dBより後の場合はどうするんでしょう？ -10dB〜-40dBの外挿でも、-10dB〜-30dBの外挿でも、最終的に-60dBまでの時間が求まれば良いんでしょうか？ それともISOに従って-5dB〜-35dBを使わないといけないのかなぁ。
僕が中学生〜高校生くらいの頃は、ポリゴンなんて計算量的に高価なものはあまり使えず、ほとんどのゲームがピクセル単位で画面描画を行っていました。プログラミングを趣味としていて、特にゲームプログラムのためのライブラリ作りが好きだった僕は、MS-DOS上でC言語を使って高速な画面描画が簡単に行えるライブラリを作ったりしていました。当時使っていたコンピュータはNEC PC-9801互換機（EPSON PC-286U）で、画面サイズは640x400ドット、4096色（RGB各6階調）から選んだ16色が使えるというものでした。同時代のアーケードゲーム機の性能は320x240ドットのものが多く、家庭用パソコンの方が画面解像度は高かったのです。その反面、アーケードゲーム機は色解像度が高く、 256色を同時に使えました。
もともとビジネス向けとゲーム向けと、ターゲットが異なるので、同じ画面解像度・色解像度にする必要はありません。たとえばパソコンはビジネス向けですので、文字表示に主眼をおいてビデオメモリの配分を行えば、画面解像度を高くして色解像度を下げるのは当然です。カラープリンターが少なかった（ドットインパクトや熱転写が主流だった）時代、カラーの書類を作ることは難しかったので、もしかしたら高解像度のモノクロ画面でも十分だったのかもしれません。それに対してアーケードゲームでは、なめらかな動きや様々な表現を見せるために、どうしても色数が必要だったのでしょう。
僕の個人的な好みなのかもしれませんが、画面解像度と色解像度であれば、僕は色解像度の高いものが好みです。アンチエイリアスを使えば画面解像度が低くてもなめらかな表現ができます。思えば、音楽フォーマットのPCMにしても、僕はサンプリング周波数の高さよりも量子化ビット数のほうに重点を置きたい人なのでした。たとえばDVD-Audioで192kHz/24bitなどの高解像度PCMがありますが、同じ帯域を使うのであれば96kHz/48bitのほうが良いんじゃないのかなぁ、と思うわけです。音の解像度と聞こえの関係を研究をしたわけじゃないので、単なる直感なんですが。
「LZWに震え上がった10年前の人たち」という記事を読んで、当時の僕もウェブサイトに載せる画像を全部PNGに変えたりしたなぁと懐かしく思い出しました。当時は圧縮技術に興味があって、いろいろと勉強していたのですが、まさか圧縮アルゴリズムがビジネスの材料として使われているとは思いもよらなかったのです。技術や情報は無料で提供されていて、皆が等しく享受できるものと思っていました。その代わり、自分が作った技術は無料で提供しなければならないとも。当時の僕はGNUの思想にけっこう影響を受けていたんですね。