OSXでText.RegexにUTF8な文字列使うとエラーでるっぽい

regex - Matching specific unicode char in haskell regexp - Stack Overflow

みたいです。実はこれと同じような状態で、Localeだけja_jp.UTF-8だけどUTF-8担ってるからいいのかなあと思ってたけどダメだった。 今回は特定の文字で文字列を分解するためだけに使ってたので諦めてsplitパッケージを使いました。 これから使うような状況になったら困るから解決法を調べたい

OSXでHaskellとMeCab

ハマったのでメモ。(割りとどうでも良い落ちだったのでアレ)

困った

環境: OSX10.9.4 + GHC7.8.2 + MeCab0.996(HomeBrewでインストール) + cabal1.20.0.2 (問題のプロジェクトはCabal sandboxにインストールしています。)
発生した問題: mecabを使ったプロジェクトでcabal install するとリンク中にエラーが発生する

Linking dist/dist-sandbox-e0def0a9/build/command-line/command-line ...
Undefined symbols for architecture x86_64:
  "_mecab_get_all_morphs", referenced from:
      _cfSP_info in libHSmecab-0.4.0.a(MeCab.o)
  "_mecab_get_lattice_level", referenced from:
      _cfFl_info in libHSmecab-0.4.0.a(MeCab.o)
  "_mecab_get_partial", referenced from:
      _cfW9_info in libHSmecab-0.4.0.a(MeCab.o)
  "_mecab_get_theta", referenced from:
      _cfCP_info in libHSmecab-0.4.0.a(MeCab.o)
  "_mecab_set_all_morphs", referenced from:
      _cgo1_info in libHSmecab-0.4.0.a(MeCab.o)
  "_mecab_set_lattice_level", referenced from:
      _cfXT_info in libHSmecab-0.4.0.a(MeCab.o)
  "_mecab_set_partial", referenced from:
      _cfU5_info in libHSmecab-0.4.0.a(MeCab.o)
  "_mecab_set_theta", referenced from:
      _cfEc_info in libHSmecab-0.4.0.a(MeCab.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
cabal: Error: some packages failed to install:

このエラーがいまいちよくわかってないのでなんとも言えないのですが、いろいろやっているうちにHaskellMeCabパッケージにあるversionを使ってみると0.97が帰ってきて、意図的にインストールした0.996とは違うのでどこかに別のMeCabがあるのではないかと思っています

なおった

cabal installするときに、使いたいMeCabのあるディレクトリを渡してあげないとダメなようです。とりあえずこれで解決しました。

cabal install mecab --extra-include-dirs=/usr/local/Cellar/mecab/0.996/include/ --extra-lib-dirs=/usr/local/Cellar/mecab/0.996/lib/

これで動作するようになってからversionを見たら0.996となっていたので、どこかに前なんかやった時のゴミが残っててそれを見に行ってしまってたようですが、そのごみがどこにあるのかわからないので気持ち悪いです。 ひとまず解決。よかった。

追記:

実際謎なので気持ち悪さが残りまくる。
追記2:まとめ

まとめ

FFIを使って他の言語のコードをリンクするようなプロジェクトの時はできるだけextra-lib-dirsとか渡したほうが面倒は少ないかもね(なげやり)

Yesodで部員管理用Webサービス作った

作ったのは結構前のことですが、書くのがいまさらになったのでメモ。
Yesodはじめてみました - haru2036のブログ
でYesodが意外としっくりきたことを書きましたが、そのままYesodで行ってみました。
私の部活はソフトウェア研究部とかいう名前のくせに部員の管理はExcelでやるとかいうとってもしょぼい感じだったので、それよりはマシかと……部員の登録から所属に合わせたメールの一括送信までを今のところサポートしています。
リポジトリはこちら:
haru2036/Member-Manager · GitHub

Yesodはじめてみました

これまでWebアプリをまともにやったことなかったので、どうすればいいのかわからなかったのと、FlaskとかRoRとか触ってみてもなんかしっくり来なかったので、ヤケになってHaskellのWebフレームワークであるYesodを触ってみました。
YBlog - Haskell web programmingを参考に最後の簡易ブログのところまでと、Yesod.AuthのGoogle認証を使った認証までを試してみました。
テンプレート言語であるhamlet自身とそのとHaskellコードの対応に若干戸惑いましたが、それなりに行けたのでもしかしたらこれがこれまで触った中で一番しっくり来る可能性が……
あとWebアプリに手を出さなかった最大の理由である怖いという理由も払拭してくれそう(デフォルトでXSSとかに対してかなり強いらしい)のでもうちょい触ってみるかなー

長門のやつの精度測定用関数を書いた

書きました。
とりあえずComplementと普通のやつに両方分類させて精度を測定します。
今masterにマージしました。
テスト用データはCSVで定義。
テスト用でーたを用意するのがめっちゃ大変だということに気づいてしまって戦慄している。

HaskellとMeCabで長門(その3) : Complement Naive Bayesもやってみた

結局やろうやろうおもいつつ全然やってなかったの続き。

今回は学習時の文書量に差があるときに効果を発揮するというComplement Naive Bayesを実装してみました。

どんなの

調べると、
新はてなブックマークでも使われてるComplement Naive Bayesを解説するよ - 射撃しつつ前転
をみつけました。

  1. そのクラスに属さない文書を使って学習
  2. そのクラスに属さない確率を計算
  3. その確率が一番低いクラスに分類

という、ほぼすべてをひっくり返した方法らしいです。これにより、学習時に文書量の多かったクラスにたくさんの単語が含まれていることにより、全体的な確率にばらつきが出てしまうことが防げるらしいです。

というわけで既存の分類器をあまりいじらずに出来ました。

どうだったの

学習元の文章自体少ないのですが、

と、かなり量がバラけています。
これは効果が期待できるのかな、と思ったけど殆ど変わりませんでした。具体的には以下から。
一応前回と同じ文章を使っています。上に表示されている結果はこれまでの普通のナイーブベイズで、下がComplement Naive Bayesです。
f:id:haru2036:20140120210025p:plain

f:id:haru2036:20140120210042p:plain

f:id:haru2036:20140120210054p:plain

f:id:haru2036:20140120210107p:plain

結局元から判別が難しいと思っていた艦これと戦艦はやっぱり無理でした。そして、長門有希に関しても"戦艦"の1語が入っていたために艦これと勘違いされています……これテーマ間違ったな。

まとめ

そもそも戦艦長門長門有希の時点でも結構テーマとしてもアレだったけどそれに人間でも紛らわしい艦これを突っ込んでしまったがためにかなりグダグダに。一応他のことにも使えるからいいか……

ソースはgithubにあります。実装もめっちゃグダグダですが……
haru2036/nagato · GitHub

次は何をしよう……

HaskellとMeCabで長門(その2)

精度改善のために

とりあえずMeCabの出力を使って品詞が名詞である単語のみをフィルタした状態で訓練するように修正しました。

結果

まず全エントリの3つの文を。
f:id:haru2036:20140111020759p:plain
f:id:haru2036:20140111020807p:plain
f:id:haru2036:20140111020812p:plain

結果としては残念なことに全部艦これになってる……

考察

長門有希の文章に関しては、「戦艦と間違われやすそうなやつ」の「戦艦」の1語の影響で、他の2つのクラスの尤度が上がってしまったことが原因だと思います。
ふつうの戦艦に関しては、そもそもが艦これの方の説明文と同じような単語がたくさん出てくるのでそもそも判別が難しいのではないかと。

まとめ

実を言うと他の文章に関してもそれなりに試したものの、ちゃんとデータをとってなかったので暇な時にいろいろ試してみようと思ってます。
ただ、個人的な感触(含プラシーボ)としては、何故か長門有希に間違われまくっていた文章が正常に艦これだったり戦艦だったりになるようにはなったイメージです。

ちょっと残念だったこと

HaskellはMaybeとかそこら辺の"失敗を明示的に表現する"(個人的なイメージ、間違ってたらおしえて)型があるにも関わらずList操作関連のheadやら!!やらで空リストだったりそのインデックスが対象のListになかったりするとExceptionが発生するの、非常に残念だと思いました。(もっといい方法あるかもしれないけどそのせいでわざわざif使ってチェックしてしまった)