C++で wstring を使って2バイト文字と1バイト文字を統一的に扱うには, mbstowcs(3) を使って const char * から wchar_t * に変換して, wstring に 格納するのが普通なのだと思う。 さらに iconv(3) で明示的にコード変換をする手もあるが, そこはロケールにお任せ することにして, wstring には EUC がそのまま入っているのだと思っていた。 ..ところが, wchar_t「あ」の中身を表示してみると, A4A2ではなく, 42 30という 謎のコードが。泉谷君に相談して二人で調べてみると, どうも wchar_t の中身は いつの間にかUTF-16になっているらしい。(!) 検索してもそんな話は全然ないし, mbstowcs(3) の中にも書いていないのですが, ロケールは入力コードを指定するために使われるのであって, 内

STLで文字列やベクトルを走査する時, 一番素直には, イテレータを使って string::iterator it; for (it = s.begin(); it != s.end(); it++) ; /* do something */ のように書けばいいが, これは終了条件で s.end() を毎回呼び出すので遅くなり そうに見える。これを回避するためには, 少し工夫して string::iterator it, end; for (it = s.begin(), end = s.end(); it != end; it++) ; /* do something */ とすればいい.. のだが, 煩雑になるので, 速度が上と一体どのくらい違うのかが 気になっていた。 いっそのこと速度を気にするのであれば, イテレータを使うのをやめてしまって const char *cp, *end

前に日記で書いた, 自己組織化二分探索木であるSplay Treeは struct splay { splay *left; splay *right; void *item; }; というデータ構造を持っているため, データ構造へのポインタのきっかり3倍の 記憶容量を必要とする。 順番は多くの場合関係ないので, こうした動的なデータ構造には本来ハッシュを 使えばいいはず だが, 普通のハッシュでは不要なメモリが沢山確保される可能性があるため, スプレー木を使っていた。 ハッシュテーブルが1つなら大した問題ではないですが, テーブル自体が何万個も あったりすると, そのロスは膨大なものになります。 最近, 開発環境をCからC++に変えたため(理由はそのうち), Googleの提供している Memory-efficientな Google Sparse Hash が使えるようになったので,

無事に発売されました。めでたい。 2007年2月号の「統計科学のすすめ その1」でも興味深い記事がいくつも ありましたが, 今回はモデレータの伊庭さん Good Job で, (僕の記事は置いておいて) 全体にさらに内容が豊富で面白くなっていると思います。 「個性をとらえる」ことのできる統計モデルというのは一般にはあまり 知られていないかもしれないですし, 多分僕も含めて研究者が読んでも色々得られるところがあるような気がします。 伊庭さんの巻頭言(特に最初と最後)はもとより, 田邉先生のメタな話, それから 最後のブックガイドの所に写真が入っているのがいいですね。 僕の原稿は伊庭さんからいただいたタイトルはこの日記の通り, 「生きたことばをモデル化する」だったのですが, 最後に編集部の要望で 「言葉」に直すように押し切られてしまって, 今でも激しく後悔。 本文の冒頭も下の画像のように本当は

Bessel関数について調べていて(言語学を突きつめるとベッセル関数に至るって どうよ..), 三井造船昭島研究所 で, 水面に波で自由に文字が描ける技術 [PDF] が開発されているのを知った。 面白すぎ。 *1 希望の合成波形が t=t0で得られるように, 波形を逆算して複数の造波器で波を生成するのだそう。 今回の技術のポイントは, 極座標(r,θ)で表示した波形関数をrとθに関して 級数展開する代わりに, 「集中点」を造波するような, 第1種と第2種Bessel関数を使った級数展開を考えて, 文字を点の集まりとして描画することで, 造波器の数を増やさなくとも 複雑な文字を波で表現できる, ということらしい。 こういうのを見ると, 日本の技術は世界一yyyyyyyyyyy! とか思ってしまう。(笑) 言語の人には僕も含めてあまり馴染みがないですが, ATRで聞いた話では, 音声の方では

zsh for the working researcher * Daichi Mochihashi daiti-m@is.aist-nara.ac.jp April 30, 1999 0. はじめに Unixに代表されるコマンド入力型の文化は世界の一つの側面であり、シェルはその 顔です。シェルに打ち込む文字列は言語に似て、一次元の記号列でありながら 豊かなイメージを持ち、多くの仕事を行うことができます。私はMacintoshが 大好きですが、GUIだけでなくそのような文字列によるシステムの操作にも ある種の美を感じ、また便利でもあると思っています。 したがって、システムとのコミュニケーションを豊かにするためには、その顔である シェルで表現できることを増やさなければなりません。多くの人は, (t)csh, あるいは bash を使っていると思いますが、このドキュメントではそれらの上位互換の

