--- a/abstract.tex	Thu Feb 09 19:28:45 2017 +0900
+++ b/abstract.tex	Fri Feb 10 10:24:52 2017 +0900
@@ -5,15 +5,22 @@
 データベース自体も、表に特化したKey Value Store、Jsonなどの不定形のデータ構造を格納するように機能拡張されてきている。
 しかし、プログラム中のデータは複雑な構造をメモリ上に構築しており、これらの方法でもまだギャップがある。
 
-そこで当研究室では、煩雑な設計を行わず、プログラム内部に木構造を格納できるデータベースJungleを提案している。
-また、Jungleは、木構造の変更を非破壊的、つまり、元の木を保存しつつ、新しい木を構築する方法を取り、
+そこで当研究室では、これらの問題を解決した、煩雑な設計を行わずプログラム内部に木構造を格納できるデータベース Jungle を提案している。
+Jungleは、木構造の変更を非破壊的、つまり、元の木を保存しつつ、新しい木を構築する方法を取り、
 木のルートをアトミックに入れ替えることでトランザクションを実現する。
 プログラムは、この木を内部のデータ構造として直接取り扱うことができるので、読み出し時にデータベースに問い合わせる必要がない。
-Jungleは分散構成も可能である。
+Jungleは、全体の整合性ではなく、木ごとに閉じた局所的な整合性を保証している。
+また、整合性のある木同士をマージすることで新しい整合性のある木を作り出すことも可能であるため、データの伝搬も容易である。
 
-Jungleは、読み込みは高速に行える反面、書き込みは木の形に依存しており、最悪の場合O(n)となってしまう。
+Jungleは、読み込みは高速に行える反面、書き込みの手間は木の形・大きさに依存しており、最悪の場合O(n)となってしまう。
 また、Indexの構築も大幅なネックとなっていた。
 そこで、本研究では、Jungleの木の構築・編集機能の改善を行う。
 その後、実際にJungleを使用したアプリケーションを開発・運用する。
 
+改善後行った性能測定では、木の編集機能の高速化を確認できた。
+また、PostgreSQL・MongoDBと読み込み速度の比較を行った。
+結果、これらのDB以上の性能を確認できた。
+
+残された課題として木の設計手法の確立、 メモリ内にある木構造の破棄、データの書き出しの高速化等についての課題が確認された.
+
 \end{abstract}

--- a/abstract_eng.tex	Thu Feb 09 19:28:45 2017 +0900
+++ b/abstract_eng.tex	Fri Feb 10 10:24:52 2017 +0900
@@ -1,3 +1,27 @@
 \begin{abstract_eng}
-英語のアブスト
+Relational DataBase(RDB) has problem of impedance mismatch.
+Exist an OR Mapper that can use database records as objects in program.
+and DB has been expand such as table specialization KVS and Json correspondence.
+However program Construction complexity structure on memory.
+Database has gap.
+
+Laboratory develops database Jungle that solves these problems.
+Jungle doesn't destroy the tree structure.
+Construction a new tree while saving trees.
+Jungle transaction by atomic exchange the root of the tree.
+Program can use Jungle tree and not ask database.
+Jungle jas Consistency for every tree.
+Possible create new consistent tree by merge consistent trees together.
+Easy to send data.
+
+Jungle can read fast.
+However writing speed depend on Structure of tree and tree size.
+worst case O(n).
+And create Index is slow
+This research will improve Jungle editing function.
+After, Develop and use applications using Jungle.
+
+benchmark was confirm the speedup of the tree editing function.
+And Jungle able to read data faster than PostgreSQL and MongDB.
+
 \end{abstract_eng}

--- a/appendix.tex	Thu Feb 09 19:28:45 2017 +0900
+++ b/appendix.tex	Fri Feb 10 10:24:52 2017 +0900
@@ -2,9 +2,6 @@
 \addcontentsline{toc}{chapter}{発表文献}
 
 \begin{itemize}
