[Swift-commit] r3756 - text/parco10submission

noreply at svn.ci.uchicago.edu noreply at svn.ci.uchicago.edu
Wed Dec 8 22:10:37 CST 2010


Author: dsk
Date: 2010-12-08 22:10:36 -0600 (Wed, 08 Dec 2010)
New Revision: 3756

Modified:
   text/parco10submission/ResponseToReviews.txt
   text/parco10submission/paper.tex
Log:
more fixes based on reviewer comments


Modified: text/parco10submission/ResponseToReviews.txt
===================================================================
--- text/parco10submission/ResponseToReviews.txt	2010-12-09 02:02:37 UTC (rev 3755)
+++ text/parco10submission/ResponseToReviews.txt	2010-12-09 04:10:36 UTC (rev 3756)
@@ -148,13 +148,21 @@
 language, so perhaps "SwiftScript" should be replaced by "Swift"
 everywhere.
 
->>> <<<
+>>>
 
+this has been done.
+
+<<<
+
 2. It's a bit awkward that "single assignment" is used in section 2.1
 but not defined until section 2.3.
 
->>> <<<
+>>> 
 
+fixed.
+
+<<<
+
 3. The example on p. 5 appears erroneous, it seems the rotate
 procedure should have an angle input in addition to the image input
 (this is corrected on p.6).
@@ -185,6 +193,8 @@
 
 RDBMS removed.
 FMRI fixed.
+GRAM doesn't seem to need explanation, it's cited where first used.
+still need to think about acronyms in Figure 1.
 
 <<<
 
@@ -200,8 +210,13 @@
 7. The mysterious numbers '12, 1000, 1000, "81 3 3"' in example 4.1
 might merit an explanation.
 
->>> <<<
+>>> 
 
+It seems clear that these are parameters passed into the app program;
+I don't think explanation is needed
+
+<<<
+
 8. The Figure numbering in the text of section 4.1 needs correction.
 
 >>> 
@@ -215,8 +230,12 @@
 In the text of section 4.1 "n x n" should be in a different font and
 "n2" is clearly wrong.
 
->>> <<<
+>>> 
 
+fixed.
+
+<<<
+
 10. Section 4.2, what is an "emblem experiment"?
 
 >>> <<<
@@ -224,8 +243,12 @@
 11. The margins in sections 4.2 and 4.4 need fixing as some lines
 run completely off the page.
 
->>> <<<
+>>> 
 
+fixed in 4.2 - not sure about the state of 4.4 yet
+
+<<<
+
 12. "Karajan" is mentioned several times, there really should be short
 definition of it and a reference to it in the bibliography.
 
@@ -238,6 +261,7 @@
 >>> 
 
 Ref 8 fixed.
+page numbers and years still need to be fixed.
 
 <<<
 

Modified: text/parco10submission/paper.tex
===================================================================
--- text/parco10submission/paper.tex	2010-12-09 02:02:37 UTC (rev 3755)
+++ text/parco10submission/paper.tex	2010-12-09 04:10:36 UTC (rev 3756)
@@ -175,7 +175,7 @@
 ongoing and future work in the Swift project, and we offer concluding
 remarks in Section~\ref{Conclusion}.
 
-\section{The SwiftScript language}
+\section{The Swift language}
 \label{Language}
 
 The Swift programming model is data-oriented: it encapsulates the
@@ -238,8 +238,12 @@
 procedures.
 
 Swift variables hold either primitive values, files, or collections of
-files. All variables are \emph{single assignment}, which provides the
-basis for Swift's model of procedure chaining.  Procedures are
+files. All variables are \emph{single-assignment} (meaning
+that they must be assigned to exactly one value during execution),
+which provides the
+basis for Swift's model of procedure chaining.  (Note that Swift arrays are not
+strictly single-assignment, but each element of an array is, as discussed in
+Section~\ref{ordering}.) Procedures are
 executed when their input parameters have all been set from existing
 data or prior procedure executions.  Procedures are chained by
 specifying that an output variable of one procedure is passed as the
@@ -314,15 +318,15 @@
 
 The examples above have used the type \verb|image| without a
 definition of that type. We can declare it as a \emph{marker type},
-which has no structure exposed to SwiftScript:
+which has no structure exposed to Swift:
 
 \begin{verbatim}
    type image;
 \end{verbatim}
 
 This does not indicate that the data is unstructured; it indicates
-that the structure of the data is not exposed to SwiftScript.
-SwiftScript will treat variables of this type as individual opaque
+that the structure of the data is not exposed to Swift.
+Swift will treat variables of this type as individual opaque
 files.
 
 With mechanisms to declare types, map variables to data files, and
@@ -389,9 +393,10 @@
 procedure, using each execution's output as the input to the next step.
 
 \subsection{Ordering of execution}
+\label{ordering}
 
-Non-array variables are \emph{single-assignment}, which means that
-they must be assigned to exactly one value during execution. A
+As previously stated, non-array variables are single-assignment,
+which means thatthey must be assigned to exactly one value during execution. A
 procedure or expression will be executed when all of its input
 parameters have been assigned values. As a result of such execution,
 more variables may become assigned, possibly allowing further parts of
