もー、こんな早起きちゃ、夢の世界のヒトがおちおち眠てらんないじゃないの。
やばい、また二度寝しそうだ。
機械学習の実験をやってるときに、とにかくムカつくのは自分の組んでいるロジックに説得力がないことだ。 「この項はなんで必要だっけ?」「ここで正規化する必要あったっけか?」とか思いつつも、 式をあれこれいじってるうちにそのうち何を計算してるのかわかんなくなり、 それでも性能は上がったりする。で、やってる本人もなんだかわからんうちに 「性能がいいからいいや」ということで許されたりする。バグがあっても実は 誰も追試しなけりゃ最後まで気づかれなかったりする。恥を知るべきだね…。 機械学習の理論的な研究はまだいいとしても、アプリケーションはあんなもん学問とは 認められない。そういう意味では、じつは新山は Google がやってるような 「簡単な方法だけを使って、あとはとにかくデータ量で力ずく勝負」には ひそかに期待しているのだ。なぜなら、それがうまくいけば今あるチマチマした 研究の多くはどうでもよくなるから。頭のいい人をこんな不毛なことに のめりこませてはいけないよ! オレはアホなのでどうでもいいが。
これは物理なんかの自然科学の研究とは根本的に違う。 あれはある程度、法則が確立されてるし問題もはっきりしているが、 こっちはほとんどなんにもないのだ。 「こんな方向で進めばうまくいくだろう」という指針さえない (昔はあったらしい、醍醐世代)。 こういう状況で、このレミングスの群れの先頭にいるやつは一体誰なんだ出てこい! …と怒ってもしょうがないので、ねよう。
Sanda M. Harabagiu, Razvan C. Bunescu, and Steven J. Maiorano, "Text and Knowledge Mining for Coreference Resolution"
概要: They tried to address coreference resolution using various kinds of knowledge, basically acquired from an existing small corpus (MUC) and WordNet graph mining.
彼らが使ったリソース:
評価: (Table 4.) , but why the precision also improved after boostrapping??
これからさらにスライドを作らねばならない。 しかしこんな論文で追試できんのかな…。
細菌、ヘルシーなものを食うことが多いなあ。
ふと思ったこと:
どうでもいいけど女物のシャツは胸にポケットがなくてきらいだ。
さて次に読むのは OS の授業のための clustered メイルサーバーの論文で、 これがまた 30ページもある。でも字がデカいから許す。
あやしい…。
どう見てもこの式は間違っているのに…。
あやしい…。
といって、正しそうな式に直すとなぜかスコアが激下がるという現象が起こる。
気が狂うよ、まったく
あちらの世界
ぜんぜそ。
朝 = 頭おけぼけ
夜 = トッカントッカンする (??)
ふと気づいた。「おけぼけ」って何だ? b ですよ b!! b がヌケてるんですよb!!
うるうる。ネムケに耐えてこそのJIS基準合格だ。
todo: ママレード買うこと。新規
>>> s="a" >>> s[0] 'a' >>> s[0][0] 'a' >>> s[0][0][0] 'a'
べつにヘンテコでもないか。 思うに、文字と文字列を区別しないというのは混乱する。
Machine Learning Lecture, Spring 2004
Friday, April 16th
11:00 a.m. - 12:15 p.m.
Interschool Lab, 7th floor, CEPSR
cs.columbia.edu
おお、なんかおもろそうなことやってんじゃないの。
(ウソだ、ほんとはぜんぜん暇じゃない、おまえは嘘をついている!)
こちらのスーパーでいつもクラクラするのは、 チーズ、パン、ジャム・はちみつ類の売り場へいったときだ…。 死ぬほど沢山の種類がある。日本人にはほとんど何がなんだかわかんないほど沢山ある。
いわく「イラクで日本人が拘束された → NY でも拘束されるかもしれないから注意しろ」 という内容だが、そんな暇人いるかい! だいたい「日本軍撤退」を目的にするより、身代金目的で誘拐したり 脅したりするほうがよっぽどおトクだ。それからもうひとつ。 中国人と新山を区別できるならしてみやがれ。
しかし、そうすると、イラクにはあまり見間違えるような東洋人はいないのかな? つまりああいう顔した人間はみんな悪者だと。それはわかりやすくていいよな。 それとも日本人のボランティアなどはあきらかにそれとわかるような格好 (ex. エルメスのスカーフ等) をしているのだろうか?? …だとすると、イラクの例の人々は「なにがブランド物かそうでないか」を識別する 訓練を受けていることになり、それはそれで笑える。しかし現実世界というのは そういう笑えるところまで細かいやつが勝つのだろう。勝つって、何に?
try: 〜 except: をよく使うが、
これは if よりも好ましい場合が多い。なぜならそのほうが
「ほんとうに自分がやりたいこと」をより目立つように書けるからである。
たとえば昨日の例でいくと:
ところが、これがtry: dic[k] += 1 # ← オレはこれがやりたい! except KeyError: dic[k] = 1 # ← だめだってさ
if を使うとこうなる:
if not dic.has_key(k): # ← まず、様子をうかがう dic[k] = 0 # ← できないらしいので、なんとか根回ししておく dic[k] += 1 # ← 絶対の自信をもって実行
これがどうわかりにくいかというのは、自然言語に置き換えてみるとわかりやすい。 たとえば新山は、次のような喋り方をする人は嫌いである:
「えーと、あの、これもしすでに言われていることだったら申しわけないんですけど、 これはぼくが個人的にそう思うことであってほかのみなさんの同意を求めてるってわけじゃ ないんですけど、そこで使うのは『速い』であって、『早い』じゃないんじゃないですか?」
言い訳が先に来ているからだ。 まあ自分でもこの嫌な喋り方をすることが多々あるのだが。 いっぽう、こう言えば:
「そこで使うのは『速い』であって、『早い』じゃないと思いますが、 え…知っててやってる? そりゃ失礼」
これのほうがあきらかにいいと思う。
しかしよく考えてみるとこれは単なるプログラミング上の問題ではなく、
生き方の問題であるかもしれない。
だいたいにおいて新山はいつも「出たとこ勝負でやって、あとはそれから考える」
という生き方をしてきた。やる前にウダウダ悩むのは嫌いである
(はい、留学したのも後先考えずに勢いだけでやりました)。
だからそれが単純にプログラミングにおいても表れているといえる。
だから用心深い人は if を好み、例外は使わないのかもしんない…。
というか、べつに例外つかってても後先考えてないわけじゃなくて、
ただ単に表現上の問題であるかもしれないのだが。前口上が長い人はいつも嫌いなのです。
さっさと本題に入れと。人生は短いのだと。まあいいや。とにかく、例外処理はその名前のとおり「例外的な」処理を
あつかうものなので、新山が if より例外を好むのは
「こちらのほうが起きる確率が少ない」ということを暗黙的に表現していることも多いからだ。
これにたいして if を使うと、どちらもほぼ同じくらいの回数で起こることを
期待しているように見える。ま、とにかく例外処理が明示的に書けるといいのは、
急いでいる人 (とにかくプログラムの動きをざっと理解したい) にとっては、
本質的なところ (try 節) だけを読んで、枝葉の部分 (except) は
読まなくてもいいよ、と言えるからだ。実際にはそれほど簡単じゃないが。
目をつぶって
両足で
ピョン
もうひとつの例は関数内関数である。これも「本質と枝葉」をすばやく見分けるための書き方で、 こっちはもっと説得力がある。closure の必要がなくても、関数を中に入れたほうがいい場合というのは多い。 なぜなら、こうすると:
このdef f(): def g(): return g()
g() は f() の外からは絶対に参照されないということが保証されるからだ。
いっぽう、g() を外に出してしまうと、これがほんとうに f() のみから
呼ばれるのかということがわからない。それにもし何らかの理由で f() を
ほかの場所へ移動することになっても、g() はどうすればいいのか? という疑問が生まれる。
従属関係をあきらかに書ける、という意味で関数内関数はいいのだ。
つねに、プログラムの「読者」を意識すること。読者の苦労を減らす (=探索範囲をせばめる)
ようなコードはつねによいのである (obfuscated なコードを書こうとしないかぎりは) 。
そういう意味では const とかもあったほうがいい。
機能的にはなにもメリットがなくても、プログラマの思考をより的確に表現できるからだ。
ただし実際には、この手の書き方はいつも「機能的な制約」として
働かねば意味がない。「機能的な制約」というのは、たとえば
という行を考える。これだけ見ても、読者はint a = 1;
a を使って何をやりたいのかわからないだろう。しかし
こうすると、あいかわらず何がやりたいのかはわからないが、 それでも「やりたいこと」の可能性が確実にせばまってはいる。 こうすることにより、読む側は書いた側の意図をより推測しやすくなり、理解が容易になる。 これが機能的な制約。 もともと強い型付きの言語ってのはそういう視点でつくられているのよね。 いっぽう、Perl みたいになんの制約も与えず 「こんな書き方もできまっせー、こんな書き方もできまっせー」という単なる 構文糖衣の乱発になると、書く側の役には立っても、ちっとも読者の役には立たない。 違う書き方をされたからといって、それが何の情報も与えてくれないからだ。 Perl は基本的に書く側のことしか考えていなくて、読者のことを考えた言語ではない (Rubyもそう)。 でも Python は読者のことも多いに考えている言語だと思うので、 どちらかといえば型の強い言語のほうが好きな新山としては、こういう機能は もっと入れてほしい。しかしそうはいっても、 「手軽さ」というメリットは捨てたくないので難しいところだ。 それでプログラムが書きにくくなったら魅力は全然なくなる。 Ada みたいな型システムは強力だが、厳しすぎる言語は使いたくない。 結局、適度に落としどころがうまいのは Python だということになるんだけど。const int a = 1;
いつも「読者」を意識するべし、というのがプログラムを書くときの新山の心がけである。 だから Python などの高レベル言語でコードを書いているときの新山は、 コンピュータのきもちからは遠く離れていると思う。むしろ、「ライターのきもち」に近い。 ただしこれはコメントをやたらとつければいいってもんでもない。 なぜなら、自然言語によるコメントはいつも曖昧で不完全だからだ。 「プログラミング言語そのもので雄弁になる」ことが重要だと思う。 こういうことを考え出したのは djb のコードを読んでからで、 かれのコードははっきりいってそれほど雄弁ではないが、 あのコメントの少なさにおどろいた。にもかかわらず、それなりに意味はわかるのである。 たとえコメントがあっても、下手なコメントがついた下手なプログラムでは、わかりやすくならない。 つづく。
ま、とにかく、オレは世界中でごく頭のいい一部の人だけが重要な技術を 理解しているという状態 (テクノクラシーというのか) は好きでない。 ディストピアとか、そんなことはどうでもよく、単純に、なんかムカつくのだ。 日本人としては、出るものは叩かなきゃだめだろ!!
ほどよく狂った結論になったのでこれで終わりにるす。
dotty に与えると
graph G {
a -- b -- c;
b -- d;
c -- d;
}
レイアウトは線が重ならないように自動的に考えてくれるらしい。 すげー。これ、実際にマウスでいじれるわけよ (レイアウトは最初は自動でやってくれるが、手動で修正したやつを保存することもできる)。 書きだしたデータは png や gif や PDF にも変換できるし、各ノードの形を変えたり色をつけたりもできる。 Python や Java や C# のライブラリもあるそう。これでは Visio のかわりになるのではないだろうか…。 ああ、でも「カクカク線」が描けないからだめか?
てくるで、教育について思い出したが、欧米では LinuxForKids や KDE Edutainment など、教育現場に Linux を積極的に応用しようという 動きがあるのに、日本ではさっぱり聞かない (すくなくとも新山は知らない)。 KDE に至っては Kiten なる 日本語学習用ソフトまであるぞ (当然、作者は欧米人だ)。 新山は計算機の教育については興味あるが、はっきりいって日本はこれについて全然ダメそうな感じ。 そもそもまともな学校教育ができてないのに、まともなソフトウエア産業が育つはずないじゃん! 結論: あきらめろ。
てくるで、さっき日本の教育がダメだということを言ったが、 それと関連して思い出したのだが、日本の博士課程の内容は知らないが、 見た目では確実に言えることがある。それは 「日本の博士学生はとことんまで人生の悲哀を味わわなければならない」ということです…。 つまり
あ、ちなみに肝心の「内容」については、 新山は日本の博士課程をやった経験がないぬでなんとも言えませぬ。
…って、これじゃどっかの専門学校だ。 いや、たしかに、設備は日本のほうがいいよ。 無駄に。 こっちなんか一台のサーバを何十人もで同時に使って 各人が勝手に個人用の apache 走らせてたり、ひどいもんだ。 日本じゃいつの話だよ?
関数内関数は遅い。とくに内部の変数を参照してないなら、外に出したほうが速くなる。
def f(): def g(): return g() # faster def g(): return def f(): g()
KeyError を捉えるのは遅い。if で判定したほうが速い。
IndexError も同様。try: dic[k] += 1 except KeyError: dic[k] = 1 # faster if not dic.has_key(k): dic[k] = 0 dic[k] += 1
try: x = seq[i] except IndexError: x = -1 # faster if i < len(x): x = seq[i] else: x = -1
リストを辞書のキーとして使いたい場合、 いちいち join して文字列にするよりも、タプルに変換したほうが速い。
dic[" ".join(seq)] = v # faster dic[tuple(seq)] = v
これらはあとで「おもちゃばこ (仮称)」に追加しておこう。 しかしなぜかさ、いつも遅いほうの書き方のほうがキレイに見えるんだよな。
weather.com に行ってみたら、つぎのようなメッセージをみかけた:
Free trial ってことは普段は金取るわけだよね…。これが商売になってしまう国アメリカって。Free Trial: Tornado Alerts by Phone!
こんなじゃいかんなー
てくるで (ところで)、さいきんなんとなく感じているこのボーー…っとした気分は、 4月の始めだからであると思われる。「4月病」とでも言うべきか。 日本では、3月の終わりから 4月の始めにかけてはなんだかいろいろゴタゴタするし、 基本的に別れの季節だし、新しい人も入ってきたり桜も咲いたりスギ花粉もあったりして 期待と緊張の日々 (?) であるわけだが、新山はこういう雰囲気があまり好きではないのだ。 なんか、ソワソワするから。この感覚はきわめて日本的なものだと思うが、 もはや「毎年この時期になるとソわそワすること」という性癖が体内にしみついているらしく、 それでいつもなんとなくボーっとしてるのかなあ、と考える。 あるいは春眠不暁覚か (てきとう語漢)。ホントヌ。
いま思ったのだがさいきん「(ナ行のほかの文字) → ぬ」という自動的脳内変換が新山においては 非常によく行われるようであ。これはふだん「ぬ」という文字を使う機械が あまりに少ないので、このたびもうすこし普及させることを (洗剤意識的に) 狙っているためだろうか??
フンヌの鬼。
まともな生活は、まずまともな食生活から。
きょうは久しぶりにブログロなことを書いてしまった。
ところで )てくるで(、なにをもって「正規の食事」を定義するのだろう…。 病院の時間にあわせれば正規の食事かな。あれが標準なのかな。 だとしたら、正規の日本人は夜かなり早くネないといけなくなるな。 もう、ぬよう。
おや、また「ぬ」だ。またぬだ。またぬがきたぞ! たろうくんとたぬろうくん。そういえばあのマンガってまだやってんのね。 こないだ 1食でその存在を確認した。つうか、google で「がんばれたろうくん」で検索すると このサイトが 4位にランクインしてしまうのだが (4年前にもオレは同じことを書いていたらしい)、 あれってそんなにマイナーなんだろうか。
生協といえば連帯ですね。
もしもっし
10.040071003 <Keyword: インターフェイス (17)> 9.53804175528 <Keyword: 自分 (741)> 8.6849994982 <Keyword: 人工無能 (5)> 8.61349595441 <Keyword: ネットワーク (74)> 8.52251070048 <Keyword: 計算機科学 (26)> 8.4427979183 <Keyword: 新山 (752)> 8.3246977399 <Keyword: 不思議な相関関係 (3)> 8.03736621691 <Keyword: 図書館 (49)> 8.0074613926 <Keyword: コンピュータ (68)> 7.98591690349 <Keyword: 言語 (283)> 7.88854254182 <Keyword: アプリケーションサーバ (3)> 7.7504210638 <Keyword: 基本的に (82)> 7.72772078649 <Keyword: 毎回毎回毎回毎回毎回毎回 (2)> 7.52182686454 <Keyword: 人間 (257)> 7.5214301973 <Keyword: スーパークリエイター (3)> 7.51863567874 <Keyword: フォント (91)> 7.35886849498 <Keyword: 過剰包装 (7)> 7.27142514538 <Keyword: 授業 (145)> 7.26639191062 <Keyword: 長野県中野市立 (2)> 7.26639191062 <Keyword: 宮沢賢治記念館 (2)> 7.19715414501 <Keyword: 自然言語処理 (16)> 7.15932250373 <Keyword: 日本 (662)> 7.14405526686 <Keyword: 名前 (151)> 7.13413230211 <Keyword: 日本語 (182)>
うーーーむ。どうなんだ? これは。いつもこういうのって、評価がわからん。 なんでもキーワードといえばいえてしまうような気がするし、 しかもちょっとパラメータを変えるとガラリと順位が変わる。こまったもんだ。
基本的なアイデアは、ウメムラ先生のところでやってる 「suffix array を使った (辞書を使わない) キーワード抽出」のパクリである。 ただし、真面目に全部の suffix を生成すると遅くってしょうがないので (全部 Python で書いているのだ)、語の境界を発見するところでは adaptation だけでなく、 「境界のあとの文字は分散しやすい」という特性も使った (このアイデアはまえ誰かに聞いたんだけど、だれだっけ)。でも、こんな方法が 本当に必要なのかどうかはナゾ。上のキーワードだって全部計算するのに 3分もかかっている。 これはひらがな文字列も単語境界として認識したかったからだが、 どーせほとんどの用語はカタカナか漢字なんだから、もっと簡単な方法でいいんではないか? ちなみに形態素解析を使う方法は、最初から考慮に入れなかった。 辞書がでかくて大げさなうえに、複合語をぼこぼこ切っちまうし、おまけに
$ echo ひらがなはむりなんだもん。 | chasen ひ ヒ ひる 動詞-自立 一段 連用形 ら ラ ら 名詞-接尾-一般 が ガ が 助詞-格助詞-一般 な ナ ない 助動詞 特殊・ナイ ガル接続 はむ ハム はむ 動詞-自立 五段・マ行 基本形 り リ り 助動詞 文語・リ 基本形 な ナ だ 助動詞 特殊・ダ 体言接続 ん ン ん 名詞-非自立-一般 だ ダ だ 助動詞 特殊・ダ 基本形 もん モン もん 名詞-非自立-一般 。 。 。 記号-句点 EOS
まあこれは ipadic にひらがなの見出し語が入ってないせいなのだが… (Juman の辞書にはちゃんと入っている)。個人的には たかが単語区切りのためだけに形態素解析を使うのは アホとしか思えない (にもかかわらず、他にまともな使われ方をほとんど されていないのだが…いったいダレのせいでしょうcaね??)。 で、ほかにも目標はいくつかあって、
どうでもいいが、MoinMoin がすげー多機能になってるのにびっくりした。 あれって、昔からあんなだったっけ?
今夜はめづらしく寒いんだよね。
ところで、新山はなぜか日本に帰ると太り、米国に帰るとやせるようなのだが (ちゃんと計測してない、あくまで推測)、これってこういうものなのかなあ。 なぜならこっちでは食い物がマズイので、調子に乗って食いすぎるということがないからである。 か?
ピーナッツのカロリーが潜在的に高いというのは、 むかし高校のときに生物の教師が授業中に実験してみせてくれてたことがある。 ようするに油分を多く含んでいるから火をつけると長時間燃えるのだ。 簡単だけど、これはカロリーとエネルギーの等価性を教えるのにいい方法だと思う。
そのあとまた棚を整理して、居間のテーブルを掃除し、 窓をあけてみると雨あがりで非常にいい匂いがした (厳密にいうと、この匂いというのは「なにかの特定の匂い」ではなく、 おそらく草木の匂いや気温、大気中のホコリや湿度による作用で鼻が感じる 「匂いといえばいえるようなもの」であると思われる、 これまた正確な言葉が見つからない)。
TODO: コーヒー豆／フィルターかうこと。
いやあ、ほんらいこのペエジはこういう生活上のメモっぽいことを 書く (はずの) 場所であったのだが、へたに抽象的なことを書くとまたアレなんだろうな (アレとはなにか言及を避ける新山)。
原則はあれから変わっていない。つねに、tangible な、実体のある、目で見えたり 手でさわれたりするもの・ことについて語ることだ。最終的にそれは自分の信仰でもある。 そして言葉にも「tangible な」領域というものがあり、 それをこえる単語は使ってはならないということなのだろう (あやしくなってきた)。 抽象的な議論を好んでする人々に“だけ”相手にされるようになったら 自分としてはおしまいだと思うので、そうならないように注意しなければ。
しかし、むかしは、西洋人って抽象的な議論が好きなのではないか? と思っていた。 でもこっちへ来てみたら感覚がちがっている。すくなくともアメリカ人は、 抽象化がスキというよりも、一般化がスキなだけのようだ。 彼らの文章の先にはいつも「具体的なもの」がくっついていて、 純粋に抽象的なことだけを語りたがる人々とは違う。でもヨウロッパ人はそうなのだろうか…? まえに (自然言語処理関係で) ドイツ留学してる人と話したのだけど、 新山が「アメリカは実用主義ばっかでときどき疲れる」といったところ、 向こうは「ヨーロッパの大学は理論的なのばっかで嫌になる」といってたな。 日本は、どっちともつかないのがいったりきたりしてる、という印象だ。
えーとえーと、これからは日本との時差は 13時間になるから、 つまり日本ではいま朝8時なわけか。
彼女はどさっと言った。
彼はぼとりと言った。
なにを言ったのか?
つまり其処には、こぼれ落ちるような重力的な言葉が在ると言う事である。
うぞぞぞぞ
しかしオレの音楽の好みって変わったのかなあ?
いま知ったのだが、「しげしげと眺める」は漢字でかくと「繁繁と眺める」になるらしい。 これ、現在では「じっと見る」のような意味だと思ったが、もともとは「頻繁に」という意味だったのね。
たぶん去年夏にきたときの 3倍くらいの時間がかかったと思う。 あきらかに外国人を入れたくないみたい。
あ〜、なんか iPod (デカい方) がほしくなってきたっ。
買わないぞ! 買わないぞ!
これは論文 (ろんぶン) が進まないのと同じことである。 よい説明というものは、あるときに「ぱくっ」と出てこないとだめで (← どう出てくるんだ? →)、 そういうひらめきがないと文章というのはいつまでたってもわかりやすくはならない (ああ、ひらがな多すぎ)。そりゃーもちろん、プログラムばっか書いてりゃ楽なんだけど、 それじゃただの駄目人間なわけよ。
新山の個人的な信念として、文章がヘタな奴はプログラミングさせてもダメだと思う (これは、よいプログラムをつくれないということだ… よいプログラムとは、問題が適切に分割され、仕事に必要な部分とそうでない部分をしっかり捉えおり、 わかりやすく直観的なロジックで書かれたプログラムのことで、 「パズル的で何やってんだかわからないが、それでも動く」プログラムは よいプログラムではない)。 米国でプレゼン能力が強調されるのは、なにも人を騙すため (だけ) ではないと思う。 人にわかりやすく説明する、しかも重要なことをごまかさずに説明するということは 結局のところよいプログラムを組むのとまったく同じことだ。プログラマの仕事とゆうのは 計算機に仕事を説明することにあるのだから…しかしまてよ。 そもそも計算機のプログラムを読むのは、ほんとうに計算機なのか? 結局のところ、プログラムは計算機を媒介にして最終的には人間に向かって語られているのではないか? ああ、これはちょっとした違いだな。つまり、プログラミングには 以下の 2つのとらえ方があるような気がする:
プログラム中のコメントで比喩を使うのは、いいことだろうか? たしか Knuth がまえにそんなことをどこかで書いていた。 新山はわりと比喩を使うほうだと思うが、 そもそもこれはふだん物事を比喩的に理解しているくせがあるからで、 使いすぎるとワケがわからなくなるし、 …何言いたいんだかわかんないのでやめる。
なぜ自然言語では obfuscated な説明のコンテストをやらないのか? もうすでにやっている、ある種の分野では…。 obfuscated なコードは、人間は誰も理解できないが計算機はできるからゲームとして成り立つのだ。 これに対して obfuscated な自然言語の説明は、宇宙の誰も理解できない。 ただの電波コンテストになってしまう。
完全に復号できたらおもしろいだろうに。
NLP理論〜概要〜 (コミュニケーション・ラボ) によると「NLP は 1970年代にカリフォルニア州サンタクルーズで誕生し、日本では 1990年代より本格的に導入された」 のだそうです。また NLP HOME PAGE によると、 「ＮＬＰは心が持つ可能性を最大限に活かすための技術」だそうです。
たかが夜間発着訓練のくせに偉そうなこと言うな!
ら、まだその時計は日本時間のままだった。
思えば先週から何回も「あとで直そう」と思いつつ、直してなかったような気のする。 ずっと 2時間ズレた時計を見てたことになるが、慣れてしまうとこれでも平気になってしまうからすごい。
今宵はネギをしょって帰ってきた。
LC_CTYP=ja_JP にすると
sort や grep に死ぐほど時間がかかってしょうがないから!
たぶん strcmp などを呼ぶごとにいちいち LC_COLLATE の順序集合をチェックしてるんだろう、
そりゃ遅いハズだ)、ぴちょん君で Unicode を表示するときに問題が生じることがわかった:
$ python -V
Python 2.3.3
$ python -c 'print unicode("あ")'
Traceback (most recent call last):
File "<string>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\u3042' in position 0: ordinal not in range(128)
$ LC_CTYPE=ja_JP.eucJP python -c 'print unicode("あ")'
あ
ascii にしてしまうらしい。
ところが、この機能は標準出力が端末のときしか適用されないみたいで、
標準出力がパイプならば ok なのである:
$ python -c 'print unicode("あ")' | cat
あ
sys.stdout.encoding が 'ANSI_X3.4-1968' になってるだ。
これが原因だ。でも、どうやって直す? 代入しようとすると readonly attribute とおこらえてしまう。
Python/pythonrun.c の Py_Initialize() 230行目〜 に
埋めこまれてるからだ。しかも、ここで使われてる CODESET なるマクロに
デフォルトのエンコーディングが入ってるらしくて、これは一体、どこで定義されてるんだっ!? と
必死になって探したがみつからず、結局これは Python の中ではなくて
/usr/include/langinfo.h なるファイルで定義されていることがわかりした。
このファイルはシステムだから修正したくないとすると、残るは pythonrun.c を
書き換えてビルドしなおすしかない。くっそー。しょうがないから、セコい方法
に書きなおすか…。敗北だ。最初からスナオにこうすりゃいいのに、 しなかったところがなおさら敗北ってる。オレってこういう失敗多いよな。alias python='LC_CTYPE=ja_JP.eucJP python'
しかし Python は初期化でトリッキーなこと (あとから変更できないような設定) をやってて好きじゃないな。
似たような例はほかにもある。sys.stdout のバッファリングを禁止する -u オプションだが、
これは frozenmain.c に埋めこまれているルーチンで、あとから呼び出せないのだ。
標準出力を一回 os.fdopen で unbuffered で開きなおしてから sys.stdout を
上書きすればできるにはできるのだけど、美しくないよね?
それにしても、すぐソースに頼るくせはやめなければならない。 大人ならドキュメントを読んでなんとかするのだ!
ところでいまふと気づいたが、西洋の「おまえはおまえ、おれはおれ」文化というのは racist であることをむしろ助長するような文化なのではないかと、なんとなく思った。
というか、いまでさえ cvs の使いにくさもじゅうぶんムカつくのだけど…。 新山が履歴管理したいと思っているデータは以下のとおりである。
基本的に、新山個人が使うぶんには branch 管理はほとんど必要ないので、 ただ履歴管理だけしてくれればいいんだけどなあ。 そもそも「リポジトリに置かれている原本を (その構造は変えずに) 修正する」って RCS 由来の哲学がどうにも大げさすぎるように思う。 だいたい最初からデータの階層構造を決め打ちにできれば苦労はしない。 そんなもの、整理していけば日々変わるのよ。 というか、cvs とかいうのは計算機科学者の独特な病気が現れたもんだと思う。 つまり連中は「木構造がやたらと好き」なので、なんでもかんでもが 木構造の枠組みにカチっとおさまっていると仮定しがちなのだ。 でも現実には、そんなことはないんだよね。
(追記 00:06、つまり「体系的にきちんと構造化されてないドキュメント集合を管理する」という 新しい観点からのドキュメント整理・管理ソフトウエアが必要なわけだ。すでに誰かやっていそうだが、 論文やプレゼン資料やプログラムなどがめたくたに入った文書集合となるとどうかな。 のっぺりしたテキストの集合に限定してなら、すでにIPAの某プロジェクトで誰かネタにしていそうだけど)
ヘンなスペイン語の電話がかかってくる。何いってんだかわからんが、 「もし言ってることがわからなければ、ここへ電話くれ」という部分だけはわかる (そこだけ英語しゃべってるから)。うちの周りはヒスパニックが多いので、 この近辺を狙った電話宣伝攻撃だと思うが、しかし何やら "Jesus Christ" といってるのが聞こえるぞ。 あやしかりける。
time.nist.gov が止まってるみたい。
おもうおもうおもうおもうおもう おもいますおもいますおもいますおもいます おもっておりますおもっておりますおもっておりますおもっております ぼかあそうはおもわないねぼかあそうはおもわないねぼかあそうはおもわないね
何かを代弁しないこと。誰にも共感されないこと。
これは孤独であるとか、異常である (?) ということを意味しない。 「そこ」に置かれているものを仮定しないということである。意味不明。
思うに、何かを誰かにかわって代弁したり、誰かに共感されはじめると その文章には期待と義務が生まれる。そんなものは生まないことだ。
(追記、「まもる」はどう考えたってひらがなのほうがいい。 「守る」ではちっともまもっているような気がしない)
今日のウラシマ効果: 地下鉄の帝都なんとかかんとか営団 (「帝都」と「営団」しか覚えてない) が 「東京メトロ」なんちゅう、対称ロマン風味の名前になったことをいまさら知った。
ってこれ、そんなに古くないのか?
新山の理想の自分像? は、あまり先例がないのでよくわからないなあ。 オレが知っている既存のどの像もいやだ。
もちろん、あなたの場合は運命というものを信じています。
ちなみに新山は、オフィスで箸を使って食っている。 日本人だらば、いついかなるときも箸ですよ! ちなみに、きのうもケーキを箸で食った。 インド文化がいかに古かろうとも箸だけは極東のほうがまさっている。 これはゆずれないね。しかも、中国の象牙バシはダメ (ワシントヌ条約定食!!)、 韓国の鉄バシもダメ (熱電導性良好!!)、日本の木製バシが 世界でもっとも先進的なマニピュレータ! なの! です。うん、これはゆずれない。 おれはアホ。
もっく、もっく、曜日、曜日、らん、らん、らん ♪
| ―― ここに 7つある曜日のうちいくつかを適用する場合、 これは「木曜日」が最適な言いかえ候補であることに注意されたい。 なぜならば、これに適用さるる曜日名はまず 2モーラである必要があり (従って火曜日と土曜日は自動的に除外される)、なおかつ 2つの音の間に 自然な促音が挿入できなければならないからである (したがって水曜日と金曜日も除外される、 「すっい、すっい」や「きっん、きっん」ではあきらかにおかしいからだ)。 すると残るは日曜日と月曜日、そして木曜日であるが、「げっつ、げっつ」は あまりにも音がキツすぎて場の雰囲気に合わない。かといって日曜日にすると あまりにも普通すぎて面白味がない。結果的に「木曜日」が最適となるのである。 Q.E.D. ―― |
The First Conference on Email and Anti-Spam (CEAS)
あとはドキュメンテーシォンがね。
目 → 皿 → 目 → 血 (ころころ)