Spell e.g. and i.e. as such.

Small wording and fonting improvements.


git-svn-id: http://svn.cactuscode.org/arrangements/CactusPUGH/PUGHSlab/trunk@127 10716dce-81a3-4424-a2c8-48026a0d3035

1 files changed, 7 insertions, 7 deletions

diff --git a/doc/documentation.tex b/doc/documentation.tex
index 1c1f70d..6eeb349 100644
--- a/doc/documentation.tex
+++ b/doc/documentation.tex
@@ -39,7 +39,7 @@ or hyperslab selections. A hyperslab is defined in this context a subset of a
 global CCTK array, with its own dimension, origin, direction, and extents.\\
 
 Another possible use of hyperslabs is the implementation of certain boundary
-conditions (eg. reflection). By having the boundary condition code calling
+conditions (e.g.\ reflection). By having the boundary condition code calling
 generic hyperslab get/put calls, it can be written without special knowledge
 about driver specifics.\\
 
@@ -98,13 +98,13 @@ In general, a hyperslab get/put operation is done in a three-level scheme:
 
 If the {\tt Hyperslab\_Get*()/Hyperslab\_Put*()} get passed a mapping for a
 global hyperslab, a global, synchronuous operation will be performed
-(ie. it must be called in sync by every processor). All input arguments must be
+(i.e., it must be called in sync by every processor). All input arguments must be
 consistent between processors.
 
 
 \subsection{Defining a hyperslab mapping}
 
-An M-dimensional hyperslab subspace mapped into an N-dimensional space
+An $M$-dimensional hyperslab subspace mapped into an $N$-dimensional space
 can be specified either by coordinates on the physical grid or by index
 points on the underlying computational grid.
 
@@ -199,12 +199,12 @@ CTK_INT Hyperslab_LocalMappingByPhys (
 
     The hyperslab location is identified by its origin (lower left corner),
     the direction vectors starting from the origin and spanning the hyperslab
-    in the N-dimensional space, and its extents (size of the hyperslab in
+    in the $N$-dimensional space, and its extents (size of the hyperslab in
     each direction).
 
     There are {\tt hdim} direction vectors (one for each hyperslab axis) with
     {\tt vdim} elements. The direction vectors are given in grid index points and must
-    not be a linear combination of each other. The {\tt direction} argument must
+    be linearly independent. The {\tt direction} argument must
     be passed as an array {\tt direction[vdim\_index + hdim\_index*vdim]}
     ({\tt vdim} is the fastest changing dimension).
 
@@ -382,7 +382,7 @@ CCTK_INT Hyperslab_PutList (CCTK_POINTER_TO_CONST       GH,
     For {\tt Hyperslab\_GetXXX()}, there may be either exactly one processor
     providing the hyperslab data (in this case, its processor ID must be given
     in {\tt proc}), or all all processors will get the extracted hyperslab data
-    (an invalid (ie. negative) processor ID should be given as {\tt proc}, or
+    (an invalid (i.e., negative) processor ID should be given as {\tt proc}, or
     {\tt procs} is passed as a NULL pointer).
     For {\tt Hyperslab\_PutXXX()}, there may only be one processor providing
     the hyperslab data to be distributed to all others.
@@ -478,7 +478,7 @@ CCTK hyperslab API as described in section \ref{specification}:
     Local hyperslabs will always include processor-boundary ghostzones.
     The {\tt hsize\_local, hoffset\_local} information returned by the
     hyperslab mapping routines should be used to locate the locate hyperslab
-    within the global grid (eg. during a recombination of several local
+    within the global grid (e.g.\ during a recombination of several local
     hyperslabs into a single global one).
 \end{enumerate}