ご結婚おめでとう。式は洋風だったのね。ということは例のああいう外人アルバイト牧師が出てきて… 以下自粛。
パパは大変ね。
さて、いきなり研究 (けんきふ) の話になるが、GLARF はほんとうにむずかしい (が、おもしろい)。
かなり「まっとうな」意味構造を返してくれるのだが、問題はそれが「まっとうすぎ」なことにある。
返された構造はほぼ完全なグラフとして扱わねばならないので
(知ってた? 本来、構文木などというものはインチキであって、
言語をまともに扱おうとすれば、木構造をしていないんだよ!)、
そこにはループも含まれている (たとえば関係代名詞節はそれ自体が従属節となっているが、
その就職先修飾先は主文である)。だから、ある動詞の主語や目的語は何か?
というときに、グラフを Dijkstra でたどらなければならない。なぜなら、
ひとつの単語が複数の動詞に対して主語としてかかるなどというのはよくあることだからだ
(そしてその逆もある)。おまけに、coordination (並列) は GLARF では入れ子になったノードとして扱われる。
これ自体もまったく正しい表現だが、これまた処理する側が正しく扱わなければ
ちっともその特徴は活かされない。そのために数々の工夫が必要になる。
Python がなかったら一体どうなっていたことか。
もっとも、グラフ構造もしょせんインチキなのだが (より精巧なインチキといえるかもしれない)。
新山は、本来ならカッコをつけなくてもいいところにカッコをつけたがる。
たとえばこんなの:
a = (b + c) + (d + e)
とーぜんこれは、意味を明確にするためのカッコである。
あと、こんなのもある:
if y and (not x) and (not z): ...
ほんらい not は and より
優先度が高いからカッコは必要ないはずだが、それでも人間が読む場合は
こちらのほうが読みやすい。
とくに C では以下の×のような記法を使うことはまずない。
× *p++;
○ *(p++);
なぜなのだ!!
やばい。止まんなくなってきた。
これはすごい理論だ。つまり開きカッコ閉じカッコはそれぞれ男と女に相当していたのだ! つまりこれは神の定められた摂理というものである。したがってゲイという連中は 世界を premature end of file させる運命にあり、したがって悪である。すばらしい! 共和党は Lisp を習うべきだ。
しかし一般の Lisp プログラムでは、男女がほんとうにくっついていること () はまれで、
たいていの場合、男の集団 (((( と女の集団 )))) とのあいだには
かなり距離があるよなあ。人生とはそんなもんよ。
やりすぎです。
ところでリンクを全部クッリクした人、あなたは負け犬だ。
そのあといつもの店で冷凍ギョウザ 30個を買い求め、家路につく。 WTC は会社帰りの人で混んでいたが、ヘンな格好したのはいなかった。 JSQ に着いたらガキんちょが仮装してたむろしていた。 はろウィーンもさすがに 5回目ともなるともう 99% 無関心だな。 きょう、ある日本人が「日本にもこんなイベントがあったら」といってるのを聞いたが、 どっこい実は似たようなイベントは全国各地にあるではないか。 ただ西洋かぶれしてる人には見えないだけのことで。
ところで、新山が Firefox で嫌いなのは、
javascript:void(0);
のようなリンクの onclick属性を下のメッセージバー領域に表示してくれないことだ。
これじゃ何されるかわからない。javascript で悪さをしたがる馬鹿を許すまじ!!
DDI.
だぼー (double)、だぼー (double)
ニュウ・ヨウクにいて中国ネタに詳しくなるってのはどうなんか??
どうでもいいけど、うちで 4年間使っていたタイガーの湯わかしポットがこわれちゃったのよ。 きょう見てみたら、ちっとも沸騰しない。そろそろ償却の時期かとも思うし、あした チャイナタウンで新しいの買ってこなきゃ。
ちなみに、いまんところ一番衝撃的だった (とはいうものの、おおかた予想はしていた) 文はこれ:
マスメディアは、実は規制を望んでいる
これを「人間は、実は規制を望んでいる」と読みかえることはできるだろうか? おおっと、また大審問官になってしまった。dixi、dixi。
最近とった写真なづ (← 「最近とった写真など」の複数形)。
…その前に書いておくと、 きょう、洗濯が終わってからさっそく Pier-1 Imports に行ってみたのだが、 去年は売っていた花瓶はもうなかった…。がっかり。 オレはつくづくあの花瓶が好きだったらしい。どちらかというと、 花を飾るためにカビンを買ったというのではなくて、花瓶を置きたいがために花を飾っていたような木がする。 似たような花瓶は探せばほかにあるかもしれないけど、Crate and Barrel とかでもそうだが、 アメリカで売ってるガラスの花瓶ってのはだいたいどれもデカくて重くて肉厚なんだよ。 一輪挿しに向いているような花瓶ってのはほんとに少ない (ちなみに、花屋で売ってる花自体もバカデカい種が多い)。 もっと別の店を探さねばダメかもしれない。 しかし、しょうがないので、その後近所の花屋に寄って小さめのガラスの花瓶 (無色透明でズン胴 -- メスシリンダーか!) を買ってき、ついでにそこにあった フリージアがあまりにキュートだったので衝動買いした。 色は「どピンク」である。以前はもっとつつましやかな花が好きだったハズなんだけど… さいきん趣味が変わったのかなあ…。
COMPUTER SCIENCE COLLOQUIUM Speaker: Gene Myers, UC, Berkeley and HHMI, Janelia Title: Whole Genome Sequencing and Imaging-Based Systems Biology
きょうの聴衆の面々をみると、かなりの大物トークであったらしい。 で、実際すげー研究で面白かった。
(追記 oct 29) 画像分析をつかって、ゲノムを別の観点から理解できないか? という内容。かなり素人には わからんところもあったし、またすごい結果が出ているわけでもないのだが、 そのアイデアはすごかった。現在さかんに行われているゲノム解析 (英語では「ジノム」と発音する) の目的というのは、そもそも何か。 多くの生物学者の興味というのは、けっきょく「遺伝子はどういう仕組みで生物をつくっているのか」ということにつきる。 遺伝子が生物の構造を決定するプログラムだということはわかっているし、 その塩基配列も読めるには読めるのだが、ある遺伝子が「存在する」ことによって 結局なにがどうなって生物の機能や組織ができるのか、その複雑な過程はまだわかっていない。
これを解明するために、生物学者はとりあえず DNA の塩基配列を読もうとしている。 しかしここには問題がある。DNA の塩基配列が全部読めたとして、結局のところ それがどのように「動く」のかをつきとめなければ、遺伝子の仕組みを解明したことにはならない。 つまり、コードは読めてもそのプログラムがどう動くかは複雑すぎてまったくわからんのである。 Perl のワンランナーで書かれた証券取引システムを渡されてどう動くか説明しろ、といってるみたいなもんだ。 しかしもっと大きな問題は、そもそも DNA を読むだけで大騒ぎ、ということである。 現在では DNA を何十万という断片にぶったぎって (長すぎると読めない)、 すげー高額な機械をつかってなんとか配列の一部を読むことはできるが、 これはとにかく時間と手間がかかる。なぜなら読みたい配列のほんの一部しか取れないし、 ノイズが多すぎるのである。で、いまのゲノム解析というのは、ほとんど 「断片をどうつなぎあわせるか」と「どうノイズを削減するか」にかかっているという。 このためにほとんどの手間がさかれている。 スライドの中にジョークとしてマンガが出てきたが、研究者が 30億ピースの ジグソーパズルをつみあげて途方にくれており、「あっ、はじっこ見つけた」とかいってる、 というものだが、この人はこれはジョークなんかではなく、実態だといっていた。とりあえず DNA の 断片は全部あつめても、それを並べる方法がそもそもわからんのである。で、いまの bioinformatics では いろんな手法を開発したりアルゴリズムを開発したりしてなんとか「つぎはぎ」の精度を上げようとしているが、 はっきりいってまだまだらしい (「Nanopore はまだ実用にならない」とかいってたが、そら一体なんじゃ?)。 データが集まれば集まるほどノイズ処理が問題になり、計算量もおそろしく増大し、 全体的な遺伝子マップはおそろしく曖昧で、この調子でこれから一体どうなんの、という状況なんだと。
で、このおじさんは「こんなのオカシイ!」と思ったのだそうな。 つまり、塩基配列を読むのはそれはそれで結構だが、何も遺伝子の発現を研究する唯一の方法は それだけではない。なにかまったく別のアプローチがあるはずだ -- といって他の分野の論文を読んでいたら、画像分析をつかう方法を思いついたという。 なんとかバエ (「D. なんとか」という学名で呼ばれているらしいが、忘れた) の 卵細胞をもってきて、そこに細胞に放射能マークした mRNA を入れてやる (これはどうやるのか知らないが、とにかくできるらしい)。そのあと胚が成長するにつれて その mRNA の動きを追っていくと、「ある遺伝子が体内のどの部分で発現したか」が 時間をおってわかるようになるそう (実際にムービーも見せてもらった)。 実際にはこれは 1匹ではなく、何十匹ものハエの成長途中の画像をクラスタリングして行う。 遺伝子の動きで謎なのは、ひとつの細胞から分裂した細胞が ある部分で特定の遺伝子だけを発現させ、特定のタンパク質をつくることによって その部位の組織をつくるというメカニズムである。これまでの研究では、 ノイズがおそろしく多いため、こういった DNA のグローバルな動きを説明することが むずかしかったという。この研究をこれから発展させると、そういった塩基配列を 別の観点から見てそうした説明をする足場が与えられるのではないか、という 期待がもてるのだそうな。また、種ごとの発現のパターンの類似性をミクロな視点で 詳しく調べることによって、ある特定の塩基配列に共通する構造を みつけることができるかもしれない、という。 「遺伝子がちょっとしか違わないのに、ぜんぜん最終形態の違う生物」というのは 沢山あるのだが、生物の塩基配列はもともとかなり再利用されているはずで、 最終形態はぜんぜん違っていても、発生段階でのある局所的な 部分の時系列によるパターンを追っていくと、そこには深いレベルでの 共通したアルゴリズムがあるかもしれないのだ…。
というわけで、かなり途中で「???」な状態にもなっていたが、 まったく眠くならずに最後まで楽しめたトークでありました。 このおじさんは喋り方も軽快で説明もうまく、おまけにアイデアも なるほどと思わせるものだったので、非常にためになった。 で、今回のホストは shashaせんせいだったのだけれど、 そもそもどういうきっかけで知り合ったのかといったら、 「イタリア旅行してるときにあるプールだかで偶然出会って、 話しているうちに非常に仲良くなったので講演を頼んだ」という。 あいかわらずおもしろい先生だ。 しかし今日は参加者も多かったので (学科じゅうから人が来ていた)、 それなりに名の知れた人だったらしい。
それにしても専門用語がなあ。新山が知っている生物用語というのは 「mRNA」とか「C elegans」ぐらいのもんで、あとはまったくわからん。 文脈からの推測でしかわからんが、それすらむずかしいときがあった。 たとえば「この実験は XYZ-456 を使って…」とかいう英数字の略語を言われても、 それがなにか生物のことを指しているのか、あるいは機械や実験手法のことをさしているのか、 それとも制限酵素かなんかなのか、ぜんぜんわからんので、 ときどき文脈が追えなくなるのだった。
今日は落ちこむことがいっぺんに起こった、よくない日だった。
唯一よかったことは、ころきあのトークが楽しかったことだ。 これはまた明日書く。しかしこんなんじゃ満たされない。翻訳もしてないし。もーもー
ところで (てくるで)、pyvnc2swf で、Windows で (人によっては) MemoryError が出る、
という問題にずっと悩まされていたのだが、新山の環境では再現しなかったので、ずっと放ったらかしにされていた
(それに Windows で使っているユーザはぜんぜん Python を知らない人が多いので誰も修正できなかった)。
ところが、今日パッチを送ってきてくれた人がいた。やったね! 原因は RFB プロトコルからの
データを受けとる recv() にあった。
Windows には socket.MSG_WAITALL がないので、
いままでの (MemoryError をひきおこす) バージョンは次のようにして MSG_WAITALL を
エミュレートしていた:
def recv(self, n):
buf = []
while n:
x = self.sock.recv(n)
if not x: break
buf.append(x)
n -= len(x)
return ''.join(buf)
で、これが修正されたバージョン:
実は MemoryError の原因はリストにたくさん文字列をつめこみすぎたためだった
(この文字列の長さは数mbytesになりうる)。ただし、これじゃー文字列をいちいち足してるから
遅くなりそうだよなあ。
def recv(self, n):
buf = ''
while n:
x = self.sock.recv(n)
if not x: break
buf += x
n -= len(x)
return buf
StringIO は、ソースを見てみたら内部でやはりリストを使っているので
メモリの節約にはならない。array('c') を使えばちょっとは速くなるだろうか?
まあ、Python でこのような大量のデータ転送処理は向いていないということは認めるよ。
それは、つぎのようなものである:
- 病気は治らない。
(この、バカ笑いぶりを見よ。バカ=笑=い的に)
I feel that OpenBSD development is evolutionary instead of revolutionary.-- Theo de Raadt
今月の nylug ミーティングは Alex Martelli による「Python のオブジェクトモデル」だった。
講演者は口ヒゲをはやしたイタリア人のおっさんで、 Python in a Nutshell と Python Cookbook の著者であるらしい。
しかし、トークは期待はずれだった。激しく期待はずれだった。
ようするに、こいつは Python クラスの __dict__ とか __get__ とか __new__ とかを
あれこれラッパして、便利な (と本人は思っている) クラスを設計しよう、
というものだが、はっきりいってサイアクだ。どの程度サイアクかは、
発表スライドのサンプルコードを見ればわかる。
はっきりいって、この手の操作をやりたいなら Lisp のマクロのほうがはるかにきれいだ。
もしオレが Python を知らずにこのトークを最初に見たら、
Lisp に転向しようと思っただろう。それくらいひどい。
おまけにこのおっさんの話し方は威圧的だしジョークは面白くなかった。
たいして得るものもなく、時間の無駄だった。
しかしオレが本当にムカついた原因はトークの内容そのものよりも、 会場のしょうない演出にある。もともとこのトークは Python だから 行ったのだが、最初はただの普通のミーティングなのだと思っていた。 しかし行ってみたらそこはいつもやっているような IBM じゃなく、バーの特設ステージで、 入った途端、あの例の「Google オブジェ (色水の中に泡ボコが浮いてるやつ)」が 並んでおり、Google のパンフレットが配られていた。これって Google の就職説明会か何かですか?? ようするに、連中は Linux ユーザのリクルートがやりたかったのである。それなら最初からそう言えよ (バカにしてるよなあ)。 バーの中はコースターからナプキンから (!) すべて "Google" の文字が入っており、 おまけに Google 印のついたヘンテコな PC が置いてあってネットが見れるようになっていた。 そんでタダ飯が用意されてるのだが、トークはいつまでたっても始まらない。 1時間ぐらいしてやっとトークが始まったら、照明はひどく暗いし 音響は悪いしプロジェクターも見づらかった。 そもそもこんなところで技術的な話をやるというのが場違っているのである。 タダ飯で釣ろうとしているのだろうが、疲れるだけ。素直に会議室でやれよ! で、このおやじも Google Tシャツを着て出てきて、最初に「google がいかにすばらしい会社であるか」を 力説するし、終わってからは別のおばさんが出てきて「わが社では Linux のエキスパートを 求めております、彼(=講演者) のような優れた人材と働きたい方はぜひ google へ!」といっていた。 なによりガッカリしたのは、出席してた連中のほとんどが Python なんか使ってもいないし、 ただ google という名前につられて来てみただけ、ということだった。 したがって今回のトークを理解した人はたぶん全体 1割もいないと思われる。 トークが終わったあとに、誰かが隣に「Python はほとんど知らないけど、すばらしいトークだったね!」 と話しているのが聞こえた。ウソつけ馬鹿野郎。 アメリカンにはこのようになーんにもわかっていないくせに称賛するアホが多いが、 こういう連中を見ると時々「氏ね」と思う。
で、今日の集まりはほとんどアヤしい新興宗教にしか 見えなかったということだ…。大量の信者に囲まれ、「中の人」もまた信者であった。 おまけに連中が必死でオタクのご機嫌とりをしている様子は、まるで某真理教を思い出させる。 頭はいいがアタマが浅い人にはうってつけの会社なのかもしれない。 それでもアメリカンからは素晴しい会社だと思われているところがおそろしい。 考えてみれば、google 自体、アメリカ人の嫌われ者ぶりを凝縮したような会社である。 気前がよくてフレンドリーで、うすっぺらい善意に満ちているが、考えが浅く、無神経で、 パワーさえあれば世界中の問題は解決できると信じており、 なぜ自分が嫌われているのかまったくわかっていない、という典型的なタイプ。 ま、どうでもいいけど (DDI)。とにかく、これからは google が関わるイベントには参加しないことにしよう。 普通のトークだと思ったオレがバカだった。
それにしても、Python Cookbook とか Python in Nutshell って以前に見たことはあったが、 なんらかの理由で「欲しい」とは思わなかったのだが、今日のおっさんのトークを聞いたら 買わなくて正解だったような気がする。あんなのが Python だと思ってもらっちゃ困るね。
(追記) そんなことより来月の講演は Eben Moglen だって! 実は Python よりそっちのほうがずっと興味あるぞ。 考えてみれば彼は Columbia の教授だから実は近所にいたんだな。
/etc/fstab も自前で書けないような軟弱者ばかりであるので、
このあとが大変だろうよ、オレ知〜らねっと)。
ひととおり話を聞いた結果、やっぱりオレのシステム管理方法は正しかったと 思った。すくなくとも、給料もらってやってる管理者と同程度のことは できていると思う (しかし新山の奨学金は研究の対価として払われているのであって、 システム管理をしても全然ホメてもらえませんが)。ただ、Danのグループよりうちのポリシーのほうが ずっとパラノイアっぽいけどな。しかし、システム管理者ごとき (=新山) が上司 (=この場合はセキネさん) に「なんてことしてくれたんですか!」とか ズバズバ言える環境ってのは恵まれてると思うのである。
どうでもいい馬鹿話 = DDIBB
今日は昼を食ってるときにも誰かが尋ねてきて翻訳ぜんぜんやってる暇なかったし、 ミヤノ日記を見ている暇もなかった。つうことでこれから今日の分の翻訳だる。
新山がいまだに恐れていること:
まあ、いまではどっちも使っているけどね。恐れていることには変わりがない。
さふいえば、そろそろ halloween なんだが、うちのビルの裏口のエレベータには
"Freight Elevator (貨物用エレベータ)" と書いてある部分が赤いマジックで
"Freight HEllevator (恐怖の地獄ベータ)"
と修正されている。この落書き、いつからあるんだろう…
業務上過失致死と業務用カシスソーダって似てるよね。
↑いまここに見てはいけないものを書きました↑
終わってますよ。ほんとに。
Thursday, November 3, at 11:00 a.m. in room 1221, 719 Broadway.
ちなみに、世の中のすべての肉体労働者は同時に頭脳労働者でもある。 が、彼らはなぜか頭脳労働者とは呼ばれない。
ところで電車の中でゲイのカップルをみかけた。 これだけなら特に珍しくもないのだが、今日見たカップルはさらに手話をしていた。 さすがにゲイで聾というのはめずらしい。まあ、アメリカ的な考え方でいけば、 ハンデにもめげず個人としてのスタイルを確立していてすばらしい! …ということになる。しかし個人的な考えでは本当にすばらしいのかどうか。 なんともいえない。
ああ、全部はむりそうだ。図書館にも行きたいし。
でも「わかってない人」に、ものをわからせるのは、ほとんど不可能だ。