-\item{Java による授業向け画面共有システムの設計と実装, 大城信康, 谷成雄(琉球大学), 河野真治(琉球大学), オープンソースカンファレンス2011 Okinawa, Sep, 2011}
-\item{Continuation based C の GCC 4.6 上の実装について,\\ 大城信康, 河野真治(琉球大学), \\ 第53回プログラミング・シンポジウム, Jan, 2012}
-\item{GraphDB 入門 TinkerPop の使い方,\\大城信康, 玉城将士(琉球大学),\\第15回 Java Kuche, Sep, 2012}
-\item{ディペンダブルシステムのための木構造を用いた合意形成データベースの提案と実装,\\ 大城信康, 河野真治(琉球大学), 玉城将士(琉球大学), 永山 辰巳(株式会社 Symphony),\\ 情報処理学会システムソフトウェアとオペレーティング・システム研究会(OS), May, 2013}
-\item{Data Segment の分散データベースへの応用, \\ 大城信康, 杉本優(琉球大学), 河野真治(琉球大学), \\ 日本ソフトウェア科学会30回大会 (2013年度) 講演論文集, Sep, 2013}
+\item{非破壊的木構造データベースJungleとその評価,金川竜己 , 河野真治(琉球大学), オープンソースカンファレンス2015 Okinawa, May, 2015}
+\item{ソフトウェア内部で使用するのに適した木構造データベースJungle, \\ 金川竜己, 武田和馬(琉球大学), 河野真治(琉球大学), \\ 第58回プログラミング・シンポジウム, Jan, 2017}
 \end{itemize}

--- a/benchMark.tex	Thu Feb 09 19:28:45 2017 +0900
+++ b/benchMark.tex	Fri Feb 10 10:24:52 2017 +0900
@@ -28,12 +28,11 @@
 
 \section{TreeMapの測定}
 5章で実装した TreeMap の性能測定を行う。
-比較対象には、 TreeMap 実装前に Jungle 使用していた Functional Java の TreeMap を使用する。
+比較対象には、 TreeMap 実装前に Jungle で使用していた Functional Java の TreeMap を使用する。
 
-図\ref{find}は、 TreeMap に対する値の Get のベンチマークである。
-TreeMap に対して1000回行う際の時間を測定した。
+図\ref{find}は、 TreeMap に1000回の Get を行った際のベンチマークである。
 X 軸は Get を行う TreeMap のノード数。
-Y 軸は かかった時間を表す
+Y 軸は Get にかかった時間を表す
 
 \begin{figure}[htpb]
 \begin{center}
@@ -45,7 +44,7 @@
 
 \ref{find}より、Functional Java の TreeMap と比較して、 Jungle の TreeMap の方が非常に高速に動いている。
 理由として、Jungle の TreeMap は、検索対象の値を持つノードを、二分探索木の探索アルゴリズムに則り探索するのに対し、
-Functional Java の TreeMap は、検索対象のノードがルートに来る木を構築し、ルートを返す。といったアルゴリズムを採用していため、
+Functional Java の TreeMap は、検索対象のノードがルートになる木を構築し、ルートを返す。といったアルゴリズムを採用していため、
 探索アルゴリズムの差が図\ref{find}の結果に出た。
 その他の処理についても、Jungleの TreeMap の方が高速に動作していた。
 
@@ -70,7 +69,7 @@
 しかし、Jungleでは木に変更を加える際、毎回 Commit を行うわけでなく、 基本的に複数回変更を行った後、一気にCommit を行う。
 差分 Update は、変更を加えたノードを記憶し、 Commit 時に Index の更新を行う。
 一方、Full Update では、 Commit を行うまでに木に加えた変更の数に関係なく、新しい Index を構築する。
-よって、 Commit を行うまでに行う木の編集回数が増えた場合、 Index の Full Update と 差分 Update では、Full Update の方が、Index の Update にかかる時間の短縮率が大きい。
+よって、 Commit を行うまでに行う木の編集回数が増えた場合、 Index の Full Update と 差分 Update では、差分 Update の方が、Index に対して多くの変更を行うことになる。
 そのため、Commit を行うまでの 木に対する変更回数によっては、 Full Update の方が高速に Index の構築を行える可能性がある。
 
 そこで、図\ref{index2}に、Commit を行うまでに行った木の編集回数と、 Index の Update 速度の測定結果を記述する。
@@ -89,13 +88,13 @@
 
 
 \newpage
