質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

Webサイト

一つのドメイン上に存在するWebページの集合体をWebサイトと呼びます。

Q&A

解決済

2回答

1771閲覧

ユーザー間のつながりを示すアルゴリズム

退会済みユーザー

退会済みユーザー

総合スコア0

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

Webサイト

一つのドメイン上に存在するWebページの集合体をWebサイトと呼びます。

0グッド

0クリップ

投稿2016/09/14 12:37

非常に大きなソーシャルネットワーキングのデータ構造を設計することを考えます。
二人のユーザ間のつながりを示すアルゴリズムをどのように設計すればいいでしょうか?

解答例
個々のユーザを一つのノードとして、お互いのユーザが友達であれば2つのノード間に辺を作る、という方法でグラフを作ります。
二人のユーザ間につながりがあるかどうか調べたい時は、一人のユーザーから始めて単純に幅優先探索を行います。

大規模なサービスの場合、一つのマシンに全てのデータを保持することはまず不可能です。
友達同士が同じマシン上にいないかもしれないからです。
そこで、代わりに友人のリストをIDのリストに置き換えて、次のように巡回する。
1 それぞれのIDに対して、int machine_index = getMachineIDForUser(personID);
2 machine_indexのマシンに移る
3 そのマシン上でPerson friend = getPersonWithID(person_id);

これが概略になります。
以下のコードはこの概略を実現しているだけなので、載せる必要はないかもしれないですが、一応載せておきます。

Java

1import java.util.HashMap; 2 3public class Server { 4 HashMap<Integer, Machine> machines = new HashMap<Integer, Machine>(); 5 HashMap<Integer, Integer> personToMachineMap = new HashMap<Integer, Integer>(); 6 7 public Machine getMachineWithId(int machineID) { 8 return machines.get(machineID); 9 } 10 11 public int getMachineIDForUser(int personID) { 12 Integer machineID = personToMachineMap.get(personID); 13 return machineID == null ? -1 : machineID; 14 } 15 16 public Person getPersonWithID(int personID) { 17 Integer machineID = personToMachineMap.get(personID); 18 if (machineID == null) { 19 return null; 20 } 21 Machine machine = getMachineWithId(machineID); 22 if (machine == null) { 23 return null; 24 } 25 return machine.getPersonWithID(personID); 26 } 27}

Java

1import java.util.ArrayList; 2 3public class Person { 4 private ArrayList<Integer> friends; 5 private int personID; 6 private String info; 7 8 public String getInfo() { return info; } 9 public void setInfo(String info) { 10 this.info = info; 11 } 12 13 public int[] getFriends() { 14 int[] temp = new int[friends.size()]; 15 for (int i = 0; i < temp.length; i++) { 16 temp[i] = friends.get(i); 17 } 18 return temp; 19 } 20 public int getID() { return personID; } 21 public void addFriend(int id) { friends.add(id); } 22 23 public Person(int id) { 24 this.personID = id; 25 } 26}

Java

1import java.util.HashMap; 2 3public class Machine { 4 public HashMap<Integer, Person> persons = new HashMap<Integer, Person>(); 5 public int machineID; 6 7 public Person getPersonWithID(int personID) { 8 return persons.get(personID); 9 } 10}

普通の幅優先探索ではノードクラスに調べたかどうかを記録するフラグを用意しますが、今回はそのようにはしたくありません。
同時に複数の探索が行われる可能性がありますので、データ自体を捜査する方法はよくないからです。
フラグを用意する代わりに、ハッシュテーブルを使ってノードの探索と探索済みかどうかのチェックを行うようにします。

ここで質問です。
「フラグを用意する代わりに、ハッシュテーブルを使ってノードの探索と探索済みかどうかのチェックを行うようにします。」
についてなんですが、どこかのクラスにハッシュテーブルを用意して、探索したPersonはそのハッシュテーブルに格納して、次に探索するPersonを決めるときにそのハッシュテーブルに格納されているかどうかで探索するかどうかを決めるということでしょうか?
そして、Personに対応させる値は探索済みかどうかを示す数字などが入ってくるのでしょうか?
もしこの方法でやるとするなら、この方法って早いのでしょうか?
フラグがあれば、基本的には0か1か(ここでは0と1にしましたが、いろいろなフラグがあると思います。)で0だったら探索、1だったら、次のPersonに進む、というようなことができると思うのですが、ハッシュテーブルに含まれているかどうかというのは高速に処理できるのでしょうか?
さらに、ハッシュテーブルに入れる意義もよくわかりません。
というのは、配列でも同様のことはできるように思えるからです。値として、フラグのようなものを設置するのは無駄なように思えます。

