Mahoutシリーズを最初から読む場合はこちらApache Mahoutで機械学習してみるべ - 都元ダイスケ IT-PRESS。 さて、前回までで、実際にMahoutのレコメンデーションエンジンを動かしてみつつ、その計算原理を軽く追いかけました。今回は、機械学習全般における大事な前提について。 仮定がいっぱい 通常プログラムを書く場合は、事実や仕様に基づいて、正確にプログラミングすることを求められます。可能性の大小や、大ざっぱな計算などに依存したプログラミングはあまり書く機会がありません。例えばあるソフトで扱う業務で、土日祝日料金と平日料金というものがあったとします。これを「1週間のうち、だいたい5日が平日で2日が休日だよね、祝日とかたまにしかないから、考慮すると大変だし、いいよね、べつに」ってことにはなりません。多分。 しかし、機械学習は違います。気づいていないだけで、実はかなり大きな

Mahoutシリーズ目次（随時更新） 非分散レコメンデーション Apache Mahoutで機械学習してみるべ - 都元ダイスケ IT-PRESS （これ） レコメンデーションの簡単な原理を視覚的に把握してから実際に計算してみる - 都元ダイスケ IT-PRESS 機械学習における重大な"仮定"と、アルゴリズムの評価 - 都元ダイスケ IT-PRESS 分散レコメンデーション Mahoutで分散レコメンド(1) - 都元ダイスケ IT-PRESS Mahoutで分散レコメンド(2) - 都元ダイスケ IT-PRESS Mahoutで分散レコメンド(3) - 都元ダイスケ IT-PRESS クラスタリング 今度はMahoutでクラスタリング - 都元ダイスケ IT-PRESS 今度はMahoutでクラスタリング(ソース編) - 都元ダイスケ IT-PRESS では、本文いきます。 Apach

Mahoutシリーズを最初から読む場合はこちらApache Mahoutで機械学習してみるべ - 都元ダイスケ IT-PRESS。 昨日分析したデータは、1番の人にお勧めなアイテムは104で、4.25点をつけるだろう、という予想でした。なぜこのような計算結果になったのか、なんとなく感覚をつかんでみよう。 入力に使ったCSVデータを、簡単にグラフ化してみたのがこれだ。 レコメンド対象となる1番の人は、青のグラフだ。この青のグラフのパターンに一番似ているのはどれだろう？ 101〜103をぱっと見た感じ、紫(5)の人と似た傾斜だと感じると思う。また、赤(4)の人も分かりづらいけど結構似ている。102の評価は抜けているものの、101*1と103の評価は近い。 逆に、緑(2)の人とは正反対の好みを持っているようだ。グラフが逆行している。黄色(3)の人は…、あんまり関連性はなさそうだな。 というような

さて、Javaで「何か作ろう」って思った時、みなさんどうします？ 書き捨てならば、どうでもいいと思うんですが、少々真面目に作っていこうかな、と思ったら、色々な開発環境整備が大変です。 Eclipse+Maven環境で開発をするのが好きな人は、とりあえず mvn archetype:generate でプロジェクトを作り、mvn eclipse:eclipse でEclipse用の基本メタデータを生成し、そしてEclipseにインポートする、なんてことをしているかもしれません。 Mavenプロジェクトとして生成 Eclipseの基本メタデータを生成 Eclipseにimport 自分用のEclipse,Checkstyle,FindBugs設定を生成 自分用好みのOSSライブラリをpomのdependencyに追加… なんていうステップが基本的な手順かな、と思ってます。ただ、これが意外とめん

easy_install さて、Pythonにおけるパッケージ（モジュール）管理システム*1はeasy_installって言う奴みたいです。このパッケージ管理システムもmacにデフォで入っていたり、Pythonの各バージョン用のものがあったり、となかなか複雑です。 ちょいと探しただけで、以下の3つが見つかりました。恐らくですが、右の括弧内に書いたそれぞれのpython用のものであろうと思います。 /usr/bin/easy_install (/usr/bin/python 用？) /usr/bin/easy_install-2.5 (/usr/bin/python2.5 用？) /usr/bin/easy_install-2.6 (/usr/bin/python2.6 用？) py26-(setuptools|distribute) とりあえず、python本体はmacportsで入れたp

