タグ

2010年4月7日のブックマーク (5件)

  • ALGORITHM NOTE ナップザック問題 Knapsack Problem

    大きさ w と価値 v を持った品物が N 個あり、これらを大きさ W のナップザックに入れたいとします。このとき、大きさの合計が W を超えず、価値の合計が最大になるような品物の組み合わせを求めたい。これがナップザック問題です。各品物を「選択する」か「選択しない」かの組み合わせなので、厳密には0-1ナップザック問題ともいいます。(各品物が複数個ある場合は、0123ナップザック問題と呼ばれます) この問題を力任せで解こうとすれば、N 個の品物を「選択する」か「選択しないか」の全組み合わせを全て調べることになるので、計算効率は O(2N) となります。N が数十個でも、実用的な時間では計算できません。 品物の大きさ w、ナップザックの大きさ W がともに整数であれば、ナップザック問題は動的計画法により O (NW) の効率で厳密解を求めることができます。 C[i][w] が、大きさ w のナ

  • naoyaのはてなダイアリー - Linuxのページキャッシュ

    世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系DBを持っていくと I/O 負荷が激減した件(当たり前だけど) - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io

    naoyaのはてなダイアリー - Linuxのページキャッシュ
  • https://labs.cybozu.co.jp/blog/kazuho/archives/2007/10/innodb_warmup.php

  • ethnaで国際化対応 - ActionFormの選択肢があるフォーム - YOD-Yのへたれ開発日誌

    ethnaフレームワークを利用して開発されている「新刊.net」を「Sinkan.com」へ国際化対応しました。 実際には別サービスなので正確にいうと国際化対応ではないのですが、ethnaの国際化対応の手法を利用して実装したのでご容赦を。 対応するに当たっていくつかコツがあったのでメモ代わりに順次書いていきたいと思います。 …というか id:hidea に残しておけと怒られました (^^; なおこの内容は、以下にあるethnaのプロジェクト国際化のテキストを前提に書かれています。 >> プロジェクトの国際化 - ethna まずは、 ActionFormの選択肢があるフォームと、{form_input}フォームヘルパへの対応 FORM_TYPE_CHECKBOX、FORM_TYPE_RADIO、FORM_TYPE_SELECT などの選択肢があるフォームは、ActionForm で以下のよ

    ethnaで国際化対応 - ActionFormの選択肢があるフォーム - YOD-Yのへたれ開発日誌
  • 第11回 転置索引の圧縮 | gihyo.jp

    はじめに 第2回で、索引は多くの場合圧縮されていることに言及しました。また第7回では、索引構築時にどの部分で索引を圧縮すればよいかを疑似コードを用いて説明しました。今回は、転置索引の具体的な圧縮方法について説明していきます。 圧縮の目的 中規模から大規模な索引の場合、転置リストは非常に長くなり、検索時にはディスクからの大量のデータの読み取りが行われます。転置索引(を用いた検索エンジン)では、これによる検索処理時間の増加を防ぐために、転置リストを圧縮しディスクからの読み込み時間の短縮を図ります。 この場合、圧縮された転置リストをディスクから読み込みさらに復元処理を行う必要がありますが、通常は次のようになります。 これは、近年のCPUとディスクの速度差が大きいため、主にCPUにおける処理である復元処理が高速に行えることによるものです。よって、圧縮というと容量を節約の意図で使うことが多いと思いま

    第11回 転置索引の圧縮 | gihyo.jp