-\section{正順線形木の構築時間の測定}
+\section{正順の線形木の構築時間の測定}
 7章で実装した、 Differential Jungle Tree の性能測定を行う。
 比較対象は、Default Jungle Tree を用いる。
 図\ref{dfTree}は、正順の木を構築するまでにかかった時間のベンチマークである。
 X 軸は、構築した木のノード数。
 Y 軸は、構築にかかった時間を表す。
-また、木を構築する正確な時間を測定するため、Index は作っていない。
+また、木のみを構築する時間を測定するため、Index は作っていない。
 
 \begin{figure}[htpb]
 \begin{center}
@@ -106,7 +105,9 @@
 \end{figure}
 
 図\ref{dfTree}より、Default Jungle Tree より、Differential Jungle Tree の方が高速に木の構築している。
-これは、Default Jungle Tree が、木を構築する際に複製を行うのに対し、Differential Jungle Tree は破壊的に木を構築しているからである。
+これは、Default Jungle Tree が、木を構築する際に複製を行うのに対し、Differential Jungle Tree は複製を行っていないからである。
+期待通りの結果が出たといえる。
+
 
 \section{Red Black Jungle Tree の測定}
 8章で実装した、Red Black Jungle Tree の性能測定を行う。

--- a/differential.tex	Thu Feb 09 19:28:45 2017 +0900
+++ b/differential.tex	Fri Feb 10 10:24:52 2017 +0900
@@ -2,7 +2,7 @@
 Jungleは木の編集時、編集を行うノードと、経路にあるノードの複製を行う。
 そのため、木の編集の手間は、木構造の形によって異なる。
 特に線形の木は、全てのノードの複製を行うため、変更の手間がO(n)になってしまう。
-そこで、Jungle は、線形の木をO(1)で変更する、PushPopの機能を持つ。
+そこで、Jungle は、線形の木をO(1)で変更するPushPopの機能を持つ。
 PushPopとは、ルートノードの上に新しいルートノードを付け加えるAPIである(図\ref{fig:pushpop})。
 すると、木の複製を行う必要が無いため、木の変更の手間がO(1)でノードの追加を行える。
 
@@ -122,7 +122,7 @@
 TreeContext の入れ替えに関しては、 Default Jungle Tree と同じように行い、
 末尾ノードへの Editor が持っている木構造の Append は、 TreeContext の入れ替えが成功した後に行う。
 TreeContext の入れ替えに失敗した場合は、Append を行わず Commit は失敗する。
-そうすることで、Commit が、別 Thread で行われているCommitと競合した際に、
+そうすることで、別 Thread で行われているCommitと競合した際に、
 TreeContext を入れ替えた Thread と別 Thread が Append を行い、木の整合性が崩れることを回避している。
 
 

--- a/indexupdate.tex	Thu Feb 09 19:28:45 2017 +0900
+++ b/indexupdate.tex	Fri Feb 10 10:24:52 2017 +0900
@@ -29,12 +29,12 @@
 \item 1 - 5をリストからノードが無くなるまで続ける。
 \end{enumerate}
 
-Parent Index から値が取得できない場合は、自身からルートまでの経路にあるノードは Index から削除されていることが保証されているため、削除を終えて、リストに入っている次のノードの削除処理を行っても構わない。
+Parent Index に現在のノードが登録されていない場合は、現在のノードからルートまでの経路にあるノードは Index から削除されていることが保証されているため、削除を終えて、リストに入っている次のノードの削除処理を行っても構わない。
 
 
 
 \section{Indexへのノードの挿入}
-Indexから不要なノードを削除した後は、新しく作られたノードをIndexに挿入する。
+Indexから不要なノードを削除した後は、木の編集時新しく作られたノードをIndexに挿入する。
 ノードの挿入は、以下の手順で行われる。
 
 \begin{enumerate}

--- a/introduciton.tex	Thu Feb 09 19:28:45 2017 +0900
+++ b/introduciton.tex	Fri Feb 10 10:24:52 2017 +0900
@@ -7,19 +7,19 @@
 データベース自体も、表に特化したKey Value Store、Jsonなどの不定形のデータ構造を格納するように機能拡張されてきている。
 しかし、プログラム中のデータは複雑な構造をメモリ上に構築しており、これらの方法でもまだギャップがある。
 
