Ignore:
Timestamp:
Aug 16, 2024, 12:03:54 PM (7 days ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
master
Children:
cef5bfc
Parents:
661e7b0
Message:

update accordion program, small changes

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/mike_brooks_MMath/array.tex

    r661e7b0 r4558df2  
    205205Orthogonally, the new @array@ type works with \CFA's generic types, providing argument safety and the associated implicit communication of array length.
    206206Specifically, \CFA allows aggregate types to be generalized with multiple type parameters, including parameterized element types and lengths.
    207 Doing so gives a refinement of C's ``flexible array member'' pattern, allowing nesting structures with array members anywhere within other structures.
     207Doing so gives a refinement of C's ``flexible array member'' pattern, allowing nesting structures with array members anywhere within the structures.
    208208\lstinput{10-15}{hello-accordion.cfa}
    209 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.
    210 For a function that operates on a @CanPop@ structure, the type system handles this variation transparently.
     209This structure's layout has the starting offset of @studentIds@ varying in generic parameter @C@, and the offset of @preferences@ varying in both generic parameters.
     210For a function that operates on a @School@ structure, the type system handles this memory layout transparently.
    211211\lstinput{40-45}{hello-accordion.cfa}
    212 \VRef[Figure]{f:checkHarness} shows the @CanPop@ harness and results with different array sizes, if the municipalities changed after a census.
     212\VRef[Figure]{f:checkHarness} shows the @School@ harness and results with different array sizes, where multidimensional arrays are discussed next.
    213213
    214214\begin{figure}
    215 \lstinput{60-68}{hello-accordion.cfa}
    216 \lstinput{70-75}{hello-accordion.cfa}
    217 \caption{\lstinline{check} Harness}
     215% super hack to get this to line up
     216\begin{tabular}{@{}ll@{\hspace{25pt}}l@{}}
     217\begin{tabular}{@{}p{3.25in}@{}}
     218\lstinput{60-66}{hello-accordion.cfa}
     219\vspace*{-3pt}
     220\lstinput{73-80}{hello-accordion.cfa}
     221\end{tabular}
     222&
     223\raisebox{0.32\totalheight}{%
     224\lstinput{85-93}{hello-accordion.cfa}
     225}%
     226&
     227\lstinput{95-109}{hello-accordion.cfa}
     228\end{tabular}
     229\caption{\lstinline{school} Harness and Output}
    218230\label{f:checkHarness}
    219231\end{figure}
     
    488500From there, @x[all]@ itself is simply a two-dimensional array, in the strict C sense, of these building blocks.
    489501An atom (like the bottommost value, @x[all][3][2]@), is the contained value (in the square box)
    490 and a lie about its size (the wedge above it, growing upward).
     502and a lie about its size (the left diagonal above it, growing upward).
    491503An array of these atoms (like the intermediate @x[all][3]@) is just a contiguous arrangement of them, done according to their size;
    492504call such an array a column.
    493505A column is almost ready to be arranged into a matrix;
    494506it is the \emph{contained value} of the next-level building block, but another lie about size is required.
    495 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).
     507At 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).
    496508These lying columns, arranged contiguously according to their size (as announced) form the matrix @x[all]@.
    497509Because @x[all]@ takes indices, first for the fine stride, then for the coarse stride, it achieves the requirement of representing the transpose of @x@.
     
    502514compared with where analogous rows appear when the row-level option is presented for @x@.
    503515
    504 \PAB{I don't understand this paragraph: These size lies create an appearance of overlap.
    505 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.
     516For 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).
    506517But only the atom 2.3 is storing its value there.
    507 The rest are lying about (conflicting) claims on this location, but never exercising these alleged claims.}
     518The rest are lying about (conflicting) claims on this location, but never exercising these alleged claims.
    508519
    509520Lying is implemented as casting.
     
    511522This structure uses one type in its internal field declaration and offers a different type as the return of its subscript operator.
    512523The 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]@.
    513 The subscript operator presents what is really inside, by casting to the type below the wedge of the lie.
     524The subscript operator presents what is really inside, by casting to the type below the left diagonal of the lie.
    514525
    515526%  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.
Note: See TracChangeset for help on using the changeset viewer.