解答お願いします。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答2

0

ベストアンサー

ハッシュテーブルに入れる意義...配列でも同様のことはできる

配列は0~size-1までの連続した整数に対する対応値を得る手段として最速といえます。質問者さんの意図は「PersonのIDがMIN_PERSON_ID~MAX_PERSON_IDの連続(or ほぼ連続)になっていてIDをindexに使えるなら配列でよくてわざわざハッシュテーブルにする意義はないのでは?」ということでしょうか。そう仮定して配列とハッシュテーブルを比較すると・・・

配列

  1. アクセスは最速
  2. PersonのIDのようなある範囲内の連続した整数値がキーでなければならない
  3. 探索範囲が狭くても広くても探索の最初から最後まで全ユーザーの大きさの配列が必要

ハッシュテーブル

  1. アクセスは配列よりは低速(ただしテーブルのSIZEに依存しないある小さな一定値で済む)
  2. キーは整数に限らずなんでもよい
  3. サイズは登録するキーの数×2倍(default)程度しか必要としない

配列は最速アクセスだが必要メモリー量が大きくなり、ハッシュテーブルは配列アクセスほど早くないものの充分高速なアクセス速度で必要メモリーははるかに小さくて済むという点を考えるとハッシュテーブルを選択することに充分価値があるといえます。

フラグのようなものを設置するのは無駄なように思えます。

少し勘違いされてるような気がします。ハッシュテーブルにはHashMap以外にもキーだけを登録するHashSetというものもあります。今回の問題であればHashMap<Person,Boolean>ではなくHashSet<Person>でいいのです。

投稿2016/09/14 15:02

KSwordOfHaste

総合スコア18392

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/09/15 13:45

前提条件として、一人のユーザから幅優先探索をしている状況を想定していますよね? そうした場合に 「最初から最後まで全ユーザーの大きさの配列が必要」というのはどういう意味なのでしょうか? また、「サイズは登録するキーの2倍程度しか必要としない」というのもよくわかりません。 例えば、あるユーザーの友達が10人だった時、登録するキーの数は10以下ですが、ハッシュテーブルのサイズはこの時20ということでしょうか? そして、配列の場合は必要とするサイズは10になりませんか?
KSwordOfHaste

2016/09/16 08:01

>「最初から最後まで全ユーザーの大きさの配列が必要」というのはどういう意味 「ユーザーIDを配列のindexとして使う」と想定した場合の話です。 なんでこういう規模を想定したかといえば、巨大SNSである一人のユーザーから初めてその友人、その友人の友人・・・と探索すると探索範囲が数千人とか数万人の範囲に広がることが普通にありそうだからです。その想定で探索済みユーザーを配列の先頭から順に格納する方法はswordoneさんの回答にあるとおりハッシュテーブルの方がだんぜん有利なのです。 >「サイズは登録するキーの2倍程度しか必要としない」 これはJavaのハッシュテーブルの実装上の特徴です。ハッシュテーブルは内部にテーブルを持ってますが登録されたキーの数がこの内部テーブルのサイズの1/2を超えた場合に内部テーブルを2倍の大きさに拡張します。つまり最悪で登録キー数Nに対してN*2だけ内部テーブルの容量が必要になるのです。2倍でもいいという根拠は探索人数が大きくなった場合の探索スピードの高速化のための代償として許容できるという意味です。探索済み人数が1万人だとすると配列なら1万エントリー、ハッシュテーブルなら最悪2万エントリーの容量が確かに必要です。容量は確かにそうですが配列を使うと1回の探索に平均5000回の比較が必要で普通許容できません。ハッシュテーブルは登録数の2倍の容量が必要ですが、1回の探索で数回程度の比較で済むことが期待できますので2倍容量が必要でもOKという考え方です。 >あるユーザーの友達が10人だった時... 最初は10人だけですけど、友人の友人といった関係を辿っていくに従って覚えておくべき探索済みユーザの数はどんどん増えていくはずです。それは幅優先でも深さ優先でも同じです。
退会済みユーザー

退会済みユーザー

2016/09/17 02:16

