===================================================================
RCS file: /home/cvs/OpenXM/doc/Attic/genkou19991125.tex,v
retrieving revision 1.5
retrieving revision 1.9
diff -u -p -r1.5 -r1.9
--- OpenXM/doc/Attic/genkou19991125.tex	1999/12/18 13:59:50	1.5
+++ OpenXM/doc/Attic/genkou19991125.tex	1999/12/18 18:02:03	1.9
@@ -53,7 +53,7 @@ SM 層、 CMO 層で定義されているデータ以外にも
 $B前述の MP や OpenMath の XML, binary 表現も
 OX 層に埋め込まれて送られるわけであるが、
 どのようなデータが埋め込まれているかは、
-OX 層の先頭の tag を見れば判別できるようになっている。
+OX 層の先頭にある tag を見れば判別できるようになっている。
 
 
 \section{OpenXM の計算の進行方法}
@@ -118,27 +118,105 @@ OpenXM では 8 bit 単位で $( \mbox{\tt 00 0
 $( \mbox{\tt 14 00 00 00})_{2^8}$ と表す方法がある。
 この表現方法の違いはクライアントとサーバの最初の接続時に
 双方の合意で決定することになっている。なお、合意がない場合には
-前者の表現方法(以後、これを network byte order と呼ぶ)を
+前者の表現方法(以後、この表現方法を network byte order と呼ぶ)を
 使うことになっている。
 また、負の数を表現する必要があるときには、
+2 の補数表現を使うことになっている。
 
 表現したい多倍長整数の絶対値を 2 進数で表した場合の桁数を $n$ と
 したとき、次にくるデータは $[(n+31)/32]$ を 32 bit の整数となる。
-これは多倍長整数の絶対値を $2^32$ 進数で表した場合の桁数ととってもよい。
+これは多倍長整数の絶対値を $2^{32}$ 進数で表した場合の桁数ととってもよい。
 ただし、表現したい数が負の場合はこの 32 bit の整数値は 2 の補数表現で負になる。
 
 %表現したい多倍長整数が負であってもこれ以降の説明は正の場合と
 %変わらないので、以後多倍長整数は正とみなす。
 
-表現したい多倍長整数の絶対値が $2^32$ 進数で $(b_0 b_1 ...)_{2^32}$
+表現したい多倍長整数の絶対値が $2^{32}$ 進数で $(b_0 b_1 ...)_{2^{32}}$
 と表せるとき、次にくるデータは $b_0$, $b_1$, $\cdots$ を
 32 bit の整数で表現した値となる。
 
+ここで具体例をだそう。
+$4294967298 = 1 \times 2^{32} + 2$ を network byte order の多倍長整数で
+表現すると、
+\begin{center}
+	{\tt 00 00 00 14 00 00 00 02 00 00 00 02 00 00 00 01}
+\end{center}
+となる。また、同じ表現方法で $-1$ を表現すると、
+\begin{center}
+	{\tt 00 00 00 14 ff ff ff ff 00 00 00 01}
+\end{center}
+となる。
 
 
 \section{MathCap について}
 
+%前節で見たように、 1 つのメッセージの長さは決まっていない。
+サーバおよびクライアント双方ともに OpenXM で規定されている
+すべてのメッセージを理解できるわけではない。
+そこで、 OpenXM では相手の理解可能なメッセージを
+収得する方法を用意している。
+CMO 層で定義されている MathCap データは
+理解可能なメッセージを表すデータであり、
+要求されればサーバは MathCap をスタックに積む。
+また、クライアントから MathCap をサーバへ送ることもでき、
+MathCap をサーバとクライアントで交換することによって、
+お互いに相手の理解不可能なメッセージを送ってしまうことを
+防ぐことができる。
+なお、 MathCap のデータの中では CMO 層で定義されている
+32 bit 整数、文字列、リスト構造を使っており、
+MathCap を理解できるためには必然的にこれらも理解できる
+必要がある。
+
+OpenXM 対応版の asir である ox\_asir が返す MathCap を
+以下に示す。なお、 $a_0$, $a_1$, $\cdots$, $a_n$ を要素に
+持つリスト構造を {\tt [$a_0$, $a_1$, $\cdots$, $a_n$]} 、
+文字列 ``string'' を {\tt "string"} 、 32 bit 整数を
+それに対応する 10 進数の整数で示す。
+
+%↓手で作ったので間違えている可能性あり。
+%%古いバージョン。差し替えの必要あり。
+\begin{verbatim}
+[ [199901160,"ox_asir"],
+  [276,275,258,262,263,266,267,268,274
+    ,269,272,265,264,273,300,270,271],
+  [ [514,[1,2,3,4,5,2130706433,2130706434
+          ,17,19,20,21,22,24,25,26,31,27,33,60]],
+    [2144202544,[0,1]]
+  ]
+]
+\end{verbatim}
+
+この MathCap データのリスト構造の最初の要素はサーバの情報が入っている。
+この最初の要素がまたリスト構造となっており、
+最初の要素はバージョンナンバーを、次の要素はサーバの名前を表している。
+
+次の要素は SM 層で定義されている理解可能なデータを表している。
+サーバの動作に対するデータは SM 層ではすべて 32 bit の整数で
+表されており、この 2 番めの要素は理解可能な SM 層のデータに
+対する 32 bit 整数のリストとなっている。
+
+最後の要素は理解可能なデータを表している。
+%このリストの要素はまたリストとなっており、
+この最後の部分もまたリストとなっており、
+あるデータ形式で理解可能なものを表現したリストを要素としている。
+{\tt [514,[1, 2, $\cdots$]]} の最初の 514 はこのリストが CMO 形式
+での理解可能なデータを表していることを示しており、
+その後のリストでは CMO 層で定義されているデータのうち、
+理解可能なデータの tag が並んでいる。
+前節で CMO 形式では多倍長整数を表す tag が 20 であることを述べたが、
+このリストに 20 が含まれているので、 ox\_asir は CMO 形式の
+多倍長整数が理解できることがわかる。
+
+最初のリストがサーバの情報を表しているといったことが理解できることと、
+データが受け取れることとはまったく別物であるので
+注意する必要がある。
+
+
 \section{security 対策}
+
+OpenXM では
+
+
 
 \section{他のプロジェクト}