タグ

データ構造に関するp_tanのブックマーク (7)

  • What's new in purely functional data structures since Okasaki?

    Since Chris Okasaki's 1998 book "Purely functional data structures", I haven't seen too many new exciting purely functional data structures appear; I can name just a few: IntMap (also invented by Okasaki in 1998, but not present in that book) Finger trees (and their generalization over monoids) There are also some interesting ways of implementing already known datastructures, such as using "nested

    What's new in purely functional data structures since Okasaki?
    p_tan
    p_tan 2017/05/11
    新しい純粋関数型データ構造のリスト
  • 興味深いデータ構造:BK木 | POSTD

    BK木とは、 距離空間 内のデータをインデックス化する目的に特化した、木構造を指します。距離空間は基的に、要素の組 $ (a,b) $ 全てについて距離関数 $ d(a,b) $ を持つオブジェクトの集合です。この距離関数は正しく動作することを保証するために、一連の公理を満たしていなければなりません。これが必要になる理由は、後述の「検索」のセクションできちんと説明します。 BK木のデータ構造は、一連のキーを検索し、与えられた検索キーの値に最も近いキーを見つける問題の解決策として、 1973年にBurkhardとKellerが提案したもの です。この問題を解決する素朴な方法は、要素の組に含まれる各要素と検索キーの値を単純に比較することです。一定の時間内に比較が完了した場合、この検索の解は $ O(n) $ となります。一方、BK木を採用すると、この時実行する比較の回数を減らせる可能性が高く

    興味深いデータ構造:BK木 | POSTD
  • 私が書いた最速のハッシュテーブル – PART 2 | POSTD

    素数か2のべき乗か ハッシュテーブルのアイテムをルックアップする際に高負荷なステップが3つあります。 キーをハッシングする キーをスロットにマッピングする 該当スロットのメモリをフェッチする ステップ1は、キーが整数であれば、低負荷になります。単にintをsize_tにキャストするだけです。しかし、文字列のようなタイプのキーの場合は高負荷となります。 ステップ2はよくある整数モジュロ演算です。 ステップ3はポインタの間接参照です。std::unordered_mapの場合は複数のポインタ間接参照となります。 処理の遅いハッシュ関数でなければ、直観的にステップ3が最も高負荷になると考えると思います。しかし、全てのルックアップでキャッシュミスが生じなければ、整数モジュロが最も高負荷な処理となります。現代のハードウェアにおいても整数モジュロは非常に遅いのです。 Intelマニュアル では、整数モ

    私が書いた最速のハッシュテーブル – PART 2 | POSTD
  • 私が書いた最速のハッシュテーブル – PART 1 | POSTD

    結局、やり出したら止まりません。私は以前、” I Wrote a Fast Hashtable(私が書いた高速なハッシュテーブル) “という記事と、それに次いで” I Wrote a Faster Hashtable(私が書いたより高速なハッシュテーブル) “という記事をブログにアップしましたが、今回ついに、最速のハッシュテーブルを書き上げました。これが意味するところは、ルックアップがどのハッシュテーブルよりも速いということです。それに加えて、挿入や削除も(最速とまではいかないまでも)非常に速く行えます。 秘訣は、探索回数の上限を設定したロビンフッドハッシュ法を使用することです。ある要素が、その理想的な位置からX数以上、離れた位置にある場合、テーブルを拡張することで、全ての要素が、その大きなテーブル内において、理想的な位置に近づくようにします。結果的に、このやり方は非常にうまくいきました。

    私が書いた最速のハッシュテーブル – PART 1 | POSTD
  • 高速な文字列検索 Crit-Bit Tree コンテナ(C++) - Qiita

    Crit-Bit Tree をご存知でしょうか。 基数木 (Radix tree) は知っている人が多いかもしれません。 Crit-Bit Tree は基数木をさらに発展させたもので、 基数木同様、高速な検索が可能な木構造です。 基数木はハッシュマップのようなハッシュ値の衝突が発生しないため hashdos1 対策として有効な手段ですが、メモリ消費量が大きい問題がありました。 Crit-Bit Tree ではハッシュ値の衝突は発生しない上に、 基数木に比べてメモリ消費量を抑えることができます。 アルゴリズム 基数木では、文字列を文字ごとに扱っていました。 例えば "AAA" "AAB" "ABC" というキー値があるとき、 以下のようなツリーが構築されます。 基数木のメモリ消費量が大きい問題は、この黒丸の部分、分岐にあります。 各分岐点では、複数の子ノードを保持する必要がありますが、 1バ

    高速な文字列検索 Crit-Bit Tree コンテナ(C++) - Qiita
  • Cache-Oblivious データ構造入門 @DSIRNLP#5

    最小カットを使って「燃やす埋める問題」を解く方法について、問題とソースコードつきで、まとめました。ニコニコ生放送「TopCoderでプログラムしてみた」2000回記念放送の資料です。

    Cache-Oblivious データ構造入門 @DSIRNLP#5
  • キャッシュフレンドリーな二分探索 ー データ構造を再考する | POSTD

    現代のコンピュータのアーキテクチャに搭載されている高速のキャッシュメモリは、 参照の局所性 に優れた(=一連のものとしてアクセスした要素が、互いに近いメモリのアドレスに配置されている)データ構造を好みます。これは、 Boost.Containerの平坦な(ツリー状ではない)連想コンテナ のようなクラスを陰で支えている理論的根拠です。要素を連続的に(かつ順序だてて)保存すると同時に、標準的なC++ノードベースの連想コンテナの機能性をエミュレートします。以下にあるのは、要素が0から30の範囲の時、 boost::container::flat_set の中で 二分探索 がどのように行われるのかを示した例です。 探索で目的の値を絞り込むにつれて、アクセスされる要素は次第に近くなっていきます。そのため、最初のうちは大きな距離を飛び越えていくような感じであっても、参照の局所性は このプロセスの最後の

    キャッシュフレンドリーな二分探索 ー データ構造を再考する | POSTD
    p_tan
    p_tan 2015/07/28
    目から鱗
  • 1