トピックモデルを試そうとgensimのLdaModelを使ってみたのですが、参考にした記事「LSIやLDAを手軽に試せるGensimを使った自然言語処理入門」は対象とするgensimのバージョンが古いようだったので、現状にあうようアレンジして試してみました。この記事で使ったgensimのバージョンは0.11.1です。 過去のgensimと今のものとでは、メソッド名等の命名規則が変わっています。旧来はcamel caseでしたが、今は小文字とアンダースコアの組み合わせになっています。たとえばnumTopicsという名前付き引数はnum_topicsに変わっています。 それ以外にも多少の違いはあるのですが、yuku_tさんのgistのコードを今のバージョンのgensimで動くように修正したのが以下になります。 WikiCorpusクラスにはsaveAsTextと等価なメソッドが今は存在しないので、個別にDictionaryとCorpusをファイルに出力しています。 生成されたモデルをもとにLSI, LDAモデルを作成する流れは、メソッド名等を(たとえばPrintTopic→print_topic)書き換える点以外は元記事とほぼ変わりません。 また、LDAモデルの生成をマルチコアで実施するgensim.corpura.LdaMulticoreというクラスも用意されています。worker=2等とワーカースレッド数を指定できる点以外はLdaModelクラスと同じです。しかし、あまりよくスケールするわけではないようで、CPU論理コア数8の環境でworker=7としてみても対して速度が上がることはないようです(参考:Multicore LDA in Python: from over-night to over-lunch)。一応workerプロセスは指定しただけ起動はするのですけど。加えてマルチコアで処理した場合、出力されるログが少なくなって進捗状況がわかりづらくなるようです。 ところで以前書いたword2vecの記事でgensimのword2vecでのマルチスレッド動作について書いていなかったので、同様にworkerスレッド数を指定できることを追記しておきました。 また、Google C言語実装のword2vecのマルチスレッド処理について一つだけ気になるところがありました。それは、単純にファイルをバイト単位でスレッド数に分割し、処理している点です。単語の区切りを一切考慮しないので、その箇所がたまたま単語の途中であってもお構いなしに処理を進めてしまいます。 もっとも、出現頻度の少ない単語は捨てられるので、実用上問題になることはほとんどないはずではあります。運悪くUTF-8の途中で切られてしまい、なおかつ語彙として記録されてしまうと、gensimで読み込もうとするときにInvalidUnicodeErrorが発生してしまうので、その点だけは気を付ける必要があります。

以前から注目しているソフトウェアとして、LanguageToolがあります。Javaで書かれた文法チェッカーで、コマンドラインやFirefoxアドオン、Libre/OpenOfficeのプラグインとして動作します。 以前簡単な紹介をおこなったり、使い方をDoc-ja Wikiに書いたりしてみました。このころはversion 2.6でしたが、現在の最新版は2.9です。 残念ながら、日本語の対応状況については今も芳しくありません。日本語のルールの数はslideshareの資料では23種類でしたが、version 2.9の段階では43種類と増えてはいるものの、まだまだ不足している状態です。 単語ベースでのルールも少ないのですが、コードベースで対応すべきケースについては現状皆無です(https://github.com/languagetool-org/languagetool/blob/master/languagetool-language-modules/ja/src/main/java/org/languagetool/language/Japanese.java)。 先日、こちらにコードを追加しないと対応できなさそうな実例が出てきたので、それを考えてみようと思います。 以前grammer.xmlのプルリクエストを送った時は、パッケージ全体をビルドする必要がなかったので、ビルド環境がそろっていなかったことに気付いていませんでした。 ビルドにはmavenが必要なので、Debian wheezy上でapt-get install mavenを行ってbuild.shをたたいてみたのですが… JVMが古すぎると怒られてしまいました。ということでsid環境で試したところ、無事ビルドできました。続きは明日の東京エリアDebian勉強会でもやってみようと思います。

ここのところKAKASIのコードをいじっています。昔から再実装したいと考えていたのですが、コードを十分理解していない部分もあったので、目視でソースを見ながらエディタで書き写す「写経」的なことをやってみました。 写経の過程でいくつかの潜在的なバグが発見でき、本体にコミットすることもできました。内容は以下です。 ee2.c:E2alphabetのn[1].c1をゼロクリア g2.c:g2jにおける出力先の変数の間違い それ以外にもいくつかコミットがありますが、直接的なバグではないもの(即値の代入、不適切なマクロ定数の利用、実害のないロジックミス)ばかりです。 それ以外にも問題はありましたが、それらは修正に関して検討が必要なものだったので、Tracにチケットを作る程度にとどめています。 写経したKAKASIのコードも一応gitにおいてあります。ただし動作検証は行っていません。あくまで実験として行ったものです。環境変数で辞書のディレクトリを指定すればおそらく動作はするはずです。 作業に関して、ソースの可読性を高めるため以下のことを念頭に行いました。 K&Rスタイルの廃止 単純なマクロ定義だった定数をいくつかenum化 配列定数として埋め込んでいたいくつかのテーブルを外部ファイル化 文字エンコーディング定数でマジックナンバーだったものをマクロ化(dict.cのみ) CMakeの採用 特に文字エンコーディングがらみはかなりわかりやすくなったのではないかと思います。旧来のコードの一部を引用してみます。 ESC $ BというのはISO-2022-JPでG0をJIS X 0208に指定するためのエスケープシーケンスですが、これをマクロで以下のように書き換えました。 コメントがなくても意味が理解しやすくなったと思っています。まだ道半ばではありますが、ゆくゆくはfrom scratchなコードを起こしたいと思っています。