@@ -413,7 +418,7 @@
    z=q(y);
 \end{verbatim}
 
-Arrays in SwiftScript are more generally \emph{monotonic}, \katznote{is this common use of monotonic?  Are the arrays monotonic?  Or is the assignment of elements in the array monotonic?}
+Arrays in Swift are more generally \emph{monotonic}, \katznote{is this common use of monotonic?  Are the arrays monotonic?  Or is the assignment of elements in the array monotonic?}
 that is,
 knowledge about the content of an array increases during execution,
 but cannot otherwise change. Once a value for a particular element is
@@ -446,9 +451,9 @@
 \subsection{Compound procedures}
 
 As with many other programming languages, procedures consisting of
-SwiftScript code can be defined. These differ from the previously
+Swift code can be defined. These differ from the previously
 mentioned procedures declared with the \verb|app| keyword, as they
-invoke other SwiftScript procedures rather than a component
+invoke other Swift procedures rather than a component
 program. The basic structure of a composite procedure may be thought
 of as a graph of calls to other procedures.
 The following script will invoke two procedures, with an intermediate
@@ -485,13 +490,13 @@
 \subsection{More about types}
 \label{LanguageTypes}
 
-Each variable and procedure parameter in SwiftScript is strongly typed.
+Each variable and procedure parameter in Swift is strongly typed.
 Types are used to structure data, to aid in debugging and program
 correctness and to influence how Swift interacts with data.
 
 The \verb|image| type declared in previous examples is a \emph{marker
 type}. Marker types indicate that data for a variable is stored in a
-single file with no further structure exposed at the SwiftScript level.
+single file with no further structure exposed at the Swift level.
 
 Arrays have been mentioned above, in the arrays section. A code block
 may be applied to each element of an array using \verb|foreach|; or
@@ -564,7 +569,7 @@
 that database. The declaration of \verb|database| contains no mapping; and
 the procedures which use \verb|database| do not reference them in any
 way; the description of \verb|database| is entirely outside of the script.
-The single assignment and execution ordering rules will still apply though;
+The single-assignment and execution ordering rules will still apply though;
 populateDatabase will always be run before analyseDatabase.
 
 \subsection{Swift mappers}
@@ -623,7 +628,7 @@
           \hline
     \end{tabular}
   \end{center}
-  \caption{SwiftScript built-in mappers: conceptual syntax}
+  \caption{Swift built-in mappers: conceptual syntax}
   \label{mappertable}
 \end{table}
 
@@ -635,7 +640,7 @@
 \subsection{The execution environment for component programs}
 \label{LanguageEnvironment}
 
-A SwiftScript \verb|app| declaration describes how a component program
+A Swift \verb|app| declaration describes how a component program
 is invoked. In order to ensure the correctness of the Swift model, the
 environment in which programs are executed needs to be constrained.
 
@@ -771,11 +776,11 @@
 \subsection{Reliable execution}
 \label{ExecutingReliably}
 
-The functional  nature of SwiftScript provides a clearly defined
+The functional  nature of Swift provides a clearly defined
 interface to imperative components, which in addition to allowing Swift great
 flexibility in where and when it runs component programs, allows those
 imperative components to be treated as atomic components that can be
-executed multiple times for any given SwiftScript procedure invocation.
+executed multiple times for any given Swift procedure invocation.
 This facilitates three different reliability mechanisms that are implemented by
 the runtime and that need not be exposed at the language level: \emph{retries},
 \emph{restarts} and \emph{replication}.
@@ -783,7 +788,7 @@
 In the simplest form of error handling in Swift, if a component
 program fails, Swift will make a subsequent attempt to rerun the
 program. In contrast to many other systems, retry here is at the level
-of the SwiftScript procedure invocation, and includes completely
+of the Swift procedure invocation, and includes completely
 reattempting site selection, stage-in, execution and stage-out. This
 provides a natural way to deal both with many transient errors, such as
 temporary network loss, and with many changes in site state.
@@ -1015,11 +1020,11 @@
 }
 
 \end{verbatim}
-    \caption{fMRI application in SwiftScript\label{FMRI_app_script}}
+    \caption{fMRI application in Swift\label{FMRI_app_script}}
 \end{figure}
 
 In this example, the logical structure of the fMRI dataset shown in
-Figure~\ref{FMRI_app_image} can be represented by the SwiftScript type declarations in
+Figure~\ref{FMRI_app_image} can be represented by the Swift type declarations in
 lines 1-6 in Figure~\ref{FMRI_app_script}. Here, Study is declared as containing an array
 of Group, which in turn contains an array of Subject, etc. Similarly,
 an fMRI Run is a series of brain scans called volumes, with a Volume
@@ -1030,17 +1035,18 @@
 which take typed data described by a mapper, perform computations
 on those data, and produce data to be stored in locations specified
 by a mapper. The