-そこで当研究室では、煩雑な設計を行わず、プログラム内部に木構造を格納できるデータベースJungleを提案している。
-また、Jungleは、木構造の変更を非破壊的、つまり、元の木を保存しつつ、新しい木を構築する方法を取り、
+
+そこで当研究室では、これらの問題を解決した、煩雑な設計を行わずプログラム内部に木構造を格納できるデータベース Jungle を提案している。
+Jungleは、木構造の変更を非破壊的、つまり、元の木を保存しつつ、新しい木を構築する方法を取り、
 木のルートをアトミックに入れ替えることでトランザクションを実現する。
 プログラムは、この木を内部のデータ構造として直接取り扱うことができるので、読み出し時にデータベースに問い合わせる必要がない。
-Jungleは分散構成も可能である。
+Jungleは、全体の整合性ではなく、木ごとに閉じた局所的な整合性を保証している。
+また、整合性のある木同士をマージすることで新しい整合性のある木を作り出すことも可能であるため、データの伝搬も容易である。
 
-Jungleは、読み込みは高速に行える反面、書き込みは木の形に依存しており、最悪の場合O(n)となってしまう。
+Jungleは、読み込みは高速に行える反面、書き込みの手間は木の形・大きさに依存しており、最悪の場合O(n)となってしまう。
 また、Indexの構築も大幅なネックとなっていた。
 そこで、本研究では、Jungleの木の構築・編集機能の改善を行う。
-
 その後、実際にJungleを使用したアプリケーションを開発・運用する。
 
-
 \section{インピータンスミスマッチ}
 インピータンスミスマッチとは、プログラム中のデータ構造とRDBの表構造の間に生まれるギャップのことである。
 例えばRPGゲーム中のユーザが持つアイテムという単純なものでも、RDBではユーザとアイテムの組をキーとする巨大な表として管理することになる。

--- a/jungle.tex	Thu Feb 09 19:28:45 2017 +0900
+++ b/jungle.tex	Fri Feb 10 10:24:52 2017 +0900
@@ -3,7 +3,7 @@
 初めに Jungle の特徴である非破壊的木構造の説明をし、その後提供しているAPIについて述べる。
 
 
-\section{非破壊的木構造}
+\section{破壊的木構造と非破壊的木構造}
 Jungle は、非破壊的木構造という特殊な木構造を持つ。
 本節では、破壊的木構造と非破壊的木構造の編集・メリットデメリットについて記述する。
 
@@ -57,7 +57,7 @@
   \end{center}
 \end{figure}
 
-また、過去の木を保持する場合、非破壊的木構造は、木の複製後編集を行う必要がある。
+また、過去の木を保持する場合、破壊的木構造は、木の複製後編集を行う必要がある。
 一方、非破壊的木構造は過去の木を上書きしないため、過去の木のルートノードを保持するだけで良い。
 
 \section{NodePath}
@@ -115,8 +115,7 @@
 
 \section{JungleTree}
 Jungleは複数の木の集合で出来ている。
-Jungleの木は、自身の情報をTreeContext というオブジェクトに保持している。
-TreeContextとは、木構造のデータ(表\ref{TreeContext1})を持つクラスである。
+Jungleの木は、自身の情報をTreeContext という木構造のデータを持つ(表\ref{TreeContext1})オブジェクトに保持している。
 
 \newpage
 \begin{table}[htb]
@@ -157,7 +156,7 @@
 
 \section{TreeNode}
 Jungleの木構造は、複数のノードの集合で出来ている。
-ノードは、自身の子のListと属性名と属性値の組でデータを持つ。
+ノードは、自身の子のリストと属性名と属性値の組でデータを持つ。
 ノードに対するアクセスは、表\ref{TreeNodeAPI}に記述されているAPIを用いて行われる。
 
 \begin{table}[htb]
@@ -225,6 +224,8 @@
 表\ref{editor}にJungle Tree Editorインターフェースに定義されているAPIを記述する。
 また、表\ref{editor}に記述しているAPIは全て、{\tt Either<Error,JungleTreeEditor>} を返す。
 
