タグ付けされた質問 「hash-tables」

多くの値を少数のアドレスにマップする関数を使用して、格納された値をアドレス指定する有限マップデータ構造。

4
(いつ)ハッシュテーブルルックアップはO(1)ですか?
ハッシュテーブルルックアップは一定の時間で動作するとよく言われます。ハッシュ値を計算すると、配列ルックアップのインデックスが得られます。しかし、これは衝突を無視します。最悪の場合、すべてのアイテムが同じバケットに到着し、ルックアップ時間は線形()になります。Θ(n)Θ(n)\Theta(n) ハッシュテーブルルックアップを本当にすることができるデータの条件はありますか?それは平均的にのみですか、またはハッシュテーブルにO (1 )最悪のケースルックアップを含めることができますか?O(1)O(1)O(1)O(1)O(1)O(1) 注:ここではプログラマーの視点から来ています。ハッシュテーブルにデータを格納すると、ほとんど常に文字列またはいくつかの複合データ構造であり、データはハッシュテーブルの有効期間中に変更されます。したがって、完璧なハッシュについての答えはありがたいですが、それらはかわいいですが、逸話的であり、私の観点からは実用的ではありません。 PSフォローアップ:ハッシュテーブル操作O(1)はどのようなデータですか?

4
ハッシュ関数でmodとして素数を使用するのが最適なのはなぜですか?
1〜100のキー値のリストがあり、それらを11個のバケットの配列に整理したい場合、mod関数を作成するように教えられました。 H=kmod 11H=kmod 11 H = k \bmod \ 11 これで、すべての値が9行に次々と配置されます。たとえば、最初のバケットには0、11、22 0,11,22…0,11,22…0, 11, 22 \dotsます。2番目では1,12,23…1,12,23…1, 12, 23 \dotsなどがあります。 悪い子になって、ハッシュ関数として非プライムを使用することにしたとしましょう-テイク12.ハッシュ関数の使用 H=kmod 12H=kmod 12 H = k \bmod \ 12 値をハッシュテーブルにつながる0,12,24…0,12,24…0, 12, 24 \dots 最初のバケットで、1,13,25…1,13,25…1, 13, 25 \dots等秒でのように。 本質的には同じものです。衝突を減らさなかったし、素数ハッシュコードを使用して物事をうまく分散させることもしなかったので、それがどのように有益であるかわかりません。

1
ハッシュテーブルとバイナリツリー
辞書を実装する場合(「顧客IDで顧客データを検索したい」)、使用される一般的なデータ構造はハッシュテーブルとバイナリ検索ツリーです。たとえば、C ++ STLライブラリは(バランスのとれた)バイナリ検索ツリーを使用して辞書(マップと呼びます)を実装し、.NETフレームワークは内部でハッシュテーブルを使用することを知っています。 これらのデータ構造の長所と短所は何ですか?特定の状況で合理的な他のオプションはありますか? キーが強力な基礎構造を持っている場合、たとえば、キーがすべて1からnまでの整数である場合など、特に興味がないことに注意してください。

1
Pastryのルーティングテーブルの作成方法
この質問は、Computer Science Stack Exchangeで回答できるため、Software Engineering Stack Exchangeから移行されました。 7年前に移行され ました。 Pastry Distributed Hash Tableを実装しようとしていますが、いくつかのことが理解を逃れています。私は誰かが明らかにできることを望んでいた。 免責事項:私はコンピューターサイエンスの学生ではありません。私は人生で正確に2つのコンピューターサイエンスコースを受講しましたが、どちらもリモートで複雑なものを扱っていません。私はソフトウェアで長年働いてきたので、アイデアに頭を包むことができれば、実装タスクに任せていると感じます。だから、明らかな何かを見逃しているだけかもしれません。 著者が発表した論文[1]を読んで、ある程度の進歩を遂げましたが、ルーティングテーブルの動作に関するこの1つの特定のポイントに固執し続けています。 論文は、 ノードのルーティングテーブル、それぞれエントリの 行に編成されます。ルーティングテーブルの行のエントリは、nodeIdが最初のn桁で現在のノードのnodeIdを共有するが、番目の桁が可能な値のいずれかを持つノードを参照します現在のノードのID の番目の数字以外。⌈ ログ2 B N ⌉ 2 B - 1 2 B - 1件の、N 、N + 1 2 B - 1 、N + 1をRRR⌈ ログ2bN⌉⌈log2b⁡N⌉\lceil \log_{2^b} N\rceil2b− 12b−12^b - 12b− 12b−12^b - 1nnnn …