計算機上で何かちょっとしたメモを取りたいとき, Windowsで暮らしている人は 紙copi(Lite) を使えばいいのですが, Unixでは使えません。 委細かまわずChangeLogメモに全部書いてしまうという手もありますが, 検索する必要があるので, 技術的なメモはそれだけまとまっていると便利だと 感じることがあります。 ATRに移ってから, 技術メモは適当なファイルに書き足していたのですが, そろそろ限界を感じてきたので, 環境が新しくなったのを機会に, 昔使っていた postit.el に戻してみました。 Postit.el(上の画像。クリックで拡大) は昔に玉越君が書いて, NAISTにいた時は僕もずっと使っていたものですが, Emacsのバージョンが上がったので使えないかと思い込んでいたら そのまま変更なしに動くことを発見。めちゃめちゃメモが使いやすくなりました。 m でメモ

電通大の情報理論の 韓太舜先生 の最終講義が3月にあって, スライドが ここから 見られるのを知った。 院生のときに 『情報と符号化の数理』 (岩波書店 応用数学)を読んで, その明晰な内容と込められた哲学に感動した ので, 感慨深いです。 16ページ目の内容が本当なら, Weber-Fechnerの法則が理論から導けるという ことなのだろうか.. フルテキストは1975年なので, 閲覧制限がかかっていて見れないのが残念。 他も, 全体的に非常に興味深いのですが, とりあえず最後がワラタ。(笑) 論文の準備のためにPPM,PPM*,CTWなど圧縮関係の論文を(完璧ではないと 思いますが), 色々読んでみた。 PPMについては, 北先生のところで1998年に, PPM*を使った言語モデルの話 が出ています。 さて, PPMは岡野原君が 言語モデルと 似ている という話を書いているのですが,

グラフィカルモデル等で, 数式(変数)の入った図を書く必要のある ことがよくあると思います。 前に DMの論文 を最初に見た時に, かなり頑張って描いているなあと思ったのですが, ちょうど査読をしていて同じような図に出会ったので, ちょっと紹介。 もうご存知の方は飛ばして下さい。 上は確かIllustratorで描いていると聞いた気がするのですが, こういう数式の入った図は, Tgif2tex を使うと綺麗に描くことができます。 Tgifを使って hoge.obj として図を描いた後, % tgif2tex hoge.obj とすると hoge.tps (文字)と hoge.dps (図)ができるので, hoge.tps の方を \input{hoge.tps} で取り込みます。 *1 これは要するに, 図を文字とそれ以外に分けて, 文字の部分を \put{} の中に入れて LaTeXで処

10日ほど有休を使って休暇を取っているので, 前から気になっていた, Masanao Aoki and Hiroshi Yoshikawa, "Reconstructing Macroeconomics : A perspective from Statistical Physics and Combinatorial Stochastic Processes", Cambridge University Press, 2006 [amazon] を買って, 最初の方を読んでみた。 これは前に 菅原さん とメールのやり取りをしていた時に出てきた本で, 今季の東大経済の 講義 のテキストにもなっているようだ。 二人分のPrefaceを読んで, 1章のIntroduction(20数ページぐらい)が10章分のまとめ になっているので, 数日かけて読んでみた。 内容が凝縮されている上, 経済の専

研究上必要があって, 前々からずっと気になっていた, SleatorとTarjanの スプレー木(Splay Tree) [LINK] を実装した。 スプレー木は「自己調整(自己組織化)二分木」ともいわれる通り, 頻度の高いアイテムをアクセスの際に木の上の方に自動的に持ってくることで, 高頻度なアイテムへの高速なアクセスを実現する順序木。 自然言語の文字列や単語列の頻度は偏りや Power law の固まりなので, 非常に適している と思う。 かつ, 最悪の場合でもスプレー木は 全体を通して, O(log n) のアクセスを提供することがわかっている。 トライを表現するデータ構造としては, 松本研的には Double Array や その実装である Darts がすぐ思い浮かぶと思いますが, Double Array は既に固定されたトライには高速にアクセス できるものの, 新しいノードの

モデルなどの名前に "model.9" "model.10" .. などと数字を付けることは クラスタリング等でよくあると思いますが, この間IWSLT関係の仕事で, "model.0"〜"model.19" という名前がついたファイルを, それぞれ "model.1"〜"model.20" にリネームする必要があった。 こういう複雑なリネームには, Camel Book のP.426にあるperlの万能スクリプト rename を使って for f in model.*; do rename 's/\.(\d+)$/".".($1+1)/e' $f done とすればいいですが(マニアック!), 実は上のファイル名グロブ "model.*" は普通は 文字列としてソートされるため, "model.1" "model.10" "model.11" .. "model.2" のように展開され

Guy Lebanon が, ACL/COLINGとほぼ同時期にやっていた UAI 2006 で, "Sequential Document Representations and Simplicial Curves" [PDF] というのを出しているようです。 これは, 文書をbag-of-wordsのように1つの多項分布(単体上の一点)で表現 するのではなく, 単体上の連続的な曲線(軌跡)として表現する, というもの。 具体的には, 文書のある時点 t での単語の出現(1/0)をスムージング係数 c で ラプラススムージングした分布を, smoothing kernel で畳み込むことで単語単体上に カーブを形成する。 *1 smoothing kernel というのは要するにハミング窓みたいなもので, 文書の長さを1に正規化して考えると, ベータ分布を使うのが一番自然で, 論文では裾