コンピュータ: 2007年11月アーカイブ

メモリを2GB載せたマシンにUbuntu Linuxを入れていたのですが、どうにも最近メモリが安く、しかもそろそろ下げどまるという雰囲気があるらしいのでメモリを2GB(1GB * 2)追加購入しました。生まれて初めてバルクに手をだして、2200円 * 2。
何に使うのかと聞かれると、あって困ることはないでしょと答えるくらいですかね（´ー` ;）
意味がある使いかたとしては、Virtual Machineにメモリをたくさん割り当てられるとか。

で、合計4GBのメモリになったわけですがfreeしてみると以下の結果。

pascal@Ubuntu:~$ free
             total       used       free     shared    buffers     cached
Mem:       3565924    1674116    1891808          0      75944    1025592
-/+ buffers/cache:     572580    2993344
Swap:      4923912          0    4923912

3.56GBしかないよ〜。マザーボードは8GBまで対応してるらしいし、BIOSでも4GB認識しているので、OSのせい。
調べてみると、@ITでの質問が見つかり、すっきりしました。

32bit OSでは32bitのメモリで4GBまでしかメモリを認識できませんが、PAE拡張を含んだカーネルだと64GBまで扱えるようになります(トレードオフとして多少メモリアクセスが遅くなる)。だけど僕の使ってるカーネルはPAEに非対応だったので全体で4GBまでしか使えず、さらにアドレスの最後の方はOSの他の部分のために予約されちゃってます。

この理解で合ってるかな…。

とりあえず、時期を見て64bit OSに入れ替えようかと思います。緊急性は非常に低いけども。

まともに読んでいないのでリンクだけです。
ちょっと草植えときますね型言語 Grass

関数型のトンデモ（？）言語としては既にUnlambdaが不動の地位を築いていたりするのですが、ネタ言語としてはこれもそれなりにアリかもしれません。理論的側面、関数型言語としての美しさから言えばやっぱりUnlambdaには大きく劣る感じがしてしまいますが…。

ところで、UnlambdaもGrassも(あとWhite Spaceも)文字は3種類です。もっと減らすことはできないだろうかと思ってみると、3種類の文字を2種類の文字2文字でエンコードすることができるので「一応」2種類まで減らせますね。

しかし、Unlambdaの場合は意味があるので言語の目的からして3つより減らすデメリットが大きいし、Grassはvを除いてしまったときに雑草としての見栄えが悪くなってしまう(解釈されない文字にvを混ぜてもいいですが)。またWhite Spaceも言語の目的からして代表的な空白文字の「Space, Tab, LF」のいずれも削れないわけです。

いずれの言語も独自の美学に従っているに違いないと思ったわけです（どんなまとめかただ

CNETの記事によると、現在アメリカで開かれているカンファレンスSC07で"量子コンピュータを使った画像認識プログラムのデモ"が行われるらしいです。日本語訳されていました。

ずいぶん懐疑的な目で見られていて、"量子もつれができてなくて古典コンピュータと一緒じゃないの、古典コンピュータでも同じ結果が出ると思うよ"なんてのも記事に載っています。今まで検証可能な形で情報を外に出してこなかった会社らしく、信用もないのかな。タイトルに「グーグルの」とありますが、これも会社としてではなくて社員の一人が絡んでいるという話のようです。

ある程度のサイズの量子FFTを実装したのでそれを使って認識させました！とかならまだありそうな話ですが、そういう流れでもないみたいだし…。
発表はアメリカで11月12日の19時(日本では13日の午前9時であってるかな)かららしいので、すごかったら続報が来るでしょう。僕は専門家じゃないのでアレですが、この盛り上がらなさからいって期待できないんでしょうか…。

昔書いたぷよぷよ on Javascriptが晒されているのを久しぶりに見つけたのでメモ。
もう4年少し前になるんですね。Short Codingの技法も、当時のものが残っているとはいえずいぶんと変わったものです。
教えてくれた毛つこさん、ありがとうございます。

当時作ったぷよぷよの最新版はここに晒していますが、現代の職人さんたちが工夫を凝らしたらもしかしたら7行に納まっちゃったりするのかもしれません。

C言語限定になるとさらにすごいhackが山のように見つけられているのですが、それに関してはShort Coding 〜職人たちの技法〜が非常に参考になると思います。もちろん他の言語に関しても、Short codingの技は発展しています。腕に自信のある方はCode Golfに参戦することをおすすめします。いや、時間を食うので本当のところはおすすめできません。

//

この機会にみなさんにお聞きしたいのですが、七行プログラミングスレを最初に立てた「トリッキーの１」さんをご存知でしょうか。軽く探しています。身近、せいぜい2hopにいると思うのですが。

以前書いた記事の内容がようやく僕のアカウントでも使えるようになりました。
確かに挙動が劇的に速くなっています。ただ、記事にあるような0.2秒でのレスポンスがどうかというと0.2秒よりはちょっと遅いかな…。今回接続したサーバまでは片道8msecだったので、サーバまでの距離が原因ではなさそう。というかprefetchするとのことなのでサーバまでの距離は関係ないかな。

firefoxが遅いことが多いうちの環境のせい、という可能性もありますが、ちゃんと調べていません。

＃前回の記事からreferしていたOfficial Gmail Blogは現在見られなくなっていますねー。

Google、中国版トップページのデザインをYahooに習う？というなんとも興味深い記事。
実際に中国のGoogleトップページを見てみると、SimpleなGoogleのトップページではなくYahoo likeなページになっていることがわかります。記事によると「試験的なもの」らしいですが、どうなるんでしょう。

中国ではBaidu(百度)に負けているGoogleですが、BaiduはGoogle likeなトップページなんですよね。似た形式で勝負したら、mp3の検索ができるBaiduと勝負するのは割にあわない…と考えたのかどうかは定かでは ありませんが。さすがにGoogleがmp3検索をサポートすると非難轟々でしょうしねぇ。

調子が良いことがわかれば、他の国でもテストしたりするのかもしれません。
もし採用するにしても、あの会社のことだからもともとの形式をユーザが選べるようにするような気がしますが。

とりあえずいろいろな憶測はさておいて、「中国でなんらかのテスト中である」というのに留めておくのが一番誤解のない情報です。

ちょっとエントリにするのが遅れましたが、大規模日本語 n-gram データの公開というエントリがあがっています。
データの入手方法に関しては言語資源協会のサイトにあります。

さすがに無料で配布ではないですが、値段としては手が出しやすいのではないかと。僕は言語屋さんではないので手を出しませんが…。

残念ながら見られなかったのだけれど、Finalがすごかったらしい。URLだけメモしておきます。

http://d.hatena.ne.jp/u-no/20071102#1194014571
http://starlancer.org/~ysn/jpcoder/
http://www.topcoder.com/tc?module=MemberProfile&cr=22652597&tab=alg

xhl氏が日本人最高ratingを塗り替えまくっているようです。

昨日はICPCアジア地区予選のClosing Partyを抜けて高校の同級生2人と飲んできました。
高校を出てから6年近くも経つとすでにいろいろな分野に人が散っていて、会社で仕事をしている人もいれば自分で会社を作っている人もいたりします。そんな人から○○について話したいって言われるのは僕がすごいわけじゃないので役得でラッキーだなぁと思っていて、そんなわけで呼ばれたら必ず行くようにしています。

こちらとしても知らない分野の教養を得ることができたりコンピュータ科学な方面から話をしてみることができたりしてかなり面白いです。

//

さて今回は同期でSEO(Search Engine Optimization)の会社をやってる社長なのかな、の人と飲んできました。正直spamとかSEOとかは好きじゃなかったりするのですが、そっちの業者の視点から見ると今まで考えたこともなかったような話があって面白いです。自分でSEOとかはやりませんが…SEOサイトが好きじゃないってのもあるし、いろいろと立場もあるし。

一番印象的な会話は以下のもの。
「1ヶ月で、1日5000アクセスを稼ぐサイトを作るにはどうしたらいいと思う？」
「5000アクセスは難しいなら、100アクセスならどうする？200アクセスならどう違う？」

さてどうでしょう。SEO業者の一番興味のあるところであり、GoogleやYahooで既に対策が取られているとニュース記事なんかで噂されているいくつかのページランク評価式も納得がいきました。
そのほかにもSEOでの将来像なんかを聞き、納得することが多々ありました。彼も生活がかかっているので本気です。「黎明期はうまくいくけど、今後とも努力に見合った成果が出る保証はないよ」とは伝えておきましたが。当面はSEOをやるみたいだけど、そのうちまた新しい黎明期の何かに突っ込んで行くんじゃないかなと思います。

上にも書きましたが、僕は「情報は欲しいときに欲しいものがあるべきで、情報の発信者がその情報の価値を好きなように変動させるべきではない」と感じています。要するに「宣伝ばっかりなのはウザイ」。そのせいで、どうやってSEOを行うかという問題を全く考えたことがなかったために目から鱗な飲み会になりました。ありがとうー。

今年のアジア地区予選東京サイトは東京大学がホスト校だったこともあり、お手伝いをしてきました。
去年は選手として参加させて頂いたわけですが、Staffの立場から見るとコンテストの姿が全く違って見えるのに驚きました。

本大会は上位陣の抜きつ抜かれつのデッドヒートで大変盛り上がりました。本当に最後まで勝負がわからない大会で、歓喜したチームもあれば思わぬ展開に涙をのんだチームもあると思います。まだ正式には決まっていないと思いますが、勝ち上がったチームは来年3月頃にカナダで行われる世界大会まで是非しっかりと力をためてください。惜しくも出られなかったチームも、あの場所で勝負できたことは貴重な体験だと思います。是非今後に生きるといいなぁと思う次第です。

結果についてはまだ公式サイトにはあがっていませんが、2ちゃんねるのスレッドに何やらそれっぽい順位が載っていたりします。


Staffの方や参加選手、コンテストのスポンサーをしているいろいろな会社の方など、普段は距離が遠かったり会う機会がなかった人たちと久しぶりに会えて楽しい時間でした。作業は正直きつい日もありましたが、やっぱり参加してよかったなと思います。
みなさん、本当にお疲れさまでした。

とりあえず、チューリングマシンの説明(By Wikipedia)。

様々な情報がありますが、とりあえず簡単にまとめます。

• 内部状態が2通り、テープに書き込む記号が2通りの万能チューリングマシンが存在しないことは以前から知られていた
• 内部状態が2通り、テープに書き込む記号が3通りのチューリングマシンをStephen Wolfram氏が提案し、万能チューリングマシンであると予想。証明に25kドルの懸賞金をかけた。
• 懸賞金がかかってから47日後、イギリスの大学生が証明を発表[pdf]。見直しの後正しい証明として公認されたらしい。
• しかし、後に証明の誤りが発見されたらしい(指摘のメール)。

「証明された」との記事がWIRED VISIONにあがっています。
また、これに基づいてスラッシュドットジャパンでも同様の記事が書かれています。
しかし、これらの記事が書かれたのは指摘のメールが届く前です。現在最新の情報は、「証明に誤りが見付かった」ということでいいと思います。

ぶっちゃけ面白そうだけどついていけません（´ー` ;）
メーリングリストへの投稿と、本家スラッシュドットへの書き込みがおそらく参考になると思います。

