Podcastle の講演

聞いてきました。

Podcastleぐぐると、まだ「もしかして」が出てしまう。がんばれ!

さて、内容ですが興味のあった音声認識は全体の1/4位で、サーバーありのクライアントありのプロジェクトの総括ありの、もりだくさんはいいけど少し希薄になってしまった。もうちょっと時間あったら良かったですね。認識まわりはざっくり、本当にざっくり説明されただけでちょっと消化不良。やっぱり懇親会行けば良かったかな。どう考えても激しくがんばらないと作れないはず(と思っている)の音声モデルに対して、言語モデルが単純な単語 bigram というのは変にアンバランスな気がしたわけですが。世の中そんなものなのか。「それ bigram と精度変わらないよ」なんだろうか。

それから、皆さん激しくプレゼンがうまい。とりわけ brazil さんは口を開くたびに大爆笑だった。いや、プレゼンがうまいんだけじゃなくて普通に話すのがうまいんだ。あの周到な用意ぶりと聴衆へのリードの取り方は見習うものがある。

個人的におもしろいというか、気になったのは、実用的なアプリケーションに仕上げるときには、すごく些末な問題がたくさん発生するということ。とりわけこうした問題の場合、未知語の処理をどうにかこうにかするのが大変そうだ。未知語だらけのテキストを分かち書きするのも大変だろうし、とりわけ音声に応用すると読み方を推定しないといけない。固定されたデータと固定された正解セットで実験しているといろいろ忘れてしまう問題を見直さないと。

標準入出力を使おうという話

ひととおり C++OCaml やらでちょっと重めのプログラムを書いて、さて Web 経由で公開しちゃうぞとか思うと、はてどうやって JavaRubyPerl から呼び出していいものかというはなしが出てきて、外部プロセスは重い(特に係数データを読み込んだりすると)、libXXXX はたるい、localhost に通信はだるい。現実的には libXXX なんですが、ohkura に「ライブラリがセグフォると、プロセスごと落ちるよ」といわれて、それもいかんなぁということになりました。OCaml でライブラリ作る気になれんし。

そこで標準入出力を使いましょうということです。標準入出力が使えない言語なんてない!(たぶん) 要は、50万棋譜のときにやったのと同じで、1行入力したら1行出力するようなプログラムにしておく。あるいは、1入力単位を読み込んだら、それに対する1出力単位を出力する。全部読まないで処理するのがポイント。そして、呼び出し元のスクリプト言語からプロセス作って、標準入力にデータを流して標準出力からデータを読み込む。これだけ。エラーが起きたら(おそらく落ちたため)、一度殺して、プロセス再起動。簡単かつ堅牢です。中断処理とかしたくなると標準入力の監視スレッドを作ったりと、少しめんどいですが、極端なはなしプロセスごと殺して再起動すればいいですし。

続きを読む

なんで Wii を買ったかって?

プレゼン用リモコンにするために決まってるじゃないか!

BlueTooth アダプタを買ってきて、つなげたら一瞬で動いてしまった。お手軽。今年加速度センサ付き入力デバイスが流行るかもね。IR センサも動くようだが、発光側が PC とつなげられないので自前で作るなり何なりするらしい。早速 ysn が作ってしまった。仕事が早い。

さて。動いたのはいいが本当に使うかと言われると・・・。