http://d.hatena.ne.jp/wasisan/20090321/p1
まず一言。E-Mailアドレスにのみ正しくマッチする正規表現というものは存在しません。それから、RFCではこういうのはたいていBNFで記載されているので、文脈自由文法が使えるならかなりそのまんまで書けるので非常に楽です。
一方で、「正規表現本来の目的＝トークンの記述」というのには首をかしげます。grep使ったことがないんでしょうか。メールアドレスを正規表現でマッチさせるというシチュエーションはいろいろ考えられますが、MTAやちゃんとした MUAを実装するのでもない限り、よくある用途は「メールアドレスフィールドに突っ込まれたユーザの入力がメールアドレスっぽいかどうか検証する」といった程度のものであり、すなわちhttp://hal456.net/qdmail/validationで書かれているような程度のことではないかと思います(ってこれMTAですが)。たとえばウェブ系ではユーザの誤入力(例えば名前とメールアドレスのフィールドを勘違いしたとか)を検出するといった簡便な用途が想定され、その程度の単純なバリデーションが大元の話題で要求されていたのだろうと思います。
以前、kazuさんがParsecについて書いていたときにも違和感を感じたのですが、何といいますか、文脈自由文法って、そんなエラいですか？ 文脈自由文法は正規表現よりも上のクラスの言語なので、マッチできる対象が広がるのは確かですよ。でもその論法を持ち出すならばチューリングマシンが最強ということになってしまう。そうではないはずです。
正規表現には正規表現なりのいいところがあります。私に言わせれば、そのいいところというのは、それなりの簡潔さでそれなりの表現力があるというところです。世の中には、正規表現をちょっと利用するだけでだいぶ楽になるけど真面目に書くと案外面倒くさい、という問題領域がかなりあります。そういう問題領域を素早く解くために正規表現は出て来ます。sed(ed)、grep、awkなどが広まったのはまさにそれが原因でしょう。
もちろん正規表現を使ってプログラミング言語をパースするとかいい出すと「そりゃー変でしょ」って思うし、BNFで記述された仕様を実装して動作を確かめるとなればどうしたって結果的にパーサを書くことになります。でもそれって単にやってることが正規表現の仕事ではないからではないでしょうか。
そういえばxtalでは正規表現のかわりにPEGにしたという話ですが、どうなったんでしょう？
京都の大学の研究室から、能登半島の研究所に行って研究をすることになってしまった大学院生の守口一郎は、あまりにも何もない周囲の淋しさに耐えかねて学生時代の友人、先輩、家庭教師時代の教え子、妹、森見登美彦、などなどに手紙を送りまくる。その文通のやりとり……ではなくて、やりとりのうち守口氏の手紙の文章だけが延々と書かれているのがこれだ。地の文はないし、相手の文章もない(ないが、守口氏の反応から何が書かれているかがうかがい知れるわけだ)。
特に技巧的に新しい手法だということもないだろうが、こういうスタイルにしては何が起きているか抜群にわかりやすい内容となっている。変に凝ったりするところがなく、するする読めてしまうが、それでいて、各章で読者にわかるのは断片的な事実だけを小出しにしつつ各章をうまく機能させてるという感じ。
全部で12の章に分けられる作品なのだけど、文通は時系列順ではなく、1つの章は特定の相手とのやりとり(の守口氏パート)だけで構成されている。守口氏はやたらと筆まめなので、同時に複数の相手と文通しているし、文通相手同士が互いに知り合いだったりするから、一方であることを書きつつ、もう一方でそれについて言及したりしている。一方の文通で相手に言われたことを別な相手に言ったり、同じような時期に同じようなことを書いていたり、そんな語られ方の中で、各キャラクターがどう考えどう行動したか、だんだんわかるようになって来るという次第。
登場人物のやっていることのあまりのくだらなさ、言い訳のせせこましさなどは『太陽の塔』などにそっくりなんですけどね。また登場人物にはモデルがいるのかな。
あと、モリミーの主人公は韜晦して、韜晦して、韜晦しっぱなしで物語を終えるわりには読者には心の内がしっかりはっきり伝わるという作品が多いですが、今回は書いちゃいましたね、きっぱりはっきり。でもそのわりに興冷めにならないのですね。妹パートの末尾、なんだか唐突にいい話になっており、しかもこんな、ごく普通の「いい話」に不覚にも感動してしまった。
なんかしばらく日記を書いてませんでした。しばらく前に「利用をやめました」と書いたtwitterに先日復帰しまして、そっちでだらだらするようになったら全くこっちを書かなくなってしまった。まったくだめですね。だからやめたのでしたが。
それはさておき、public betaが出たSafari4をダウンロードしたらなかなか良い感じだったので、すっかりメイン環境にしていたのですが、やっぱり諦めました。
そもそもメイン環境にしたのはなぜかというと、起動が速かったから。Firefoxの起動は本当に遅くてイライラしていましたがSafari4は非常に素早い。他の機能もまずまずで、たまにちょっと予想しない動作になることもありますが、まぁ満足していました。今更戻る理由は特に見当たらない、というぐらいには良かったわけです(新しくブックマークレットを登録する方法の面倒臭さには辟易しましたが)。
で、やめた理由。gmail chatで音がならないから。
gmailのchatはなかなかよくできていて、誰かが話しかけたりしてチャットウィンドウができると音がなるんですよね。それで何かがアクティブになったということがわかるようになっている。これはgmailのタブそのものはバックグラウンドにしていて他のことをしているときは、特に便利なんですな。音を鳴らすのはたぶん、見えないflashでも作っているんではないかと思いますが。
ところがこれが鳴らない。もちろんこれは別にgmail固有の問題ではない。推定に推定を重ねますが、Safariではバックグラウンドウィンドウではflashの動作に制限があるのだと思います(3系でどうだったかは記憶してません)。なんかゲームやってても、バックグラウンドになると音がやんだりするんですよね。YouTube動画は再生し続けてますけど。いずれにせよバックグラウンドでflashが動くことを制限する、というのは比較的わかりやすいポリシーです。それはそれで分かる。
ただ、gmailで音がならなくなるとちょっと困るんで、諦めました。解決策とか募集中。でも推定があっているのだとするとポリシーであってバグではないので、解決策はなさそうですね。
なんか変だと思ったらすっかり勘違いをしていたことに今ごろ気づいた。LZMAの人たちが新しくxz utilsというのを作ってたのね。で、これまでLZMAに割り当てられていたJというフラグをxz utilsに割り当て直すとともに、.xzという拡張子もサポートしますよと。LZMA自体は2007年からずっとGNU tarでサポートされていて、拡張子としては.lzmaが使われていたらしい。そうだったのか……己の不明を恥じるのみです。
という訳でもう一度比較。昨日と同じファイルを使った。のでデータはxz utilsだけ。その他の環境は一緒。
圧縮後のサイズ。
2527556 Gauche.tar.xz
圧縮、伸長の時間。
% time xzcat -z Gauche.tar > Gauche.tar.xz
xzcat -z Gauche.tar > Gauche.tar.xz 25.10s user 0.30s system 98% cpu 25.762 total
% time xzcat Gauche.tar.xz > /dev/null
xzcat Gauche.tar.xz > /dev/null 0.44s user 0.03s system 95% cpu 0.489 total
ということで、圧縮効率ではLZMAの方がちょっといいが、圧縮時間はちょっと短縮。逆に伸長時間はちょっと長くなっている。圧縮効率の問題かも。-0から-9まで指定できるようで、-9としても圧縮にかかる時間はそれほど変わらないが、ファイルサイズは2429624バイトまで減少してlzmaを抜いた。この辺のチューニングはまだこれからなのかも。
全体的にオプションとか使い方がgzip/bzip2に似ているのが嬉しいが、試した感じでははLZMAとよく似た挙動になっている。てことでたぶん基本的なアルゴリズムにはそう大きな変更はないのだろうから結論は変えなくていいのではないかと思う。ただ、lzmaもサポートされてたわりに全く広まった気配がないことを考えると、けっきょくgzとbz2の優位はゆるがないかもねえ、と思い直した。
ところでtrimpath-junctionの圧縮率が大して効率よくない件についてですが、逆にgzipでもかなりうまく圧縮できてしまっているのでそれほど改善されているように見えないというだけの話のような気がしないでもない。
LZMAについては前にmasakiの雑記帳で存在だけは知っていたが試したことがなかった。今回gzipより圧縮効率が大きく向上した「xz」をサポートを読んでちょっと見てみた。
といっても結果はmasakiさんと変わらないので、リンク先だけ読むとよいよ。
手元にcheckoutしておいたいつかのバージョンのGaucheのソースコードを試した。gzip 1.3.10、bzip2 1.0.5、lzma 4.65での比較。
圧縮後のサイズ。
29419520 Gauche.tar
4725235 Gauche.tar.bz2
6605527 Gauche.tar.gz
2515224 Gauche.tar.xz
圧縮にかかる時間。
% time gzip -c Gauche.tar > /dev/null
gzip -c Gauche.tar > /dev/null 2.11s user 0.03s system 99% cpu 2.153 total
% time bzcat -z Gauche.tar > /dev/null
bzcat -z Gauche.tar > /dev/null 6.85s user 0.06s system 99% cpu 6.928 total
% time lzma e Gauche.tar -so > /dev/null
LZMA 4.65 : Igor Pavlov : Public domain : 2009-02-03
lzma e Gauche.tar -so > /dev/null 30.77s user 0.23s system 99% cpu 31.203 total
伸長にかかる時間。
% time gzcat Gauche.tar.gz > /dev/null
gzcat Gauche.tar.gz > /dev/null 0.32s user 0.01s system 98% cpu 0.329 total
% time bzcat Gauche.tar.bz2 > /dev/null
bzcat Gauche.tar.bz2 > /dev/null 1.79s user 0.02s system 99% cpu 1.820 total
% time lzma d Gauche.tar.xz -so > /dev/null
LZMA 4.65 : Igor Pavlov : Public domain : 2009-02-03
lzma d Gauche.tar.xz -so > /dev/null 0.37s user 0.02s system 93% cpu 0.409 total
lzmaは圧縮にかかる時間がとても長い。今回の計測ではgzipの15倍ぐらい。もちろん時間はターゲットによって変動するが、全体的にかなり重いように感じられる。ところが伸長はすごく速い。bz2は圧縮、伸長ともにそこそこの時間という具合。
なのでソフトウェアを配布する場合なんかではlzmaは非常に便利だ。今回tarがサポートしたことで、lzmaは重要なポジションを得るような気がする。gzがなくなることはないと思うが、たとえばこれからbz2の配布は減っていくというのはそんなにおかしな予測でもなさそうだ。
ところで興味深い事例をもう一つ。手元にあった他のファイルで圧縮後のサイズを比較してみた。
1925120 MochiKit-1.4.2.tar
280325 MochiKit-1.4.2.tar.bz2
383756 MochiKit-1.4.2.tar.gz
262442 MochiKit-1.4.2.tar.xz
10117120 trimpath-junction-1.1.22.tar
5511052 trimpath-junction-1.1.22.tar.bz2
5664840 trimpath-junction-1.1.22.tar.gz
5374993 trimpath-junction-1.1.22.tar.xz
これらの例でもlzmaは一番圧縮効率がいいのだが、あえてlzmaを選ぶほど圧縮効率が良くない。なぜなのかはよくわからないけれど、けっこう元のデータに依存するアルゴリズムなのか？
ところでcoreutil-7.1.tar.xzって確かに小さいんですが、私の手元のlzma 4.65だと伸長できません。なぜだ。→これについては翌日の記事も参照のこと。いろいろ勘違いでした。
先日気づいたけど、もじぴったんうぇぶというサイト上で普通に遊べるのね。お試し版という位置づけで、ステージ数はそれほどないんですが、ルールは同じだしきちんと遊べる。音楽も出る(出ないようにも選べます)。
あと対戦版がなかなか厳しくて楽しい。
基本的にはどのマスが何回ひっくり返るかを計算して手番を作るというそれだけのゲームなんですが、こういうのって苦手なんですよね。盤面が狭いからか何なのか知りませんが、詰めっぽい側面がだいぶ強調されてるような気も。そんなこんなで案外勝てない(まぁ語彙とか、語彙とか、語彙とか、そういう問題もありますけれど)。しかしむかしPS2でやってたときはこんなルールだったかなぁ。あんまし記憶にない。
「ふたりのもじぴったん」も私が知っているのとは別のアレンジになっていて、これもこれでよい。
行ってきた。
特に黒田さんの発表が面白かったけど、全体的に蚊帳の外な感が強かった。すくなくとも何らかの活動はしないとヲチだけでは楽しめないということがわかりました。
で、黒田さんのトークは何が面白いかというと、自分の中での軸が定まっていてぶれないというところだな、と思った。聞いていて、その軸というのは2つあるように思える。
一つ目は後方互換性。Schemeの何が駄目かということはいろいろおっしゃっていたが、究極的には後方互換性を維持するという態度が見られないのが駄目だと考えられているのではないかと思った。駄目というか、そんなんじゃプログラムを安心して書けないよね、というか。
もう一つの軸は実用性。仕事はJavaですが趣味でlispを書いてますなんて駄目、といったことを最後に仰っていたし、冒頭ではCより遅いというぐらいでしょげてはいけないという煽りめいた表現も使っていた。ある言語、ある処理系をなぜ使うかといえばそれが最も適切であり、実用的であるからだろう、という感じかな。あとLispを語るなら実用の経験があってこそだろうとか。あの場にいる人には結構耳の痛い主張だろうと思うのだけど、結構ウケていたのは、仕事でLispを触ってる人ばかりなのかなあ(だといいですね)。
あとライブラリの話は面白かった。