+\newpage 
+
 \begin{table}[htb]
   \begin{center}
     \caption{Editorに実装されているAPI}
@@ -289,7 +290,7 @@
 Jungle Tree Editor を用いて木に変更を加えた後は、Commit を行う必要がある。
 Commit は、前節で記述した Jungle Tree Editor が持つ関数 {\tt success()} を使用することで行われる。
 
-Commit を行うと、Jungle Tree Editor が保持している編集後の木構造のデータを持つ TreeContext を作成する。
+Commit を行うと、Jungle Tree Editor は、保持している編集後の木構造のデータを持つ TreeContext を作成する。
 そして、編集前の木が持つ TreeContext と 新しく作った TreeContext を置き換えることで Commit は完了する。
 TreeContext の置き換えは、編集を行っている他の Thread と競合した際に、木の整合性を保つために以下の手順で行われる。
 
@@ -355,11 +356,9 @@
 2行目で、検索を行う関数 {\tt find()} を使用する。
 今回は、Index を使って、属性名 {\tt "belong"} 属性値 {\tt "ryukyu"} を持つノード取得し、
 3 - 5行目で定義されたクエリに渡す。
-
 そして、クエリの中で属性名 {\tt "name"} 属性値 {\tt "kanagawa"} を持つノードかどうかを確かめる。
 
 結果として、属性名 {\tt "belong"} 属性値{\tt "ryukyu"}と、属性名 {\tt "name"} 属性値{\tt kanagawa}の2つのデータを持つノードの {\tt Iterator} が取得できる。
-
 検索の際に使用する Index の実装については次節に記述する。
 
 \begin{comment}
@@ -382,7 +381,7 @@
 Jungleは、非破壊的木構造というデータ構造上、過去の版の木構造を全て保持している。
 よって、全ての版に独立したIndexが必要となるため、前の版のIndexを破壊すること無く、Indexを更新する必要がある。
 既存のTreeMapでは、一度Indexの複製を行ない、その後更新する必要があったため、Indexの更新オーダーがO(n)となっていた。
-その問題を解決するため、非破壊TreeMapを自作し、それを用いてIndexの実装を行った。
+その問題を解決するため、Java 上で関数型プログラミングを行えるライブラリである、 Functional Java の TreeMapを使用し、それを用いてIndexの実装を行った。
 このTreeMapは、Jungleと同じようにルートから変更を加えたノードまでの経路の複製を行い、データの更新を行った際、前の版と最大限データを共有した新しいTreeMapを作成する。
 Jungleとの違いは、木の回転処理が入ることである。
 これにより複数の版全てに対応したIndexをサポートすることが可能になった。

--- a/jungleUpdatePoint.tex	Thu Feb 09 19:28:45 2017 +0900
+++ b/jungleUpdatePoint.tex	Fri Feb 10 10:24:52 2017 +0900
@@ -1,5 +1,5 @@
 \chapter{データベースJungleに\\新たに追加した構成要素}
-本章では、本研究で既存のJungleに追加した、大まかな構成要素の概要を記述する。
+本章では、本研究でJungleに追加した、大まかな構成要素の概要を記述する。
 
 \section{非破壊 Red Black Treeの実装}
 JungleのIndexは、Java上で関数型プログラミングが行えるFunctional Java の非破壊 TreeMapを使って実装されていた。
@@ -25,10 +25,12 @@
 
 
 \section{Red Black Jungle Tree}
-Default Jungle Treeにおいて、Indexの更新は大きな手間となっている。
-Indexに使用する属性名が1種類で、木構造の形がデータを表現していない場合、Jungle Tree自身をIndexとしたほうが、効率的に木構造を構築できる。
-そこで、Red Black Treeの性質を組み込んだRed Black Jungle Treeの実装を行った。
-Red Black Jungle Tree は、生成時に木のバランスを取る際に使用する属性名(Balance Key)を指定する。
-そして、ノードの挿入・削除時、Balance Keyを用いて木のバランスを取る。
+Jungle は、木に編集を加えた際、編集を加えたノードと、経路にあるノードの複製を取る。
+その為、木の編集の手間は、木の大きさにも依存している。
+最適なバランスの取れた木構造を構築することで、編集の手間をn(logN)にすることは可能だが、
+Default Jungle Tree だと、木の形をユーザーが Path を用いて、バランスを取る必要ある。
+しかし、ユーザーが全ての木構造の形を把握し、バランスの取れた木を構築するのは難しい。
+そこで、自動で木のバランスを取り、最適な木構造を構築する機能を Jungle Tree に実装した。
+バランスは、木の生成時に特定の {\tt Balance Key} 決定し、それを使って行う。
 
 木の探索に関してはBalanceKeyを用いた場合N(Logn)、そうでない場合はO(n)で行える。