2007年のICPC世界大会出場記がpublicになったので晒してみます。

これに関連して、高校生のときに作った問題を6年ぶりに思い出しました。ICPCの問題にしばらく触れていたこともあり、プログラミングコンテストっぽくアレンジ、美しい問題ができあがりました。難易度はかなり高いような気がしています。作成者本人でも3時間ほどかかりましたが、美しさが尋常ではないのでOB/OG会の将来の問題候補としてsubmitしてみました。

いきなり僕の想定解法にたどり着くには結構ぶっ飛んだ数学的考察が必要だと思うので、プログラミングコンテストには不向きな気はしたのですが…。

http://japan.cnet.com/marketing/story/0,3800080523,20359549,00.htm
線で繋げばいいじゃん、無線を使えばいいじゃん、という日常のレベルからは大きく外れた将来像を描いています。

現在でも「大容量データなら、インターネットでデータを送信するよりもバイク便でHDDを送る方が早くて確実」なんて話をすることがありますが、ハイスループット、ハイレイテンシという情報通信方法が現実のものになるのでしょうか。
考えてみると、惑星間の通信では惑星の位置関係によっては直接の通信ができない時期がでてくるのは当然ですね(間に太陽があると直接は無理だと思われる)。途中でどこかの惑星を経由させて無線で通信は将来的には可能だと信じていますが。