-procedure reslice\_wf defines a compound procedure, which comprises
+procedure {\tt reslice\_wf} defines a compound procedure, which comprises
 a series of procedure calls, using variables to establish
 data dependencies.
 
-In the example, reslice\_wf defines a four-step pipeline computation,
+In the example, {\tt reslice\_wf} defines a four-step pipeline computation,
 using variables to establish data dependencies. It applies reorientRun
 to a run first in the x axis and then in the y axis, and then aligns
 each image in the resulting run with the first image. The program
-alignlinear \katznote{should this be alignlinearRun?} determines how to spatially adjust an image to match a
+{\tt alignlinear} \katznote{should this be alignlinearRun?} determines how to spatially adjust an image to match a
 reference image, and produces an air parameter file. The actual
-alignment is done by the program reslice. \katznote{or resliceRun?} Note that variable yR is
+alignment is done by the program {\tt reslice}.
+\katznote{or resliceRun?} Note that variable {\tt yR} is
 the output of the first step and the input of the second step, and as such, defines
 the data dependencies between the two steps. %The pipeline is
 %illustrated in the center of % Figure~\ref{FMRIFigure2},
@@ -1054,19 +1060,19 @@
 The procedure reorientRun
 is also a compound procedure.
 The foreach statement defines an iteration over the input run
-ir and applies the procedure reorient (which rotates a brain image
+{\tt ir} and applies the procedure {\tt reorient} (which rotates a brain image
 along a certain axis) to each volume in the run to produces a
 reoriented run or. Because the multiple calls to reorient operate on
 independent data elements, they can proceed in parallel.
 
 The procedure reorient in this example is an atomic procedure.
-This procedure has typed input parameters iv, direction and overwrite and
-one output ov. The body specifies that it
+This procedure has typed input parameters ({\tt iv}, {\tt direction}, and {\tt overwrite}) and
+one output ({\tt ov}). The body specifies that it
 invokes a program (also called reorient) that will be
 dynamically mapped to a binary executable, which will
 execute at an execution site chosen by the Swift runtime system. The
 body also specifies how input parameters map to command line
-arguments. The notation @filename is a built-in mapping function that
+arguments. The notation {\tt @filename} is a built-in mapping function that
 maps a logical data structure to a physical file name. In this case,
 it extracts the file name of input header and output header, which are
 then put in the command line to invoke the reorient program.
@@ -1110,7 +1116,7 @@
 self-contained, structural equation models---we generated 65,535 R
 objects representing all models with 1 to 16 connections
 of varying weights between 4 pre-selected regions of interest.
-A 4x4 matrix represents connections between the four regions,
+A 4~x~4 matrix represents connections between the four regions,
 with 16 possible connections (connections between the same two
 regions but in different directions are tested separately).
 \katznote{should refer to figure~\ref{omxFigure} here?  If so, the residual variances
@@ -1138,8 +1144,8 @@
 
 A model generator was developed for the OpenMx package and is designed
 explicitly to enable parallel execution of exhaustive or partially
-pruned sets of model objects. Given an n x n covariance matrix it can
-generate the entire set of possible models with anywhere from 0 to n2
+pruned sets of model objects. Given an $n$~x~$n$ covariance matrix it can
+generate the entire set of possible models with anywhere from 0 to $n^2$
 connections; however, it can also take as input a single index from
 that set and it will generate and run a single model. What this means
 in the context of workflow design is that the generator can be
@@ -1167,7 +1173,7 @@
         initweight, speech);
 12.	}
 \end{verbatim}
-\caption{Swiftscript for 4-region exhaustive SEM for a single experimental condition\label{omxScript1}}
+\caption{Swift script for 4-region exhaustive SEM for a single experimental condition\label{omxScript1}}
 \end{figure}
 
 First, a covariance matrix containing activation data for 4 brain regions,
@@ -1218,7 +1224,7 @@
         initweight, cond);
 9.	}
 \end{verbatim}
-\caption{Swiftscript for 4-region exhaustive SEM for 2 experimental conditions\label{omxScript2}}
+\caption{Swift script for 4-region exhaustive SEM for 2 experimental conditions\label{omxScript2}}
 \end{figure}
 
 
@@ -1255,7 +1261,7 @@
 p = readdata("paramslist.txt");
 runDocks(p);
 \end{verbatim}
-\caption{Swiftscript for running Dock\label{DockScript}}
+\caption{Swift script for running Dock\label{DockScript}}
 \end{figure}
 
 \katznote{no text in this subsection -- no reference to Figure~\ref{DockScript}}
@@ -1266,7 +1272,7 @@
 data from a large dataset of files that categorize the Earth's surface,
 from the MODIS sensor instruments that orbit Earth on two NASA
 satellites of the Earth Observing System.
-The SwiftScript analyzes the dataset to find the files with the ten
+The Swift script analyzes the dataset to find the files with the ten
 largest total urban area and then produces a new dataset with viewable
 color images of those top-ten urban data ``tiles''.
 




More information about the Swift-commit mailing list