Binary file master_paper.pdf has changed

--- a/master_paper.tex	Thu Feb 09 19:28:45 2017 +0900
+++ b/master_paper.tex	Fri Feb 10 10:24:52 2017 +0900
@@ -8,7 +8,7 @@
 %\input{dummy.tex} %% font
 
 \jtitle{ソフトウェア内部で使用するのに適した 木構造データベース Jungle}
-\etitle{英語タイトル}
+\etitle{Tree Structure Database Jungle to Use Inside of software}
 \year{平成28年度}
 \affiliation{\center%
   \includegraphics[clip,keepaspectratio,width=.15\textwidth]
@@ -25,7 +25,7 @@
 \end{minipage}}
 \markleftfoot{% 左下に挿入
   \begin{minipage}{.8\textwidth}
-  	英語タイトル
+  	Tree Structure Database Jungle to Use Inside of software
 \end{minipage}}
 
 \newcommand\figref[1]{図 \ref{fig:#1}}

--- a/redBlackJungleTree.tex	Thu Feb 09 19:28:45 2017 +0900
+++ b/redBlackJungleTree.tex	Fri Feb 10 10:24:52 2017 +0900
@@ -2,16 +2,16 @@
 Jungle は、木に編集を加えた際、編集を加えたノードと、経路にあるノードの複製を取る。
 その為、木の編集の手間は、木の大きさにも依存している。
 最適なバランスの取れた木構造を構築することで、編集の手間をn(logN)にすることは可能だが、
-Default Jungle Tree だと、木の形をユーザーが Path を用いて、バランスを取る必要ある。
-しかし、ユーザーが全ての木構造の形を把握し、バランスの取れた木を構築するのは難しい。
-そこで、自動で木のバランスを取り、最適な木構造を構築する機能を Jungle Tree に実装した。
+Default Jungle Tree の場合、木の形をユーザーが Path を用いて、バランスを取る必要ある。
+しかし、ユーザーが全ての木構造の形を把握し、バランスの取れた木を構築するのは困難である。
+そこで、自動で木のバランスを取り、最適な形の木構造を構築する機能を持つ Red Black Jungle Tree に実装した。
 バランスは、木の生成時に特定の {\tt Balance Key} 決定し、それを使って行う。
 木のバランスを取るアルゴリズムは、前述した非破壊 TreeMap と同じものを使用する。
 
 しかし、木の編集を加えた際、木がどのようにバランスを取るか予想するのは困難であるため、木の構造で、組織構造等のデータを表現するのは難しい。
 なので、この機能が使えるのは、木の構造自体がデータを表現していない場合に限る。
 
-また、Red Black Jungle Tree は、自身の木構造が、{\tt Balance Key} を使った Index と同じ働きを持つため、木の Commit 時に別途 Index を構築する必要が無い、といったメリットもある。
+また、自身の木構造が、{\tt Balance Key} を使った Index と同じ働きを持つため、木の Commit 時に別途 Index を構築する必要が無い、といったメリットもある。
 
 
 \section{Red Black Jungle Treeの作成}
@@ -40,9 +40,16 @@
 
 \section{NodePath の拡張}
 Red Black Jungle Treeは、ノードを追加・削除するたびに木のバランスが行われ、各ノードの Path が変わってしまう。
-その為、数字を使った NodePath では、編集を加える際、編集対象のノードの Path をいちいち調べる必要がある。
-その問題を解決するために、NodePath を拡張した RedBlackTreeNodePath を作成し 属性名 BalanceKey 属性値 valueのペアでノードを指定できるようにした。
-RedBlackTreeNodePathは、生成時コンストラクタの引数にString型のBalanceKeyとByteBuffer型のvalueを取る。
+その為、数字を使った NodePath では、編集を加える際、編集対象のノードの Path を毎回調べる必要がある。
+その問題を解決するために、NodePath を拡張した Red Black Tree Node Path を作成し 属性名 BalanceKey 属性値 valueのペアでノードを指定できるようにした。
+RedBlackTreeNodePathは、引数にString型のBalanceKeyとByteBuffer型のvalueを取る。
+ソースコード\ref{createRedBlackNodePath}に、属性名 {\tt "balanceKey"} 属性値 {\tt value}を持つノードを指定する Red Black Tree Node Path を作成するサンプルを記述する。
+
+\begin{lstlisting}[frame=lrbt,numbers=left,label=createRedBlackNodePath,caption=Red Black Tree Node Pathの生成]
+String balanceKey = "balanceKey";
+ByteBuffer value = ByteBuffer.wrap(("value").getBytes());
+NodePath path = new RedBlackTreeNodePath(balanceKey,value);
+\end{lstlisting}
 
 \section{Red Black Jungle Treeの編集}
 
@@ -79,21 +86,15 @@
 \end{table}
 
 \newpage
-Red Black Jungle Tree にノードを追加し、値を挿入するサンプルコードを記載する(ソースコード\ref{src:rbtEdit})。
+Red Black Jungle Tree にノードを挿入するサンプルコードを記載する(ソースコード\ref{src:rbtEdit})。
 
 \begin{lstlisting}[frame=lrbt,label=src:rbtEdit,caption=RedBlackJungleTreeの編集例,numbers=left]
 String balanceKey = "balanceKey";
+ByteBuffer value = ByteBuffer.wrap(("Elphelt").getBytes());
 JungleTree tree = jungle.createNewRedBlackTree("TreeName", balanceKey)
 JungleTreeEditor editor = tree.getJungleTreeEditor();
-NodePath path = new RedBlackTreeNodePath();
-ByteBuffer balanceValue = ByteBuffer.wrap(("Elphelt").getBytes());
-Either<Error, JungleTreeEditor> either = editor.addNewChildAndPutAttribute(path, 0, balanceKey, balanceValue);
-if (either.isA())  return either.a();
-editor = either.b();
-NodePath rbtPath = new RedBlackTreeNodePath(balanceKey,balanceValue));
-String key = "key";
-ByteBuffer value = ByteBuffer.wrap(("value").getBytes())
-Either<Error, JungleTreeEditor> either = editor.putAttribute(rbtPath, key, testPutValue);
+NodePath path = new RedBlackTreeNodePath(balanceKey,value));
+Either<Error, JungleTreeEditor> either = editor.addNewChildAt(path,0);
 if (either.isA())  return either.a();
 editor = either.b();
 either = editor.success();
