changeset 16:33f56478f7a4

commit
author tatsuki
date Thu, 09 Feb 2017 18:32:01 +0900
parents 33d8077a5d45
children 4d66607c369c
files differential.tex indexupdate.tex master_paper.pdf
diffstat 3 files changed, 19 insertions(+), 14 deletions(-) [+]
line wrap: on
line diff
--- a/differential.tex	Thu Feb 09 17:25:56 2017 +0900
+++ b/differential.tex	Thu Feb 09 18:32:01 2017 +0900
@@ -34,7 +34,7 @@
 \begin{center}
 \caption{Jungleに新しく実装したAPI}
 \begin{tabular}{|p{15em}|p{24em}|}        \hline
-{\small {\tt JungleTree createNewDifferentialTree(String treeName)}} &{\small Jungleに新しくDifferential Jungle Tree を生成する。木の名前が重複した場合、生成に失敗しnullを返す。}     \\ \hline
+{\small {\tt createNewDifferenceTree(String treeName)}} &{\small Jungleに新しくDifferential Jungle Tree を生成する。木の名前が重複した場合、生成に失敗しnullを返す。}     \\ \hline
 \end{tabular}
 \label{createDifTreeAPI}
 \end{center}
@@ -64,9 +64,9 @@
 \section{末尾ノードを使用した木の編集}
 Differential Jungle Treeの木の編集は、Differential Jungle Tree Editorを使用して行う。
 Differential Jungle Tree Editor は、Default Jungle Tree Editor と違い、生成時に新しい木構造(Sub Tree)を自身の中に構築する。
-そして、木の編集は、Editor が保持している木構造に対して行う。
-編集後、Commitを行う際に構築した木構造を、 Differential Jungle Tree の末尾ノードにAppendする。
-そうすることで、木の複製を行う必要がないため、木の変更の手間はO(1)で行える。
+そして、木の編集は、自身が保持している木構造に対して行う。
+編集後、Commiti を行う際に構築した木構造を、 Differential Jungle Tree の末尾ノードにAppendする。
+その際木の複製は行わない。
 
 また、Differential Treeは自身が保持している木構造に対する変更しか行えないため、一度Commitした木に対して変更は行えない。
 図\ref{fig:EditDifTree}にDifferential Jungle Treeの編集の流れを記述する。
@@ -86,7 +86,8 @@
 \end{enumerate}
 
 Editor が保持している木構造に最後に追加したノードが、新しい木の末尾ノードとなる。
-また、Differential TreeのIndexのアップデートは、Commit 時に Editor が保持している木構造のデータをIndexに追加するだけで良い。
+また、Differential Jungle Tree は、木の編集時複製を行わないため、
+Indexのアップデートは、Editor が保持している木構造のデータをIndexに追加するだけで良い。
 
 
 
@@ -97,7 +98,7 @@
 ここで、{\tt Tree ver1}に対して、検索をIndexを使わず行った場合、
 本来{\tt Tree ver1}に存在しないノード3・4も検索対象に含まれてしまう。
 
-そこで、その版の木が持つ末尾ノード以下のSub Treeを検索対象から除外する検索を持つ、Differential Interface Traverser を実装した。
+そこで、その版の木が持つ末尾ノード以下のSub Treeを検索対象から除外する、Differential Interface Traverser を実装した。
 Differential Interface Traverser を用いて Index を使用せず木の全探索を行った場合、{\tt Tree ver1}に存在しないノード3・4は検索対象から省かれる。
 
 \begin{figure}[htpb]
@@ -114,7 +115,7 @@
 
 
 \section{Differential Jungle Treeの整合性}
-Default Jungle Tree への Commit は、 編集後の木のデータを持つ TreeContext を作り、編集前の木が持つ TreeContext と入れ替えることで行われる。
+Default Jungle Tree への Commit は、 編集後の木のデータを持つ TreeContext を作り、編集前の木が持つ TreeContext Atomic に入れ替えることで行われる。
 しかし、Differentail Jungle Tree への Commit は、Default Jungle Tree のCommit と異なり、
 TreeContext の入れ替えと、Editor が保持している木構造の末尾ノードへの Append の2つのプロセスからなる。
 TreeContext の入れ替えに関しては、 Default Jungle Tree と同じように行う。
--- a/indexupdate.tex	Thu Feb 09 17:25:56 2017 +0900
+++ b/indexupdate.tex	Thu Feb 09 18:32:01 2017 +0900
@@ -4,14 +4,18 @@
 なので、高速にIndexの更新を行うため、Index の差分アップデートを実装した。
 
 \section{差分 Updateの実装}
-Indexの差分 Updateを行うためには、編集を行ったノードを覚えておく必要がある。
+Jungle は木の編集を行う際に、編集を行うノードと、経路にあるノードの複製を行い新しい木構造を構築するため、
+Index の中には、編集後の木には存在しない複製前のノードが残ってしまう。
+なので、Index の差分 Update を行う際には、それらのノードを Index から削除して、新しく複製されたノードを Index に登録する必要がある。
+
+そのためには、編集を行ったノードを覚えておく必要がある。
 そこで、Jungle Tree Editor 内に、編集を加えたノードを覚えておくためのリストを定義した。
 Editor は、木に編集を加えたら、リストに編集前のノードを保存する。
-そして、Commit 時にリストにあるノードを使って Index の Update を行う。
+そして、Commit 時にリストにあるノードを使って Index の中に残っている、編集後の木に存在しないノードを削除する。
+その後、新しく作られたノードを Index に登録して Update は終了する。
 
-Indexの Update は、削除と挿入の2つのプロセスで行われる。
 
-\section{Indexの削除}
+\section{編集前のノードの削除}
 IndexのUpdateを行う際、初めに、編集後の木に存在しないノードをIndexから削除する。
 削除の対象は、変更を加えたノードと、ルートから変更を加えたノードまでの経路にあるノードである。
 ノードの削除は、以下の手順で行われる。
@@ -25,7 +29,7 @@
 \item 1 - 5をリストからノードが無くなるまで続ける。
 \end{enumerate}
 
-Parent Index から値が取得できない場合は、以降ルートまでのノードは Index から削除されていることが保証されているため、削除を終えて次のノードに行っても構わない。
+Parent Index から値が取得できない場合は、自身からルートまでの経路にあるノードは Index から削除されていることが保証されているため、削除を終えて、リストに入っている次のノードの削除処理を行っても構わない。
 
 
 
@@ -39,14 +43,14 @@
 \item 登録されている場合、そのノード以下のSub Treeは、全てIndexに登録されているので、次のノードに移動する。
 \item 登録されていなかった場合、自身が保持している値をIndexに登録する
 \item 自身と子ノードをParent Index に登録する。
-\item 全てのノードを挿入するまで 2 - 5 を繰り返す。
+\item 自身の子ノードを取得したノードとして2に戻る。
+\item 全てのノードを登録したら終了する。
 \end{enumerate}
 
 
 \section{Full Update との使い分け}
 Indexの差分Updateは、不要なノードの削除と新しく木に追加されたノードの挿入を行っているため、1ノードに対する処理は Full Updateより大きい。
 少ない回数編集を行った後の Commit は、差分Updateの方が高速に行えるが、多くの編集を行った後の Commitだと、Full Updateの方が高速に動作する可能性がある。
-そのため、Commit 前の、木の編集回数によって、Indexの更新方法を変更したほうが高速に Update を行える可能性がある。
 これに関しての検証は、性能測定の章に記述する。
 
 \newpage
Binary file master_paper.pdf has changed