最小完全ハッシュのソースコードを生成するコマンドを仕上げてみたのだが、cmph や bep がソースコード生成じゃない理由がひとつわかった気がする。
アルゴリズムとして大きなデータを扱えるようになったために、(とくに key や value を含めると) 生成されるコードも大きくなって、コンパイルに時間がかかる (もしくは、終わらない) からなのではないだろうか。
今月の FSIJ 月例会の案内が出た。
新部さんがこの問題を追い詰めるのを横から見ていた、というか仮説を聞いては疑問を述べるということをやっていたのだが、最終的にソフトウェアの底を突き抜け、ハードウェアの話になってしまったというのがなんとも感慨深い。
レジスタ割り付けアルゴリズムに興味を持つ。
ふむ。グラフ彩色でやるというのは、命令を並べた後の話なのか。
gzip は適当にブロックに分割して並列処理できると思う。
というわけで探してみると、すでにある?
bzip2 なのもあるらしい
ちょうどというかなんというかそういう記事が出ている。
そうか、圧縮はともかく、なにも考慮されていなければ伸長を並列処理するのは難しいわけか。
手元のツールをいくつか Ruby 1.9 対応してみると、どうも scan がひっかかる。
htree でも、日記でも、メモ用のスクリプトでも問題になった。
長い文字列を scan で分割して取り出すのに、MatchData#begin 等を使っていると、時間がかかりすぎる。
/pattern/ を /\G(.*?)pattern/m に変えて MatchData#begin 等を排除すればまともな速度で動くようになるのだが、厄介である。
リモートログインしていたら突如として接続が切られたのだが、どうも停電だったようだ。まぁ、そういうこともあるか。
以下のプログラムがコンパイルエラーになることに気がつく。
% cat t.c
void f(int a)
{
int a;
}
% gcc t.c
t.c: In function 'f':
t.c:3: error: 'a' redeclared as different kind of symbol
t.c:1: error: previous definition of 'a' was here
調べてみると、パラメータはボディの先頭で宣言されたと同じ効果を持つので、同名の変数はボディ直下では再宣言できないということが明確に書いてあった。
どんな仕様がありうるかちょっと考えてみた。
まず、String#succ は文字列から文字列への関数であり、ひとつの文字列が与えられればそれに succ が適用された文字列というのはひとつ決まる。
そして、空文字列以外の文字列は、1回以上 succ を適用してその文字列自体に戻ることはない。たぶん。ここでは空文字列は除外して考えることにしよう。
そうすると、文字列 a, b が与えられたときに、a から b へ succ でたどり着けるという関係は半順序とみなすことができる。
順序がつく場合は upto はそう動くのが順当であろう。順序がつかない場合は、厳格な仕様をデザインするなら例外であろう。厳格でない仕様を考えるなら、ほかの選択肢もあるかもしれない。
では、実装がそうなっているかというと、そうなってはいない。これは順当な部分も含めてそうである。たとえば、"zz".succ は "aaa" であるが、"zz".upto("aaa") {|x| p x } は何も表示しない。
情報処理学会の学会誌を眺めていて、ペアワイズテストに興味を持ったので調べてみる。
[latest]