地図と辞書の違いは何ですか？
マップは、キーを値にマップするデータ構造であることを知っています。辞書は同じではありませんか？地図と辞書の違いは何ですか1？
1.私はそれらが言語XまたはYでどのように定義されているかを尋ねていません（これは一般的に人々がSOでここで求めていることのようです）。
同じことに対する2つの用語：
- "Map"はJava、C++で使用されます
- "Dictionary"は.Net、Pythonで使用されます
- 「連想配列」はPHPで使用されます
"Map"は正しい数学用語ですが、 関数型プログラミング で別の意味を持つため、避けられます。
一部の言語では、他の用語（Javascriptの「オブジェクト」、Rubyの「ハッシュ」、Luaの「テーブル」）を使用していますが、これらはすべて別個の意味を持っていますプログラミングでもそうなので、私はそれらを避けるでしょう。
詳細については here を参照してください。
1つは他の古い用語です。通常、「辞書」という用語は、「マップ」という数学用語が定着する前に使用されていました。また、辞書にはキータイプの文字列が含まれる傾向がありますが、それはどこでも100％真実ではありません。
私の2セント。
辞書はJavaの抽象クラスですが、Mapはインターフェースです。 Javaは複数の継承をサポートしないため、クラスがディクショナリを拡張する場合、他のクラスを拡張することはできません。
そのため、Mapインターフェイスが導入されました。
辞書クラスは廃止され、Mapの使用が推奨されます。
通常、マップはハッシュテーブルによってサポートされていると想定しています。順序付けられていないストアを意味します。辞書は注文されたストアを意味します。
Trie と呼ばれるツリーベースの辞書があります。
LISPでは、次のようになります。
(a (n (d t)) n d )
単語をカプセル化します：
- a
- そして
- 蟻
- と
- 広告
上から葉への横断は、言葉を生み出します。
本当に同じことではありません。マップは辞書のサブセットです。辞書は here 挿入、削除、および検索機能を持つものとして定義されています。 Javaで使用されるマップ（ this による）は、値へのキーマッピングが厳密に1対1の関数としてマップされるという要件を持つ辞書です。辞書には、1つの値への複数のキーマップ、または複数の値への1つのキーマップ（hasttableでのチェーンなど）、たとえばTwitterハッシュタグ検索があります。
より「現実の世界」の例として、辞書で単語を検索すると、同じ単語の定義がいくつか得られ、別のエントリ（他の単語を参照）を指すエントリが見つかった場合、多くの単語定義の同じリストの場合。現実の世界では、マップははるかに広く、名前の場所または座標の名前を持つことができますが、最も近い隣人または他の属性（人口など）を見つけることもできるため、おそらくグラフベースの実装を持つマップタイプですが、特に値の最近傍と他の属性はすべて値のデータメンバーである可能性があるため、常にキーと値のペアのみを想定するのが最善です。
Javaマップは、1対1の要件にもかかわらず、値がコレクション自体として一般化される場合、または値が単に他の場所に保存されたコレクションへの参照である場合、一般化辞書のようなものを実装できます。
JavaメンテナーはADT定義のメンテナーではなく、Javaの決定はJava専用であることを忘れないでください。
かなり一般的なこの概念の他の用語：連想配列とハッシュ。
はい、それらは同じです。「連想配列」をミックスに追加できます。
HashtableまたはHashを使用することは、実装を指します。
純粋に理論的なレベルで。
辞書は、リンクされた値を見つけるために使用できる値です。マップは、別の値を見つける方法に関する指示を提供する値です
単純な配列にも正しい値にマッピングするインデックスがあるため、非線形アクセスを許可する（つまり、最初に取得するか最後に取得する）コレクションはすべてマップです。したがって、ディクショナリはマップの一種ですが、マップは可能な機能のはるかに広い範囲です。
実際には、通常は名前を定義するマッピング関数であるため、HashMapは、ハッシュアルゴリズムを使用してキーを値にリンクするマップされたデータ構造です。Dictionaryでは、キーと値のリンク方法を指定しませんリンクリスト、ツリー、またはその他のアルゴリズムを介して保存できます。使用法の終わりから、あなたは通常、それらが機能するアルゴリズムだけを気にしませんので、汎用辞書を使用し、アルゴリズムのタイプを強制する必要がある場合にのみ他の構造の1つにシフトします
主な違いは、Mapでは、すべてのエントリ（値とキーのペア）に一意のキーが必要であることです。衝突が発生した場合、つまり、新しいエントリが既にコレクションにあるエントリと同じキーを持っている場合、衝突処理が必要です。
通常、Separate Chainingのいずれかを使用して衝突を処理します。またはLinear Probing。
Dictionaryを使用すると、複数のエントリを同じキーにリンクできます。
マップがセパレートチェーンを実装している場合、ディクショナリに似ている傾向があります。
この質問への回答は、使用した特定の言語またはシステムでより具体的な意味が与えられた用語を見たプログラマーによって複雑になりますが、質問は「理論上」の言語に依存しない比較を要求します。これはコンピューティングサイエンス用語。
用語の説明
オックスフォード大学Dictionary of Computer Scienceリスト：
dictionary_要素の挿入と削除、およびメンバーシップのテストをサポートできる要素のセットを表すデータ構造
- たとえば、一連の要素{A、B、C、D ...}を挿入でき、削除を開始でき、"is C present？"。
コンピューティングサイエンスのmapの概念は、数学用語mappingに基づいています。これは、Oxford Dictionaryで次のように定義されています。
mapping特定のセット（ドメイン）の各要素を2つ目のセット（範囲）の1つ以上の要素に関連付ける操作。
- そのため、mapデータ構造は、所定のセットの要素-既知のマップ内の "キー"から、2番目のセットの1つ以上の要素へ-関連する「value（s）」として知られています。
- "... or 2番目のセットの複数の要素"アスペクトが実装でサポートできるのは、2つの異なる方法です：
- 多くのマップ実装はキーの一意性を強制し、各キーを1つの値にのみ関連付けることができますが、その値は、より単純なデータ型の多くの値を含むデータ構造そのものになる可能性があります。 {{1、{"one"、 "ichi"}、{2、{"two"、 "ni"}}}は、文字列のペアで構成される値を示しています。
- 他のマップ実装では、同じ値または異なる値にマッピングする重複キーを許可します。これにより、機能的に「関連付け...各[キー]要素...と... [複数] [値]要素」のケースが満たされます。たとえば、{{1、 "one"}、{1、 "ichi"}、{2、 "two"}、{2、 "ni"}}。
辞書と地図の対比
したがって、上記の厳密なComp Sciの用語を使用すると、辞書はの場合にのみ辞書になりますインターフェイスは、すべての辞書に必要のない追加の操作をサポートします：
個別のkeyおよびvalueコンポーネントを持つ要素を保存する機能
retrieveキーのみが指定された値を取得する機能
些細なひねり：
- マップインターフェースは、{key、value}ペアがコンテナ内にあるかどうかのテストを直接サポートしない場合があります。これは、要素がたまたま{key、value}ペアである辞書の要件です。マップにはキーをテストする機能さえないかもしれませんが、最悪の場合、キーによる値取得の試行が成功したか失敗したかを見ることができ、気になったらキーが期待値を取得したかどうかを確認できます。
明確に視聴者に伝えます
all上記のすべてにもかかわらず、上記で説明した厳密なコンピューティングサイエンスの意味で辞書を使用する場合、聴衆が最初に従うことを期待したり、用語を共有して擁護するときに感銘を受けたりしないでください。質問（およびその賛成票）は、ほとんどのプログラマーの経験において"dictionary"が "map"と同義である可能性を示しています。より広く明確な用語を選択してください。理解された：例えば.
- 連想コンテナ：値の取得とキーによる消去を伴うキー/値ペアを格納するコンテナ
- ハッシュマップ：関連付けられたコンテナのハッシュテーブル実装
- 一意のキーを強制するハッシュセット：要素/値を個別のキー/値コンポーネントを含むものとして扱うことなく要素/値を格納するディクショナリのハッシュテーブル実装。要素の複製は挿入できません
- 重複キーをサポートするバイナリツリーマップのバランス：...
Comp Sciの用語と特定の実装の相互参照
C++標準ライブラリ
- マップ：
map、multimap、unordered_map、unordered_multimap - その他の辞書：
set、multiset、unordered_set、unordered_multiset - 注：イテレータまたは
std::findを使用すると、要素を消去し、array、vectorのメンバーシップをテストできます。list、dequeなどですが、O（N）で要素を見つけることは非常に非効率的であるため、コンテナインターフェイスはそれを直接サポートしません。挿入/消去のケースは非効率的であり、これらの操作をサポートすることは、コンテナが暗示する意図的に制限されたAPIを損なう-例えばdequesは、一部のキーに関してではなく、前面と背面でのみ消去/ポップをサポートする必要があります。検索を調整するためにコードでより多くの作業を行う必要があるため、プログラマーはより効率的な検索でコンテナーデータ構造に切り替えるようになります。
...後で他の言語を追加するか、自由に編集してください...