@@ -101,6 +102,15 @@
 
 
 ソースコード\ref{src:rbtEdit}の解説を以下に記す。
+
+1 - 2行目で、挿入するノードが持つ 属性名 {\tt balanceKey} と属性値 {\tt value}を作成する。
+3行目で、木の名前が{\tt "TreeName"} バランスを {\tt balanceKey} を使って行う Red Black Jungle Tree を作成する。
+4行目で、Editorを取得し、5行目でPath作成している。
+6行目で、Path で指定した属性名 {\tt balanceKey} 属性値 {\tt value} の組の値を持つノードを木に挿入している。
+そして9行目で、今回行った変更を Commit して編集を終了している。
+
+
+\begin{comment}
 \begin{enumerate}
 \item 木のバランスに使用するbalanceKeyを宣言する。
 \item 1で宣言したbalanceKeyを使って、Red Black Jungle Treeを{\tt TreeName}という名前で作成する。
@@ -118,9 +128,9 @@
 \item 成功していた場合{\tt either}から、編集後の木を持つEditorを取得する。
 \item 編集を木にCommitする。
 \end{enumerate}
+\end{comment}
 
-Red Black Jungle Tree は、Index を持たないため、木の編集時 Index を更新する必要がない。
-つまり、Default Jungle Tree より高速に木の変更を行える。
+Red Black Jungle Tree は、木の編集時 Index を更新しないので、Default Jungle Tree より高速に木の変更を行える。
 
 
 \section{Jungle Red Black Treeの検索}

