TF-IDF

NLP

なんか Wikipedia の TF-IDF の項目がちょっとひどいな、これは。
普通、tf は「あるドキュメント中における」ある単語の出現頻度という意味で使うんじゃないかなぁ。
あとまぁ、一口に TF-IDF といっても、idf が 1 + log(N/df) だったり、tf の square root を取ったり idf の二乗を取ったりとか結構バリエーションがあったりするもんです。

Generics と template

Java C++

Generics で Duck type は無理です。
基本的には kinaba さんが書かれている通りで。

Dのテンプレートは、仕組み的には C++ のそれと全く同じです。引数の違う実体は全部別のインスタンスとして、コンパイル時にマクロ的に展開されます。型チェックも、JavaやC#のジェネリクスのようなテンプレートの段階での型チェックは入らなくて、実際にmixinや関数適用の形で使った時点で初めて型チェックが行われます。

C++/D*1 の template は実際に使われたときに、その型ごとに実装を生成してから、型チェックという具合になるわけだけど、Java/C#*2 の Generics ではそういう実装の生成はなくて、単に前後に cast が入ったりするだけ。
だから

public static <T> void func(T ducky) {
    ducky.quack();
}

はメソッドの実装時の情報だけで型チェックが入って、ducky の型は Object とみなされてエラーになると。
もちろん、

interface Duck {
    void quack();
}

class test {
    static <T extends Duck> void func(T ducky) {
        ducky.quack();
    }
}

なんかは OK だけど、これは普通に継承関係を使って型チェックが入っているわけで、Duck Typing と呼ぶような代物ではないよね。

*1:実は D のことはほとんど知らないんだけど

*2:これまた C# のことは良く知らない

Project Euler

ProjectEuler

なんか Project Euler をやれといわれたのでやってみたんだけども、若い番号の問題がやたら簡単でびっくりした。
例えば Problem 5 とか Gauche なら

(use srfi-1)
(apply lcm (iota 20 1))

で、Haskell なら

foldl1 lcm [1..20]

んで、もって Problem 160 とか解き方が良く分からなかったから、Hadoop を使ってぶん回して解いた*1。ひどい。Quad Core とか Dual Core x 2 とかそういうマシンを複数台使って 90 分とかだったから、普通にやると多分1日以上かかるだろうなぁ。
とりあえず、今 49 問 解いてて 27% genius.

*1:といっても(10^12)! をまじめに計算したりはしていない

Problem 160

Java Hadoop ProjectEuler

Hadoop はドキュメントが少なすぎ。ソフトウェア自体は良くできているっぽいのにもったいない。
まぁ、ということで、Project Euler の Problem 160 を解くプログラムでも。マジックナンバー多すぎだけど気にしない。まぁ、examples の PiEstimater でも読んどいたほうが良いと思うけど。
しっかし、JobConf の設定も面倒だが、Generics の型パラメータが煩雑だ。こういうのは Scala の得意分野な気もするが、どうだろう。

続きを読む