5
ハッシュテーブル操作O(1)とはどのようなデータですか?
答えから(いつ)ハッシュテーブルルックアップはO(1)ですか?、データが特定の統計条件を満たしている場合、ハッシュテーブルには少なくとも償却されたO(1)O(1)O(1)最悪の場合の振る舞いがあり、これらの条件を広くするのに役立つテクニックがあります。 しかし、プログラマーの観点から、私は自分のデータが何であるかを事前に知りません。それはしばしば外部ソースから来ます。そして、一度にすべてのデータを取得することはめったにありません。挿入と削除は、ルックアップの速度をそれほど下回らない速度で行われることが多いため、データを前処理してハッシュ関数を微調整します。 だから、一歩を踏み出す:データソースに関する知識があれば、ハッシュテーブルにO(1)O(1)O(1)操作の可能性があるかどうか、そしておそらくハッシュ関数で使用するテクニックを判断するにはどうすればよいですか?

3
「非病理学的データ」とはどういう意味ですか?
Courseraでアルゴリズムクラスを受講しました。ハッシュテーブルに関するビデオの教授は、 真実は、非病理学的データの場合、適切に実装されたハッシュテーブルで一定時間の操作を取得するということです。 「非病理学的データ」とはどういう意味ですか?例を挙げていただけますか?

1
実際のユニバーサルハッシュ
HHHh :U→ { 0 、… 、M− 1 }h:うん→{0、…、M−1}h: U \rightarrow \{0,\ldots,M-1\}∀ X 、Y∈ U、x ≠ y⇒ PrをH ∈ H[ h (x )= h (y)] ≤ 1M∀バツ、y∈うん、バツ≠y⇒Prh∈H[h(バツ)=h(y)]≤1M\forall x,y \in U, x \neq y \Rightarrow \Pr_{h \in H}[h(x) = h(y)] \leq \frac{1}{M} ユニバーサルハッシュの概念は、学部のデータ構造コースの標準的な部分になりました。産業用アプリケーションでのユニバーサルハッシュの重要性について学生を動機付けることができればうれしいです。だから私の質問は: ハッシュ関数のユニバーサルファミリーの構築は実際には重要ですか?答えが「はい」の場合、これまでに見た興味深い産業用アプリケーションをいくつか教えてください。

4
カッコウハッシュが動的な完全ハッシュよりも優れている点は何ですか?
動的な完全ハッシュテーブルとカッコウハッシュテーブルは、最悪の場合のO(1)ルックアップと予想されるO(1)時間の挿入と削除をサポートする2つの異なるデータ構造です。どちらもO(n)補助スペースと、操作のためにハッシュ関数のファミリーへのアクセスが必要です。 これらのデータ構造はどちらもそれ自体で美しく、素晴らしいと思いますが、これらのデータ構造が他のデータ構造よりもいつどのように望ましいかはわかりません。 これらのデータ構造の1つが他のデータ構造よりも明確な利点を持っている特定のコンテキストはありますか?それとも、ほとんど交換可能ですか?