--- a/redBlackTree.tex	Thu Feb 09 19:28:45 2017 +0900
+++ b/redBlackTree.tex	Fri Feb 10 10:24:52 2017 +0900
@@ -34,7 +34,7 @@
 
 \section{非破壊 TreeMap のAPI}
 
-非破壊 TreeMap は、値の挿入・削除を行うために、表\ref{RedBlackTreeAPI}に記述してあるAPIを提供している。
+非破壊 TreeMap は、値の検索・挿入・削除を行うために、表\ref{RedBlackTreeAPI}に記述してあるAPIを提供している。
 \begin{table}[htb]
 \begin{center}
 \caption{非破壊 TreeMap に実装されているAPI}
@@ -77,7 +77,7 @@
 {\LARGE データ挿入時のバランス ケース1}
 \vspace{0.2in}
 
-バランス時、ノードを挿入した位置がルートだった場合、ルートノードの色を黒に変更することで木のバランスを取る。
+バランス時、ノードinsの位置がルートだった場合、ルートノードの色を黒に変更することで木のバランスを取る。
 ルートノードの色を黒に変更しても、左右のSub Treeの黒の個数が一つ増えるだけなので、Red Black Treeの条件は守られる。
 
 
@@ -118,7 +118,7 @@
 {\LARGE データ挿入時のバランス ケース4}
 \vspace{0.2in}
 
-バランス時、ノードinsの親の親ノードAが黒かつ、ノードAのノードins側の子ノードBが赤かつ、逆側の子ノードCが黒かつ、ノードinsがノードBの木の中心側にある場合、ノードBを中心に外側に回転処理を行い(図\ref{fig:RedBlackTreeInsert3})、次節に記述するバランス5を行う。
+バランス時、ノードinsの親の親ノードAが黒かつ、ノードAのノードins側の子ノードBが赤かつ、逆側の子ノードCが黒かつ、ノードinsがノードBの木の中心側の子である場合、ノードBを中心に外側に回転処理を行い(図\ref{fig:RedBlackTreeInsert3})、次節に記述するバランス5を行う。
 その際、ノードBをノードinsとして扱う。
 
 \begin{figure}[htpb]
@@ -135,7 +135,7 @@
 {\LARGE データ挿入時のバランス ケース5}
 \vspace{0.2in}
 
-バランス時、ノードinsの親の親ノードAが黒かつ、ノードAのノードins側の子ノードBが赤かつ、逆側の子ノードCが黒かつ、ノードinsが木の外側の子の場合、ノードAを中心に内側に回転処理を行い、回転後ノードAとノードBの色を入れ替える。
+バランス時、ノードinsの親の親ノードAが黒かつ、ノードAのノードins側の子ノードBが赤かつ、逆側の子ノードCが黒かつ、ノードinsが木の外側の子の場合、ノードAを中心にノードinsと逆側に回転処理を行い、回転後ノードAとノードBの色を入れ替える。
 
 \begin{figure}[htpb]
 \begin{center}

--- a/thanx.tex	Thu Feb 09 19:28:45 2017 +0900
+++ b/thanx.tex	Fri Feb 10 10:24:52 2017 +0900
@@ -1,3 +1,14 @@
 \chapter*{謝辞}
 \addcontentsline{toc}{chapter}{謝辞}
-謝辞を書く
+
+本研究を行うにあたりご多忙にも関わらず日頃より多くの助言, ご指導をいただきました河野真治准教授に心より感謝いたします.\\
+研究を行うにあたり, 並列計算環境の調整, 意見, 実装に協力いただいた谷成 雄さん, 杉本 優さん, 並びに並列信頼研究室の全てのメンバーに感謝いたします.\\
+様々な研究や勉強の機会を与えてくださった, 株式会社Symphonyの永山辰巳さん, 同じく様々な助言を頂いた森田育宏さんに感謝いたします.
+様々な研究に関わることで自身の研究にも役立てることが出来ました.\\
+最後に, 大学の修士まで支えてくれた家族に深く感謝します.
+
+\begin{flushright}
+
+2017年 3月 \\ 金川竜己
+
+\end{flushright}