Changeset 960665c for doc/theses/mike_brooks_MMath/array.tex

Timestamp:

Aug 20, 2024, 6:15:01 PM (13 months ago)

Author:

JiadaL <j82liang@…>

Branches:

master

Children:

ad47ec4

Parents:

d1f5054 (diff), df2e00f (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.

Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

File:

• doc/theses/mike_brooks_MMath/array.tex (modified) (4 diffs)

doc/theses/mike_brooks_MMath/array.tex

@@ -205 +205 @@
 Orthogonally, the new @array@ type works with \CFA's generic types, providing argument safety and the associated implicit communication of array length.
 Specifically, \CFA allows aggregate types to be generalized with multiple type parameters, including parameterized element types and lengths.
-Doing so gives a refinement of C's ``flexible array member'' pattern, allowing nesting structures with array members anywhere within other structures.
+Doing so gives a refinement of C's ``flexible array member'' pattern, allowing nesting structures with array members anywhere within the structures.
 \lstinput{10-15}{hello-accordion.cfa}
-This structure's layout has the starting offset of @municipalities@ varying in @NprovTerty@, and the offset of @total_pt@ and @total_mun@ varying in both generic parameters.
-For a function that operates on a @CanPop@ structure, the type system handles this variation transparently.
+This structure's layout has the starting offset of @studentIds@ varying in generic parameter @C@, and the offset of @preferences@ varying in both generic parameters.
+For a function that operates on a @School@ structure, the type system handles this memory layout transparently.
 \lstinput{40-45}{hello-accordion.cfa}
-\VRef[Figure]{f:checkHarness} shows the @CanPop@ harness and results with different array sizes, if the municipalities changed after a census.
+\VRef[Figure]{f:checkHarness} shows the @School@ harness and results with different array sizes, where multidimensional arrays are discussed next.
 
 \begin{figure}
-\lstinput{60-68}{hello-accordion.cfa}
-\lstinput{70-75}{hello-accordion.cfa}
-\caption{\lstinline{check} Harness}
+% super hack to get this to line up
+\begin{tabular}{@{}ll@{\hspace{25pt}}l@{}}
+\begin{tabular}{@{}p{3.25in}@{}}
+\lstinput{60-66}{hello-accordion.cfa}
+\vspace*{-3pt}
+\lstinput{73-80}{hello-accordion.cfa}
+\end{tabular}
+&
+\raisebox{0.32\totalheight}{%
+\lstinput{85-93}{hello-accordion.cfa}
+}%
+&
+\lstinput{95-109}{hello-accordion.cfa}
+\end{tabular}
+\caption{\lstinline{school} Harness and Output}
 \label{f:checkHarness}
 \end{figure}
@@ -488 +500 @@
 From there, @x[all]@ itself is simply a two-dimensional array, in the strict C sense, of these building blocks.
 An atom (like the bottommost value, @x[all][3][2]@), is the contained value (in the square box)
-and a lie about its size (the wedge above it, growing upward).
+and a lie about its size (the left diagonal above it, growing upward).
 An array of these atoms (like the intermediate @x[all][3]@) is just a contiguous arrangement of them, done according to their size;
 call such an array a column.
 A column is almost ready to be arranged into a matrix;
 it is the \emph{contained value} of the next-level building block, but another lie about size is required.
-At first, an atom needs to be arranged as if it were bigger, but now a column needs to be arranged as if it is smaller (the wedge above it, shrinking upward).
+At first, an atom needs to be arranged as if it were bigger, but now a column needs to be arranged as if it is smaller (the left diagonal above it, shrinking upward).
 These lying columns, arranged contiguously according to their size (as announced) form the matrix @x[all]@.
 Because @x[all]@ takes indices, first for the fine stride, then for the coarse stride, it achieves the requirement of representing the transpose of @x@.
@@ -502 +514 @@
 compared with where analogous rows appear when the row-level option is presented for @x@.
 
-\PAB{I don't understand this paragraph: These size lies create an appearance of overlap.
-For example, in \lstinline{x[all]}, the shaded band touches atoms 2.0, 2.1, 2.2, 2.3, 1.4, 1.5 and 1.6.
+For example, in \lstinline{x[all]}, the shaded band touches atoms 2.0, 2.1, 2.2, 2.3, 1.4, 1.5 and 1.6 (left diagonal).
 But only the atom 2.3 is storing its value there.
-The rest are lying about (conflicting) claims on this location, but never exercising these alleged claims.}
+The rest are lying about (conflicting) claims on this location, but never exercising these alleged claims.
 
 Lying is implemented as casting.
@@ -511 +522 @@
 This structure uses one type in its internal field declaration and offers a different type as the return of its subscript operator.
 The field within is a plain-C array of the fictional type, which is 7 floats long for @x[all][3][2]@ and 1 float long for @x[all][3]@.
-The subscript operator presents what is really inside, by casting to the type below the wedge of the lie.
+The subscript operator presents what is really inside, by casting to the type below the left diagonal of the lie.
 
 %  Does x[all] have to lie too?  The picture currently glosses over how it it advertises a size of 7 floats.  I'm leaving that as an edge case benignly misrepresented in the picture.  Edge cases only have to be handled right in the code.