お返事ありがとうございます。 幅優先探索の場合、データ構造としてキューを使っていると思います。 そうすると、ユーザーAの友達がB,C,Dの三人いるとすれば、B,C,Dをこの順でキューに格納すると、その後にBの友達をC,Dの後に追加し、次にCの友達をキューに追加し、、という形になります。 つまり、キューは次のように変化していきます。 B,C,D -> C,D,B1,B2,B3 -> D,B1,B2,B3,C1,C2 B1やB2はBの友達、C1やC2はCの友達です。 幅優先探索ならこのように探索していくので、全ユーザの大きさほどは必要ないと思われます。 もちろん最悪の場合は全ユーザーの大きさが必要になるかもしれないですが、そんな場合はほとんど考えられなく、実際的には全ユーざーの数よりもはるかに小さい大きさの配列で十分なように思えますが、どうでしょうか? >サイズは登録するキーの2倍程度しか必要としない デフォルトではload factorは0.75ですから、元の配列の3/4が埋まった時に配列をより大きな配列にコピーするという処理をするわけですが、これとは違う話をしているのでしょうか? 回答の中ではload factorの値を0.5としてる気がしたのですが。。
KSwordOfHaste

2016/09/17 05:13

>幅優先探索ならこのように探索していくので、全ユーザの大きさほどは必要ないと思われます。 二分木のように循環がない有向グラフの探索であればおっしゃるとおり探索にはキューだけで充分ですが、本問題については「循環がない」という仮定はおけませんね?循環を許す探索方式では「探索済みかどうかを覚えておく仕組み」が必要になりますのでこれまでの議論はそこに関してのものです。 >サイズは登録するキーの2倍程度しか必要としない 失礼、色々間違ってましたw; デフォルトではご指摘どおり0.75ですね。ロードファクターを超えると内部テーブルが2倍に拡張されますので、より厳密にはロードファクターが0.5なら最悪4倍、ロードファクターが0.75なら最悪8/3倍(2.7倍)、1.0なら最悪2倍程度ですね。よって通常は2~3倍程度と思っておけばよいと思います。
退会済みユーザー

退会済みユーザー

2016/09/17 10:41

全ユーザーを格納できる大きさの配列では、探索済みかどうかを覚えておけるのでしょうか?
KSwordOfHaste

2016/09/17 15:31

personIDが0~N-1と仮定すると、大きさNのbooleanの配列doneを用意しておけば覚えられます。 done[personID] = true; //このユーザーが探索済みであることを覚える
退会済みユーザー

退会済みユーザー

2016/09/18 09:12

回答ありがとうございました。
guest

0

配列を使った場合、対象のPersonが探索済みかを調べるために、配列を最初から最後まで順番に調べないといけません。
ハッシュテーブルの場合、ハッシュによって格納する場所がある程度決まるので、探す場合もある程度決まった場所を探すことができます。そのため、数が多くなるとハッシュテーブルの方が速く調べられます。

投稿2016/09/14 12:47

swordone

総合スコア20649

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/09/14 13:46

>ハッシュによって格納する場所がある程度決まるので、探す場合もある程度決まった場所を探すことができます。 ここがよくわかりませんでした。 ハッシュテーブルでは、keyとvalueの他にhash値を保持するのは知っていますが、hash値によって格納する場所がある程度決まるとは一体どういう意味なのでしょうか?
swordone

2016/09/14 16:46

例えばHashMapは、データを格納しているものの実体は配列です。 この配列の何番にデータを入れるかを決定する要素の一部がハッシュなのです。 Javaの規約で、equals()によって等しいと判定されるオブジェクトはhashCode()による返り値を等しくする必要があります。これにより、等しいオブジェクトは必ず同じハッシュを返し、配列の同じ場所を参照することになるのです。 普通の配列を使い、どこに何が入っているかわからない状態で都度最初から順番に探索するよりも早く探索できます。
退会済みユーザー

退会済みユーザー

2016/09/15 13:47

途中オブジェクトの話が出ていますが、このオブジェクトはHashMap<K, V>のKのことを言っておられるのでしょうか? それともVでしょうか? また、HashMap<K,V>の場合、実態は二次元配列ということでしょうか?
swordone

2016/09/15 14:44

K、つまりキーの事です。
退会済みユーザー

退会済みユーザー

2016/09/16 07:08

回答ありがとうございます。 この場合、HashSetを用いるのでしょうか?
swordone

2016/09/17 16:20

今回の場合、キーとなるPersonに値を関連付ける必要はなく、「探索した」事実があれば十分なので、HashSetが適しているでしょう。
退会済みユーザー

退会済みユーザー

2016/09/18 09:12

回答ありがとうございました。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問