1
絞り込みタイプの推測
職場では、動的言語に関する型情報を推論する必要があります。次のように、ステートメントのシーケンスをネストされたlet式に書き換えます。 return x; Z => x var x; Z => let x = undefined in Z x = y; Z => let x = y in Z if x then T else F; Z => if x then { T; Z } else { F; Z } 一般的なタイプ情報から始めて、より具体的なタイプを推測しようとしているので、自然な選択は絞り込みタイプです。たとえば、条件演算子は、trueブランチとfalseブランチの型の和集合を返します。単純なケースでは、非常にうまく機能します。 ただし、次のタイプを推測しようとしたときに、思わぬ障害に遭遇しました。 function …
11 programming-languages  logic  type-theory  type-inference  machine-learning  data-mining  clustering  order-theory  reference-request  information-theory  entropy  algorithms  algorithm-analysis  space-complexity  lower-bounds  formal-languages  computability  formal-grammars  context-free  parsing  complexity-theory  time-complexity  terminology  turing-machines  nondeterminism  programming-languages  semantics  operational-semantics  complexity-theory  time-complexity  complexity-theory  reference-request  turing-machines  machine-models  simulation  graphs  probability-theory  data-structures  terminology  distributed-systems  hash-tables  history  terminology  programming-languages  meta-programming  terminology  formal-grammars  compilers  algorithms  search-algorithms  formal-languages  regular-languages  complexity-theory  satisfiability  sat-solvers  factoring  algorithms  randomized-algorithms  streaming-algorithm  in-place  algorithms  numerical-analysis  regular-languages  automata  finite-automata  regular-expressions  algorithms  data-structures  efficiency  coding-theory  algorithms  graph-theory  reference-request  education  books  formal-languages  context-free  proof-techniques  algorithms  graph-theory  greedy-algorithms  matroids  complexity-theory  graph-theory  np-complete  intuition  complexity-theory  np-complete  traveling-salesman  algorithms  graphs  probabilistic-algorithms  weighted-graphs  data-structures  time-complexity  priority-queues  computability  turing-machines  automata  pushdown-automata  algorithms  graphs  binary-trees  algorithms  algorithm-analysis  spanning-trees  terminology  asymptotics  landau-notation  algorithms  graph-theory  network-flow  terminology  computability  undecidability  rice-theorem  algorithms  data-structures  computational-geometry 

2
リストの代わりに検索ツリーを使用したハッシュ
私はハッシュと二分探索木資料と格闘しています。そして、同じハッシュ値を持つエントリを格納するためにリストを使用する代わりに、バイナリサーチツリーを使用することも可能だと私は読んだ。そして、私は操作の最悪の場合と平均の場合の実行時間を理解しようとします insert、 find そして delete 価値があります。平均的なケース。リストに関しては改善されますか?

3
(衝突のない)ハッシュテーブル検索は本当にO(1)なのですか?
免責事項:私はこことStackoverflowで同様の聞こえる質問があることを知っています。しかし、それらはすべて衝突についてであり、それは私が求めているものではありません。 私の質問は次のとおりです。なぜそもそも衝突のないルックアップなのO(1)ですか? 私がこのハッシュテーブルを持っているとしましょう: Hash Content ------------- ghdjg Data1 hgdzs Data2 eruit Data3 xcnvb Data4 mkwer Data5 rtzww Data6 今、私はkハッシュ関数h(k)が与えるキーを探していますh(k) = mkwer。しかし、ルックアップはハッシュmkwerが5の位置にあることをどのように「知っている」のでしょうか。それO(n)を見つけるためにすべてのキーをスクロールする必要がないのはなぜですか?ハッシュは、実際のハードウェアアドレスではあり得ません。データを移動する能力を失うからです。そして、私の知る限りでは、ハッシュテーブルはハッシュでソートされていません(そうであったとしても、検索にも時間がかかりますO(log n))? ハッシュを知ることは、テーブル内の正しい場所を見つけるのにどのように役立ちますか?

3
線形時間の最悪の場合をどのようにカウントするのですか?
この質問とこの質問は私に少し考えさせられました。長さの配列をソートするためnnnとkkk中のユニークな要素、我々は、配列内の値の数を格納できるようにする必要があります。いくつかの提案がありますが、最悪の場合線形時間でこれを行う方法を探しています。すなわち:O(n+klogk)O(n+klog⁡k)O(n + k \log k) リストの指定されたのを有する要素別個の要素、タプルのリストを決定すべての固有の要素よう要素の数であるで。AAAnnnkkkU={(xi,ci)}kU={(xi,ci)}kU = \{(x_i, c_i)\}^kxi∈Axi∈Ax_i \in Acicic_ixixix_iAAA 私がこれまでに提案してきた(失敗した)アイデアの一部を以下に示します。 平衡型二分探索木 -これを使用すると、O(logk)O(log⁡k)O(\log k)をツリーに挿入して値を増やす必要があります。挿入後、O(k)O(k)O(k)でツリートラバーサルを実行できます。したがって、合計時間がO(nlogk)O(nlog⁡k)O(n \log k)これは遅すぎます。 ハッシュマップ -これにより、O(1)O(1)O(1) 予想される挿入、つまりO(n)O(n)O(n) 予想される時間を取得できます。ただし、これはまだO(n)O(n)O(n)最悪のケースではありません。 空の空間マッピングAAA最小要素と最大要素を見つけます。この範囲をカバーするのに十分なメモリを割り当てます(ただし、初期化しません)。このメモリを基本的にハッシュマップとして使用し、ランダムハッシュを含めて、破損したメモリにアクセスしないようにします。この戦略には問題があります。(1)失敗する可能性が非常に低い確率論的ですが、保証されていません。このようなメモリを使用すると、浮動小数点または整数の制約に制限されます。 連想配列 - ハッシュマップやBSTと同様に、使用できる他の多くの連想配列がありますが、これらの制約に一致するものは見つかりません。 たぶん私が見逃している明らかな方法があるかもしれませんが、それは潜在的に不可能かもしれないと私は思います。あなたの考えは何ですか?

