\documentclass{article} \def\version{1.2} %% Copyright 2013 Steven B. Segletes % % This work may be distributed and/or modified under the % conditions of the LaTeX Project Public License, either version 1.3 % of this license or (at your option) any later version. % The latest version of this license is in % http://www.latex-project.org/lppl.txt % and version 1.3c or later is part of all distributions of LaTeX % version 2005/12/01 or later. % % This work has the LPPL maintenance status `maintained'. % % The Current Maintainer of this work is Steven B. Segletes. % Revisions: % v1.01 Documentation revision % v1.1 Added \csname record\roman{@row}\endcsname to \readdef % v1.2 -Corrected the [truncated] LPPL license info % -Added \arrayij and \arrayijk, which can be put into \edef % -Used \romannumeral in preference to \roman{}, when possible, % to avoid unnecessary use of counters. \parskip 1em \parindent 0em \newcommand\rl{\rule{1em}{0in}} \def\rdar{\textsf{readarray}} \usepackage{readarray} \usepackage{verbatimbox} \let\vb\verb \def\bs{{\ttfamily\char'134}} \reversemarginpar \marginparwidth 1.5in \newcommand\margcmd[1]{\marginpar{\hfill\ttfamily\char'134#1}} \begin{document} \begin{center} \LARGE The {\rdar} Package\\ \rule{0em}{.7em}\small Routines for inputting formatted array data and recalling it on an element-by-element basis.\\Currently supports 2-D and 3-D array structures\\ \rule{0em}{2.7em}\large Steven B. Segletes\\ steven.b.segletes.civ@mail.mil\\ \rule{0em}{1.7em}\today\\ v\version \end{center} \section{Description and Commands} The {\rdar} package allows for the inputting of data arrays (numeric, string, or even formatted) in either file form or \vb|\def| form, such that the elements of multiple arrays can be specified and later recalled in an orderly fashion, on a cell-by-cell basis. Routines have been developed to support the storage and recall of both 2-D and 3-D arrays. The commands included in this package help the user input data, define it in terms of array elements and recall those elements at will. Those commands are:\\\itshape \rl\vb|\readdef{|filename\vb|}{|token\vb|}|\\ \rl\vb|\showrecord[|error\vb|]{|record number\vb|}|\\ \rl\vb|\copyrecords{|identifier\vb|}|\\ \rl\vb|\readArrayij{|token\vb|}{|identifier\vb|}{|columns\vb|}|\\ \rl\vb|\readArrayijk{|token\vb|}{|identifier\vb|}{|rows\vb|}{|columns\vb|}|\\ \rl\vb|\Arrayij[|error\vb|]{|identifier\vb|}{|row\vb|}{|column\vb|}|\\ \rl\vb|\Arrayijk[|error\vb|]{|identifier\vb|}{|plane\vb|}{|row\vb|}{|% column\vb|}|\\ \rl\vb|\arrayij{|identifier\vb|}{|row\vb|}{|column\vb|}|\\ \rl\vb|\arrayijk{|identifier\vb|}{|plane\vb|}{|row\vb|}{|% column\vb|}|\upshape Several strings of fixed name are defined through the use of this package which are accessible to the user:\\ \rl\vb|\nrows|\\ \rl\vb|\ncols|\\ \rl\vb|\nrecords|\\ \rl\vb|\record|\textit{index} In addition to the strings of fixed name, there are various strings created whose name is a function of the user-specified data, such as\\\itshape \rl\vb|\|identifier\vb|CELLS|\\ \rl\vb|\|identifier\vb|PLANES|\\ \rl\vb|\|identifier\vb|ROWS|\\ \rl\vb|\|identifier\vb|COLS|\\\upshape where \textit{identifier} is the alphabetic-character string by which you have designated a particular array. They will be discussed in relation to the commands that create these strings. Support routines which are generally not required directly by the user for the specification and recall of data arrays, but which are useful to this package and in a variety of other circumstances include the following:\\\itshape \rl\vb|\getargsC{|token {\upshape or} string\vb|}|\\ \rl\vb|\arg|index\\ \rl\vb|\narg|\\ \rl\vb|\showargs[|number\vb|]|\\\upshape \rl\vb|\def\converttilde{|T or F\vb|}|\upshape \begin{center} \vfill [\textsc{This Space Intentionally Left Blank}] \vfill \end{center} \clearpage \section{Data Structure} The first requirement is to lay out a format for the data interface to this package. The {\rdar} package is set up to digest space-separated data. The format for the data organization is as follows, for 2-D arrays: \( \begin{array}{lllll} A_{11} &A_{12} &A_{13} & \ldots & A_{1\mathrm{(columns)}} \\ A_{21} &A_{22} & \ldots && \\ \vdots&&&&\\ A_{\mathrm{(rows)}1} &A_{\mathrm{(rows)}2} &A_{\mathrm{(rows)}3} & \ldots & A_{\mathrm{(rows)}\mathrm{(columns)}} \\ \end{array} \) and for 3-D arrays: \( \begin{array}{lllll} A_{111} &A_{112} &A_{113} & \ldots & A_{11\mathrm{(columns)}} \\ A_{121} &A_{122} & \ldots && \\ \vdots&&&&\\ A_{1\mathrm{(rows)}1} &A_{1\mathrm{(rows)}2} &A_{1\mathrm{(rows)}3} & \ldots & A_{1\mathrm{(rows)}\mathrm{(columns)}} \\ &&&&\\ A_{211} &A_{212} &A_{213} & \ldots & A_{21\mathrm{(columns)}} \\ A_{221} &A_{222} & \ldots && \\ \vdots&&&&\\ A_{2\mathrm{(rows)}1} &A_{2\mathrm{(rows)}2} &A_{2\mathrm{(rows)}3} & \ldots & A_{2\mathrm{(rows)}\mathrm{(columns)}} \\ &&&&\\ \vdots&&&&\\ &&&&\\ A_{\mathrm{(planes)}11} &A_{\mathrm{(planes)}12} &A_{\mathrm{(planes)}13} & \ldots & A_{\mathrm{(planes)}1\mathrm{(columns)}} \\ A_{\mathrm{(planes)}21} &A_{\mathrm{(planes)}22} & \ldots && \\ \vdots&&&&\\ A_{\mathrm{(planes)}\mathrm{(rows)}1} &A_{\mathrm{(planes)}\mathrm{(rows)}2} &A_{\mathrm{(planes)}\mathrm{(rows)}3} & \ldots & A_{\mathrm{(planes)}\mathrm{(rows)}\mathrm{(columns)}} \\ \end{array} \) \section{Getting Data into Array Structures\label{s:ex}} One can provide data to be digested by this package in one of two ways: either through an external file, or by way of ``cut and paste'' into a \vb|\def|. If one chooses the external file approach, the command \vb|\readdef|\margcmd{readdef} is the command which can achieve this result. The command takes two arguments. The first is the file in which the data is stored, while the second is the token into which the data will be placed, for example \rl\vb|\readdef{data.txt}{\dataA}| In this case, the contents of the file \vb|data.txt| will be placed into the token \vb|\dataA|. At this point, the data is still not digested into a data ``array,'' but merely stuffed into a \vb|\def| (a \vb|\protected@edef| actually). Thus, there is no \textit{requirement} that carriage returns be part of the input file after each row of data, nor that blank lines exist between planes of data (if the data is 3-D). \textit{However}, there is a reason to do so, nonetheless. In particular, for datafiles that are organized in the preferred fashion, for example: \begin{verbbox} A111 A112 A113 A114 A121 A122 A123 A124 A131 A132 A133 A134 A211 A212 A213 A214 A221 A222 A223 A224 A231 A232 A233 A234 \end{verbbox} \tabcolsep 1em\begin{tabular}{l} \theverbbox \end{tabular} a \vb|\readdef| will cause the following strings to be set: \vb|\ncols|\margcmd{ncols} and \vb|\nrows|\margcmd{nrows}, in this case to values of \vb|4| and \vb|3|, respectively. Such data could prove useful if the array size is not known in advance. When \verb|\readdef| is invoked, a string \verb|\nrecords|\margcmd{nrecords} will also be set to the number of file records processed by the \vb|\readdef| command. In lieu of \verb|\readdef|, a generally less preferred, but viable way to make the data available is to cut and paste into a \vb|\def|. However, because a blank line is not permitted as part of the \vb|\def|, a filler symbol (\vb|%| or \vb|\relax|) must be used in its place, if it is desired to visually separate planes of data, as shown in the \verb|\def| example at the top of the following page. Note that the \vb|%| is also required at the end of the line containing \vb|\def|, in order to guarantee that, in this case, \vb|A111| is the first element of data (and not a linebreak). However, unlike \vb|\readdef|, this definition will set the values of neither \vb|\ncols| nor \vb|\nrows|. \begin{verbbox}[] \def{\dataA}{% A111 A112 A113 A114 A121 A122 A123 A124 A131 A132 A133 A134 % A211 A212 A213 A214 A221 A222 A223 A224 A231 A232 A233 A234 } \end{verbbox} \begin{tabular}{l} \theverbbox \end{tabular} Once the data to be placed into an array is available by way of either \vb|\readdef| or \vb|\def|, the command to digest the data into an array is either \vb|\readArrayij| (or \verb|\copyrecords|), in the case of 2-D data, or \vb|\readArrayijk|, for 3-D data. \subsection{Creating 2-D Arrays} In the case of \vb|\readArrayij|\margcmd{readArrayij}, the command takes three arguments. The first is the token into which the data had previously been stuffed. The second is an alphabetic-string identifier for the array, which can be one or more characters in length. Finally, the last argument is the number of columns in the array. If the data had been read by way of \vb|\readdef|, the string \vb|\ncols| may be used to signify this value. \subsection{Creating Pseudo-1-D Arrays} While the {\rdar} package has no explicit provisions for 1-D arrays, one could use the 2-D \verb|\readArrayij| command, with the third argument set to a value of unity \{1\}, instead of \verb|\ncols|. In this way, each space-separated word of the input file will be set to a new data row. While this approach is useful for sticking each ``word'' of input data into its own single-column data row, the command \verb|\copyrecords|\margcmd{copyrecords} can be used to stick the individual ``file records'' from the most recent \verb|\readdef| into a 2-D array of \textbf{single-column width}. The \verb|\copyrecords| command takes as its argument an alphabetic string identifier to associate with the array of data. Its use accomplishes two things: 1) it allows records (rather than words) of a file to be accessed using the general \verb|\Arrayij| nomenclature to be discussed shortly; and 2) it saves the most recently read file data into its own data structure, so that it is not overwritten by a subsequent invocation of \verb|\readdef|. \subsection{Creating 3-D Arrays} For the 3-D case, \vb|\readArrayijk|\margcmd{readArrayijk} takes an additional argument, in comparison to \verb|\readArrayij|. The first two arguments are identical to \vb|\readArrayij|; namely, the token containing the data and an identifier for the array. The third argument is the number of rows in the array, while the fourth argument is the number of columns. Likewise, if \vb|\readdef| had been used on a properly formed input file, both \vb|\nrows| and \vb|\ncols| may be used to supply the third and fourth arguments. While it may be easily envisioned that the array data is numerical, this need not be the case. The data may be text, and even formatted text. Furthermore, one may introduce space characters into the data of individual cells through the use of hardspaces (\vb|~|), since normal white space would otherwise be interpreted as a data separator. Thus, given the following definitions and array initialization, \begin{verbbox}[] \def\I#1{\textit{#1}} \def\dataC{% \I{am} \I{are} have~\I{been} have~\I{been} \I{are} \I{are} have~\I{been} have~\I{been} \I{is} \I{are} has~\I{been} have~\I{been} % \I{was} \I{were} had~\I{been} had~\I{been} \I{were} \I{were} had~\I{been} had~\I{been} \I{was} \I{were} had~\I{been} had~\I{been} % will~\I{be} will~\I{be} will~have~\I{been} will~have~\I{been} will~\I{be} will~\I{be} will~have~\I{been} will~have~\I{been} will~\I{be} will~\I{be} will~have~\I{been} will~have~\I{been} } \readArrayijk{\dataC}{tobeConjugation}{3}{4} \end{verbbox} \begin{tabular}{l} \theverbbox \end{tabular} \def\I#1{\textit{#1}} \def\dataC{% \I{am} \I{are} have~\I{been} have~\I{been} \I{are} \I{are} have~\I{been} have~\I{been} \I{is} \I{are} has~\I{been} have~\I{been} % \I{was} \I{were} had~\I{been} had~\I{been} \I{were} \I{were} had~\I{been} had~\I{been} \I{was} \I{were} had~\I{been} had~\I{been} % will~\I{be} will~\I{be} will~have~\I{been} will~have~\I{been} will~\I{be} will~\I{be} will~have~\I{been} will~have~\I{been} will~\I{be} will~\I{be} will~have~\I{been} will~have~\I{been} } \readArrayijk{\dataC}{tobeConjugation}{3}{4} multi-word sequences will be placed into the individual array elements of an array identified as ``tobeConjugation,'' with the appropriate italic emphases applied to the words. If, perchance, a row is only partially defined by \vb|\readArrayij| or a plane is only partially defined by \vb|\readArrayijk|, the partial data is discarded. \subsection{Treatment of Hardspaces} For either the 2-D or 3-D \verb|\readArray| commands, the interpretation of hardspaces (\vb|~|) as data is specifically designed to allow multi-word data entries. However, one may choose to turn this feature off by setting the flag \rl\vb|\def\converttilde{T}| which will have the effect of converting hardspaces to regular space tokens. \section{Recalling Data from Array Structures} While one has specified the number of columns and/or rows associated with the \vb|\readArray...| initialization, those numbers may not yet be known to the user, if the values employed came from the \vb|\readdef| initializations of \vb|\ncols| and \vb|\nrows|. Therefore, the \vb|\readArray...| \margcmd{{\rmfamily\itshape identifier}CELLS}% \margcmd{{\rmfamily\itshape identifier}PLANES}% \margcmd{{\rmfamily\itshape identifier}ROWS}% \margcmd{{\rmfamily\itshape identifier}COLS}% commands also set the following strings: \itshape\vb|\|identifier\vb|CELLS|, \vb|\|identifier\vb|PLANES|% , \vb|\|identifier\vb|ROWS|{\upshape, and} \vb|\|identifier\vb|COLS|\upshape, where \textit{identifier} is the array identifier string that was supplied to the \verb|\readarray...| command. Note that it is the case, for 3-D arrays, that \rl\itshape\vb|\|identifier\vb|CELLS| $=$ \vb|\|identifier\vb|PLANES| $\times$ \vb|\|identifier\vb|ROWS| $\times$ \vb|\|identifier\vb|COLS|\upshape For the ``tobeConjugation'' example of the prior section, \tobeConjugationCELLS $=$\tobeConjugationPLANES $\times$\tobeConjugationROWS $\times$% \tobeConjugationCOLS. Likewise, for 2-D arrays \rl\itshape\vb|\|identifier\vb|CELLS| $=$ \vb|\|identifier\vb|ROWS| $\times$ \vb|\|identifier\vb|COLS|\upshape To retrieve the data from the array, one need employ either the \vb|\Arrayij| \margcmd{Arrayij} or \vb|\Arrayijk| \margcmd{Arrayijk} commands, depending on whether the array is 2-D or 3-D. The first mandatory argument to either of these commands is the array identifer. The remaining arguments to these commands are simply the row and column, in the case of the 2-D \vb|\Arrayij|, or else the plane, row, and column, in the case of the 3-D \vb|\Arrayijk|. Thus, in the case of the earlier example involving conjugation of the verb \textit{to be}, the second-person future-perfect tense of the verb is given by\\ \rl\vb|\Arrayijk{tobeConjugation}{3}{2}{4}|,\\ which yields ``\Arrayijk{tobeConjugation}{3}{2}{4}.'' For pseudo-1-D arrays, either created with \verb|\copyrecords| or else using the \verb|\readarray| command with the third argument set to unity, access to these arrays is achieved by way of \verb|\Arrayij|, setting the column argument to unity. There are also strings defined, one for each record that was read from the file, with the name \verb|\record|\textit{index}\margcmd{record\itshape\rmfamily index}, where \textit{index} is the record number expressed in roman numerals. Thus in the example from section~\ref{s:ex}, \vb|\recordii| would contain the string ``\vb|A121 A122 A123 A124|''. However, such syntax provides no bounds checking. An alternate (perhaps preferred) way to access one of the file records read during the most recent \verb|\readdef|, in a way which provides bounds checking, is to use the \verb|\showrecord| command\margcmd{showrecord}. For the section~\ref{s:ex} example, the alternative to executing \vb|\recordii| would be to use \verb|\showrecord{2}|. The optional argument to this command provides an alternative error message if the record requested is out of bounds. The default error messages for negative or excessive record numbers are, respectively: \def\nrecords{1} \rl\showrecord{-1}\\ \rl\showrecord{10} Unlike the \vb|\Arrayij| and \verb|\Arrayijk| commands already discussed, the record data from a given file read will only be available until the next invocation of \verb|\readdef|. For this reason, the command \verb|\copyrecords| was introduced to convert file-record data into an array data structure. While the user is developing his application involving the {\rdar} package, there may accidentally arise the unintended circumstance where an array element is asked for which falls outside the array bounds. Like \verb|\showrecord|, the \verb|\Arrayij| and \verb|\Arrayijk| commands also employ bounds checking. These commands check for four error conditions that, by default, produce the following error messages:\\ \rl\Arrayijk{tobeConjugation}{-3}{2}{4}\\ \rl\Arrayijk{tobeConjugation}{9}{2}{4}\\ \rl\Arrayijk{tobeConjugation}{3}{9}{4}\\ \rl\Arrayijk{tobeConjugation}{3}{2}{9} which are written in lieu of a valid array element datum. While such messages help in debugging, the user may desire an error tailored to the application. The optional argument to both \vb|\Arrayij| and \vb|\Arrayijk| replaces the default error messages and is to be printed if any error condition arises. It could be a blank \vb|[]|, a black box \vb|[\rule{1ex}{1ex}]|, or anything else that makes sense for the application. \section{Alternate Accessing Commands if \texttt{\bs edef} is Required} The\verb|\Arrayij| and \verb|\Arrayijk| commands may, of course, be placed as arguments of \verb|\def| commands. They, cannot, however, be placed into an \verb|\edef|. If the user has need to place the array-element content into an \verb|\edef| (and assuming that the actual array-element content is suitable for an \verb|\edef|), the user should employ the \verb|\arrayij| and \verb|\arrayijk| commands, as alternatives. \margcmd{arrayij}\margcmd{arrayijk}% These commands do not perform any bounds checking (thus eliminating the need for an optional argument). Their advantage, however, is that they may be freely placed into an \verb|\edef|. \section{Support Routines} The engine for the {\rdar} package is the \vb|\getargsC| \margcmd{getargsC} command, based on the \vb|\getargs| command found in the \textsf{stringstrings} package. This command has been herein rewritten for speed. The \vb|\getargsC| command takes a string or token as its argument and separates each of the space-separated words of it into individual strings, named with roman numerals as \vb|\argi|\margcmd{arg\itshape\rmfamily index}, \vb|\argii|, \textit{etc}. The total number of arguments that are separated is given by the string \vb|\narg|\margcmd{narg}. This command can be useful for a variety of applications outside of \rdar. While generally used only for diagnostic purposes, the command \vb|\showargs|\margcmd{showargs} is used print out all the arguments recently digested by an invocation of \vb|\getargsC|, separated by small black blocks. The optional argument to \vb|\showargs| is the number of individual arguments to place on a single line of output, before issuing a linefeed. Thus, the command \begin{verbbox}[] \showargs[4] \end{verbbox} \begin{tabular}{l} \theverbbox \end{tabular} yields the following result: \showargs[4] Note that the 37$^{th}$ argument is non-printing and represents the residual linefeed left over fromt he \vb|\def| of \vb|\dataC|. A similar residual argument is also left by the \vb|\readdef| command. It can be eliminated if the last record of the \vb|\readdef| input file (or the last record of the \vb|\def| command) ends with a \vb|%| symbol, so as to discard the final linefeed prior to the end-of-file (or \vb|}|). As mentioned earlier, the flag \vb|converttilde|\margcmd{converttilde}, by default ``false,'' can be set to \vb|\def\converttilde{T}| so as to tell \vb|\getargsC| to treat hardspaces as ordinary spaces. \section{Acknowledgements} The author would like to thank Dr. David Carlisle for his assistance in helping the author rewrite the \vb|\getargs| command, originally found in the \textsf{stringstrings} package. To distinguish the two versions, and in deference to him, it is herein named \vb|\getargsC|. \clearpage \section{Code Listing} \verbatiminput{readarray.sty} \end{document}