ただ、当初の惑星間通信のバックボーンは宇宙船に頼る可能性が高いように思いますが、長期的に見るとやはり光速で通信できる無線に軍配があがるような気がします。あの会社のことだから、どちらが主流になろうと食いついていきそうな気がします…。

Ubuntu May Be Killing Your Laptop's Hard Drive
Ubuntu Linuxをバッテリーで使用しさらに消費電力を抑える設定にしていると、電源管理部分のバグでハードの寿命を縮めるんだとか。既にfixが出ている模様。

タイトルがキャッチーで秀逸。

重要メールフィルタを作れば？って話を見て面白いなーと思いました。僕は重要っぽいメールから順番に読んでいくしね。
上のほうに重要なのがずらずら並んでいれば、手間がほんの少し省けるかも。ベイジアンなら小数の値が得られるから順序付けも簡単。そもそも既に迷惑メールフィルタが実装されているので、重要メールフィルタもただ単に「やってみる」という点では技術的には難しくないはず。既にやってるかもしれませんが。

…といいたいところだけど、Gmailの強みである「全員のメールの状態から学習させる」ってのが使いにくいかな。「重要」の指標は「迷惑」の指標と違って人によって違うから。
3人いるだけで

• AはBより大事
• BはCより大事
• CはAより大事