2
ハッシュテーブルのサイズ変更時にサイズ変更のカスケードを回避するにはどうすればよいですか?
個別のチェーンや線形/二次プローブなどの従来の衝突解決方法では、キーのプローブシーケンスを任意に長くすることができます。テーブルの負荷係数を低く維持することで、キーの確率を短くして、高い確率で維持できます。したがって、再ハッシュ中の衝突は負荷率に影響を与えないため、問題にはなりません。 ただし、カッコウハッシュ(および最悪の場合のO(1)ルックアップ時間を提供する他の方法)では、キーのプローブシーケンスが長くなりすぎると、サイズ変更が発生する必要があります。しかし、リハッシュ中にキーがシャッフルされると、1つのキーに対して長すぎるプローブシーケンスが作成され、別のサイズ変更が必要になる場合があります。確率は小さいですが、特に優れたハッシュ関数を使用すると、確率は低くなります。 再ハッシュ中に完全なハッシュ関数を明示的に生成するのではなく、この方法でサイズ変更をカスケードできないようにする方法はありますか?おそらく特定の衝突解決スキームに固有ですか?これまでに出会った文献は、問題を完全に覆い隠しているようです。ハッシュテーブルを成長させるだけでなく、縮小することにも興味があることを覚えておいてください。

2
ハッシュテーブルO(1)はハッシュ速度をどのように考慮していますか?
ハッシュテーブルは、特定の容量で言う単純な連鎖と倍加を使用してを償却すると言われています。Θ(1)Θ(1)\Theta(1) ただし、これは要素の長さが一定であることを前提としています。要素のハッシュを計算するには、要素を、時間がかかります。ここで、は長さです。lΘ(l)Θ(l)\Theta(l)lll ただし、要素を区別するには、少なくともビットの長さの要素が必要です。そうでなければ、鳩の巣の原理によって、それらは区別されません。要素のビットを通過するハッシュ関数は時間かかります。LG N LG N Θ (LG N )nnnlgnlg⁡n\lg nlgnlg⁡n\lg nΘ(lgn)Θ(lg⁡n)\Theta(\lg n) 代わりに、入力のすべての部分を使用する合理的なハッシュ関数を考慮したハッシュテーブルの速度は、実際にはであると言えるでしょうか。では、なぜ実際にハッシュテーブルが文字列や大きな整数などの可変長要素を格納するのに効率的であるのでしょうか。Θ(lgn)Θ(lg⁡n)\Theta(\lg n)

3
ハッシュテーブルの値はどのように物理的にメモリに格納されますか?
質問: 効率的に使用され、値を頻繁に再配置する必要がない場合に、ハッシュテーブルの値はどのようにメモリに格納されますか? 私の現在の理解(間違っている可能性があります): ハッシュテーブルに3つのオブジェクトが格納されているとしましょう。それらのハッシュ関数はこれらの値を生成します: 0 10 20 これらのオブジェクトのポインタは、次のメモリアドレスに格納されません。これらのオブジェクト間には大きなギャップがあるためです。 startOfHashTable + 0 startOfHashTable + 10 startOfHashTable + 20 ハッシュテーブル上のWikipediaの記事は、「インデックス」とは、のように計算されていることを述べています: hash = hashfunc(key) index = hash % array_size したがって、私の例では、インデックスは次のようになります。 0%3 = 0 10%3 = 1 20%3 = 2 これにより、前述の大きなギャップが解消されます。このモジュロスキームを使用しても、ハッシュテーブルにさらにオブジェクトを追加すると問題が発生します。ハッシュテーブルに4番目のオブジェクトを追加すると、インデックスを取得するために%4を適用する必要があります。これで、過去に行った%3はすべて無効になりませんか?以前の%3のすべてを%4の場所に再配置する必要がありますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.