調べたメモ。色々思い込みや想定に基づいた事も書いてるので、鵜呑みして騙され注意報発令さしとく。 最近分散技術系の話題をよく聞くようになりました。企業内グループ内で使うような業務システムであれば、そこまで無茶な数のアクセスも無いだろうから、数台〜数十台規模のサーバを立てればだいたい事足りたのだろう。例えば、サーバ構成を「Webサーバ - APサーバ - DBサーバ」という3レイヤにして、各サーバを冗長化していく、等の手法でどうにかなった。 ただ、処理リクエスト数の増大や、処理対象データの増大、そして処理ロジックの複雑化に伴って、大量のデータを逐次処理するだけでは処理が追いつかない世界が出てきた。業務システムではなく、サービスプロバイダの世界では、この現象は顕著。 また、Webサーバ層とAPサーバ層の冗長化は比較的簡単だけども、DBサーバ層は大量のステートを持っているレイヤだから冗長化がめんど

私は、Jiemamy Projectというオープンソースプロジェクトを運営している。 ある意味、一人で作っている頃は楽だった。Javaにおけるpublicというキーワードの重みも知らず、複数人によるコミュニケーションのオーバーヘッドも気にすることなく、それはそれは勝手気ままにひたすらコードを書くだけだった。 当初、Jiemamyは「そんなに難しいモンじゃないだろｗ さっさと作って便利にしようぜｗｗ」くらいのノリで作っていたのだが、作れば作るほど色々な問題点も浮上し、勉強すればするほど新しい機能も欲しくなった。人の欲とは恐ろしいものだ。一人じゃ、もう作れない、限界がすぐに訪れた。 Jiemamyは、（私の知る限り）今までにあまり無い考え方を打ち出したプロジェクトだ。ただ語られていなかっただけかもしれないが、「私はこうあるべきだと思う」という理想（Jiemamy開発プロセス）を打ち出し、それを

久々のシリーズ。 今回はcommons-configuration。設定ファイル、ってありますよね。Javaだとproperties、Windosだとiniファイルが使われる事が多い。複雑なものだとXMLで書いたりする。 さて、そんなファイルの読み込み・書き出しってどうしますか。まさかFileInputStreamで自前で読み出すとか、しないですよね。コメント行の処理等、やらなきゃいけないことは結構あります。まぁ、propファイルだったらPropertiesクラスで読み書きできますが、それでも、そうそう便利には出来ていません。 XMLファイルだったりすると、DOM組んで読み書きしますかね。これも結構大仕事。 という時に使うのがcommons-configurationのようです。まぁ、能書きよりコードですかね。 propertiesファイルの場合 foo = hoge foo.bar =

1st Seasonはこちら。Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS 以前は、何かをスローする状況を3つに分けてそれに合った設計をした例外を投げましょう、という考え方を示しました。 callerのバグ: RTE calleeのバグ: Error どちらでもない: Exception (非RTE) まぁ詳しくはSeason1の方で。 Seasar2はRuntimeExceptionですね。2004年ぐらいからのフレームワークはRTEをスローしていると思いますよって、ひがさんから情報。 チェックされる例外とチェックされない例外について - じゅんいち☆かとうの技術日誌 ただ、上記のような考え方もあるのも事実。実際.NETやRuby, Python, 新鋭のScala等もcatchを強制する例外というものが言語仕様的に存在しません*1。逆に、チェック例

Java開発者であれば、しばしばEclipseでJavaプロジェクトを作ると思います。 JDT標準の「Java Project」ウィザードを使う事もあれば、Maven構成のプロジェクトを使うためにarchetypeを使ってmvn eclipse:eclipseをしたり。まあ色んなパターンがあると思います。 先日の日経ソフトウエア記事を切っ掛けに、「コンパイラ設定やcheckstyle設定を適度に厳しく設定して、綺麗なコードを書いていこうぜ」という主張を始めている都元ですが、記事の通りに設定ファイルをコピーしたり何なりって意外とめんどくさく、サボってしまいがちです。俺自身も。 じゃあ、ちょっとした設定が済んでいるプロジェクトを吐けるようになればいいじゃない。というプラグインを作りました。題して「Strict Java Project Plugin」。 色々細かく作り込むのが面倒だったので、以

俺、この設定しないと、もうその単語がクラス名なのか変数名なのか分からなくて死にますｗ EnableしてBoldをONにする感じ。デフォルトでdisableなんだけども、実は裏側でColorは設定されている。この色分けも便利。Preview で「InterfaceName」「Color」「Object」がそれぞれ太字になっていて、僅かに色が付いている。

例えば、if〜instanceofを避ける(1) - 都元ダイスケ IT-PRESSの続き。 解決策は幾つかある。とりあえず今回は１つ紹介。 public enum Processor { LIST(List.class) { @Override public void process() { // List用処理 } }, MAP(Map.class) { @Override public void process() { // Map用処理 } }; private final Class<?> clazz; private Processor(Class<?> clazz) { this.clazz = clazz; } public abstract void process(); public static Processor get(Object obj) { for (Pro