っていうことが簡単に発生するし、人数が多ければもっと大規模に発生するだろうし。
でもそのうちなんとかなればいいなぁと思ったりします。

//

Official Gmail Blogが更新されてたので簡単にまとめ。

IMAP対応を打ち出したばっかりだけど、またGmailに機能を追加するよ！メールの検索をブックマークできるようになったり、新しいキーボードショートカットが実装されたりするよ！

あと、メールが表示されるまでの時間がちょっと長い気がしたから、コードをばっさり書き換えて高速化するよ！メールのprefetchとかをするようにして、今まで1秒くらいかかっていた表示までの時間を0.2秒以内に抑えるつもりだよ！

FirefoxなんかのGmail Extensionを使ってる人には申し訳ないけど使えなくなるかもしれないよ。でも事前に著明なFirefox Extension作者には情報を教えてるから、新しいバージョンが出ないかどうかチェックするといいよ！ごめんね！

だそうです。0.2秒ってあたりは完全にデスクトップアプリと速度の勝負に入ったということかなと思います。ほんのわずかな違いでも速度はやっぱり大事で(時間が惜しいからって理由ではなくてね)、もっさりしてるなぁという点の解消は大いに期待したいところ。

今回はガワのインターフェースが大きく変わることはないようです。あんまり変えるとユーザビリティ下がるしねー。

先のエントリにも書いたように、CPANのmoduleそのままではHTMLのscrappingをやると日本語環境で問題が起きます。また、日本語環境では動かないという報告はちらほら見かけるものの、動かしたとか使ったという報告は見かけませんでした。
なので、cpanのmoduleをちょっとだけ変更してちゃんと動くようにしてみました。これでいくらか便利になるかな？

perlのモジュール化をまともに触ったことがないので、パッチをあげるのはその辺をしっかり理解してからにします。
数日以内にしたいなーと思っています。

修正箇所などの詳細は続きからどうぞ。

scrapping: HTMLなんかから必要な箇所の情報だけを抜き取ること

もちろん正規表現を使ってごにょごにょと俺はなんでこんなことをやっているんだ的な時間を過ごせば解決することではあるんだけども、それだとWebサイトがちょっとデザイン変更しただけであっという間に使えなくなってまたごにょごにょといじらなきゃいけなくなってしまう。

…ってのはさんざん言われてる話なので解決策は既にいくらでもあるものだと思っていたんだけど、「cpanからモジュールを入れたそのままの状態では」日本語が使えないなどの点からなかなかうまい方法が見付かりませんでしたよという話。見落としてるだけかもしれないけどね。

以下、試してみたperlのCPANモジュール。

• HTML::TokeParser
• HTML::TokeParser::Simple
• HTML::Parser
• HTML::Parse
• HTML::DOM
• HTML::TreeBuilder::XPath
  

【鉄道】1文字分のミスで大トラブルに　首都圏改札機トラブル[07/10/28]
一般アプリケーションのバグの原因がここまで詳細に記されているのは見たことがなかったのでちょっと面白かったです。プレスリリースが詳しいと末端にまで詳しく情報が伝わることもあるんだなぁ。

…普通の人がどこまで理解するかは不明ですが。

現在使用しているUbuntu Linuxにはデフォルトのデスクトップ検索がついていたのだけれど、検索が非常に遅いだとかインターフェースがなんだかなぁとかいうのがあって、Google Desktop on Linuxを使うことにしました。

で、問題点を見つけたのでメモ。
画像を検索したときに、見付かった画像へのリンクと画像のサムネイルが表示されるのですが、サムネイルが別のファイルのものになっているケースがままあります。印象では2%くらいかな。
どうしてこういうことが起きてるのか、とりあえず考えられる原因列挙。

1. なんらかの外部要因でキャッシュが壊れちゃった。
2. 確率的にそういうことが発生することを許す代わりにインデックスサイズを小さくしている。 なので仕様。
3. バグ。

さぁどれだ！

もっと大きな問題があって、自動的にindexを作っているときに稀に暴走？してメモリを1.5GBくらい食ってしまったりします。こういうときにはkillしてやるしかない(GUIから止めても暴走しつづける)ので、それが原因でキャッシュが壊れている可能性もあります。

問題点以外で言うと、Windows版みたいにデスクトップガジェットがあったほうが遊べそうな気がします。

きまぐれ日記、最速インターフェース研究会(1)(2)より。
Bloom Filterという確率的アルゴリズムの見本みたいなアルゴリズムがありますよー。というお話。

一番上のリンク先が詳しいと思いますが、

• ハッシュはよく使われる
• アルゴリズムが超簡単
• パラメータ調整ができ、消費メモリ量の削減を比較的正確に見積もれる

ってあたり、人を魅きつけるものがあるんだと思います。