<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Não Aqui! &#187; Programing</title>
	<atom:link href="http://www.chokkan.org/blog/archives/category/programing/feed" rel="self" type="application/rss+xml" />
	<link>http://www.chokkan.org/blog</link>
	<description>Blog presented by Naoaki Okazaki</description>
	<lastBuildDate>Mon, 10 Oct 2011 02:14:56 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>CRFツールのベンチマーク</title>
		<link>http://www.chokkan.org/blog/archives/436</link>
		<comments>http://www.chokkan.org/blog/archives/436#comments</comments>
		<pubDate>Fri, 12 Aug 2011 14:42:50 +0000</pubDate>
		<dc:creator>chokkan</dc:creator>
				<category><![CDATA[Programing]]></category>
		<category><![CDATA[Research]]></category>

		<guid isPermaLink="false">http://www.chokkan.org/blog/?p=436</guid>
		<description><![CDATA[CRFsuite 0.12のリリースに合わせて，チャンキングタスクによるベンチマークを更新しました．見所は，0.11→0.12でどのくらい速くなったのか，高速だと謳っているWapitiがどのくらい速いかです．その他，各学習アルゴリズムによる性能（学習速度，精度）差も，興味深い点かと思います．比較したツールは， CRFsuite 0.12 CRFsuite 0.11 (１つ前のバージョン) sgd 1.3 CRF++ 0.54 Wapiti v1.1.3 MALLET 2.0.6 実験では，L2正則化（C=1），L-BFGSの終了条件は直近10回の反復で目的関数の改善率が1e-5を下回ったとき，平均化パーセプトロンの反復回数は50に固定，という条件にしました． まず，CRFsuite 0.12で実装された平均化パーセプトロン（AP）は，非常に高速でありながら，L-BFGSやSGDに迫るタグ付け性能を示しています．精度はL-BFGSやSGDと比較して0.1～0.3ポイントくらい低下するようですが，学習データを１回（iteration）処理するのに要する時間は，1.7-1.9倍高速です．１回の反復に要する時間が短くなるのは，各事例に対してViterbiアルゴリズムを適用するだけで学習を進めることができ，手間のかかる対数尤度や勾配の計算を省くことができるからです．さらに，今回の実験では8回の反復でピークの性能を示したので，反復の回数を開発データセットなどでうまく調整できれば，非常に有用な学習アルゴリズムと言えます． 比較したソフトウェアの中で後発のWapitiはなかなか速いですが，一回の反復に要する時間を比較するとCRFsuiteより遅いようです．Wapitiのデフォルトのパラメータでは，L-BFGSの収束判定が非常に甘いため，30回強の反復で最適化が終了してしまいます（このため収束判定条件を統一しました）．L-BFGSのiteration回数と精度のグラフを見ていると，30回付近では精度の改善が続いているため，この段階で最適化を止めてしまうのは早すぎます．WapitiはML compで長い間最速を維持していると謳っていますが，収束判定が甘いのが主要因だとすると，利用には注意が必要かもしれません． CRFsuiteもML compにエントリーしたいのですが，系列ラベリングタスクの素性生成は各ソフトウェアに任されており，しかも，各ソフトウェアはどのタスクのデータが来たのか分からないため，有益な比較がしづらい状況にあります．つまり，与えられたデータの各列の意味がソフトウェア側からは（トリッキーな方法を使わない限り）分からないので，品詞タグ付けやチャンキングで同じ素性セットを使うことになってしまいます．さらに，素性数や学習アルゴリズム，パラメータなどで学習時間は大きく変わるので，純粋な実装の「良さ」をML compの実験環境で見積もるのは難しいと思います． CRFsuite 0.11と0.12の比較（L-BFGS学習時）では，sparse素性で1.38倍，dense素性で1.46倍の速度向上が見られました．大した速度向上ではないかもしれませんが，0.12ではソースコードの可読性・再利用性を劇的に改善したので，この結果には満足しています． Tweet]]></description>
		<wfw:commentRss>http://www.chokkan.org/blog/archives/436/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>CRFsuite 0.12 released</title>
		<link>http://www.chokkan.org/blog/archives/430</link>
		<comments>http://www.chokkan.org/blog/archives/430#comments</comments>
		<pubDate>Thu, 11 Aug 2011 05:04:02 +0000</pubDate>
		<dc:creator>chokkan</dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[Programing]]></category>
		<category><![CDATA[Research]]></category>

		<guid isPermaLink="false">http://www.chokkan.org/blog/?p=430</guid>
		<description><![CDATA[CRFsuiteのバージョン0.12をリリースしました．このバージョンは変更点がてんこ盛りです．張り切りすぎたせいで，ドキュメントの更新に手間取り，コードが出来てからリリースまで１年くらい経過してしまいました．変更点はChangeLogの通りですが，このブログではいくつか補足しながら紹介します． ソースコードの大がかりな再構成を行いました．特に，グラフィカルモデルの処理に関する部分（対数尤度や勾配の計算など）と，学習アルゴリズムに関する部分を分離しました．今回のソースコードの再構成により，新しい学習アルゴリズムの追加や，異なる形状のグラフィカルモデル（例えば属性とラベルバイグラムに対する素性や二次マルコフ素性）を追加しやすくしました．ソースコードの再構成をやるモチベーションは前々からあったのですが，@yuutatさんの「Fast Newton-CG Method for Batch Learning of Conditional Random Fields」の研究に混ぜて頂いたのをきっかけに，コードの大がかりな修正を行いました．新しいグラフィカルモデルを追加したり，ヘッシアン・ベクトル積のDPによる計算を追加することには，まだ未着手ですが，そのための基礎を固めました． ソースコードを綺麗にしたついでに，平均化パーセプトロン，Passive-Aggressive，Adaptive Regularization of Weights (AROW) の学習アルゴリズムを追加しました．学習アルゴリズムは，-aオプションで指定することになりました．学習アルゴリズム毎のパラメータの一覧は，-Hオプションで見ることができます． ソースコードの見直しを行っているときに，「あー昔は理解が足りず無駄な計算をしているなぁ」と思うところがいくつかあったので，その部分を修正しました．日記で書いていたSSEのexp計算ルーチンも取り込まれています．これらの修正により，だいたい1.4～1.5倍速くなりました．新しいベンチマーク結果を載せておきました． 系列の開始（BOS）と終了（EOS）の素性を自動的に生成するのを廃止しました．以前のCRFsuiteでは，BOS，EOSという特殊なステートを定義し，そのステートから各ラベルへの遷移素性（バイグラム素性）を作っていました．考えてみたら，系列の先頭と末尾にEOS/BOSを表す属性を追加すれば十分だったので，BOS/EOSに対する特殊なコードを削除しました．BOS/EOS素性を作りたいときは，各インスタンスの先頭と末尾のアイテムに，&#8221;__BOS__&#8221;や&#8221;__EOS__&#8221;みたいな属性を追加してください． いくつかの学習パラメータの名前が変更になりました．重要なところでは，&#8221;regularization.sigma&#8221;が&#8221;c1&#8243;及び&#8221;c2&#8243;になりました（c1 = 1.0 / regularization.sigma; c2 = 0.5 / regularization.sigma^2）．これにより，L1正則化，L2正則化が同時に使えるようになりました．L1正則化，L2正則化をOFFにするときは，それぞれ&#8221;c1&#8243;，&#8221;c2&#8243;を0にセットしてください（sigmaによる設定だと無限大にする必要があったので，cによる設定に変更しました）． 交差検定（cross-validation）やテストセットによる評価（holdout-evaluation）を，データセットにグループ番号を割り振ることで実装しました．学習と同時にテストセットで評価を行うには，複数のデータセットをCRFsuiteに入力し，どのデータセットで評価を行うのか，グループ番号を指定します．交差検定を行うときは，N個のデータセットを明示的に与えるか，-gオプションを使い入力されたデータセットを自動的にN分割すればOKです． データセットのフォーマットに関するドキュメントを書きました．データフォーマットはCRFsuiteの特徴の一つでもあるのですが，ユーザからの質問が多いので，きちんと書くことにしました． これまでは，#でコメントを書くことを許していたのですが，自然言語のテキストから属性を作るときにうっかりと&#8221;#&#8221;を使ってしまうトラブルが起きそうなので，廃止しました． 予測されたラベル系列の条件付き確率（-pオプション）や，各ラベルの周辺確率（-iオプション）を出力できるようにしました．これらの機能には多くの要望が寄せられました． CRFsuiteのC言語APIを大幅に改訂しました．ライブラリの名前はlibcrfからlibcrfsuiteに変更になりました．ライブラリが公開している関数名は，&#8221;crfsuite_&#8221;という文字列から始まるようになりました．C言語のAPIドキュメントを書きました． CRFsuiteのライブラリを簡単に使うために，C++のラッパー（crfsuite_api.hppとcrfsuite.hpp）を書きました（C++/SWIGのAPIドキュメント）．さらに，C++のAPIをSWIGを経由して他の言語から呼び出せるようにしました．手始めにPythonのモジュールを構築し，学習とタグ付けがPythonから行えるようになりました．モジュールのビルド方法はREADMEを参照してください． CRFsuiteに与えるデータセットを生成するためのサンプルスクリプトを改良しました．チャンキングのサンプル（chunking.py）は，わかりやすい属性名を出力するようになりました．また，CRFsuiteのPythonモジュールを利用して直接タグ付けを行う機能も実装されました．CRF++互換のテンプレートを処理するためのスクリプト（template.py）を追加しました．その他，固有表現抽出（ner.py），品詞タグ付け（pos.py）のサンプルも追加しました．これらのサンプルを改変するだけで，CRFsuiteを新しいタスクに適用できると思います． メモリリークを何点か修正し，メモリ使用量を若干削減しました． モデルファイルが存在しないときに落ちる問題を修正しました． Tweet]]></description>
		<wfw:commentRss>http://www.chokkan.org/blog/archives/430/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>exp(x)の高速計算 ～実験編～</title>
		<link>http://www.chokkan.org/blog/archives/352</link>
		<comments>http://www.chokkan.org/blog/archives/352#comments</comments>
		<pubDate>Thu, 02 Sep 2010 14:24:55 +0000</pubDate>
		<dc:creator>chokkan</dc:creator>
				<category><![CDATA[Programing]]></category>

		<guid isPermaLink="false">http://www.chokkan.org/blog/?p=352</guid>
		<description><![CDATA[最後に，の計算がどのくらい高速化できたのか，実験してみました．アルゴリズムとして，以下のものを比較しました． libcのexp関数 パデ近似を用いたもの（cephesの実装に近いです） ５次～13次でテーラー展開を0を中心として行ったもの ５次～13次の最良多項式近似をの範囲で行ったもの ５次～13次の最良多項式近似をの範囲で行ったもの ５次～11次の最良多項式近似をの範囲で行ったものをSSE2で実装したもの SSE2の実装で11次で打ち止めしているのは，11次と13次で演算精度の差が殆どないことが分かり，単に実装するのが面倒くさかったからだけです．0を中心としたテーラー展開や，最良多項式をの範囲で構成する手法は，の値を切り下げではなく，四捨五入（つまり0.5を足してから切り下げる）で求めます（Wapitiやsse_mathfun.hのexp計算ルーチンは四捨五入を使っています）． 実験では，0を平均としたガウス分布で乱数を10,000,000個発生させ，その値のexpを全て計算するのに要する時間と，libcの演算結果を正しいものと仮定したときの誤差を測定しました．実験環境は，Intel(R) Xeon(R) CPU 5140 (2.33GHz) 上でDebian Linuxを動作させたアプリケーション・サーバーです．gccのバージョンは4.1.2で，コンパイルオプションは「-O3 -fomit-frame-pointer -msse2 -mfpmath=sse -ffast-math -lm」です．実験に用いたコードは，こちらからダウンロードもしくは閲覧できます． 横軸に計算時間，縦軸に誤差のRMS（二乗平均平方根）をプロットしたものを示します． 縦に一本線が入っているのが，libcの計算時間です．これを基準に誤差を測定しているので，エラーは０です．この線よりも左側に入っていないと，高速化の意味が無いことになります．各アルゴリズムは，左上が５次の多項式近似で，右下に向かって７次，９次，11次，13次と，精密かつ遅くなっていきます．だいたい，あたりで計算誤差の改善が止まっています．これは倍精度浮動小数点の有効桁数である16桁と大体一致しています． 計算精度に着目すると，テイラー展開 &#60; 最良近似式 [-0.5, +0.5] &#60; 最良近似式 [0, log 2] という順で，どの近似式も次数を上げていくと，付近まで誤差が改善します．ただ，アルゴリズムをＣで実装してしまうと，libcと比較しても大した速度向上が得られません．5次まで近似精度を落としたとしても，２倍程度しか速くなりません．libcのexpの実装も相当に高速化されているので，一筋縄ではいかないようです． これに対し，アルゴリズムをSSE2で実装したものは，４倍～８倍程度高速化されています．しかも，計算精度はSSE2化していないものとぴったり一致しているので，計算精度を犠牲にすることなく，高速化が達成できたことになります．を大量に計算する状況では，11次の最良近似式を用いたSSE2ルーチンを使えば，演算精度を落とすことなく高速化できますし，近似式の精度が低くて良ければ，次数を下げてさらに高速化できます．次期バージョンのCRFsuiteでは，その他の改良も含めて，SSE2ルーチンを搭載する予定です． Tweet]]></description>
		<wfw:commentRss>http://www.chokkan.org/blog/archives/352/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>exp(x)の高速計算 ～SSE2実装編～</title>
		<link>http://www.chokkan.org/blog/archives/340</link>
		<comments>http://www.chokkan.org/blog/archives/340#comments</comments>
		<pubDate>Thu, 02 Sep 2010 14:04:49 +0000</pubDate>
		<dc:creator>chokkan</dc:creator>
				<category><![CDATA[Programing]]></category>

		<guid isPermaLink="false">http://www.chokkan.org/blog/?p=340</guid>
		<description><![CDATA[exp(x)の高速計算 ～理論編～ の内容を元に，SSE2で実装してみます．ここからは，SSE2に関する基礎知識が必要になるのですが，すべて書くのは面倒なので，簡単にまとめると， SSE2では，倍精度浮動小数点の２個の値に対して同じ演算をすると速い． 現在のIntel CPUでは，SSE専用のレジスタ（128bit）が8個ある． 加減乗除の算術演算や，ビットシフトなど，殆どの命令がSSE専用に準備されている． メモリとSSE専用のレジスタ間でデータ転送を行うときは，メモリアドレスが16バイトでアライメントされている必要がある（厳密には「すべき」という言い方が正しいが）． C言語のソースコードの中でSSE用のコードを手っ取り早く書く方法は，コンパイラのintrinsicを使う方法．Microsoft Visual C++とgccでほぼ完全な互換性があるのが嬉しい． コンパイラintrinsicは，アセンブラではないので，自分が意図したとおりの最適化コードが生成されるとは限らない．一応，コンパイラが最適化して速いコードを生成することになっているが，実際はそう上手くいかないことの方が多いので，コンパイル後のアセンブラコードを確認する必要がある． SSEは，かなり昔にへるみさんのページで勉強しました．大体感触を掴んだら，MSDNのドキュメントなどを見ながら，コンパイラintrinsicを書けば，そんなに難しくないと思います． SSEの命令を並べるときは，命令のロード・演算・ストアのパイプライン処理を頭の中で考えるべき． だいたいこんな所ですかね．先ほどのexp(x)の計算ルーチン（５次最良多項式近似）をSSE2で書くと，こういうコードになります． #include < emmintrin.h > #ifdef _MSC_VER #define MIE_ALIGN(x) __declspec(align(x)) #else #define MIE_ALIGN(x) __attribute__((aligned(x))) #endif #define CONST_128D(var, val) \ MIE_ALIGN(16) static const double var[2] = {(val), &#8230; <a href="http://www.chokkan.org/blog/archives/340">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
		<wfw:commentRss>http://www.chokkan.org/blog/archives/340/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>exp(x)の高速計算 ～理論編～</title>
		<link>http://www.chokkan.org/blog/archives/320</link>
		<comments>http://www.chokkan.org/blog/archives/320#comments</comments>
		<pubDate>Thu, 02 Sep 2010 14:01:26 +0000</pubDate>
		<dc:creator>chokkan</dc:creator>
				<category><![CDATA[Programing]]></category>

		<guid isPermaLink="false">http://www.chokkan.org/blog/?p=320</guid>
		<description><![CDATA[ロジスティック回帰やCRFなどの対数線形モデルの学習でよく出てくるのが，expの計算です．これをSSE2を使って高速化するのが，今回のテーマです．まずは，背景の理論を説明します． まず，指数関数を２の指数関数に変換することを考えます（なぜ２の指数関数かはいずれ分かります）． 両辺の自然対数をとり，について解くと，．IEEE754など，２を基数とした指数部を採用している浮動小数点形式では，整数に対してを容易に構築できるので，上式の実数解の代わりに整数， を用い，の大まかな値を計算することを考えます．ただし，はを超えない最大の整数を表します． さて，をで近似したときの誤差の範囲は，．誤差にを乗じたものを，と定義すると， 上式の両辺の指数をとると， ここで，はを超えない最大の整数なので，の値域は，． これらのことから，は以下のステップで計算出来ることが分かります． を計算する． を計算する． を定義域において，テーラー展開もしくは最良近似多項式などで近似計算する． 浮動小数点形式を利用してを構築し，との積を計算する． ステップ1は簡単そうに見えますが，負の数を整数にキャストすると，0に近づいてしまうことに注意が必要です．つまり，doubleからintへのキャストは，正の値は切り下げ，負の値は切り上げになってしまいます．このことに注意すると，このステップは次のように書けます（a &#60; 0で，ifによる分岐を作らないのが賢いやり方）． a = LOG2E * x; a -= (a < 0); n = (int)a; ステップ２はそのまま書けばOKです． ステップ３では，を多項式に近似します．多項式近似というとテーラー展開が一般的ですが，「･･･点の周りについてテーラー展開すると」という表現の通り，ある点の近傍の近似は良いのですが，そこから離れた点では近似精度があんまりよくないという欠点があります．Cephesというライブラリでは，パデ近似（Padé approximant）を採用していますが，除算を１回だけ行う必要があります．最近のCPUは速くなったとはいえ，SSE2で倍精度のパック除算（DIVPD）をやるのに必要なレイテンシ・スループットは，70・70で，倍精度のパック乗算（MULPD）の7・6と比べると，除算が圧倒的に遅いことになります．そこで，今回は最良近似式を用います．なにやら難しそうに見えますが，Sollya というソフトウェアを使えば，簡単に最良多項式が求まります．以下の例では，の範囲で，５次の最良多項式を求めています． > remez(exp(x), 5, [0, log(2)]); 0.99999989311082729779536722205742989232069120354073 + x &#8230; <a href="http://www.chokkan.org/blog/archives/320">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
		<wfw:commentRss>http://www.chokkan.org/blog/archives/320/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>SimString (類似文字列検索ライブラリ) 1.0 released</title>
		<link>http://www.chokkan.org/blog/archives/285</link>
		<comments>http://www.chokkan.org/blog/archives/285#comments</comments>
		<pubDate>Sun, 07 Mar 2010 14:28:38 +0000</pubDate>
		<dc:creator>chokkan</dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[Programing]]></category>
		<category><![CDATA[Research]]></category>

		<guid isPermaLink="false">http://www.chokkan.org/blog/?p=285</guid>
		<description><![CDATA[SimStringという類似文字列検索ライブラリをBSDライセンスでリリースしました．類似文字列検索とは，文字列集合（データベース）の中から，クエリ文字列と似ているものを見つけ出す処理です．コンピュータは，正確に一致する文字列を探すのは得意ですが，表記揺れに出くわすと，途端に対応できなくなります．例えば，「スパゲティ」に対して，レストラン情報などを返すサービスにおいて，「スパゲッティ」や「スパゲティー」などの表記揺れが検索クエリに与えられると，通常のデータベースでは情報を提示することが出来ません．類似文字列検索を用いると，表記揺れが検索クエリに与えられても，「スパゲティ」という既知語を代替クエリとして提案したり，「スパゲティ」の情報をダイレクトに引き出すことができるようになります． 似てる語を探す技術って，文字列処理の基本中の基本で，自然言語処理では当たり前のように使われていてもおかしくないと思うのですが，研究ではほとんど見かけません．２つの文字列が与えられたときに，似てるか似てないかの識別する研究は，色々あるのですが，ある文字列が与えられたときに，どの文字列が近いかを高速に収集する方法は，あまり見かけません．検索エンジンを提供している会社では，検索クエリログに基づくクエリ訂正などを行っていますが，検索クエリログは誰でも入手できるわけではありません．類似文字列検索は，データベースやデータマイニングの分野で盛んに研究がされていますが，単語や用語レベルの文字列が簡単に扱えるツールが見つからなかったので，自分で作ってみました． SimStringは，「文字列集合の中で，検索文字列との類似度がある閾値以上のものをすべて返す」という処理を高速に行えるように設計されています．類似度関数としては，コサイン係数，ジャッカード係数，ダイス係数，オーバーラップ係数をサポートしています．類似度を計算するときの文字列の特徴として，文字Nグラムを採用しています． 例えば，3グラム（N=3）を用いたとき，「スパゲティ」は「＄＄ス」「＄スパ」「スパゲ」「パゲテ」「ゲティ」「ティ＄」「ィ＄＄」と表現されます．このとき，文字列の先頭と末尾を表す特殊な記号「＄」が挿入されていますが，これを用いるか用いないかはカスタマイズ可能です（デフォルトでは用いないことになっている）．また，Nグラムの単位（すなわちNの値）も，自由に設定できます．また，日本語などのマルチバイト文字でも正確にNグラムが計算できるように，ユニコードをサポートしています． SimStringは，類似文字列検索を正確に，かつ高速に行えるように設計されています．Google Web 1Tコーパス の英単語（13,588,391文字列）から，コサイン類似度が0.7以上の文字列を検索するのに必要な時間は，１クエリあたり平均 1.10 [ms] 程度です． 実装はC++で，ヘッダファイルをインクルードするだけで他のアプリケーションに組み込めるようになっています．また，PythonとRubyのSimStringモジュールも，ビルドできるようになっています．他言語のモジュールはSWIGを用いてラッパを自動生成しているので，Perlなどの言語にも対応できるはずです（ビルド報告，サンプルプログラムなど歓迎致します）．Pythonで類似文字列が一瞬で検索出来るなんて，楽しい世界が広がると思いませんか？ $ python Python 2.5.1 (r251:54863, Oct 15 2007, 23:38:19) [GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import &#8230; <a href="http://www.chokkan.org/blog/archives/285">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
		<wfw:commentRss>http://www.chokkan.org/blog/archives/285/feed</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>SQLite3のINSERT文を高速化</title>
		<link>http://www.chokkan.org/blog/archives/250</link>
		<comments>http://www.chokkan.org/blog/archives/250#comments</comments>
		<pubDate>Wed, 07 Oct 2009 14:04:53 +0000</pubDate>
		<dc:creator>chokkan</dc:creator>
				<category><![CDATA[Programing]]></category>

		<guid isPermaLink="false">http://www.chokkan.org/blog/?p=250</guid>
		<description><![CDATA[こちらのFAQを参照．小ネタですが，以前に１回調べて，また忘れていたので，メモ． Tweet]]></description>
		<wfw:commentRss>http://www.chokkan.org/blog/archives/250/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Classias 1.0 released</title>
		<link>http://www.chokkan.org/blog/archives/246</link>
		<comments>http://www.chokkan.org/blog/archives/246#comments</comments>
		<pubDate>Sat, 26 Sep 2009 17:49:52 +0000</pubDate>
		<dc:creator>chokkan</dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[Programing]]></category>
		<category><![CDATA[Research]]></category>

		<guid isPermaLink="false">http://www.chokkan.org/blog/?p=246</guid>
		<description><![CDATA[Classiasという分類のための機械学習アルゴリズムの実装を公開しました．今のところ，L1/L2正則化ロジスティック回帰（最大エントロピー法），L1/L2正則化L1損失線形カーネルサポートベクトルマシン（SVM），平均化パーセプトロンをサポートしています．学習アルゴリズムとしては，平均化パーセプトロン，L-BFGS法，OWL-QN法，Pegasos，Truncated Gradient（L1-FOLOS）を実装してあります．カーネルは使えませんが，線形識別モデルを高速に学習できるようになっています．二値分類，多クラス分類，候補選択（明示的に与えられた候補の中からスコア最大のものを選ぶタスク）をサポートしています（SVMは今のところ二値分類のみ）． このツールはもともと，最大エントロピー法を自分で使うために実装したもので，作り始めてからもう２年くらい経過しています．去年のColingやEMNLPの論文の機械学習の箇所は，このツールで実験しています．文字列による素性，自動分割交叉検定など，自然言語処理の実験に便利な機能に重点を置いて作ったつもりです．詳しくは，使い方を参照してください． ソースコードも，インスタンスのデータ構造，損失関数，学習アルゴリズムなどのコンポーネントを，C++テンプレートクラスとして実装するという設計になっています．L-BFGS法を実装しているlibLBFGSを除けば，ヘッダファイルをインクルードするだけでClassiasを利用したプログラムが書けるようになっています．クラスリファレンスやサンプルコードはドキュメントを参照してください．新しい学習アルゴリズムも，簡単に追加できるようになっているのですが，ドキュメントをもう少し充実させていかなければなりません･･･． LIBLINEARやLIBSVMと一緒にrcv1.binaryでパフォーマンスを測ってみました．まず，分類精度に関してはロジスティック回帰とL1損失SVMに大差がなく，平均化パーセプトロンはちょっと悪いという予想通りの結果で，Classias，LIBLINEAR，LIBSVMのどれも同程度の分類精度を出しています． 学習速度に関しては，LIBLINEAR速すぎです．L1正則化のロジスティック回帰ではそれほどスピードの差はありませんが，L2正則化のロジスティック回帰では，LIBLINEARの方が４倍くらい速くなっています．アルゴリズム的には，L-BFGS法と信頼空間ニュートン法の戦いで，後者はヘッシアンを使っているので，速くなるのも頷けます．ただ，収束の判定条件が違うと思うので，後できちんと検証してみようと考えています． SVMに関しては，LIBLINEARの圧勝（LIBLINEARの方が10～20倍高速）でした．ClassiasのPegasosも健闘していますが，学習率や収束判定の調整で10～20倍の速度差を埋められるかは疑問です．Dual coordinate descentはやっぱり強いですね．こちらも後で実装して遊んでみたいです． 実装するといろいろ分かることがあるので，これからも実験しながら育てていきたいと考えています． Tweet]]></description>
		<wfw:commentRss>http://www.chokkan.org/blog/archives/246/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>CRFsuite 0.9 released</title>
		<link>http://www.chokkan.org/blog/archives/234</link>
		<comments>http://www.chokkan.org/blog/archives/234#comments</comments>
		<pubDate>Thu, 24 Sep 2009 10:55:38 +0000</pubDate>
		<dc:creator>chokkan</dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[Programing]]></category>

		<guid isPermaLink="false">http://www.chokkan.org/blog/?p=234</guid>
		<description><![CDATA[CRFsuite 0.9をリリースしました．libLBFGS 1.8と組み合わせてビルドすることが出来なくなっていたので，その問題の修正のみです．また，試験的にLinuxバイナリの配布を始めてみました．libLBFGSと静的にリンクしてあるので，このバイナリを落として実行するだけで動くはずです． いろいろやっていたら，もう２ヶ月も経っていた･･･． Tweet]]></description>
		<wfw:commentRss>http://www.chokkan.org/blog/archives/234/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>CDB++ 1.1 released</title>
		<link>http://www.chokkan.org/blog/archives/229</link>
		<comments>http://www.chokkan.org/blog/archives/229#comments</comments>
		<pubDate>Mon, 13 Jul 2009 17:05:48 +0000</pubDate>
		<dc:creator>chokkan</dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[Programing]]></category>

		<guid isPermaLink="false">http://www.chokkan.org/blog/?p=229</guid>
		<description><![CDATA[CDB++のバージョン1.1をリリースしました．こちらも，libLBFGSで大変お世話になっている今道様からパッチを頂きました． 一つ目はgotoを使っていたためのコンパイルエラーの修正です．よく「gotoは読みづらくなるから使うな」という主張を見かけますが，私はエラー時の終了処理など，用途がはっきりしている場合は積極的に使うべきだと考えています．error_exitみたいなラベルを付ければ，エラー時の処理内容が分かりやすくなりますし，何重にもネストしたループから脱出する場合も，gotoを使わないとロジックが分かりづらくなります． ただ，C++では変数の宣言が関数内の何処にでも書けるという仕様から，gotoの使い方が難しくなります．具体的には，次のようなコードの場合です． // Processing #1... if (error_condition_1) { goto error_exit; } // Processing #2... if (error_condition_2) { goto error_exit; } // Continue the procedure... int variable = foo(...); return true; error_exit: // Error handling... return false; このコードでは，error_exitにジャンプしたときに，variableの値が不定になるので，たとえerror_exit以降の処理でvariableを参照しなくても，gccのバージョンによってはコンパイルエラーになります．このミスは今までも何回かやっていたのですが，ついつい忘れてしまうんですよね．C++ではやっぱりgotoは慎重に使うスタンスが安全なのかもしれません． また，ハッシュ関数をSuperFastHashからMurmurHashに置き換えました．私はこのハッシュ関数を知らず，これも今道さまに教えて頂きました．MurmurHashはSuperFastHashよりも２倍くらい高速だと謳われていて，コードもすごくシンプルです．「むらむらハッシュ」ってすごい名前だなぁと思っていたら，「multiply + &#8230; <a href="http://www.chokkan.org/blog/archives/229">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
		<wfw:commentRss>http://www.chokkan.org/blog/archives/229/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

