LGPLと商用利用にまつわる話 - kaisehのブログ
商用アプリケーションにLGPLライブラリを組み込むにあたって、いろいろ問題があるらしいということは知っていましたが、それが具体的に何なのかは良く分かっていませんでした。 Javalobbyに2004年にポストされた「LGPL and Java」という以下のトピックと、そこで繰り広げられているFSF支持派（以下肯定派）とLGPLうざい派（以下否定派）のバトルを読んで、少し状況が理解できました。 LGPL and Java - FSF clarifies この論争で主に槍玉にあげられているのは、LGPLが定めている以下の点です（この原則自体、あまり正確には把握されていないんじゃないかな。特に3とか）。これらは、LGPLライブラリの商用利用の障害になる可能性があります。 LGPLライブラリにリンクするアプリケーションは、そのリンクの形態がいかなるものであれ、LGPLライブラリの派生物になる。した
Lucene 2.4とLucene 2.0のインデックス構築速度比較 - kaisehのブログ
Luceneは、こちらのベンチマークなどを見る限り、Sennaなど他の全文検索エンジンに比べて相当遅いとされているようです。 上記ページのベンチマークではLucene 2.0が使われています。僕も数年前にLucene 2.0を使ったことがあって、それ以降はLuceneに触れていなかったんですが、最近のバージョンはパフォーマンスが大幅に改善されているそうなので、どれくらい速くなったのか、インデックス作成速度を比較してみました。 比較に使ったのはLucene 2.4.1（2009/03）とLucene 2.0.0（2006/05）です。以下の条件でインデックス作成時間を計測しました。 データ: 日本語版Wikipediaのダンプから先頭20万記事 インデックス形式: 記事タイトル: Store.YES, Index.ANALYZED（元文字列＋インデックス） 記事本文: Store.COMPR
RDBMSをKey-Value Storageとして使う場合のパフォーマンス計測（H2, MySQL編） - kaisehのブログ
Tokyo Cabinet, QDBM, Lux IOなど、DBM同士のパフォーマンス比較はWebで良く見かけるのですが、MySQLのような普通のRDBMSをKey-Value Storage的に使用した場合、DBMと比べてどれくらい差が付くものなのかイメージが湧かなかったので、実際に計測してみました。 Javaプログラムから、Berkeley DB、H2、MySQLの3種類のストレージを使用しました。条件は以下の通りです。 Berkeley DB Java Edition 3.3.75 デフォルト設定 H2 1.1.106 jdbc:h2:file:~/dbmbench Embeddedモードで使用 デフォルト設定 DDLは以下を使用 create table casket ( id integer auto_increment primary key, key_ varchar(255
K-means法によるクラスタリングのスマートな初期値選択を行うK-means++ - kaisehのブログ
K-means法は、入力データからK個のランダムな個体を初期クラスタの中心として選択し、以降、クラスタの重心を移動させるステップを繰り返すことでクラスタリングを行う非階層的手法です。K-means法はシンプルで高速ですが、初期値依存が大きいのが弱点で、不適切な初期値選択をすると間違った解に収束してしまいます。 以下は、Introduction to Information Retrievalの16章に出てくる例です。 {d1, d2, ..., d6}をK=2でクラスタリングする場合、{{d1, d2, d4, d5}, {d3, d6}}が大域最適解ですが、初期クラスタの中心をd2, d5で与えると、{{d1, d2, d3}, {d4, d5, d6}}という誤った解に収束してしまいます。 この問題を改善するK-means++という手法を見つけたので、試してみました。 K-means+
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
