スラッシュドット・ジャパン

Linux等で日本語入力のソフト等を色々なレイヤーで協調して開発ができてるうちに開発者の誰かが日本OSS貢献者賞(参考)を取れたら良いなあなんて思ってたのですが、結局、誰も受賞しないうちに現役開発者と呼べそうな人がほとんどいなくなってしまっているのが現状だと思います。
実際のところ、審査に関わられたmatz氏の日記によると、ビジネス的な側面も求められるようで、さもありなんという感じです。

...という感じで残念と思ってたところで、anthyをバックエンドに使ってくれているSocial IMEがネットランナーの賞を受賞したというのを知って、ちょっとうれしかったです。

#IPAのOSSなんとかによる頭越しの"標準化"に嫌気がさしてinput methodsの周辺から逃げてしまった身としては色々申し訳なく思う今日この頃です。(2004年頃のフレームワークがどうとかの時は対立を辞さなかったのですが…)

Tx: Succinct Trie Data structureというライブラリのサブセットをCで書いてみました。rx-0.1
Txより良い点や今後の見通しがあるわけではないですが、色々と勉強になって面白かったです。

追記：構築の時にメモリをバカ食いするのを修正したrx-0.2に更新しました。trieの実装で素直に長さ256のポインタ配列を使ってたのが原因です。trieを使うのを止めて構築を高速化するのと、pop countで遊んでアクセスを高速化することぐらいが次のネタでしょうか。

最近、youtubeのJennifer ESLで英語の練習をしています。
特に発音のレッスンは長年適当に発音してた音を学びなおすことができて良い感じです。

何気なくLinux conferenceのcfpを見てたら「自然言語処理: SocialIME、Anthy、ChaIME など」とあって当惑。
まあ、深く考えずに書いたであろうところを深読みしてもしょうがないのでスルーですかね。

あとこのストーリーで内定を取り消された人が自分の友人であることに気付いて愕然。

自分も含めて以前にオープンソースのソフトウェアを書いていた人たちで自分たちの書いたソフトウェアの性質について議論する機会がありました。その場のメンツの書いたソフトウェアの特徴として(1)Computer Science系の手の込んだアルゴリズムとデータ構造を持ち、その部分は開発に参加する敷居が高い。(2)それらのソフトウェアの出力は比較的エンドユーザに見える形で利用される。このような特徴を持ったソフトウェアの開発には往々にして周辺を肥大化させてコアのメンテナンス性を悪化させる方向に圧力がかかってしまうという傾向があるんではないかという話がありました。

コアをいじる側の人間としては、自分のバックグラウンドと小難しい技術を振りかざして周辺の開発者を妨げるような最悪最低なことはしたくありませんし(そんなことするぐらいならどこか別の所へ行くべきでしょう、特にこれはオープンソースの話ですし)、周辺の開発者も悪意があってやっているわけではないはずです。
とは言っても、コアの側への理解の無い人間がフレームワークとか言ってたり、予算を取って(コアのメンテナンス性を犠牲にした上で)コアの部分以外で色々な成果っぽいものを出してたりすると、もっと適切なバランスはないものかと考えてしまいます。

ここ数年、手帳に フェルテ5を使ってたんですが、去年まで黒かったのが微妙な色になってしまったので フェルテ4を買ってきました。一日分のスペースが小さくなってしまってるんですが、普段はpost itにラクガキしてベタベタ貼って使うだけなので問題ない感じです。

(内輪向け連絡：僕のもう一方のblogを読みたい人は連絡plz)

何かに勝利するって話じゃなくて、Computer Science系の話です。

以前のエントリで紹介した論文「Scaling to Very Very Large Corpora for Natural Language Desambiguation」のFigure 1の右の方で最高の性能を出しているWinnowって手法を知らなかったんですが(他の3つは知ってたんですが)、Winnowのわかり易い解説を見つけました。
理論的な方まで追うと他のものよりも大変そうですが、コードを書くレベルでは驚くほど簡単な手法に見えます。
anthyの最近のはMemory basedのclassifierを使ってて、Social IMEとかで使ってるものにはvotingを追加してみたりしてますが、将来に検討するようなことがあればこの辺のアルゴリズムもアリな気もします。

古いネタ帳が出てきたので、面白いのを引用。多分、自作

• 割の合わないギャンブルを繰り返すと、次に賭けるものが無くなる。金とか信頼とか若さとか。
• 自分の潜水能力を超えた深みに挑んではいけません。
• ハッカーと墓守は発音が似ている。
• ヒューリスティクスは漬物みたいなもので、主食にしてはいけません。
• 尻拭いは事が終わってからやるべし。
• 明後日の選挙は明日の国政を左右する重要なものです。
• 組織内でのリーダーシップは全体の目標に対して各人が効果的に行動できることを目指すが、アマチュアでのフリーソフト開発のリーダーシップは各人の目標に対して各人が良い成果を出すことを目指す。
• 冷や飯アラカルトを食わす。
• 払うべきツケが多すぎて、何のツケを払っているのかわからない。
• トイレで手を洗わないのは勝手だが、手を洗えないトイレを設計することは許されない。
• 素人に手術されたくない、せめて手を洗え。
• 虎穴に入ったら虎のクソ発見。
• 組織の名前を変えるのがjob rotation。
• 少しのハッタリはプラスだが、あんまり多いとモラルハザード。
• 心配事を列挙してくれるのは良いんだが、一番心配すべきことが抜けててイヤだ。
• ホウキに跨ることと、それで空を飛ぶことの間には大きなギャップがある。

なんか中二病っぽいですね。

統計的手法を使って良い結果を得ようとする場合、サンプル数で精度を稼ぐ方法とより良い手法の選択をする方法が考えられると思いますが、この辺のトレードオフを説明しても理解してもらえないことが多いので、ちょっとたとえ話を考えてみました。

一定額の元手から年10万円を稼がないといけないというシチュエーションを想定します。
元手が10万円しかないのであれば、運と技と手間が必要でリスクは高いですが価格変動の大きそうな株の短期的な売買をするというような手を思いつきます。もし100万円あればリスクの高めな投資信託等を利用すれば、それなりの確率で目標が達成できるかと思います。 1000万円の場合は国債を買って寝ていればokのはずです。1億もあれば、その辺の銀行で定期預金にすれば十分でしょうか。普通預金でも十分かもしれません。

このような感じで、入力(統計処理のサンプル or 元手)が大きければ大きいほど安易な手法で安定して同じ結果を出すことができるようになると考えられます。また、ソフトウェア等の場合、失敗してもリアルマネーが無くなるわけではなく、開発者のリソースが捻出できる限り手法の選択や実装の詳細をリトライすれば良い成果が出てくることもあるかと思います。
まあ、自分的に最重要なのは、リスクを取ったり工夫したりするのは疲れるからそんなにやりたくないというところですね :-)

内輪向けで発表した資料で2007年のinput method 10大ニュースです。選び方が偏ってるのは自分でも認識してます。あと、開発者ネタは削除してます。