Bibliography

*************** *** 541,546 **** --- 612,629 ---- T + + template instantiation + + applying a template class to template parameters to create a + type. For example, foo<double,3> + instantiates template <typename T, int n> class + foo with the type &double; and the constant + integer 3. Template instantiation is analogous to applying a + function to function arguments. + + + &tensor; *************** *** 558,563 **** --- 641,673 ---- mathematical matrices as first-class objects. &tensor; &vector; + + + + + trait + + a characteristic of a type. + traits class + + + + + traits class + + a class containing one or more traits all describing a + particular type's chacteristics. + trait + + + + + Turing complete + + describes a language that can compute anything that can be + computed. That is, the language for computation is as powerful as + it can be. Most wide-spread programming languages are + Turing-complete, including &cc;, &c;, and &fortran;. Index: introduction.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/introduction.xml,v retrieving revision 1.1 diff -c -p -r1.1 introduction.xml *** introduction.xml 2001/12/17 17:27:41 1.1 --- introduction.xml 2002/01/04 17:14:06 *************** *** 2,21 **** Introduction The Parallel Object-Oriented Methods and Applications ! POOMA &toolkitcap; is a &cc; &toolkit; for ! writing high-performance scientific programs for sequential and ! distributed computation. The &toolkit; provides a variety of ! tools: containers and other abstractions suitable for scientific computation, - several container storage classes to reduce a program's - storage requirements, - - support for a variety of computation modes including data-parallel expressions, stencil-based computations, and lazy evaluation, --- 2,16 ---- Introduction The Parallel Object-Oriented Methods and Applications ! (POOMA) &toolkitcap; is a &cc; &toolkit; for ! writing high-performance scientific programs. The &toolkit; provides ! a variety of tools: containers and other abstractions suitable for scientific computation, support for a variety of computation modes including data-parallel expressions, stencil-based computations, and lazy evaluation, *************** *** 25,31 **** automatic creation of all interprocessor communication for ! parallel and distributed programs, and automatic out-of-order execution and loop rearrangement --- 20,30 ---- automatic creation of all interprocessor communication for ! parallel and distributed programs ! ! ! several container storage classes to reduce a program's ! storage requirements, and automatic out-of-order execution and loop rearrangement *************** *** 34,53 **** Since the &toolkit; provides high-level abstractions, &pooma; programs are much shorter than corresponding &fortran; or &c; ! programs, requiring less time to write and less time to debug. ! Using these high-level abstractions, the same code runs on a wide ! variety of computers almost as fast as carefully crafted ! machine-specific hand-written programs. The &toolkit; is freely ! available, open-source software compatible with any modern &cc; ! compiler. ! &pooma; Goals. The goals for the &poomatoolkit; have remained unchanged ! since its inception in 1994: Code portability across serial, distributed, and parallel ! architectures with no change to source code. Development of reusable, cross-problem-domain components --- 33,55 ---- Since the &toolkit; provides high-level abstractions, &pooma; programs are much shorter than corresponding &fortran; or &c; ! programs and require less time to write and less time to debug. ! Using these high-level abstractions, the same code runs on a ! sequential, parallel, and distributed computers. It runs almost as ! fast as carefully crafted machine-specific hand-written programs. ! The &toolkit; is freely available, open-source software compatible ! with any modern &cc; compiler. ! !

! &pooma; Goals ! The goals for the &poomatoolkit; have remained unchanged ! since its conception in 1994: Code portability across serial, distributed, and parallel ! architectures without any change to the source code. Development of reusable, cross-problem-domain components *************** *** 58,66 **** scientific simulation. ! [&toolkitcap;] design and development driven by ! applications from a diverse set of scientific problem ! domains. Shorter time from problem inception to working parallel --- 60,67 ---- scientific simulation. ! &toolkitcap; design and development driven by applications ! from a diverse set of scientific problem domains. Shorter time from problem inception to working parallel *************** *** 68,296 **** ! ! - Code Portability for Sequential and Distributed Programs. - &pooma; programs run on sequential, distributed, and parallel - computers with no change in source code. The programmer writes two - or three lines specifying how each container's domain should be - distributed among available processors. Using these directives and - run-time information about the computer's configuration, the - &toolkit; automatically distributes pieces of the container - domains, called patches, among the available - processors. If a computation needs values from another patch, - &pooma; automatically passes the value to the place it is needed. - The same program, and even the same executable, works regardless of - the number of the available processors and the size of the - containers' domains. A programmer interested in only sequential - execution can omit the two or three lines specifying how the - domains are to be distributed. - - -

- Science, Algorithms, Engineering, and &pooma; - - - - - - how &pooma; helps translate algorithms into programs - - - In the translation from theoretical science and math to - computational science and math to computer programs, &pooma; - containers eases the translation of algorithms to computer - programs. - - - - - Rapid Application Development. - The &poomatoolkit; is designed to enable rapid development of - scientific and distributed applications. For example, its vector, - matrix, and tensor classes model the corresponding mathematical - concepts. Its &array; and &field; classes model the discrete - spaces and mathematical arrays frequently found in computational - science and math. See . The left column - illustrates theoretical science and math, the middle column - computational science and math, and the right column computer - science implementations. For example, theoretical physics - frequently uses continuous fields in three-dimension space, while - algorithms for the corresponding computational physics problem - usually uses discrete fields. &pooma; containers, classes, and - functions ease the engineering to map these algorithms to computer - programs. For example, the &pooma; &field; container models - discrete fields; both map locations in discrete space to values and - permit computations of spatial distances and values. The &pooma; - &array; container models the mathematical concept of an array, used - in numerical analysis. - - - &pooma; containers support a variety of computation modes, - easing transition of algorithms into code. For example, many - algorithms for solving partial differential equations use - stencil-based computations. &pooma; supports stencil-based - computations on &array;s and &field;s. It also supports - data-parallel computation. For computations where one &field;'s - values is a function of several other &field;'s values, the - programmer can specify a relation. Relations are lazily evaluated; - whenever the dependent &field;'s values are needed and it is - related to a &field; whose values have changed, the former - &field;'s values are computed. Lazy evaluation also assists - correctness by eliminating the (frequently forgotten) need for a - programmer to ensure a &field;'s values are up-to-date before being - used. - - Efficient Code. - &pooma; incorporates a variety of techniques to ensure it - produces code that executes as quickly as special-case, - hand-written code. - - These techniques include extensive use of templates, out-of-order - evaluation to permit communication and computation to overlap, - availability of guard layers to reduce processors' synchronicity, - and use of &pete; to produce fast inner loops. - - - Using templates permits the expressiveness of using pointers - and function arguments but ensures as much as work as possible - occurs at compile time, not run time. Also, more code is exposed - to the compiler's optimizer, further speeding execution. For - example, use of template parameters to define the &pooma; &array; - container permits the use of specialized data storage classes - called engines, fast creation of views of a portion of an &array;, - and polymorphic indexing. An &array;'s engine template parameter - specifies how data is stored and indexed. Some &array;s expect - almost all values to be used, while others might be mostly empty. - In the latter case, using a specialized engine storing the few - nonzero values would greatly reduce space requirements. Using - engines also permits fast creation of container views, known as - array sections in Fortran 90. A view's - engine is the same as the original container's engine, while the - view object maps its restricted domain to the original domain. - Space requirements and execution time are minimal. Using templates - also permits containers to support polymorphic indexing, e.g., - indexing both by integers and by three-dimensional coordinates. - For example, a container defers returning values to its engine - using a templatized index operator. The engine can define indexing - functions with different function arguments, without the need to - add corresponding container functions. Some of these features can - be expressed without using templates, but doing so increases - execution time. For example, a container could have a pointer to - an engine object, but this requires a pointer dereference for each - operation. Implementing polymorphic indexing without templates - would require adding virtual function corresponding to each of the - indexing functions. - - - - To ensure multiprocessor &pooma; programs execute quickly, it - is important that interprocessor communication overlaps with - intraprocessor computation as much as possible and communication is - minimized. Asynchronous communication, out-of-order evaluation, and - use of guard layers all help achieve this. &pooma; uses the - asynchronous communication facilities of the &cheetah; communication - library. When a processor needs data stored or computed by another - processor, a message is sent between the two. For synchronous - communication, the sender must issue an explicit send, and the - recipient must issue an explicit receive. This synchronizes them. - &cheetah; permits the sender to put and get data without the - intervention of the remote site and also invoke functions at the - remote site to ensure the data is up-to-date. Thus, out-of-order - evaluation must be supported. Out-of-order evaluation has another - benefit: only computations directly or indirectly related to values - that are printed need occur. - - Using guard layers also helps overlap communication and - computation. For distributed computation, each container's domain is - split into pieces distributed among the available processors. - Frequently, computing a container value is local, involving just the - value itself and a few neighbors. Computing a value near the edge of - a processor's domain may require knowing a few values from a - neighboring domain. Guard layers permit these values to be copied - locally so they need not be repeatedly communicated. - - &pooma; uses &pete; technology to ensure inner loops using - &pooma;'s object-oriented containers run as quickly as hand-coded - loops. &pete; (the Portable Expression Template - Engine) uses expression-template technology to convert - data-parallel statements frequently found in the inner loops of - programs into efficient loops without any intermediate - computations. For example, consider evaluating the A += - -B + 2 * C; statement where A and - C are vector<double>s and - B is a vector<int>s. - Ordinary evaluation might introduce intermediaries for - -B, 2*C, and their - sum. The presence of these intermediaries in inner loops can - measurably slow evaluation. To produce a loop without - intermediaries, &pete; stores each expression as a parse tree. The - resulting parse trees can be combined into a larger parse tree. - Using its templates, the parse tree is converted, at compile time, - to an outer loop with contents corresponding to evaluating each - component of the result. Thus, no intermediate values are computed - or stored. For example, the code corresponding to A += - -B + 2 * C; is - - vector<double>::iterator iterA = A.begin(); - vector<int>::const_iterator iterB = B.begin(); - vector<double>::const_iterator iterC = C.begin(); - while (iterA != A.end()) { - *iterA += -*iterB + 2 * *iterC; - ++iterA; ++iterB; ++iterC; - } - - Furthermore, since the code is available at compile-, not run-, time, - it can be further optimized, e.g., moving any loop-invariant code out - of the loop. - - Used for Diverse Set of Scientific Problems. - &pooma; has been used to solve a wide variety of scientific - problems. Most recently, physicists at Los Alamos National - Laboratory implemented an entire library of hydrodynamics codes as - part of the U.S. government's Science-based Stockpile Stewardship - (SBSS) program to simulate nuclear weapons. - Other applications include a matrix solver, an accelerator code - simulating the dynamics of high-intensity charged particle beams in - linear accelerators, and a Monte Carlo neutron transport - code. - - - Easy Implementation. - &pooma;'s tools greatly reduce the time to implement - applications. As we noted above, &pooma;'s containers and - expression syntax model the computational models and algorithms - most frequently found in scientific programs. Using these - high-level tools which are known to be correct reduce the time - needed to debug programs. Programmers can write and test programs - using their one or two-processor personal computers. With no - additional work, the same program runs on computers with hundreds - of processors; the code is exactly the same, and the &toolkit; - automatically handles distribution of the data, all data - communication, and all synchronization. Using all these tools - greatly reduces programming time. For example, a team of two - physicists and two support people at Los Alamos National Laboratory - implemented a suite of hydrodynamics kernels in six months. Their - work replaced the previous suite of less-powerful kernels which had - taken sixteen people several years to implement and debug. Despite - not previously implementing any of the kernels, they averaged one - new kernel every three days, including the time to read the - corresponding scientific papers! -

History of &pooma; ! The &poomatoolkit; developed at Los Alamos National Laboratory to assist nuclear fusion and fission research. ! In 1994, the &toolkit; grew out of the Object-Oriented ! Particle Simulation (OOPS) class library developed for ! particle-in-cell simulations. The goals of the Framework, as it ! was called at the time, were driven by the Numerical Tokamak's ! Parallel Platform Paradox:

The average time required to implement a moderate-sized application on a parallel computer architecture is equivalent to --- 69,335 ---- ! Below, we discuss how &pooma; achieves these goals. ! ! ! Code Portability for Sequential and Distributed Programs ! ! The same &pooma; programs run on sequential, distributed, and ! parallel computers. No change in source code is required. Two or ! three lines specifying how each container's domain should be ! distributed among available processors. Using these directives and ! run-time information about the computer's configuration, the ! &toolkit; automatically distributes pieces of the container domains, ! called patches, ! among the available processors. If a computation needs values from ! another patch, &pooma; automatically passes the value to the patch ! where it is needed. The same program, and even the same executable, ! works regardless of the number of the available processors and the ! size of the containers' domains. A programmer interested in only ! sequential execution can omit the two or three lines specifying how ! the domains are to be distributed. ! ! Rapid Application Development ! ! The &poomatoolkit; is designed to enable rapid development of ! scientific and distributed applications. For example, its vector, ! matrix, and tensor classes model the corresponding mathematical ! concepts. Its &array; and &field; classes model the discrete spaces ! and mathematical arrays frequently found in computational science and ! math. See . ! The left column indicates theoretical science and math concepts, the ! middle column computational science and math concepts, and the right ! column computer science implementations. For example, theoretical ! physics frequently uses continuous fields in three-dimension space, ! while algorithms for a corresponding computational physics problem ! usually uses discrete fields. &pooma; containers, classes, and ! functions ease engineering computer programs for these algorithms. ! For example, the &pooma; &field; container models discrete fields; ! both map locations in discrete space to values and permit ! computations of spatial distances and values. The &pooma; &array; ! container models the mathematical concept of an array, used in ! numerical analysis. ! !
! How &pooma; Fits Into the Scientific Process ! ! ! ! ! ! &pooma; helps translate algorithms into programs. ! ! ! In the translation from theoretical science and math to ! computational science and math to computer programs, &pooma; eases ! the implementation of algorithms as computer programs. ! ! !
! ! &pooma; containers support a variety of computation modes, ! easing translation of algorithms into code. For example, many ! algorithms for solving partial differential equations use ! stencil-based computations. &pooma; supports stencil-based ! computations on &array;s and &field;s. It also supports ! data-parallel computation similar to &fortran 90 syntax. For ! computations where one &field;'s values is a function of several ! other &field;'s values, the programmer can specify a relation. ! Relations are lazily evaluated: whenever the dependent &field;'s ! values are needed and it is dependent on a &field; whose values have ! changed, its values are computed. Lazy evaluation also assists ! correctness by eliminating the frequently forgotten need for a ! programmer to ensure a &field;'s values are up-to-date before being ! used. ! ! Efficient Code ! ! &pooma; incorporates a variety of techniques to ensure it ! produces code that executes as quickly as special-case, ! hand-written code. ! ! These techniques include extensive use of templates, out-of-order ! evaluation, use of guard layers, and production of fast inner loops. ! ! &pooma;'s uses of &cc; templates permits the expressiveness ! from using pointers and function arguments but ensures as much as ! work as possible occurs at compile time, not run time. This speeds ! programs' execution. Since more code is produced at compile time, ! more code is available to the compiler's optimizer, further speeding ! execution. The &pooma; &array; container benefits from the use of ! template parameters. Their use permits the use of specialized data ! storage classes called engines. An ! &array;'s engine template parameter specifies how data is stored and ! indexed. Some &array;s expect almost all values to be used, while ! others might be mostly vacant. In the latter case, using a ! specialized engine storing the few nonzero values greatly reduces ! space requirements. Using engines also permits fast creation of ! container views, known as array sections in ! Fortran 90. A view's engine is the same as the original ! container's engine, but the view object maps its restricted domain to ! the original domain. Space requirements and execution time to use ! views are minimal. Using templates also permits containers to ! support polymorphic indexing, e.g., indexing both by integers and by ! three-dimensional coordinates. A container defers indexing ! operations to its engine's templatized index operator. Since it uses ! templates, the engine can define indexing functions with different ! function arguments, without the need to add corresponding container ! functions. Some of these benefits of using templates can be ! expressed without them, but doing so increases execution time. For ! example, a container could have a pointer to an engine object, but ! this requires a pointer dereference for each operation. Implementing ! polymorphic indexing without templates would require adding virtual ! functions corresponding to each of the indexing functions. ! ! ! ! To ensure multiprocessor &pooma; programs execute quickly, it ! is important that interprocessor communication overlaps with ! intraprocessor computations as much as possible and that ! communication is minimized. Asynchronous communication, out-of-order ! evaluation, and use of guard layers all help achieve these goals. ! &pooma; uses the asynchronous communication facilities of the ! &cheetah; communication library. When a processor needs data that is ! stored or computed by another processor, a message is sent between ! the two. If synchronous communication was used, the sender must ! issue an explicit send, and the recipient must issue an explicit ! receive, synchronizing the two processors. &cheetah; permits the ! sender to put and get data without synchronizing with the recipient ! processor, and it also permits invoking functions at remote sites to ! ensure desired data is up-to-date. Thus, out-of-order evaluation ! must be supported. Out-of-order evaluation also has another benefit: ! Only computations directly or indirectly related to values that are ! printed need occur. ! ! Surrounding a patch with guard ! layers can help reduce interprocessor ! communication. For distributed computation, each container's domain ! is split into pieces distributed among the available processors. ! Frequently, computing a container value is local, involving just the ! value itself and a few neighbors, but computing a value near the edge ! of a processor's domain may require knowing a few values from a ! neighboring domain. Guard layers permit these values to be copied ! locally so they need not be repeatedly communicated. ! ! &pooma; uses &pete; technology to ensure inner loops involving ! &pooma;'s object-oriented containers run as quickly as hand-coded ! ! loops. &pete; (the Portable Expression Template Engine) uses ! expression-template technology to convert data-parallel statements ! in the inner loops of programs into efficient loops ! without any intermediate computations. For example, consider ! evaluating the statement ! ! A += -B + 2 * C; ! where A and C are ! vector<double>s and B is a ! vector<int>. Naive evaluation might introduce ! intermediaries for -B, ! 2*C, and their sum. The presence of these ! intermediaries in inner loops can measurably slow evaluation. To ! produce a loop without intermediaries, &pete; stores each expression ! as a parse tree. The resulting parse trees can be combined into a ! larger parse tree. Using its templates, the parse tree is converted, ! at compile time, to a loop evaluating each component of the result. ! Thus, no intermediate values are computed or stored. For example, ! the code corresponding to the statement above is ! ! vector<double>::iterator iterA = A.begin(); ! vector<int>::const_iterator iterB = B.begin(); ! vector<double>::const_iterator iterC = C.begin(); ! while (iterA != A.end()) { ! *iterA += -*iterB + 2 * *iterC; ! ++iterA; ++iterB; ++iterC; ! } ! Furthermore, since the code is available at compile, not run, time, ! it can be further optimized, e.g., moving any loop-invariant code out ! of the loop. ! ! Used for Diverse Set of Scientific Problems ! ! &pooma; has been used to solve a wide variety of scientific ! problems. Most recently, physicists at Los Alamos National ! Laboratory implemented an entire library of hydrodynamics codes as ! part of the U.S. government's science-based Stockpile Stewardship ! Program to simulate nuclear weapons. Other applications include a ! matrix solver, an accelerator code simulating the dynamics of ! high-intensity charged particle beams in linear accelerators, and a ! Monte Carlo neutron transport code. ! ! Easy Implementation ! ! &pooma;'s tools greatly reduce the time to implement ! applications. As we noted above, &pooma;'s containers and expression ! syntax model the computational models and algorithms most frequently ! found in scientific programs. These high-level tools are known to be ! correct and reduce the time to debug programs. Since the same ! programs run on one processor and multiple processors, programmers ! can write and test programs using their one or two-processor personal ! computers. With no additional work, the same program runs on ! computers with hundreds of processors; the code is exactly the same, ! and the &toolkit; automatically handles distribution of the data, all ! data communication, and all synchronization. The net results is a ! significant reduction in programming time. For example, a team of ! two physicists and two support people at Los Alamos National ! Laboratory implemented a suite of hydrodynamics kernels in six ! months. Their work replaced a previous suite of less-powerful ! kernels which had taken sixteen people several years to implement and ! debug. Despite not have previously implemented any of the kernels, ! they implemented one new kernel every three days, including the time ! to read the corresponding scientific papers! !

! ! !

! &pooma; Produces Fast Programs ! ! almost as fast as &c;. wide variety of configurations: one ! processor, many processors, give performance data for at least two ! different programs ! HERE ! ! describe &doof2d; here ! ! &doof2d; is a two-dimensional diffusion simulation program. ! Initially, all values in the square two-dimensional grid are zero ! except for the central value. ! ! HERE ! !

! ! ! !

! &pooma; is Free, Open-Source Software ! ! The &poomatoolkit; is open-source software. Anyone may ! download, read, redistribute, and modify the &pooma; source code. ! If an application requires a specialized container, any programmer ! may add it. Any programmer can extend it to solve problems in ! previously unsupported domains. Companies using the &toolkit; can ! read the source code to ensure it has no hidden back doors or ! security holes. It may be downloaded for free and used for ! perpetuity. There are no annual licenses and no on-going costs. By ! keeping their own copies, companies are guaranteed the software will ! never disappear. In summary, the &poomatoolkit; is free, low-risk ! software. !

History of &pooma; ! The &poomatoolkit; was developed at Los Alamos National Laboratory to assist nuclear fusion and fission research. ! In 1994, the &toolkit; grew out of the Object-Oriented Particle Simulation ! class library developed for particle-in-cell simulations. The goals ! of the Framework, as it was called at the time, were driven by the ! Numerical Tokamak's Parallel Platform Paradox:

The average time required to implement a moderate-sized application on a parallel computer architecture is equivalent to *************** *** 298,304 ****

The framework's goal of being able to quickly write efficient scientific code that could be run on a wide variety of platforms ! remains unchanged today. Development, driven mainly by the Advanced Computing Laboratory at Los Alamos, proceeded rapidly. A matrix solver application was written using the framework. --- 337,343 ---- The framework's goal of being able to quickly write efficient scientific code that could be run on a wide variety of platforms ! remains unchanged today. Development, mainly at the Advanced Computing Laboratory at Los Alamos, proceeded rapidly. A matrix solver application was written using the framework. *************** *** 307,321 **** By 1998, &pooma; was part of the U.S. Department of Energy's Accelerated Strategic Computing Initiative ! (ASCI). The Comprehensive Test Ban Treaty ! forbid nuclear weapons testing so they were instead simulated. ! ASCI's goal was to radically advance the state ! of the art in high-performance computing and numerical simulations ! so the nuclear weapon simulations could use 100-teraflop ! computers. A linear accelerator code linac and a Monte Carlo neutron ! transport code MC++ ! were written. --- 346,360 ---- By 1998, &pooma; was part of the U.S. Department of Energy's Accelerated Strategic Computing Initiative ! (ASCI). The Comprehensive Test Ban Treaty forbid ! nuclear weapons testing so they were instead simulated using ! computers. ASCI's goal was to radically advance ! the state of the art in high-performance computing and numerical ! simulations so the nuclear weapon simulations could use 100-teraflop ! parallel computers. A linear accelerator code linac and a Monte Carlo neutron ! transport code MC++ were ! among the codes written. *************** *** 332,348 **** engines were added. Release 2.1.0 included &field;s with their spatial extent and &dynamicarray;s with the ability to dynamically change its domain size. Support for particles and ! their interaction with &field;s was added. The &pooma; messaging implementation was revised in release 2.3.0. Use of the &cheetah; Library separated &pooma; from the actual messaging ! library used. Support for applications running on clusters of ! computers was added. During the past two years, the &field; abstraction and implementation was improved to increase its flexibility, add support for multiple values and materials in the same cell, and permit lazy evaluation. Simultaneously, the ! execution speed of the inner loops was greatly increased. The ! particle code has not yet been ported to the new &field; ! abstraction.

--- 371,389 ---- engines were added. Release 2.1.0 included &field;s with their spatial extent and &dynamicarray;s with the ability to dynamically change its domain size. Support for particles and ! their interaction with &field;s were added. The &pooma; messaging implementation was revised in release 2.3.0. Use of the &cheetah; Library separated &pooma; from the actual messaging ! library used, and support for applications running on clusters of ! computers was added. CodeSourcery, LLC, and ! Proximation, LLC, took ! over &pooma; development from Los Alamos National Laboratory. ! During the past two years, the &field; abstraction and implementation was improved to increase its flexibility, add support for multiple values and materials in the same cell, and permit lazy evaluation. Simultaneously, the ! execution speed of the inner loops was greatly increased.

Index: manual.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/manual.xml,v retrieving revision 1.4 diff -c -p -r1.4 manual.xml *** manual.xml 2001/12/17 17:27:41 1.4 --- manual.xml 2002/01/04 17:14:10 *************** *** 26,31 **** --- 26,33 ---- Cheetah" > + + Doof2d" > *************** *** 38,47 **** MPI"> PDToolkit"> PETE"> ! POOMA"> POOMA &toolkitcap;"> --- 40,51 ---- MPI"> + + PDToolkit"> PETE"> ! POOMA"> POOMA &toolkitcap;"> *************** *** 87,92 **** --- 91,98 ---- Inform"> + int"> + Interval"> Layout"> *************** *** 155,162 **** --- 161,172 ---- + + + + *************** *** 183,189 **** ! ]> --- 193,205 ---- ! ! ! ! ! ! ! ]> *************** *** 205,211 **** 0.01 ! 2001 Nov 26 jdo first draft --- 221,227 ---- 0.01 ! 2001 Dec 18 jdo first draft *************** *** 280,292 **** Programming with &pooma; ! &introductory-chapter; &tutorial-chapter; &concepts-chapter; Writing Sequential Programs --- 296,1819 ---- Programming with &pooma; + + &introductory-chapter; + + + + Programming with Templates + + &pooma; extensively uses &cc; templates to support type + polymorphism without any run-time cost. In this chapter, we + briefly introduce using templates in &cc; programs by relating them + to ordinary &cc; constructs such as values, objects, + and classes. The two main concepts underlying &cc; templates will + occur repeatedly: + + + Template programming occurs at compile time, not run + time. That is, template operations occur inside the compiler, + not when a program runs. + + + Templates permit declaring families of classes with a + single declaration. For example, the &array; template + declaration permits using arrays with many different element + types, e.g., arrays of integers, arrays of floating point + numbers, and arrays of arrays. + + + For those interested in the implementation of &pooma;, we close + with a discussion of some template programming concepts used in the + implementation but not likely to be used by &pooma; users. + +

+ Templates Occur at Compile-Time + + &pooma; uses templates to support type polymorphism without + incurring any run-time cost as a program executes. All template + operations are performed at compile time by the compiler. + + Prior to the introduction of templates, almost all a + program's interesting computation occurred when it was executed. + When writing the program, the programmer, at programming + time, would specify which statements and + expressions would occur and which types to use. At compile + time, the compiler converts the program's + source code into an executable program. Even though the compiler + uses the types to produce the executable, no interesting + computation occurs. At run + time, the resulting executable program + actually performs the operations. + + The introduction of templates permits interesting + computation to occur while the compiler produces the executable. + Most interesting is template instantiation, which produces a type + at compile time. For example, the &array; type + definition requires template parameters Dim, + T, and EngineTag, specifying + its dimension, the type of its elements, and its engine type. To + use this, a programmer specifies values for the template + parameters: + Array<2,double,Brick>. + At compile time, the compiler creates a type definition by + substituting the values for the template parameters in the + template definition. The substitution is analogous to the + run-time application of a function to specific values. + + All computation not involving run-time input or output can + occur at program time, compile time, or run time, whichever is + more convenient. At program time, a programmer can perform + computations by hand rather than writing code to compute it. &cc; + templates are Turing-complete so they can compute anything. + Unfortunately, syntax for compile-time computation is more + difficult than for run-time computation, and also current compiler + are not as efficient as executables. Run-time &cc; constructs are + Turing-complete so using templates is unnecessary. Thus, we shift + computation to the time which best trades off the ease of + expressing syntax with the speed of computation by programmer, + compiler, or computer chip. For example, &pooma; uses expression + template technology to speed run-time execution of data-parallel + statements. The &pooma; developers decided to shift some of the + computation from run-time to compile-time using template + computations. The resulting run-time code runs more quickly, but + compiling the code takes longer. Also, programming time for the + &pooma; developers increased significantly, but, since most users + are most concerned about decreasing run times, they made this + choice. + +

+ + +

+ Template Programming for &pooma; Users + + Most &pooma; users need only understand a subset of + available tools for template programming. These tools include + + + reading template declarations and understanding template + parameters, which are used in this book. + + + template instantiation, specifying a particular type by + specifying values for template parameters. + + + nested type names, which are types specified within a + class definition. + + + We discuss these below. ! ! Classes Storing Pairs of Values ! &pairs-untemplated; ! ! ! Templates generalize writing class declarations by ! permitting class declarations dependent on other types. For ! example, consider writing a class storing a pair of integers and a ! class storing a pair of doubles. See . ! Almost all of the code for the two definitions is the same. Both ! of these definitions define a class with a constructor and storing ! two values named left and ! right having the same type. Only the classes' ! names and its use of types differ. ! ! ! Templated Class Storing Pairs of Values ! &pairs-templated; ! ! ! Template parameters are written before, not after, a ! class name. ! ! ! The constructor has two parameters with the type T. ! ! ! An object stores two values having type T. ! ! ! To use a templated class, specify the template ! parameter's argument after the class's name and surrounded by ! angle brackets (<>). ! ! ! ! ! Using templates, we can use a template parameter to ! represent their different uses of types and write one templated ! class definition. See . ! The templated class definition is a copy of the common portions of ! the two preceding definitions. Because the two definitions differ ! only in their use of the ∫ and &double; types, we replace ! these concrete types with a template ! parameter T. We ! precede, not follow, the class definition ! with template <typename T>. The ! constructor's parameters' types are changed ! to T as are the data members' ! types. ! ! To use a template class definition, template arguments ! follow the class name surrounded by angle ! brackets (<>). For example, ! pair<int> instantiates ! pair template class definition with ! T equal to ∫. That is, the compiler ! creates a definition for pair<int> by copying ! pair's template definition and substituting ! ∫ for each occurrence of T. The copy ! omits the template parameter declaration template ! <typename T> at the beginning of its definition. ! The result is a definition exactly the same as ! pairOfInts. + + Correspondences Between Run-Time and Compile-Time + Programming Constructs + + + + + + run time + compile time + + + + + values + integers, strings, objects, functions, … + types, … + + + create a value to store multiple values + object creation + class definition + + + values stored in a collection + data member, member function + nested type name, nested class, static member function, + constant integral values + + + placeholder for any particular value + variable, e.g., any int + template argument, e.g., any type + + + repeated operations + A function generalizes a particular operation applied to + different values. The function parameters are placeholders + for particular values. + A template class generalizes a particular class + definition using different types. The template parameters are + placeholders for particular values. + + + application + Use a function by appending function arguments + surrounded by parentheses. + Use a template class by appending template arguments + surrounded by angle brackets (<>). + + + +

+ + As we mentioned above, template instantiation is analogous + to function application. A template class is analogous to a + function. The analogy between compile-time and run-time + programming constructs can be extended. At run time, values used + consist of things such as integers, floating point numbers, + pointers, functions, and objects. Programs compute by operating + on these values at run time. At compile time, the values used + include types. Compile-time operations use these types. &cc; + defines default sets of values that all conforming compilers must + support. Object creation extends the set of run-time values, + while a class definition extends the set of compile-time types. + + Functions generalize similar run-time operations, while + template class generalize similar class definitions. A function + definition generalizes a similar run-time operation. For + example, consider repeatedly printing the largest of two numbers: + + std::cout << (3 > 4 ? 3 : 4) << std::endl; + std::cout << (4 > -13 ? 4 : -13) << std::endl; + std::cout << (23 > 4 ? 23 : 4) << std::endl; + std::cout << (0 > 3 ? 0 : 3) << std::endl; + Each statement is exactly the same except for its + two values. Thus, we can generalize these statements writing a function. + + void maxOut(int a, int b) + { std::cout &openopen; (a > b ? a : b) &openopen; std::endl; } + The function's body consists of a statement with + variables substituted for the two particular values. Each parameter + is a placeholder that, when used, holds one particular value among the + set of possible integral values. The function must be named to permit + its use, and declarations for its two parameters follow. Using the + function simplifies the code: + + maxOut(3, 4); + maxOut(4, -13); + maxOut(23, 4); + maxOut(0, 3); + To use a function, the function's name precedes + parentheses surrounding specific values for its parameters. The + function's return value does not appear. + + A template class definition generalizes similar class + definitions. If two class definitions differ only in a few types, + template parameters can be substituted. Each parameter is a + placeholder that, when used, holds one particular value, i.e., + type, among the set of possible values. The class definition is + named to permit its use, and declarations for its parameters + precede it. The example found in the previous section illustrates + this transformation. Compare the original, untemplated classes in + + with the templated class in . + Note the notation for the template class parameters. + template <typename T> + precedes the class definition. The keyword + typename indicates the template + parameter is a type. T is the template + parameter's name. Note that using + class is equivalent to using + typename so template + <class T> is equivalent to template + <typename T>. Using a templated class requires + postfix, not prefix, notation. The class's name precedes angle + brackets (<>) surrounding specific values (types) for + its parameters. As we showed above, + pair<int> instantiates + the template class pair with ∫ for its + type parameter T. + + In template programming, nested type names store + compile-time data that can be used within template classes. Since + compile-time class definitions are analogous to run-time objects + and the latter stores named values, nested type names are values, + i.e., types, stores within class definitions. For example, the + template class &array; has an nested type name for the type of its + domain: + + typedef typename Engine_t::Domain_t Domain_t; + This typedef, i.e., type + definition, defines the type Domain_t as equivalent + to Engine_t::Domain_t. The :: + operator selects the Domain_t nested type from inside + the Engine_t type. This illustrates how to access + &array;'s Domain_t when not within &array;'s scope: + Array<Dim, T, EngineTag>::Domain_t. The + analogy between object members and nested type names alludes to + its usefulness. Just as run-time object members store information + for later use, nested type names store type information for later + use at compile time. Using nested type names has no impact on the + speed of executing programs. +

+ + +

+ Template Programming Used to Write &pooma; + + The preceding section presented template programming tools + needed to read this &book; and write programs using the + &poomatoolkit;. In this section, we present template programming + techniques used to implement &pooma;. We extend the + correspondence between compile-time template programming + constructs and run-time constructs. Reading this section is not + necessary unless you wish to understand how &pooma; works. + + + More Correspondences Between Compile-Time and Run-Time + Programming Constructs + + + + + + run time + compile time + + + + + values + integers, strings, objects, functions, … + types, constant integers and enumerations, … + + + control flow to choose among operations + if, while, goto, … + template class specializations with pattern matching + + + values stored in a collection + An object stores values. + A traits + class contains values describing a type. + + + + + + + + +

+ + + + + HERE +

+ + + + + + &tutorial-chapter; &concepts-chapter; + + + + Data-Parallel Expressions + + In the previous sections, we accessed container values one at + a time. Accessing more than one value in a container required a + writing an explicit loop. Scientists and engineers commonly + operate on sets of values, treated as an aggregate. For example, a + vector is a one-dimension collection of data and two vectors can be + added together. A matrix is a two-dimensional collection of data, + and a scalar and a matrix are multiplied. A data-parallel + expression simultaneously uses multiple + container values. &pooma; supports data-parallel syntax. + + After introducing data-parallel expressions and statements, + we present the corresponding &pooma; syntax. Then we present its + implementation, which uses expression-template technology. A naive + data-parallel implementation might generate temporary variables, + cluttering a program's inner loops and slowing its execution. + Instead, &pooma; uses &pete, the Portable Expression Template + Engine. Using expression templates, it constructs a parse tree of + expressions and corresponding types, which is then quickly + evaluated without the need for temporary variables. + + +

+ Expressions with More Than One Container Value + + Science and math is filled with aggregated values. A vector + contains several components, and a matrix is a two-dimensional + object. Operations on individual values are frequently extended + to operations on these aggregated values. For example, two + vectors having the same length are added by adding corresponding + components. The product of two matrices is defined in terms of + sums and products on its components. The sine of an array is an + array containing the sine of every value in it. + + A data-parallel + expression simultaneously refers to + multiple container values. Data-parallel statements, i.e., + statements using data-parallel expressions, frequently occur in + scientific programs. For example, the sum of two vectors v and w + is written as v+w. Algorithms frequently use data-parallel + syntax. Consider, for example, computing the total energy E + as the sum of kinetic energy K and potential energy U. + For a simple particle subject to the earth's gravity, the kinetic + energy K equals mv2/2, and the + potential energy U equals mgh. These formulae apply to both + an individual particle with a particular mass m and + height h and to an entire field of particles with + masses m and heights h. Our algorithm works with + data-parallel syntax, and we would like to write the corresponding + computer program using data-parallel syntax as well.. +

+ + +

+ Their Use + + &pooma; containers can be used in data-parallel expressions + and statements. The basic guidelines are simple: + + + The &cc; built-in and mathematical operators operate on + an entire container by operating element-wise on its values. + + + Binary operators operate only on containers with the same + domain types by combining values with the same indices. If the + result is a container, it has a domain equal to the left operand's + domain. + + + For assignment operators, the domains of the left + operand and the right operand must have the same type and + be conformable, i.e., have the same shape. + + + + + The operators operate element-wise on containers' values. + For example, if A is a one-dimensional array, + -A is a one-dimensional + array with the same size such that the value at the + ith position equals -A(i). If + A and B are two-dimensional + &array;s on the same domain, + A+B + is an array on the same domain with values equaling the sum of + corresponding values in A and + B. + +

+ Adding &array;s with Different Domains + + + + + + Adding two arrays with different domains adds values + with the same indices. + + + Adding &array;s with different domains is supported. + Solid lines indicate the domains' extent. Values with the same + indices are added. + + + + + Binary operators operate on containers with the same domain + types. The domain's indices need not be the same, but the result + will have a domain equal to the left operand. For example, the + sum of an &array; A with a one-dimensional + interval [0,3] and an &array; B with + a one-dimensional interval [1,2] is well-defined because both + domains are one-dimensional intervals. The result is an &array; + with a one-dimensional interval [0,3]. Its first and last + entries equal A's first and last entries, while + its middle two entries are the sums + A(1)+B(1) and + A(2)+B(2). We assume zero is the + default value for the type of values stored + in B. A more complicated example of + adding two &array;s with different domains is illustrated in . Code for + these &array;s could be + + Interval<1> H(0,2), I(1,3), J(2,4); + Array<2, double, Brick> A(I,I), B(J,H); + // ... fill A and B with values ... + ... = A + B; + Both A and + B have domains of two-dimensional intervals so + they may be added, but their domains' extent differ, as indicated + by the solid lines in the figure. The sum has domain equal to the + left operand's domain. Values with the same indices are added. For + example, A(2,2) and + B(2,2) are added. B's + domain does not include index (1,1) so, when adding + A(1,1) and B(1,1), + the default value for B's value type is used. + Usually this is 0. Thus, A(1,1) + + B(1,1) equals 9 + 0. + + Operations with &array;s and scalar values are supported. + Conceptually, a scalar value can be thought of as an &array; with + any desired domain and having the same value everywhere. For + example, consider + + Array<1, double, Brick> D(Interval<1>(7,10)); + D += 2*D + 7; + 2*D obeys the guidelines + because the scalar 2 can be thought of as + an array with the same domain as D. It has the + same value 2 everywhere. Likewise the + conceptual domain for the scalar 7 is the + same as 2*D's domain. Thus, + 2*D(i) + 7 is added to + D(i) wherever index i is in + D's domain. In practice, the &toolkit; does + not first convert scalar values to arrays but instead uses them + directly in expressions. + + Assignment to containers is also supported. The domain + types of the assignment's left-hand side and its right-hand side + must be the same. Their indices need not be the same, but they + must correspond. That is, the domains must be conformable + domains, or have the same + shape, i.e., have the same number of indices for each + dimension. For example, the one-dimensional interval [0,3] is + conformable to the one-dimensional interval [1,4] because they + both have the same number of indices in each dimension. The + domains of A and B, as + declared + + Interval<1> H(0,2), I(1,3), J(2,4), K(0,4); + Array<2, double, Brick> A(I,I), B(H,J), C(I,K); + are conformable because each dimension has the same + number of indices. A and C + are not conformable because, while their first dimensions are + conformable, their second dimensions are not conformable. It has + three indices while the other has four. We define conformable + containers to be containers with + conformable domains. + + When assigning to a container, corresponding container + values are assigned. (Since the left-hand side and the right-hand + side are conformable, corresponding values exist.) In this code + fragment, + + Array<1, double, Brick> A(Interval<1>(0,1)); + Array<1, double, Brick> B(Interval<1>(1,2)); + A = B; + A(0) is assigned + B(1) and A(1) is + assigned B(2). + + Assigning a scalar value to an &array; also is supported, + but assigning an &array; to a scalar is not. A scalar value is + conformable to any domain because, conceptually it can be viewed + as an &array; with any desired domain and having the same value + everywhere. Thus, the assignment B = 3 + ensures every value in B equals 3. Even + though a scalar value is conformable to any &array;, it is not an + l-value so it cannot appear on the left-hand side of an + assignment. + + Data-parallel expressions can involve typical mathematical + functions and output operations. For example, + sin(A) yields an &array; with values equal + to the sine of each of &array; A's values. + dot(A,B) has values equaling the dot + product of corresponding values in &array;s A + and B. The contents of an entire &array; can + be easily printed to standard output. For example, the program + + Array<1, double, Brick> A(Interval<1>(0,2)); + Array<1, double, Brick> B(Interval<1>(1,3)); + A = 1.0; + B = 2.0; + std::cout << A-B << std::endl; + yields + + (000:002:001) = 1 -1 -1. The initial + (000:002:001) indicates the + &array;'s domain ranges from 0 to 2 with a stride of 1. The + three values in A-B follow. + + So far, all of the above examples illustrating data-parallel + expressions and statements operate on all of a container's values. + Frequently, operating on a subset is useful. In &pooma;, a subset + of a container's values is called a view. Combining views and + data-parallel expressions will enable us to more succinctly and more + easily write the diffusion program. Views are discussed in the + next chapter. + + + + + Operators Permissible for Data-Parallel Expressions + + + + + + supported operators + + + + + unary operators + +, -, ~, ! + HERE + + + binary operators + +, -, *, /, %, &, |, ^ + HERE + + + +

+ + + Mathematical Operators Permissible for Data-Parallel Expressions + + + + + function + effect + + + + + Every effort has been made to present accurate + information, but restrictions caused by the underlying + functions may further restriction the data-parallel + functions. + + + + + Array<T> peteCast (const T1&, const Array<T>& A) + Returns the casting of the array's values to type T1. + + + Array<T> ldexp (const Array<T1>& A, const Array<T2>& B) + Multiplies A's values by the + corresponding integral power of two in B. + + + + Trigonometric and Hyperbolic Operators + #include <math.h> + + + Array<T> cos (const Array<T>& A) + Returns the cosines of the array's values. + + + Array<T> sin (const Array<T>& A) + Returns the sines of the array's values. + + + Array<T> tan (const Array<T>& A) + Returns the tangents of the array's values. + + + Array<T> acos (const Array<T1>& A) + Returns the arc cosines of the array's values. + + + Array<T> asin (const Array<T1>& A) + Returns the arc sines of the array's values. + + + Array<T> atan (const Array<T1>& A) + Returns the arc tangents of the array's values. + + + Array<T> cosh (const Array<T>& A) + Returns the hyperbolic cosines of the array's values. + + + Array<T> sinh (const Array<T>& A) + Returns the hyperbolic sines of the array's values. + + + Array<T> tanh (const Array<T>& A) + Returns the hyperbolic tangents of the array's values. + + + Absolute Value and Rounding Operators + #include <math.h> + + + Array<T> fabs (const Array<T1>& A) + Returns the absolute values of the floating point + numbers in the array. + + + Array<T> ceil (const Array<T1>& A) + For each of the array's values, return the integer + larger than or equal to it (as a floating point number). + + + Array<T> ceil (const Array<T1>& A) + For each of the array's values, return the integer + larger than or equal to it (as a floating point number). + + + Array<T> floor (const Array<T1>& A) + For each of the array's values, return the integer + smaller than or equal to it (as a floating point number). + + + Powers, Exponentiation, and Logarithmic Operators + #include <math.h> + + + Array<T> PETE_identity (const Array<T>& A) + Returns the array. That is, it applies the identity operation. + + + Array<T> sqrt (const Array<T>& A) + Returns the square roots of the array's values. + + + Array<T> pow2 (const Array<T>& A) + Returns the squares of A's values. + + + Array<T> pow3 (const Array<T>& A) + Returns the cubes of A's values. + + + Array<T> pow4 (const Array<T>& A) + Returns the fourth powers of A's values. + + + Array<T> exp (const Array<T>& A) + Returns the exponentiations of the array's values. + + + Array<T> log (const Array<T>& A) + Returns the natural logarithms of the array's values. + + + Array<T> log10 (const Array<T>& A) + Returns the base-10 logarithms of the array's values. + + + Operators Involving Complex Numbers + #include <complex> + + + Array<T> real (const Array<complex<T&closeclose;& A) + Returns the real parts of A's complex numbers. + + + Array<T> imag (const Array<complex<T&closeclose;& A) + Returns the imaginary parts of A's complex numbers. + + + Array<T> abs (const Array<complex<T&closeclose;& A) + Returns the absolute values (magnitudes) of + A's complex numbers. + + + Array<T> abs (const Array<T>& A) + Returns the absolute values of A's values. + + + Array<T> arg (const Array<complex<T&closeclose;& A) + Returns the angle representations (in radians) of the + polar representations of A's complex + numbers. + + + Array<T> norm (const Array<complex<T&closeclose;& A) + Returns the squared absolute values of + A's complex numbers. + + + Array<complex<T&closeclose; conj (const Array<complex<T&closeclose;& A) + Returns the complex conjugates of + A's complex numbers. + + + Array<complex<T&closeclose; polar (const Array<T1>& A, const Array<T2>& B) + Returns the complex numbers created from polar + coordinates (magnitudes and phase angles) in corresponding + arrays. + + + Array<complex<T&closeclose; polar (const T1& l, const Array<T2>& A) + Returns the complex numbers created from polar + coordinates with magnitude l and + phase angles in the array. + + + Array<complex<T&closeclose; polar (const Array<T1>& A, const T2& r) + Returns the complex numbers created from polar + coordinates with magnitudes in the array and phase + angle r. + + + Operators Involving Matrices and Tensors + #include "Pooma/Tiny.h" + + + T trace (const Array<T>& A) + Returns the sum of the A's diagonal + entries, viewed as a matrix. + + + T det (const Array<T>& A) + Returns the determinant of A, viewed as a matrix. + + + Array<T> transpose (const Array<T>& A) + Returns the transpose of A, viewed as a matrix. + + + Array<T> symmetrize (const Array<T>& A) + Returns the tensors of A with the + requested output symmetry. + + + Array<T> dot (const Array<T1>& A, const Array<T2>& B) + Returns the dot products of values in the two arrays. + Value type T equals the type of the + dot operating on T1 + and T2. + + + Array<T> dot (const Array<T1>& A, const T2& r) + Returns the dot products of values in the array + with r. + Value type T equals the type of the + dot operating on T1 + and T2. + + + Array<T> dot (const T1& l, const Array<T2>& A) + Returns the dot products of l with + values in the array. Value type T equals the type of the + dot operating on T1 + and T2. + + + Array<T> dot (const Array<T1>& A, const T2& B) + Returns the dot products of values in the array + Value type T equals the type of the + dot operating on T1 + and T2. + + + Array<Tensor<T&closeclose; outerProduct (const Array<T1>& A, const Array<T2>& B) + Returns tensors created by computing the outer product + of corresponding vectors in the two arrays. Value + type T equals the type of the product of + T1 and T2. The vectors + must have the same length. + + + Array<Tensor<T&closeclose; outerProduct (const T1& l, const Array<T2>& A) + Returns tensors created by computing the outer product + of l with the vectors in the array. Value + type T equals the type of the product of + T1 and T2. The vectors + must have the same length. + + + Array<Tensor<T&closeclose; outerProduct (const Array<T1>& A, const T2& r) + Returns tensors created by computing the outer product + of vectors in the array with r. Value + type T equals the type of the product of + T1 and T2. The vectors + must have the same length. + + + TinyMatrix<T> outerProductAsTinyMatrix (const Array<T1>& A, const + Array<T2>& B) + Returns matrices created by computing the outer product + of corresponding vectors in the two arrays. Value + type T equals the type of the product of + T1 and T2. The vectors must have + the same length. + + + TinyMatrix<T> outerProductAsTinyMatrix (const T1& l, const + Array<T2>& A) + Returns matrices created by computing the outer + product of l with the vectors in the array. Value + type T equals the type of the product of + T1 and T2. The vectors must + have the same length. + + + TinyMatrix<T> outerProductAsTinyMatrix (const + Array<T1>& A, const T2& r) + Returns matrices created by computing the outer + product of the vectors in the array + with r. Value + type T equals the type of the product of + T1 and T2. The vectors must + have the same length. + + + Comparison Operators + + + Array<T> max (const Array<T1>& A, const Array<T2>& B) + Returns the maximum of corresponding array values. + + + Array<T> max (const T1& l, const Array<T2>& A) + Returns the maximums of l with the array's values. + + + Array<T> max (const Array<T1>& A, const T2& r) + Returns the maximums of the array's values with r. + + + Array<T> min (const Array<T1>& A, const Array<T2>& B) + Returns the minimum of corresponding array values. + + + Array<T> min (const T1& l, const Array<T2>& A) + Returns the minimums of l with the array's values. + + + Array<T> min (const Array<T1>& A, const T2& r) + Returns the minimums of the array's values with r. + + + Array<bool> LT (const Array<T1>& A, const Array<T2>& B) + Returns booleans from using the less-than + operator < to compare corresponding array values in + A and B. + + + Array<bool> LT (const T1& r, const Array<T2>& A) + Returns booleans from using the less-than + operator < to compare l with the array's + values. + + + Array<bool> LT (const Array<T1>& A, const T2& r) + Returns booleans from using the less-than + operator < to compare the array's + values with r. + + + Array<bool> LE (const Array<T1>& A, const Array<T2>& B) + Returns booleans from using the less-than-or-equal + operator ≤ to compare array values in + A and B. + + + Array<bool> LE (const T1& l, const Array<T2>& A) + Returns booleans from using the less-than-or-equal + operator ≤ to compare l with the array's values. + + + Array<bool> LE (const Array<T1>& A, const T2& r) + Returns booleans from using the less-than-or-equal + operator ≤ to compare the array's values + with r. + + + Array<bool> GE (const Array<T1>& A, const Array<T2>& B) + Returns booleans from using the greater-than-or-equal + operator ≥ to compare array values in + A and B. + + + Array<bool> GE (const T1& l, const Array<T2>& A) + Returns booleans from using the greater-than-or-equal + operator ≥ to compare l with the array's values. + + + Array<bool> GE (const Array<T1>& A, const T2& r) + Returns booleans from using the greater-than-or-equal + operator ≥ to compare the array's values with r. + + + Array<bool> GT (const Array<T1>& A, const Array<T2>& B) + Returns booleans from using the greater-than + operator > to compare array values in + A and B. + + + Array<bool> GT (const T1& l, const Array<T2>& A) + Returns booleans from using the greater-than + operator > to compare l with the array's values. + + + Array<bool> GT (const Array<T1>& A, const T2& r) + Returns booleans from using the greater-than + operator > to compare the array's values with r. + + + Array<bool> EQ (const Array<T1>& A, const Array<T2>& B) + Returns booleans from determining whether + corresponding array values in A and + B are equal. + + + Array<bool> EQ (const T1& l, const Array<T2>& A) + Returns booleans from determining whether + l equals the array's values.. + + + Array<bool> EQ (const Array<T1>& A, const T2& r) + Returns booleans from determining whether the array's values equal r. + + + Array<bool> NE (const Array<T1>& A, const Array<T2>& B) + Returns booleans from determining whether + corresponding array values in A and + B are not equal. + + + Array<bool> NE (const T1& l, const Array<T2>& A) + Returns booleans from determining whether + l does not equal the array's values. + + + Array<bool> NE (const Array<T1>& A, const T2& r) + Returns booleans from determining whether the + array's values are not equal to r. + + + + +

+ + We need to explain that proper types must be chosen. For + example, cos on complex and double works but ceil on complex does not. + HERE + + + + +

+ + +

+ Implementation of Data-Parallel Statements + + Data-parallel statements involving containers occur + frequently in the inner loops of scientific programs so their + efficient execution is important. A naive implementation for + these statements may create and destroy containers holding + intermediate values, slowing execution considerably. + In 1995, Todd Veldhuizen and David Vandevoorde developed an + expression-template technique to transform arithmetic expressions + involving array-like containers into efficient loops without using + temporaries. Despite its perceived complexity, &pooma; + incorporated the technology. The framework called &pete, the + Portable Expression Template Engine + framework, is also available separately from &pooma; at + . + + In this section, we first describe how a naive + implementation may slow execution. Then, we describe &pete;'s + faster implementation. A data-parallel statement is converted + into a parse tree, rather than immediately evaluating it. The + parse tree has two representations. Its run-time representation + holds run-time values. Its compile-time representation records + the types of the tree's values. After a parse tree for the entire + statement is constructed, it is evaluated. Since it is a + data-parallel statement, this evaluation involves at least one + loop. At run time, each loop iteration, the value of one + container value is computed and assigned. At compile time, when + the code for the loop iteration is produced, the parse tree's + types are traversed and code is produced without the need for any + intermediate values. We present the implementation in , but first we + explain the difficulties caused by the naive implementation. + +

+ Naive Implementation + + A conventional implementation to evaluate data-parallel + expressions might overload arithmetic operator functions. + Consider this program fragment: + + Interval<1> I(0,3); + Array<1, double, Brick> A(I), B(I); + A = 1.0; + B = 2.0; + A += -A + 2*B; + std::cout << A << std::endl; + Our goal is to transform the data-parallel + statement A += -A + 2*B into a single + loop, preferably without intermediary containers. To simplify + notation, let Ar abbreviate the type + Array<1, double, Brick>. + + Using overloaded arithmetic operators would require using + intermediate containers to evaluate the statement. For example, + the sum's left operand -A + would be computed by the overloaded unary operator Ar + operator-(const Ar&), which would produce an + intermediate &array;. Ar operator*(double, + const Ar&) would produce another intermediate + &array; holding 2*B. Yet another + intermediate container would hold their sum, all before + performing the assignment. Thus, three intermediate containers + would be created and destroyed. Below, we show these are + unnecessary. +

+ +

+ Portable Expression Template Engine + + &pooma; uses &pete;, the Portable Expression + Template Engine framework, to evaluate + data-parallel statements using efficient loops without + intermediate values. &pete; uses expression-template technology. + Instead of aggressively evaluating a data-parallel statement's + subexpressions, it defers evaluation, instead building a parse + tree of the required computations. The parse tree's type records + the types of each of its subtrees. Then, the parse tree is + evaluated using an evaluator determined by the left-hand side's + type. This container type determines how to loop through its + domain. Each loop iteration, the corresponding value of the + right-hand side is evaluated. No intermediate loops or temporary + values are needed. + +

+ Annotated Parse Tree for <statement>-A + 2*B</statement> + + + + + + A parse tree for the statement is produced. + + + The parse tree for -A + 2*B with + type annotations. The complete type of a node equals the + concatenation of the preorder traversal of annotated types. + + + + + Before explaining the implementation, let us illustrate + using our example statement A += -A + 2*B. + Evaluating the right-hand side creates a parse tree similar to + the one in . + For example, the overloaded unary minus operator yields a tree + node representing -A, having a unary-minus + function object, and having type + Expression<UnaryNode<OpMinus,Ar&closeclose;. + The binary nodes continue the construction process yielding a + parse tree object for the entire right-hand side and having type + Expression<BinaryNode<OpAdd, UnaryNode<OpMinus, + Ar>, + BinaryNode<OpMultiply<Scalar<int>,Ar&closeclose; >. + Evaluating the left-hand side yields an object + representing A. + + Finally, the assignment operator += + calls the evaluate function corresponding to + the left-hand side's type. At compile time, it produces the code + for the computation. Since this templated function is + specialized on the type of the left-hand side, it generates a + loop through the left-hand side's container. In the loop body, + the forEach function produces code for the + right-hand side expression at a specific position using a + post-order parse-tree traversal. At a leaf, this evaluation + queries the leaf's container for a specified value or extracts a + scalar value. At an interior node, its children's results are + combined using its function operator. One loop performs the + entire assignment. It is important to note that the type of the + entire right-hand side is known at compile time. Thus, all of + these evaluate, + forEach, and function operator function + calls can be inlined at compile time to yield simple code without + any temporary containers and hopefully as fast as hand-written + loops! + + To implement this scheme, we need &pooma; code to both + create the parse tree and to evaluate it. We describe parse tree + creation first. Parse trees consist of leaves, + UnaryNodes, BinaryNodes, and + TrinaryNodes. Since TrinaryNodes are + similar to BinaryNodes, we omit describing them. A + BinaryNode's three template parameters correspond to + the three things it must store: + + + Op + + the type of the node's operation. For example, the + OpAdd type represents adding two operands + together. + + + + Left + + the type of the left child. + + + + Right + + the type of the right child. + + + + The node stores the left and right children's nodes. + + BinaryNode does not need to store any + representation of the node's operation. Instead the + Op type is an empty structure declaring a function + object. For example, OpAdd's function object is + declared as + + template<class T1, class T2> + inline typename BinaryReturn<T1, T2, OpAdd>::Type_t + operator()(const T1 &a, const T2 &b) const + { + return (a + b); + } + Since it has two template arguments, it can be + applied to operands of any type. Because of &cc; type + conversions, the type of the result is determined using the + BinaryReturn traits class. Consider adding an ∫ + and a &double;. BinaryReturn<int, double, + OpAdd>::Type_t equals &double;. Inlining the function + ensures all this syntax is eliminated, leaving behind just an + addition. + + UnaryNodes are similar but have only two + template parameters and store only one child. + + Parse tree leaves are created by the + CreateLeaf class and its specializations. The + default leaf is a scalar so it has the most general definition: + + template<class T> + struct CreateLeaf + { + typedef Scalar<T> Leaf_t; + + inline static + Leaf_t make(const T &a) + { + return Scalar<T>(a); + } + }; + The Scalar class stores the scalar + value. The CreateLeaf's Leaf_t type + indicates its type. The static + make function is invoked by an overloaded + operator function when creating its children. + + The CreateLeaf class is specialized for &array;s: + + template<int Dim, class T, class EngineTag> + struct CreateLeaf<Array<Dim, T, EngineTag> > + { + typedef Array<Dim, T, EngineTag> Input_t; + typedef Reference<Input_t> Leaf_t; + typedef Leaf_t Return_t; + inline static + Return_t make(const Input_t &a) + { + return Leaf_t(a); + } + }; + The &array; object is stored as a + Reference, rather than directly as for scalars. + + To simplify the next step of overloading arithmetic + operators, a parse tree's topmost type is an + Expression. + + Now that we have defined the node classes, the &cc; + arithmetic operators must be overloaded to return the appropriate + parse tree. For example, unary minus operator + operator- overloaded to accept an &array; + argument should create a UnaryNode having an &array; + as its child, which will be a leaf: + + template<int D1,class T1,class E1> + inline typename MakeReturn<UnaryNode<OpUnaryMinus, + typename CreateLeaf<Array<D1,T1,E1> >::Leaf_t> >::Expression_t + operator-(const Array<D1,T1,E1> & l) + { + typedef UnaryNode<OpUnaryMinus, + typename CreateLeaf<Array<D1,T1,E1> >::Leaf_t> Tree_t; + return MakeReturn<Tree_t>::make(Tree_t( + CreateLeaf<Array<D1,T1,E1> >::make(l))); + } + Tree_t specifies the node's unique + type. Constructing the object first involves creating a leaf + containing the &array; reference through the call to + CreateLeaf<Array<D1,T1,E1> + >::make. The call to + MakeReturn<Tree_t>::make permits + programmers to store trees in different formats. The &pooma; + implementation stores them as Expressions. The + function's return type is similar to the + return statement except it extracts the + type from Expression's internal + Expression_t type. + + Specialized all the operators for &array;s using such + complicated is likely to be error-prone so &pete; provides a way + to automate it. Using its MakeOperators + command with this input: + + classes + ----- + ARG = "int D[n],class T[n],class E[n]" + CLASS = "Array<D[n],T[n],E[n]>" + automatically generates code for all the needed operators. + The [n] strings are used to number arguments for binary + and ternary operators. + + Assignment operators must also be specialized for &array;. + Inside the &array; class definition, each such operator just + invokes the assign function with a corresponding + function object. For example, operator+= + invokes assign(*this, rhs, OpAddAssign()). + rhs is the parse tree object for the right-hand + side. Calling this function invokes + evaluate, which begins the evaluation. + + Before we explain the evaluation, let us summarize the + effect of the code so far described. If we are considering run + time, parse trees for the left-hand and right-hand sides have been + constructed. If we are considering compile time, the types of + these parse trees are known. At compile time, the + evaluate function described below will + generate a loop through the left-hand side container's domain. + The loop's body will have code computing a container's value. At + run time, this code will read values from containers, but the + run-time parse tree object itself will not traversed! + + We now explore the evaluation, concentrating on compile + time, not run time. evaluate is an + overloaded function specialized on the type of the left-hand side. + In our example, the left-hand side is a one-dimensional &array;, + so evaluate(const Ar& a, const Op& op, const + RHS& rhs) is inlined into a loop like + + int end = a's domain[0].first() + a's domain[0].length(); + for (int i = a's domain[0].first(); i < end; ++i) + op(a(i), rhs.read(i)); + a is the array, + op is a function object representing the + assignment operation, and rhs is the right-hand + side's parse tree. + + Evaluating rhs.read(i) inlines into a + call to the forEach function. This function + performs a compile-time post-order parse-tree + traversal. Its general form is + + forEach(const Expression& e, const LeafTag& f, const CombineTag& c). + That is, it traverses the nodes of the + Expression object e. At + leaves, it applies the operation specified by + LeafTag f. At interior + nodes, it combines the results using the CombineTag + operator c. It inlines into a call to + + ForEach<Expression, LeafTag, CombineTag>::apply(e, f, c). + The apply function continues + the traversal through the tree. For our example, + LeafTag equals EvalLeaf<1>, and + CombineTag equals OpCombine. The former + indicates that, when reaching a leaf, the leaf should be a + one-dimensional container which should be evaluated + at the position stored in the EvalLeaf object. The + OpCombine class applies an interior node's + Op to the results of its children. + + ForEach structures are specialized for the + various node types. For example, the specialization for + UnaryNode is + + template<class Op, class A, class FTag, class CTag> + struct ForEach<UnaryNode<Op, A>, FTag, CTag> + { + typedef typename ForEach<A, FTag, CTag>::Type_t TypeA_t; + typedef typename Combine1<TypeA_t, Op, CTag>::Type_t Type_t; + inline static + Type_t apply(const UnaryNode<Op, A> &expr, const FTag &f, + const CTag &c) + { + return Combine1<TypeA_t, Op, CTag>:: + combine(ForEach<A, FTag, CTag>::apply(expr.child(), f, c), c); + } + }; + Since this structure is specialized for + UnaryNodes, the first parameter of its + static apply function + is a UnaryNode. After recursively calling its child, + it invokes the combination function indicated by the + Combine1 traits class. In our example, the + c function object should be applied. Other + combiners have different roles. For example, using the + NullCombine tag indicates the child's result should + not be combined but occurs just for side effects. + + Leaves are treated as the default behavior so they are not + specialized: + + template<class Expr, class FTag, class CTag> + struct ForEach + { + typedef typename LeafFunctor<Expr, FTag>::Type_t Type_t; + inline static + Type_t apply(const Expr &expr, const FTag &f, const CTag &) + { + return LeafFunctor<Expr, FTag>::apply(expr, f); + } + }; + Thus, LeafFunctor's + apply member is called. Expr + represents the expression type, e.g., an &array;, and + FTag is the LeafTag, e.g., + EvalLeaf. The LeafFunctorspecialization + for &array; passes the index stored by the EvalLeaf + object to the &array;'s engine, which returns the corresponding + value. + + If one uses an aggressive optimizing compiler, code + resulting from the evaluate function + corresponds to this pseudocode: + + int end = A.domain[0].first() + A.domain[0].length(); + for (int i = A.domain[0].first(); i < end; ++i) + A.engine(i) += -A.engine.read(i) + 2 * B.engine.read(i); + The loop iterates through A's + domain, using &array;'s engines to obtain values and assigning + values. Notice there is no use of the run-time parse tree so the + optimizer can eliminate the code to construct it. All the work to + construct the parse tree by overloading operators is unimportant + at run time, but it certainly helped the compiler produce improved + code. + + &pete;'s expression template technology may be complicated, + using parse trees and their types, but the code they produce is + not. Using the technology is also easy. All data-parallel + statements are automatically converted. In the next chapter, we + explore views of containers, permitting use of container subsets + and making data-parallel expressions even more useful. +

+ +

+ + + + Writing Sequential Programs *************** HERE *** 297,303 **** FIXME: Explain the format of each section. HERE ! FIXME: Explain the order of the sections. HERE Proposed order. Basically follow the order in the proposed --- 1824,1830 ---- FIXME: Explain the format of each section. HERE ! FIXME: Explain the order of the sections. HERE Proposed order. Basically follow the order in the proposed *************** HERE *** 475,490 **** finalize. These functions respectively prepare and shut down &pooma;'s run-time structures. !

! Files #include "Pooma/Pooma.h" // or "Pooma/Arrays.h" or "Pooma/Fields.h" or ... -

! Declarations --- 2002,2014 ---- finalize. These functions respectively prepare and shut down &pooma;'s run-time structures. ! Files #include "Pooma/Pooma.h" // or "Pooma/Arrays.h" or "Pooma/Fields.h" or ... ! Declarations *************** HERE *** 520,529 **** -

! Description Before its use, the &poomatoolkit; must be initialized by a call to initialize. This usually occurs in --- 2044,2051 ---- ! Description Before its use, the &poomatoolkit; must be initialized by a call to initialize. This usually occurs in *************** HERE *** 572,581 **** Including almost any &pooma; header file, rather than just Pooma/Pooma.h suffices since most other &pooma; header files include it. -

! Example Program Since every &pooma; program must call initialize and --- 2094,2101 ---- Including almost any &pooma; header file, rather than just Pooma/Pooma.h suffices since most other &pooma; header files include it. ! Example Program Since every &pooma; program must call initialize and *************** HERE *** 584,599 **** use. &initialize-finalize; -

&pooma; Command-line Options Every &pooma; program accepts a set of &pooma;-specific command-line options to set values at run-time.

Options Summary --- 2104,2163 ---- use. &initialize-finalize;

+ +

+ Global Variables + + &pooma; makes a few global variables available after + initialization. + + + &pooma; Global Variables + + + + + variable + description + + + + + &inform; pinfo + output stream used to print informative messages to the + user while the program executes. The stream accepts a + superset of standard output operations. + + + &inform; pwarn + HERE output stream used to print informative messages to the + user while the program executes. The stream accepts a + superset of standard output operations. + + + +

+ +

+ + +

&pooma; Command-line Options Every &pooma; program accepts a set of &pooma;-specific command-line options to set values at run-time. + QUESTION: Should I defer documenting &options; to the + reference manual, instead just listing commonly used options in + the previous section? + + UNFINISHED +

Options Summary *************** HERE *** 601,614 **** &dashdash;pooma-info ! ! HERE Who uses this? FIXME: Be sure to list default values. --- 2165,2181 ---- &dashdash;pooma-info ! enable use of the pinfo, used to ! print informative messages to the user while the program ! executes. FIXME: Be sure to list default values. + + *************** HERE Who uses this? *** 616,627 **** - QUESTION: Should I defer documenting &options; to the - reference manual, instead just listing commonly used options in - the previous section? - - UNFINISHED -

--- 2183,2188 ---- *************** UNFINISHED *** 740,746 **** code. An Array maps a fairly arbitrary input domain to an arbitrary range of outputs. When used by itself, an &array; object A refers to all of the values in its ! domain. Element-wise mathematical operations or functions can be applied to an array using straightforward notation, like A + B or sin(A). Expressions involving Array objects are themselves Arrays. The operation A(d), where d is a domain object that --- 2301,2307 ---- code. An Array maps a fairly arbitrary input domain to an arbitrary range of outputs. When used by itself, an &array; object A refers to all of the values in its ! domain. Element-wise mathematical operations or functions can be applied to an array using straightforward notation, like A + B or sin(A). Expressions involving Array objects are themselves Arrays. The operation A(d), where d is a domain object that *************** UNFINISHED *** 1188,1195 **** class="libraryfile">.cmpl.cpp, .mk, .conf. Should we also explain use ! of inline even when necessary and the template ! model, e.g., including .cpp files. QUESTION: What are the key concepts around which to organize --- 2749,2756 ---- class="libraryfile">.cmpl.cpp, .mk, .conf. Should we also explain use ! of inline even when necessary and the template ! model, e.g., including .cpp files. QUESTION: What are the key concepts around which to organize *************** UNFINISHED *** 1420,1426 **** dimension ! T array element type --- 2981,2987 ---- dimension ! T array element type *************** UNFINISHED *** 3014,3021 **** class="headerfile">src/Utilities/DerefIterator.h: DerefIterator<T> and ConstDerefIterator<T> automatically ! dereference themselves to maintain const ! correctness. --- 4575,4582 ---- class="headerfile">src/Utilities/DerefIterator.h: DerefIterator<T> and ConstDerefIterator<T> automatically ! dereference themselves to maintain const ! correctness. *************** UNFINISHED *** 3042,3048 **** Discuss &options; and related material. Add developer command-line options listed in Utilities/Options.cmpl.cpp and also possibly &dashdash;pooma-threads n. --- 4603,4609 ---- Discuss &options; and related material. Add developer command-line options listed in Utilities/Options.cmpl.cpp and also possibly &dashdash;pooma-threads n. *************** UNFINISHED *** 3600,3859 **** - - - - - Bibliography - - FIXME: How do I process these entries? - - - mpi99 - - - WilliamGropp - - - EwingLusk - - - AnthonySkjellum - - - - 1999 - Massachusetts Institute of Technology - - 0-262-57132-3 - - The MIT Press -

Cambridge, MA

- - Using MPI - Portable Parallel Programming with the Message-Passing Interface - second edition - - - - pooma95 - - - JohnV. W.Reynders - - Los Alamos National Laboratory -

Los AlamosNM

- - - - PaulJ.Hinker - - Dakota Software Systems, Inc. -

Rapid CitySD

- - - - JulianC.Cummings - - Los Alamos National Laboratory -

Los AlamosNM

- - - - SusanR.Atlas - - Parallel Solutions, Inc. -

Santa FeNM

- - - - SubhankarBanerjee - - New Mexico State University -

Las CrucesNM

- - - - WilliamF.Humphrey - - University of Illinois at Urbana-Champaign -

Urbana-ChampaignIL

- - - - SteveR.Karmesin - - California Institute of Technology -

PasadenaCA

- - - - KatarzynaKeahey - - Indiana University -

BloomingtonIN

- - - - MarydellTholburn - - Los Alamos National Laboratory -

Los AlamosNM

- - - - &pooma; - A Framework for Scientific Simulation on Parallel Architectures - unpublished - - - - pooma-sc95 - - - SusanAtlas - - Los Alamos National Laboratory -

Los AlamosNM

- - - - SubhankarBanerjee - - New Mexico State University -

Las CrucesNM

- - - - JulianC.Cummings - - Los Alamos National Laboratory -

Los AlamosNM

- - - - PaulJ.Hinker - - Advanced Computing Laboratory -

Los AlamosNM

- - - - M.Srikant - - New Mexico State University -

Las CrucesNM

- - - - JohnV. W.Reynders - - Los Alamos National Laboratory -

Los AlamosNM

- - - - MarydellTholburn - - Los Alamos National Laboratory -

Los AlamosNM

- - - - &pooma; - A High Performance Distributed Simulation Environment for - Scientific Applications - - - - - pooma-siam98 - - - JulianC.Cummings - - Los Alamos National Laboratory -

Los AlamosNM

- - - - JamesA.Crotinger - - Los Alamos National Laboratory -

Los AlamosNM

- - - - ScottW.Haney - - Los Alamos National Laboratory -

Los AlamosNM

- - - - WilliamF.Humphrey - - Los Alamos National Laboratory -

Los AlamosNM

- - - - SteveR.Karmesin - - Los Alamos National Laboratory -

Los AlamosNM

- - - - JohnV. W.Reynders - - Los Alamos National Laboratory -

Los AlamosNM

- - - - StephenA.Smith - - Los Alamos National Laboratory -

Los AlamosNM

- - - - TimothyJ.Williams - - Los Alamos National Laboratory -

Los AlamosNM

- - - - Raid Application Development and Enhanced Code - Interoperability using the &pooma; Framework - - - - - - pete-99 - - - ScottHaney - - - JamesCrotinger - - - SteveKarmesin - - - StephenSmith - - - Easy Expression Templates Using &pete;: The Portable - Expression Template Engine - - - &glossary-chapter; --- 5161,5168 ---- + &bibliography-chapter; &glossary-chapter; Index: tutorial.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/tutorial.xml,v retrieving revision 1.3 diff -c -p -r1.3 tutorial.xml *** tutorial.xml 2001/12/17 17:27:42 1.3 --- tutorial.xml 2002/01/04 17:14:11 *************** *** 54,60 **** ! The Initial Configuration --- 54,60 ---- ! The Initial &doof2d; Configuration *************** *** 476,482 **** ! Adding two arrays with different domains. When adding arrays, values in corresponding positions are --- 476,482 ---- ! Adding two arrays with different domains is supported. When adding arrays, values in corresponding positions are *************** *** 587,593 **** ! Apply a stencil to position (1,3) of an array. To compute the value associated with index position (1,3) --- 587,593 ---- ! Apply a stencil to position (1,3) of an &array;. To compute the value associated with index position (1,3) *************** *** 692,698 **** ! the &pooma; distributed computation model. The &pooma; distributed computation model combines --- 692,698 ---- ! the &pooma; distributed computation model The &pooma; distributed computation model combines Index: figures/box-macros.mp =================================================================== RCS file: box-macros.mp diff -N box-macros.mp *** /dev/null Fri Mar 23 21:37:44 2001 --- box-macros.mp Fri Jan 4 10:14:11 2002 *************** *** 0 **** --- 1,106 ---- + %% Oldham, Jeffrey D. + %% 2001Dec20 + %% Pooma + + %% Macros to Improve Boxes + + %% Assumes 'input boxes;' + + % Ensure a list of boxes all have the same width. + % input <- suffixes for the boxes; + % output-> all boxes have the same width (maximum picture width + defaultdx) + vardef samewidth(suffix $)(text t) = + save p_; pair p_; + p_ = maxWidthAndHeight($)(t); + numericSetWidth(xpart(p_)+2defaultdx)($)(t); + enddef; + + % Ensure a list of boxes all have the same height. + % input <- suffixes for the boxes; + % output-> all boxes have the same height (maximum picture height + defaultdy) + vardef sameheight(suffix $)(text t) = + save p_; pair p_; + p_ = maxWidthAndHeight($)(t); + numericSetWidth(ypart(p_)+2defaultdy)($)(t); + enddef; + + % Given a list of boxes, determine the maximum picture width and + % maximum picture height. + % input <- suffixes for the boxes + % output-> pair of maximum picture width and height + vardef maxWidthAndHeight(suffix f)(text t) = + save w_, h_; numeric w_, h_; + w_ = xpart((urcorner pic_.f - llcorner pic_.f)); + h_ = ypart((urcorner pic_.f - llcorner pic_.f)); + forsuffixes uu = t: + if xpart((urcorner pic_.uu - llcorner pic_.uu)) > w_ : + w_ := xpart((urcorner pic_.uu - llcorner pic_.uu)); + fi + if ypart((urcorner pic_.uu - llcorner pic_.uu)) > h_ : + h_ := ypart((urcorner pic_.uu - llcorner pic_.uu)); + fi + endfor + (w_, h_) + enddef; + + % Given a width, ensure a box has the given width. + % input <- box width + % suffix for the one box + % output-> the box has the given width by setting its .dx + vardef numericSetWidthOne(expr width)(suffix f) = + f.dx = 0.5(width - xpart(urcorner pic_.f - llcorner pic_.f)); + enddef; + + % Given a width, ensure all boxes have the given width. + % input <- box width + % suffixes for the boxes + % output-> all boxes have the given width by setting their .dx + vardef numericSetWidth(expr width)(suffix f)(text t) = + f.dx = 0.5(width - xpart(urcorner pic_.f - llcorner pic_.f)); + forsuffixes $ = t: + $.dx = 0.5(width - xpart(urcorner pic_.$ - llcorner pic_.$)); + endfor + enddef; + + % Given a height, ensure all boxes have the given height. + % input <- box height + % suffixes for the boxes + % output-> all boxes have the given height by setting their .dx + vardef numericSetHeight(expr height)(suffix f)(text t) = + f.dy = 0.5(height - ypart(urcorner pic_.f - llcorner pic_.f)); + forsuffixes $ = t: + $.dy = 0.5(height - ypart(urcorner pic_.$ - llcorner pic_.$)); + endfor + enddef; + + % Ensure a list of boxes and circles all to have the same width, height, + % and diameter. + % input <- suffixes for the boxes and circles + % output-> all boxes have .dx and .dy set so they have the same width, + % height, and radius + % The boxes are squares and the circles are circular, not oval. + vardef sameWidthAndHeight(suffix f)(text t) = + save p_; pair p_; + p_ = maxWidthAndHeight(f)(t); + if (xpart(p_)+2defaultdx >= ypart(p_)+2defaultdy): + numericSetWidth(xpart(p_)+2defaultdx)(f)(t); + numericSetHeight(xpart(p_)+2defaultdx)(f)(t); + else: + numericSetWidth(ypart(p_)+2defaultdy)(f)(t); + numericSetHeight(ypart(p_)+2defaultdy)(f)(t); + fi + enddef; + + % Ensure a list of boxes and circles all to have the same width and + % the same height. Unlike sameWidthAndHeight, the width and height + % can differ. + % input <- suffixes for the boxes and circles + % output-> all boxes have .dx and .dy set so they have the same width, + % height, and radius + % The boxes are squares and the circles are circular, not oval. + vardef sameWidthSameHeight(suffix f)(text t) = + save p_; pair p_; + p_ = maxWidthAndHeight(f)(t); + numericSetWidth(xpart(p_)+2defaultdx)(f)(t); + numericSetHeight(ypart(p_)+2defaultdy)(f)(t); + enddef; Index: figures/data-parallel.mp =================================================================== RCS file: data-parallel.mp diff -N data-parallel.mp *** /dev/null Fri Mar 23 21:37:44 2001 --- data-parallel.mp Fri Jan 4 10:14:11 2002 *************** *** 0 **** --- 1,157 ---- + %% Oldham, Jeffrey D. + %% 2001Dec20 + %% Pooma + + %% Illustrations for the Data-Parallel Chapter + + %% Assumes TEX=latex. + + input boxes; + input box-macros; + input grid-macros; + + verbatimtex + \documentclass[10pt]{article} + \input{macros.ltx} + \begin{document} + etex + + %% Parse Tree for Example Statement A += -A + 2*B + beginfig(101) + numeric unit; unit = 1.5cm; + numeric xunit; xunit = unit; + numeric yunit; yunit = unit; + + %% Create the tree nodes. + circleit.b0(btex \statement{+=} etex); + circleit.b1(btex \varname{A} etex); + circleit.b2(btex \statement{+} etex); + circleit.b3(btex \statement{-} etex); + circleit.b4(btex \varname{A} etex); + circleit.b5(btex \statement{*} etex); + circleit.b6(btex \statement{2} etex); + circleit.b7(btex \varname{B} etex); + numeric nuBoxes; nuBoxes = 7; + sameWidthAndHeight(b0,b1,b2,b3,b4,b5,b6,b7); + + %% Position the tree nodes. + b2.c = origin; + b0.c - 0.5[b1.c,b2.c] = (0,yunit); + b2.c - 0.5[b3.c,b5.c] = (0,yunit); + b3.c - 0.5[b4.c,b6.c] = (0,yunit); + b5.c - 0.5[b6.c,b7.c] = (0,yunit); + b1.c - b2.c = b3.c - b5.c = b4.c - b6.c = b6.c - b8.c = (-xunit,0); + + %% Draw the tree. + for t = 2 upto 7: + drawboxed(b[t]); + endfor + vardef drawEdge(expr start, stop) = + draw b[start].c -- b[stop].c cutbefore bpath b[start] cutafter bpath b[stop]; + enddef; + for t = (2,3), (2,5), (3,4), (5,6), (5,7): + drawEdge(xpart(t),ypart(t)); + endfor + + %% Label the node's types. + % TMP label.rt(btex \type{OpAddAssign} etex, b0.e); + % TMP label.rt(btex \type{Expression} etex, 0.5[b0.c,b2.c]); + label.top(btex \type{Expression} etex, b2.n); + % TMP label.lft(btex \type{Ar} etex, b1.w); + label.rt(btex \type{BinaryNode} etex, b6.s); + label.rt(btex \type{Ar} etex, b7.e); + + endfig; + + + %% An illustratation of the addition of arrays. + beginfig(212) + numeric unit; unit = 0.9cm; % width or height of an individual grid cell + numeric nuCells; nuCells = 5; % number of cells in each dimension + % This number should be odd. + numeric nuArrayCells; nuArrayCells = 3; + % number of cells in array in each dimension + numeric operatorWidth; operatorWidth = 1.5; + % horizontal space for an operator as + % a multiple of "unit" + + %% Determine the locations of the arrays. + z0 = origin; + z1 = z0 + unit * (nuCells+operatorWidth,0); + z2 - z1 = z1 - z0; + + %% Draw the grid cells and the operators. + for t = 0 upto 2: + drawGridDashed(nuCells, unit, z[t]); + endfor + for t = 0 upto 1: + drawGrid(nuArrayCells, unit, z[t]+unit*(1,1)); + endfor + drawGrid(nuArrayCells, unit, z2+unit*(2,0)); + + label(btex = etex, z1 + unit*(-0.6operatorWidth, 0.5nuCells)); + label(btex + etex, z2 + unit*(-0.6operatorWidth, 0.5nuCells)); + + %% Label the indices. + % Label b(I,J) grid indices. + for t = 0 upto 2: + labelCellBottom(btex \footnotesize 0 etex, (0,0), z[t]); + labelCellBottom(btex \footnotesize 1 etex, (1,0), z[t]); + labelCellBottom(btex \footnotesize 2 etex, (2,0), z[t]); + labelCellBottom(btex \footnotesize 3 etex, (3,0), z[t]); + labelCellBottom(btex \footnotesize 4 etex, (4,0), z[t]); + labelCellLeft(btex \footnotesize 0 etex, (0,0), z[t]); + labelCellLeft(btex \footnotesize 1 etex, (0,1), z[t]); + labelCellLeft(btex \footnotesize 2 etex, (0,2), z[t]); + labelCellLeft(btex \footnotesize 3 etex, (0,3), z[t]); + labelCellLeft(btex \footnotesize 4 etex, (0,4), z[t]); + endfor + + %% Label the grid cells' values. + % Label b(I,J) grid values. + pair zShift; + zShift := z1 + unit*(1,1); + labelCell(btex \normalsize 9 etex, (0,0), zShift); + labelCell(btex \normalsize 11 etex, (1,0), zShift); + labelCell(btex \normalsize 13 etex, (2,0), zShift); + labelCell(btex \normalsize 17 etex, (0,1), zShift); + labelCell(btex \normalsize 19 etex, (1,1), zShift); + labelCell(btex \normalsize 21 etex, (2,1), zShift); + labelCell(btex \normalsize 25 etex, (0,2), zShift); + labelCell(btex \normalsize 27 etex, (1,2), zShift); + labelCell(btex \normalsize 29 etex, (2,2), zShift); + % Label b(I+1,J-1) grid values. + zShift := z2 + unit*(2,0); + labelCell(btex \normalsize 3 etex, (0,0), zShift); + labelCell(btex \normalsize 5 etex, (1,0), zShift); + labelCell(btex \normalsize 7 etex, (2,0), zShift); + labelCell(btex \normalsize 11 etex, (0,1), zShift); + labelCell(btex \normalsize 13 etex, (1,1), zShift); + labelCell(btex \normalsize 15 etex, (2,1), zShift); + labelCell(btex \normalsize 19 etex, (0,2), zShift); + labelCell(btex \normalsize 21 etex, (1,2), zShift); + labelCell(btex \normalsize 23 etex, (2,2), zShift); + % Label b(I,J)+b(I+1,J-1) grid values. + zShift := z0 + unit*(1,1); + labelCell(btex \normalsize 9 etex, (0,0), zShift); + labelCell(btex \normalsize 22 etex, (1,0), zShift); + labelCell(btex \normalsize 26 etex, (2,0), zShift); + labelCell(btex \normalsize 17 etex, (0,1), zShift); + labelCell(btex \normalsize 38 etex, (1,1), zShift); + labelCell(btex \normalsize 42 etex, (2,1), zShift); + labelCell(btex \normalsize 25 etex, (0,2), zShift); + labelCell(btex \normalsize 27 etex, (1,2), zShift); + labelCell(btex \normalsize 29 etex, (2,2), zShift); + + %% Label the grids. + labelGrid(btex $A+B$ etex, nuCells, z0); + labelGrid(btex $A$ etex, nuCells, z1); + labelGrid(btex $B$ etex, nuCells, z2); + endfig; + + + bye Index: figures/doof2d.mp =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/doof2d.mp,v retrieving revision 1.2 diff -c -p -r1.2 doof2d.mp *** figures/doof2d.mp 2001/12/11 20:36:13 1.2 --- figures/doof2d.mp 2002/01/04 17:14:11 *************** verbatimtex *** 12,46 **** \begin{document} etex ! % Draw a set of grid cells. ! vardef drawGrid(expr nuCells, unit, llCorner) = ! for i = 0 upto nuCells-1: ! for j = 0 upto nuCells-1: ! draw unitsquare scaled unit shifted (llCorner + unit*(i,j)); ! endfor ! endfor ! enddef; ! ! % Label the specified grid, grid cell, or its edge. ! % Place a value at the center of a grid cell. ! vardef labelCell(expr lbl, xy, llCorner) = ! label(lbl, llCorner + unit*(xy + 0.5*(1,1))); ! enddef; ! ! % Label the bottom of a grid cell. ! vardef labelCellBottom(expr lbl, xy, llCorner) = ! label.bot(lbl, llCorner + unit*(xy + 0.5*(1,0))); ! enddef; ! ! % Label the left side of a grid cell. ! vardef labelCellLeft(expr lbl, xy, llCorner) = ! label.lft(lbl, llCorner + unit*(xy + 0.5*(0,1))); ! enddef; ! ! % Label the top of a grid. ! vardef labelGrid(expr lbl, nuCells, llCorner) = ! label.top(lbl, llCorner + unit*(nuCells/2,nuCells)); ! enddef; %% Global Declarations numeric unit; unit = 0.9cm; % width or height of an individual grid cell --- 12,18 ---- \begin{document} etex ! input grid-macros; %% Global Declarations numeric unit; unit = 0.9cm; % width or height of an individual grid cell Index: figures/grid-macros.mp =================================================================== RCS file: grid-macros.mp diff -N grid-macros.mp *** /dev/null Fri Mar 23 21:37:44 2001 --- grid-macros.mp Fri Jan 4 10:14:11 2002 *************** *** 0 **** --- 1,45 ---- + %% Oldham, Jeffrey D. + %% 2001Dec21 + %% Pooma + + %% Macros for Drawing Grids + + % Draw a set of grid cells. + vardef drawGrid(expr nuCells, unit, llCorner) = + for i = 0 upto nuCells-1: + for j = 0 upto nuCells-1: + draw unitsquare scaled unit shifted (llCorner + unit*(i,j)); + endfor + endfor + enddef; + + % Draw a set of grid cells with dashed lines. + vardef drawGridDashed(expr nuCells, unit, llCorner) = + for i = 0 upto nuCells-1: + for j = 0 upto nuCells-1: + draw unitsquare scaled unit shifted (llCorner + unit*(i,j)) dashed evenly; + endfor + endfor + enddef; + + % Label the specified grid, grid cell, or its edge. + % Place a value at the center of a grid cell. + vardef labelCell(expr lbl, xy, llCorner) = + label(lbl, llCorner + unit*(xy + 0.5*(1,1))); + enddef; + + % Label the bottom of a grid cell. + vardef labelCellBottom(expr lbl, xy, llCorner) = + label.bot(lbl, llCorner + unit*(xy + 0.5*(1,0))); + enddef; + + % Label the left side of a grid cell. + vardef labelCellLeft(expr lbl, xy, llCorner) = + label.lft(lbl, llCorner + unit*(xy + 0.5*(0,1))); + enddef; + + % Label the top of a grid. + vardef labelGrid(expr lbl, nuCells, llCorner) = + label.top(lbl, llCorner + unit*(nuCells/2,nuCells)); + enddef; + Index: figures/introduction.mp =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/introduction.mp,v retrieving revision 1.1 diff -c -p -r1.1 introduction.mp *** figures/introduction.mp 2001/12/17 17:27:42 1.1 --- figures/introduction.mp 2002/01/04 17:14:11 *************** *** 7,12 **** --- 7,13 ---- %% Assumes TEX=latex. input boxes; + input box-macros; verbatimtex \documentclass[10pt]{article} *************** beginfig(101) *** 21,125 **** numeric horizSpace; horizSpace = 8unit; numeric vertSpace; vertSpace = unit; numeric nuBoxes; % number of boxes - - % Ensure a list of boxes all have the same width. - % input <- suffixes for the boxes; - % output-> all boxes have the same width (maximum picture width + defaultdx) - vardef samewidth(suffix $)(text t) = - save p_; pair p_; - p_ = maxWidthAndHeight($)(t); - numericSetWidth(xpart(p_)+2defaultdx)($)(t); - enddef; - - % Ensure a list of boxes all have the same height. - % input <- suffixes for the boxes; - % output-> all boxes have the same height (maximum picture height + defaultdy) - vardef sameheight(suffix $)(text t) = - save p_; pair p_; - p_ = maxWidthAndHeight($)(t); - numericSetWidth(ypart(p_)+2defaultdy)($)(t); - enddef; - - % Given a list of boxes, determine the maximum picture width and - % maximum picture height. - % input <- suffixes for the boxes - % output-> pair of maximum picture width and height - vardef maxWidthAndHeight(suffix f)(text t) = - save w_, h_; numeric w_, h_; - w_ = xpart((urcorner pic_.f - llcorner pic_.f)); - h_ = ypart((urcorner pic_.f - llcorner pic_.f)); - forsuffixes uu = t: - if xpart((urcorner pic_.uu - llcorner pic_.uu)) > w_ : - w_ := xpart((urcorner pic_.uu - llcorner pic_.uu)); - fi - if ypart((urcorner pic_.uu - llcorner pic_.uu)) > h_ : - h_ := ypart((urcorner pic_.uu - llcorner pic_.uu)); - fi - endfor - (w_, h_) - enddef; - - % Given a width, ensure a box has the given width. - % input <- box width - % suffix for the one box - % output-> the box has the given width by setting its .dx - vardef numericSetWidthOne(expr width)(suffix f) = - f.dx = 0.5(width - xpart(urcorner pic_.f - llcorner pic_.f)); - enddef; - - % Given a width, ensure all boxes have the given width. - % input <- box width - % suffixes for the boxes - % output-> all boxes have the given width by setting their .dx - vardef numericSetWidth(expr width)(suffix f)(text t) = - f.dx = 0.5(width - xpart(urcorner pic_.f - llcorner pic_.f)); - forsuffixes $ = t: - $.dx = 0.5(width - xpart(urcorner pic_.$ - llcorner pic_.$)); - endfor - enddef; - - % Given a height, ensure all boxes have the given height. - % input <- box height - % suffixes for the boxes - % output-> all boxes have the given height by setting their .dx - vardef numericSetHeight(expr height)(suffix f)(text t) = - f.dy = 0.5(height - ypart(urcorner pic_.f - llcorner pic_.f)); - forsuffixes $ = t: - $.dy = 0.5(height - ypart(urcorner pic_.$ - llcorner pic_.$)); - endfor - enddef; - - % Ensure a list of boxes and circles all to have the same width, height, - % and diameter. - % input <- suffixes for the boxes and circles - % output-> all boxes have .dx and .dy set so they have the same width, - % height, and radius - % The boxes are squares and the circles are circular, not oval. - vardef sameWidthAndHeight(suffix f)(text t) = - save p_; pair p_; - p_ = maxWidthAndHeight(f)(t); - if (xpart(p_)+2defaultdx >= ypart(p_)+2defaultdy): - numericSetWidth(xpart(p_)+2defaultdx)(f)(t); - numericSetHeight(xpart(p_)+2defaultdx)(f)(t); - else: - numericSetWidth(ypart(p_)+2defaultdy)(f)(t); - numericSetHeight(ypart(p_)+2defaultdy)(f)(t); - fi - enddef; - - % Ensure a list of boxes and circles all to have the same width and - % the same height. Unlike sameWidthAndHeight, the width and height - % can differ. - % input <- suffixes for the boxes and circles - % output-> all boxes have .dx and .dy set so they have the same width, - % height, and radius - % The boxes are squares and the circles are circular, not oval. - vardef sameWidthSameHeight(suffix f)(text t) = - save p_; pair p_; - p_ = maxWidthAndHeight(f)(t); - numericSetWidth(xpart(p_)+2defaultdx)(f)(t); - numericSetHeight(ypart(p_)+2defaultdy)(f)(t); - enddef; % Create the boxes. boxit.b0(btex \textsl{science / math} etex); --- 22,27 ---- Index: programs/Doof2d-Array-distributed-annotated.patch =================================================================== RCS file: Doof2d-Array-distributed-annotated.patch diff -N Doof2d-Array-distributed-annotated.patch *** /tmp/cvsKKb5AR Fri Jan 4 10:14:11 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,184 **** - *** Doof2d-Array-distributed.cpp Wed Dec 5 14:04:36 2001 - --- Doof2d-Array-distributed-annotated.cpp Wed Dec 5 14:07:56 2001 - *************** - *** 1,3 **** - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - *************** - *** 14,18 **** - // (i,j). The "C" template parameter permits use of this stencil - // operator with both Arrays and Fields. - ! template - inline - typename C::Element_t - --- 16,20 ---- - // (i,j). The "C" template parameter permits use of this stencil - // operator with both Arrays and Fields. - ! template <class C> - inline - typename C::Element_t - *************** - *** 42,46 **** - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - --- 44,48 ---- - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - *************** - *** 48,52 **** - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; - return EXIT_FAILURE; - } - --- 50,54 ---- - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; - return EXIT_FAILURE; - } - *************** - *** 55,63 **** - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 57,65 ---- - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 65,69 **** - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - --- 67,71 ---- - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - *************** - *** 71,80 **** - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the distributed arrays. - --- 73,82 ---- - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the distributed arrays. - *************** - *** 83,98 **** - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire array domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // The template parameters indicate 2 dimensions and a 'double' - // element type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Array<2, double, MultiPatch > > a(layout); - ! Array<2, double, MultiPatch > > b(layout); - - // Set up the initial conditions. - --- 85,100 ---- - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire array domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // The template parameters indicate 2 dimensions and a 'double' - // element type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > a(layout); - ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > b(layout); - - // Set up the initial conditions. - *************** - *** 104,112 **** - - // Create the stencil performing the computation. - ! Stencil stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - --- 106,114 ---- - - // Create the stencil performing the computation. - ! Stencil<DoofNinePt> stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - *************** - *** 117,121 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 119,123 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - *************** - *** 125,126 **** - --- 127,129 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: programs/Doof2d-Array-element-annotated.patch =================================================================== RCS file: Doof2d-Array-element-annotated.patch diff -N Doof2d-Array-element-annotated.patch *** /tmp/cvslmAiwW Fri Jan 4 10:14:11 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,143 **** - *** Doof2d-Array-element.cpp Tue Dec 4 12:02:10 2001 - --- Doof2d-Array-element-annotated.cpp Tue Dec 4 12:24:25 2001 - *************** - *** 1,5 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - ! #include "Pooma/Arrays.h" // has Pooma's Array - - // Doof2d: Pooma Arrays, element-wise implementation - --- 1,6 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - ! #include "Pooma/Arrays.h" // has Pooma's Array - - // Doof2d: Pooma Arrays, element-wise implementation - *************** - *** 7,17 **** - int main(int argc, char *argv[]) - { - ! // Prepare the Pooma library for execution. - Pooma::initialize(argc,argv); - - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 8,18 ---- - int main(int argc, char *argv[]) - { - ! // Prepare the Pooma library for execution. - Pooma::initialize(argc,argv); - - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,37 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - ! // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - for (int j = 1; j < n-1; j++) - for (int i = 1; i < n-1; i++) - --- 20,38 ---- - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - ! // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - for (int j = 1; j < n-1; j++) - for (int i = 1; i < n-1; i++) - *************** - *** 43,51 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - ! a(i,j) = weight * - (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + - b(i ,j+1) + b(i ,j ) + b(i ,j-1) + - --- 44,52 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - ! a(i,j) = weight * - (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + - b(i ,j+1) + b(i ,j ) + b(i ,j-1) + - *************** - *** 53,58 **** - - // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b(i,j) = weight * - (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + - --- 54,59 ---- - - // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b(i,j) = weight * - (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + - *************** - *** 62,71 **** - - // Print out the final central value. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - ! // The arrays are automatically deallocated. - - ! // Tell the Pooma library execution has finished. - Pooma::finalize(); - return EXIT_SUCCESS; - } - --- 63,74 ---- - - // Print out the final central value. - ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - ! // The arrays are automatically deallocated. - - ! // Tell the Pooma library execution has finished. - Pooma::finalize(); - return EXIT_SUCCESS; - } - + --- 0 ---- Index: programs/Doof2d-Array-parallel-annotated.patch =================================================================== RCS file: Doof2d-Array-parallel-annotated.patch diff -N Doof2d-Array-parallel-annotated.patch *** /tmp/cvsuReKr3 Fri Jan 4 10:14:11 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,116 **** - *** Doof2d-Array-parallel.cpp Tue Dec 4 11:49:43 2001 - --- Doof2d-Array-parallel-annotated.cpp Tue Dec 4 12:24:36 2001 - *************** - *** 1,4 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - *************** - *** 12,17 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 13,18 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,43 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - // All grid values should be zero except for the central value. - a = b = 0.0; - ! // Ensure all data-parallel computation finishes before accessing a value. - Pooma::blockAndEvaluate(); - b(n/2,n/2) = 1000.0; - --- 20,44 ---- - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - // All grid values should be zero except for the central value. - a = b = 0.0; - ! // Ensure all data-parallel computation finishes before accessing a value. - Pooma::blockAndEvaluate(); - b(n/2,n/2) = 1000.0; - *************** - *** 47,52 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - --- 48,53 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - *************** - *** 63,67 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 64,68 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - *************** - *** 71,72 **** - --- 72,74 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: programs/Doof2d-Array-stencil-annotated.patch =================================================================== RCS file: Doof2d-Array-stencil-annotated.patch diff -N Doof2d-Array-stencil-annotated.patch *** /tmp/cvsLwSPO9 Fri Jan 4 10:14:11 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,152 **** - *** Doof2d-Array-stencil.cpp Tue Dec 4 11:49:39 2001 - --- Doof2d-Array-stencil-annotated.cpp Tue Dec 4 12:26:46 2001 - *************** - *** 1,9 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - // Doof2d: Pooma Arrays, stencil implementation - - ! // Define the stencil class performing the computation. - class DoofNinePt - { - --- 1,10 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - // Doof2d: Pooma Arrays, stencil implementation - - ! // Define the stencil class performing the computation. - class DoofNinePt - { - *************** - *** 14,19 **** - // This stencil operator is applied to each interior domain position - // (i,j). The "C" template parameter permits use of this stencil - ! // operator with both Arrays and Fields. - ! template - inline - typename C::Element_t - --- 15,20 ---- - // This stencil operator is applied to each interior domain position - // (i,j). The "C" template parameter permits use of this stencil - ! // operator with both Arrays and Fields. - ! template <class C> - inline - typename C::Element_t - *************** - *** 26,30 **** - } - - ! inline int lowerExtent(int) const { return 1; } - inline int upperExtent(int) const { return 1; } - - --- 27,31 ---- - } - - ! inline int lowerExtent(int) const { return 1; } - inline int upperExtent(int) const { return 1; } - - *************** - *** 42,47 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 43,48 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 49,68 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - --- 50,69 ---- - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - *************** - *** 73,82 **** - b(n/2,n/2) = 1000.0; - - ! // Create the stencil performing the computation. - ! Stencil stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - --- 74,83 ---- - b(n/2,n/2) = 1000.0; - - ! // Create the stencil performing the computation. - ! Stencil<DoofNinePt> stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - *************** - *** 87,91 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 88,92 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - *************** - *** 95,96 **** - --- 96,98 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: programs/Doof2d-C-element-annotated.patch =================================================================== RCS file: Doof2d-C-element-annotated.patch diff -N Doof2d-C-element-annotated.patch *** /tmp/cvs2hDHVf Fri Jan 4 10:14:11 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,150 **** - *** Doof2d-C-element.cpp Tue Nov 27 08:36:38 2001 - --- Doof2d-C-element-annotated.cpp Tue Nov 27 12:08:03 2001 - *************** - *** 1,4 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - - // Doof2d: C-like, element-wise implementation - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - - // Doof2d: C-like, element-wise implementation - *************** - *** 6,30 **** - int main() - { - ! // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - ! // Use two-dimensional grids of values. - double **a; - double **b; - - // Ask the user for the number n of elements along one dimension of - ! // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - ! // Allocate the arrays. - typedef double* doublePtr; - a = new doublePtr[n]; - b = new doublePtr[n]; - ! for (int i = 0; i < n; i++) { - a[i] = new double[n]; - b[i] = new double[n]; - --- 7,31 ---- - int main() - { - ! // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - ! // Use two-dimensional grids of values. - double **a; - double **b; - - // Ask the user for the number n of elements along one dimension of - ! // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - ! // Allocate the arrays. - typedef double* doublePtr; - a = new doublePtr[n]; - b = new doublePtr[n]; - ! for (int i = 0; i < n; i++) { - a[i] = new double[n]; - b[i] = new double[n]; - *************** - *** 32,49 **** - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - ! for (int j = 0; j < n; j++) - ! for (int i = 0; i < n; i++) - a[i][j] = b[i][j] = 0.0; - b[n/2][n/2] = 1000.0; - - ! // In the average, weight elements with this value. - const double weight = 1.0/9.0; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - a[i][j] = weight * - (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + - --- 33,50 ---- - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - ! for (int j = 0; j < n; j++) - ! for (int i = 0; i < n; i++) - a[i][j] = b[i][j] = 0.0; - b[n/2][n/2] = 1000.0; - - ! // In the average, weight elements with this value. - const double weight = 1.0/9.0; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - a[i][j] = weight * - (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + - *************** - *** 51,57 **** - b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); - - ! // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b[i][j] = weight * - (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + - --- 52,58 ---- - b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); - - ! // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b[i][j] = weight * - (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + - *************** - *** 60,68 **** - } - - ! // Print out the final central value. - ! std::cout << (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) << std::endl; - - ! // Deallocate the arrays. - ! for (int i = 0; i < n; i++) { - delete [] a[i]; - delete [] b[i]; - --- 61,69 ---- - } - - ! // Print out the final central value. - ! std::cout << (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) << std::endl; - - ! // Deallocate the arrays. - ! for (int i = 0; i < n; i++) { - delete [] a[i]; - delete [] b[i]; - *************** - *** 73,74 **** - --- 74,76 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: programs/Doof2d-Field-distributed-annotated.patch =================================================================== RCS file: Doof2d-Field-distributed-annotated.patch diff -N Doof2d-Field-distributed-annotated.patch *** /tmp/cvsF2z45n Fri Jan 4 10:14:11 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,176 **** - *** Doof2d-Field-distributed.cpp Wed Dec 5 14:05:10 2001 - --- Doof2d-Field-distributed-annotated.cpp Wed Dec 5 14:41:24 2001 - *************** - *** 1,3 **** - ! #include // has EXIT_SUCCESS - #include "Pooma/Fields.h" // has Pooma's Field - - --- 1,4 ---- - ! - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Fields.h" // has Pooma's Field - - *************** - *** 12,16 **** - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - --- 13,17 ---- - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - *************** - *** 18,22 **** - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; - return EXIT_FAILURE; - } - --- 19,23 ---- - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; - return EXIT_FAILURE; - } - *************** - *** 25,33 **** - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 26,34 ---- - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 35,39 **** - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - --- 36,40 ---- - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - *************** - *** 41,50 **** - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Partition the fields' domains uniformly, i.e., each patch has the - --- 42,51 ---- - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Partition the fields' domains uniformly, i.e., each patch has the - *************** - *** 52,74 **** - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire field domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // The template parameters indicate a mesh and a 'double' - // element type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Field, double, MultiPatch > > a(cell, layout, mesh); - ! Field, double, MultiPatch > > b(cell, layout, mesh); - - // Set up the initial conditions. - --- 53,75 ---- - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire field domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // The template parameters indicate a mesh and a 'double' - // element type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, - ! Remote<Brick> > > a(cell, layout, mesh); - ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, - ! Remote<Brick> > > b(cell, layout, mesh); - - // Set up the initial conditions. - *************** - *** 83,87 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - a(I,J) = weight * - --- 84,88 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - a(I,J) = weight * - *************** - *** 99,103 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The fields are automatically deallocated. - --- 100,104 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The fields are automatically deallocated. - *************** - *** 107,108 **** - --- 108,110 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: programs/Doof2d-Field-parallel-annotated.patch =================================================================== RCS file: Doof2d-Field-parallel-annotated.patch diff -N Doof2d-Field-parallel-annotated.patch *** /tmp/cvswOFpSv Fri Jan 4 10:14:11 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,120 **** - *** Doof2d-Field-parallel.cpp Tue Dec 4 10:01:28 2001 - --- Doof2d-Field-parallel-annotated.cpp Tue Dec 4 11:04:26 2001 - *************** - *** 1,5 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - ! #include "Pooma/Fields.h" // has Pooma's Field - - // Doof2d: Pooma Fields, data-parallel implementation - --- 1,6 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - ! #include "Pooma/Fields.h" // has Pooma's Field - - // Doof2d: Pooma Fields, data-parallel implementation - *************** - *** 12,17 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 13,18 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,44 **** - // the grid. - long n; - ! std::cout << "Please enter the field size: "; - ! std::cin >> n; - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! DomainLayout<2> layout(vertDomain); - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // Create the fields. - // The template parameters indicate a mesh, a 'double' element - ! // type, and ordinary 'Brick' storage. - ! Field, double, Brick> a(cell, layout, mesh); - ! Field, double, Brick> b(cell, layout, mesh); - - // Set up the initial conditions. - --- 20,45 ---- - // the grid. - long n; - ! std::cout << "Please enter the field size: "; - ! std::cin >> n; - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! DomainLayout<2> layout(vertDomain); - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // Create the fields. - // The template parameters indicate a mesh, a 'double' element - ! // type, and ordinary 'Brick' storage. - ! Field<UniformRectilinearMesh<2>, double, Brick> a(cell, layout, mesh); - ! Field<UniformRectilinearMesh<2>, double, Brick> b(cell, layout, mesh); - - // Set up the initial conditions. - *************** - *** 51,56 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - --- 52,57 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - *************** - *** 67,71 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The fields are automatically deallocated. - --- 68,72 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The fields are automatically deallocated. - *************** - *** 75,76 **** - --- 76,78 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: programs/makefile =================================================================== RCS file: makefile diff -N makefile *** /tmp/cvsfaiLlD Fri Jan 4 10:14:11 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,12 **** - ### Oldham, Jeffrey D. - ### 2001Nov27 - ### Pooma - ### - ### Produce Annotated Source Code - - all: Doof2d-C-element-annotated.cpp Doof2d-Array-element-annotated.cpp \ - Doof2d-Array-parallel-annotated.cpp Doof2d-Array-stencil-annotated.cpp \ - Doof2d-Array-distributed-annotated.cpp - - %-annotated.cpp: %-annotated.patch %.cpp - patch -o $@ < $< --- 0 ---- From oldham at codesourcery.com Fri Jan 4 11:02:05 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 4 Jan 2002 03:02:05 -0800 Subject: Manual Patch: Program Movements and Additions Message-ID: <20020104030205.A13228@codesourcery.com> This patch moves some existing program examples and adds some new short program examples to the R2 manual. 2002-Jan-04 Jeffrey D. Oldham * examples/Doof2d/Doof2d-Array-distributed-annotated.patch: Moved from '.'. * examples/Doof2d/Doof2d-Array-element-annotated.patch: Likewise. * examples/Doof2d/Doof2d-Array-parallel-annotated.patch: Likewise. * examples/Doof2d/Doof2d-Array-stencil-annotated.patch: Likewise. * examples/Doof2d/Doof2d-C-element-annotated.patch: Likewise. * examples/Doof2d/Doof2d-Field-distributed-annotated.patch: Likewise. * examples/Doof2d/Doof2d-Field-parallel-annotated.patch: Likewise. * examples/Doof2d/Makefile: Likewise. * examples/Sequential/Makefile: New file. * examples/Sequential/initialize-finalize-annotated.patch: New file. * examples/Templates/Makefile: New file. * examples/Templates/pairs-templated-annotated.patch: New file. * examples/Templates/pairs-untemplated-annotated.patch: New file. Applied to mainline. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: examples/Doof2d/Doof2d-Array-distributed-annotated.patch =================================================================== RCS file: Doof2d-Array-distributed-annotated.patch diff -N Doof2d-Array-distributed-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- Doof2d-Array-distributed-annotated.patch Fri Jan 4 10:53:56 2002 *************** *** 0 **** --- 1,184 ---- + *** Doof2d-Array-distributed.cpp Wed Dec 5 14:04:36 2001 + --- Doof2d-Array-distributed-annotated.cpp Wed Dec 5 14:07:56 2001 + *************** + *** 1,3 **** + ! #include // has EXIT_SUCCESS + #include "Pooma/Arrays.h" // has Pooma's Array + + --- 1,5 ---- + ! + ! #include <iostream> // has std::cout, ... + ! #include <stdlib.h> // has EXIT_SUCCESS + #include "Pooma/Arrays.h" // has Pooma's Array + + *************** + *** 14,18 **** + // (i,j). The "C" template parameter permits use of this stencil + // operator with both Arrays and Fields. + ! template + inline + typename C::Element_t + --- 16,20 ---- + // (i,j). The "C" template parameter permits use of this stencil + // operator with both Arrays and Fields. + ! template <class C> + inline + typename C::Element_t + *************** + *** 42,46 **** + // canot use standard input and output. Instead we use command-line + // arguments, which are replicated, for input, and we use an Inform + ! // stream for output. + Inform output; + + --- 44,48 ---- + // canot use standard input and output. Instead we use command-line + // arguments, which are replicated, for input, and we use an Inform + ! // stream for output. + Inform output; + + *************** + *** 48,52 **** + if (argc != 4) { + // Incorrect number of command-line arguments. + ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; + return EXIT_FAILURE; + } + --- 50,54 ---- + if (argc != 4) { + // Incorrect number of command-line arguments. + ! output &openopen; argv[0] &openopen; ": number-of-processors number-of-averagings number-of-values" &openopen; std::endl; + return EXIT_FAILURE; + } + *************** + *** 55,63 **** + // Determine the number of processors. + long nuProcessors; + ! nuProcessors = strtol(argv[1], &tail, 0); + + // Determine the number of averagings. + long nuAveragings, nuIterations; + ! nuAveragings = strtol(argv[2], &tail, 0); + nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + --- 57,65 ---- + // Determine the number of processors. + long nuProcessors; + ! nuProcessors = strtol(argv[1], &tail, 0); + + // Determine the number of averagings. + long nuAveragings, nuIterations; + ! nuAveragings = strtol(argv[2], &tail, 0); + nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + *************** + *** 65,69 **** + // the grid. + long n; + ! n = strtol(argv[3], &tail, 0); + // The dimension must be a multiple of the number of processors + // since we are using a UniformGridLayout. + --- 67,71 ---- + // the grid. + long n; + ! n = strtol(argv[3], &tail, 0); + // The dimension must be a multiple of the number of processors + // since we are using a UniformGridLayout. + *************** + *** 71,80 **** + + // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<2> interiorDomain(I,I); + + // Create the distributed arrays. + --- 73,82 ---- + + // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<2> interiorDomain(I,I); + + // Create the distributed arrays. + *************** + *** 83,98 **** + // dimension. Guard layers optimize communication between patches. + // Internal guards surround each patch. External guards surround + ! // the entire array domain. + ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), + ! GuardLayers<2>(1), // internal + ! GuardLayers<2>(0)); // external + ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); + + // The template parameters indicate 2 dimensions and a 'double' + // element type. MultiPatch indicates multiple computation patches, + // i.e., distributed computation. The UniformTag indicates the + ! // patches should have the same size. Each patch has Brick type. + ! Array<2, double, MultiPatch > > a(layout); + ! Array<2, double, MultiPatch > > b(layout); + + // Set up the initial conditions. + --- 85,100 ---- + // dimension. Guard layers optimize communication between patches. + // Internal guards surround each patch. External guards surround + ! // the entire array domain. + ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), + ! GuardLayers<2>(1), // internal + ! GuardLayers<2>(0)); // external + ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); + + // The template parameters indicate 2 dimensions and a 'double' + // element type. MultiPatch indicates multiple computation patches, + // i.e., distributed computation. The UniformTag indicates the + ! // patches should have the same size. Each patch has Brick type. + ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > a(layout); + ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > b(layout); + + // Set up the initial conditions. + *************** + *** 104,112 **** + + // Create the stencil performing the computation. + ! Stencil stencil; + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(interiorDomain) = stencil(b, interiorDomain); + + --- 106,114 ---- + + // Create the stencil performing the computation. + ! Stencil<DoofNinePt> stencil; + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(interiorDomain) = stencil(b, interiorDomain); + + *************** + *** 117,121 **** + // Print out the final central value. + Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; + + // The arrays are automatically deallocated. + --- 119,123 ---- + // Print out the final central value. + Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! output &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; + + // The arrays are automatically deallocated. + *************** + *** 125,126 **** + --- 127,129 ---- + return EXIT_SUCCESS; + } + + Index: examples/Doof2d/Doof2d-Array-element-annotated.patch =================================================================== RCS file: Doof2d-Array-element-annotated.patch diff -N Doof2d-Array-element-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- Doof2d-Array-element-annotated.patch Fri Jan 4 10:53:56 2002 *************** *** 0 **** --- 1,143 ---- + *** Doof2d-Array-element.cpp Tue Dec 4 12:02:10 2001 + --- Doof2d-Array-element-annotated.cpp Tue Dec 4 12:24:25 2001 + *************** + *** 1,5 **** + ! #include // has std::cout, ... + ! #include // has EXIT_SUCCESS + ! #include "Pooma/Arrays.h" // has Pooma's Array + + // Doof2d: Pooma Arrays, element-wise implementation + --- 1,6 ---- + ! + ! #include <iostream> // has std::cout, ... + ! #include <stdlib.h> // has EXIT_SUCCESS + ! #include "Pooma/Arrays.h" // has Pooma's Array + + // Doof2d: Pooma Arrays, element-wise implementation + *************** + *** 7,17 **** + int main(int argc, char *argv[]) + { + ! // Prepare the Pooma library for execution. + Pooma::initialize(argc,argv); + + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout << "Please enter the number of averagings: "; + ! std::cin >> nuAveragings; + nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + --- 8,18 ---- + int main(int argc, char *argv[]) + { + ! // Prepare the Pooma library for execution. + Pooma::initialize(argc,argv); + + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout &openopen; "Please enter the number of averagings: "; + ! std::cin &closeclose; nuAveragings; + nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + *************** + *** 19,37 **** + // the grid. + long n; + ! std::cout << "Please enter the array size: "; + ! std::cin >> n; + + ! // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + ! // Create the arrays. + // The template parameters indicate 2 dimensions, a 'double' element + // type, and ordinary 'Brick' storage. + ! Array<2, double, Brick> a(vertDomain); + ! Array<2, double, Brick> b(vertDomain); + + // Set up the initial conditions. + ! // All grid values should be zero except for the central value. + for (int j = 1; j < n-1; j++) + for (int i = 1; i < n-1; i++) + --- 20,38 ---- + // the grid. + long n; + ! std::cout &openopen; "Please enter the array size: "; + ! std::cin &closeclose; n; + + ! // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + ! // Create the arrays. + // The template parameters indicate 2 dimensions, a 'double' element + // type, and ordinary 'Brick' storage. + ! Array<2, double, Brick> a(vertDomain); + ! Array<2, double, Brick> b(vertDomain); + + // Set up the initial conditions. + ! // All grid values should be zero except for the central value. + for (int j = 1; j < n-1; j++) + for (int i = 1; i < n-1; i++) + *************** + *** 43,51 **** + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + // Read from b. Write to a. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + ! a(i,j) = weight * + (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + + b(i ,j+1) + b(i ,j ) + b(i ,j-1) + + --- 44,52 ---- + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + // Read from b. Write to a. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + ! a(i,j) = weight * + (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + + b(i ,j+1) + b(i ,j ) + b(i ,j-1) + + *************** + *** 53,58 **** + + // Read from a. Write to b. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + b(i,j) = weight * + (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + + --- 54,59 ---- + + // Read from a. Write to b. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + b(i,j) = weight * + (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + + *************** + *** 62,71 **** + + // Print out the final central value. + ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; + + ! // The arrays are automatically deallocated. + + ! // Tell the Pooma library execution has finished. + Pooma::finalize(); + return EXIT_SUCCESS; + } + --- 63,74 ---- + + // Print out the final central value. + ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; + + ! // The arrays are automatically deallocated. + + ! // Tell the Pooma library execution has finished. + Pooma::finalize(); + return EXIT_SUCCESS; + } + + Index: examples/Doof2d/Doof2d-Array-parallel-annotated.patch =================================================================== RCS file: Doof2d-Array-parallel-annotated.patch diff -N Doof2d-Array-parallel-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- Doof2d-Array-parallel-annotated.patch Fri Jan 4 10:53:56 2002 *************** *** 0 **** --- 1,116 ---- + *** Doof2d-Array-parallel.cpp Tue Dec 4 11:49:43 2001 + --- Doof2d-Array-parallel-annotated.cpp Tue Dec 4 12:24:36 2001 + *************** + *** 1,4 **** + ! #include // has std::cout, ... + ! #include // has EXIT_SUCCESS + #include "Pooma/Arrays.h" // has Pooma's Array + + --- 1,5 ---- + ! + ! #include <iostream> // has std::cout, ... + ! #include <stdlib.h> // has EXIT_SUCCESS + #include "Pooma/Arrays.h" // has Pooma's Array + + *************** + *** 12,17 **** + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout << "Please enter the number of averagings: "; + ! std::cin >> nuAveragings; + nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + --- 13,18 ---- + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout &openopen; "Please enter the number of averagings: "; + ! std::cin &closeclose; nuAveragings; + nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + *************** + *** 19,43 **** + // the grid. + long n; + ! std::cout << "Please enter the array size: "; + ! std::cin >> n; + + // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + ! // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<1> J(1,n-2); + + // Create the arrays. + // The template parameters indicate 2 dimensions, a 'double' element + // type, and ordinary 'Brick' storage. + ! Array<2, double, Brick> a(vertDomain); + ! Array<2, double, Brick> b(vertDomain); + + // Set up the initial conditions. + // All grid values should be zero except for the central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; + --- 20,44 ---- + // the grid. + long n; + ! std::cout &openopen; "Please enter the array size: "; + ! std::cin &closeclose; n; + + // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + ! // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<1> J(1,n-2); + + // Create the arrays. + // The template parameters indicate 2 dimensions, a 'double' element + // type, and ordinary 'Brick' storage. + ! Array<2, double, Brick> a(vertDomain); + ! Array<2, double, Brick> b(vertDomain); + + // Set up the initial conditions. + // All grid values should be zero except for the central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; + *************** + *** 47,52 **** + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(I,J) = weight * + (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + + --- 48,53 ---- + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(I,J) = weight * + (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + + *************** + *** 63,67 **** + // Print out the final central value. + Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; + + // The arrays are automatically deallocated. + --- 64,68 ---- + // Print out the final central value. + Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; + + // The arrays are automatically deallocated. + *************** + *** 71,72 **** + --- 72,74 ---- + return EXIT_SUCCESS; + } + + Index: examples/Doof2d/Doof2d-Array-stencil-annotated.patch =================================================================== RCS file: Doof2d-Array-stencil-annotated.patch diff -N Doof2d-Array-stencil-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- Doof2d-Array-stencil-annotated.patch Fri Jan 4 10:53:56 2002 *************** *** 0 **** --- 1,152 ---- + *** Doof2d-Array-stencil.cpp Tue Dec 4 11:49:39 2001 + --- Doof2d-Array-stencil-annotated.cpp Tue Dec 4 12:26:46 2001 + *************** + *** 1,9 **** + ! #include // has std::cout, ... + ! #include // has EXIT_SUCCESS + #include "Pooma/Arrays.h" // has Pooma's Array + + // Doof2d: Pooma Arrays, stencil implementation + + ! // Define the stencil class performing the computation. + class DoofNinePt + { + --- 1,10 ---- + ! + ! #include <iostream> // has std::cout, ... + ! #include <stdlib.h> // has EXIT_SUCCESS + #include "Pooma/Arrays.h" // has Pooma's Array + + // Doof2d: Pooma Arrays, stencil implementation + + ! // Define the stencil class performing the computation. + class DoofNinePt + { + *************** + *** 14,19 **** + // This stencil operator is applied to each interior domain position + // (i,j). The "C" template parameter permits use of this stencil + ! // operator with both Arrays and Fields. + ! template + inline + typename C::Element_t + --- 15,20 ---- + // This stencil operator is applied to each interior domain position + // (i,j). The "C" template parameter permits use of this stencil + ! // operator with both Arrays and Fields. + ! template <class C> + inline + typename C::Element_t + *************** + *** 26,30 **** + } + + ! inline int lowerExtent(int) const { return 1; } + inline int upperExtent(int) const { return 1; } + + --- 27,31 ---- + } + + ! inline int lowerExtent(int) const { return 1; } + inline int upperExtent(int) const { return 1; } + + *************** + *** 42,47 **** + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout << "Please enter the number of averagings: "; + ! std::cin >> nuAveragings; + nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + --- 43,48 ---- + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout &openopen; "Please enter the number of averagings: "; + ! std::cin &closeclose; nuAveragings; + nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + *************** + *** 49,68 **** + // the grid. + long n; + ! std::cout << "Please enter the array size: "; + ! std::cin >> n; + + // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<2> interiorDomain(I,I); + + // Create the arrays. + // The template parameters indicate 2 dimensions, a 'double' element + // type, and ordinary 'Brick' storage. + ! Array<2, double, Brick> a(vertDomain); + ! Array<2, double, Brick> b(vertDomain); + + // Set up the initial conditions. + --- 50,69 ---- + // the grid. + long n; + ! std::cout &openopen; "Please enter the array size: "; + ! std::cin &closeclose; n; + + // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<2> interiorDomain(I,I); + + // Create the arrays. + // The template parameters indicate 2 dimensions, a 'double' element + // type, and ordinary 'Brick' storage. + ! Array<2, double, Brick> a(vertDomain); + ! Array<2, double, Brick> b(vertDomain); + + // Set up the initial conditions. + *************** + *** 73,82 **** + b(n/2,n/2) = 1000.0; + + ! // Create the stencil performing the computation. + ! Stencil stencil; + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(interiorDomain) = stencil(b, interiorDomain); + + --- 74,83 ---- + b(n/2,n/2) = 1000.0; + + ! // Create the stencil performing the computation. + ! Stencil<DoofNinePt> stencil; + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(interiorDomain) = stencil(b, interiorDomain); + + *************** + *** 87,91 **** + // Print out the final central value. + Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; + + // The arrays are automatically deallocated. + --- 88,92 ---- + // Print out the final central value. + Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; + + // The arrays are automatically deallocated. + *************** + *** 95,96 **** + --- 96,98 ---- + return EXIT_SUCCESS; + } + + Index: examples/Doof2d/Doof2d-C-element-annotated.patch =================================================================== RCS file: Doof2d-C-element-annotated.patch diff -N Doof2d-C-element-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- Doof2d-C-element-annotated.patch Fri Jan 4 10:53:56 2002 *************** *** 0 **** --- 1,150 ---- + *** Doof2d-C-element.cpp Tue Nov 27 08:36:38 2001 + --- Doof2d-C-element-annotated.cpp Tue Nov 27 12:08:03 2001 + *************** + *** 1,4 **** + ! #include // has std::cout, ... + ! #include // has EXIT_SUCCESS + + // Doof2d: C-like, element-wise implementation + --- 1,5 ---- + ! + ! #include <iostream> // has std::cout, ... + ! #include <stdlib.h> // has EXIT_SUCCESS + + // Doof2d: C-like, element-wise implementation + *************** + *** 6,30 **** + int main() + { + ! // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout << "Please enter the number of averagings: "; + ! std::cin >> nuAveragings; + nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + ! // Use two-dimensional grids of values. + double **a; + double **b; + + // Ask the user for the number n of elements along one dimension of + ! // the grid. + long n; + ! std::cout << "Please enter the array size: "; + ! std::cin >> n; + + ! // Allocate the arrays. + typedef double* doublePtr; + a = new doublePtr[n]; + b = new doublePtr[n]; + ! for (int i = 0; i < n; i++) { + a[i] = new double[n]; + b[i] = new double[n]; + --- 7,31 ---- + int main() + { + ! // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout &openopen; "Please enter the number of averagings: "; + ! std::cin &closeclose; nuAveragings; + nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + ! // Use two-dimensional grids of values. + double **a; + double **b; + + // Ask the user for the number n of elements along one dimension of + ! // the grid. + long n; + ! std::cout &openopen; "Please enter the array size: "; + ! std::cin &closeclose; n; + + ! // Allocate the arrays. + typedef double* doublePtr; + a = new doublePtr[n]; + b = new doublePtr[n]; + ! for (int i = 0; i < n; i++) { + a[i] = new double[n]; + b[i] = new double[n]; + *************** + *** 32,49 **** + + // Set up the initial conditions. + ! // All grid values should be zero except for the central value. + ! for (int j = 0; j < n; j++) + ! for (int i = 0; i < n; i++) + a[i][j] = b[i][j] = 0.0; + b[n/2][n/2] = 1000.0; + + ! // In the average, weight elements with this value. + const double weight = 1.0/9.0; + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + a[i][j] = weight * + (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + + --- 33,50 ---- + + // Set up the initial conditions. + ! // All grid values should be zero except for the central value. + ! for (int j = 0; j < n; j++) + ! for (int i = 0; i < n; i++) + a[i][j] = b[i][j] = 0.0; + b[n/2][n/2] = 1000.0; + + ! // In the average, weight elements with this value. + const double weight = 1.0/9.0; + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + a[i][j] = weight * + (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + + *************** + *** 51,57 **** + b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); + + ! // Read from a. Write to b. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + b[i][j] = weight * + (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + + --- 52,58 ---- + b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); + + ! // Read from a. Write to b. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + b[i][j] = weight * + (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + + *************** + *** 60,68 **** + } + + ! // Print out the final central value. + ! std::cout << (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) << std::endl; + + ! // Deallocate the arrays. + ! for (int i = 0; i < n; i++) { + delete [] a[i]; + delete [] b[i]; + --- 61,69 ---- + } + + ! // Print out the final central value. + ! std::cout &openopen; (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) &openopen; std::endl; + + ! // Deallocate the arrays. + ! for (int i = 0; i < n; i++) { + delete [] a[i]; + delete [] b[i]; + *************** + *** 73,74 **** + --- 74,76 ---- + return EXIT_SUCCESS; + } + + Index: examples/Doof2d/Doof2d-Field-distributed-annotated.patch =================================================================== RCS file: Doof2d-Field-distributed-annotated.patch diff -N Doof2d-Field-distributed-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- Doof2d-Field-distributed-annotated.patch Fri Jan 4 10:53:56 2002 *************** *** 0 **** --- 1,176 ---- + *** Doof2d-Field-distributed.cpp Wed Dec 5 14:05:10 2001 + --- Doof2d-Field-distributed-annotated.cpp Wed Dec 5 14:41:24 2001 + *************** + *** 1,3 **** + ! #include // has EXIT_SUCCESS + #include "Pooma/Fields.h" // has Pooma's Field + + --- 1,4 ---- + ! + ! #include <stdlib.h> // has EXIT_SUCCESS + #include "Pooma/Fields.h" // has Pooma's Field + + *************** + *** 12,16 **** + // canot use standard input and output. Instead we use command-line + // arguments, which are replicated, for input, and we use an Inform + ! // stream for output. + Inform output; + + --- 13,17 ---- + // canot use standard input and output. Instead we use command-line + // arguments, which are replicated, for input, and we use an Inform + ! // stream for output. + Inform output; + + *************** + *** 18,22 **** + if (argc != 4) { + // Incorrect number of command-line arguments. + ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; + return EXIT_FAILURE; + } + --- 19,23 ---- + if (argc != 4) { + // Incorrect number of command-line arguments. + ! output &openopen; argv[0] &openopen; ": number-of-processors number-of-averagings number-of-values" &openopen; std::endl; + return EXIT_FAILURE; + } + *************** + *** 25,33 **** + // Determine the number of processors. + long nuProcessors; + ! nuProcessors = strtol(argv[1], &tail, 0); + + // Determine the number of averagings. + long nuAveragings, nuIterations; + ! nuAveragings = strtol(argv[2], &tail, 0); + nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + --- 26,34 ---- + // Determine the number of processors. + long nuProcessors; + ! nuProcessors = strtol(argv[1], &tail, 0); + + // Determine the number of averagings. + long nuAveragings, nuIterations; + ! nuAveragings = strtol(argv[2], &tail, 0); + nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + *************** + *** 35,39 **** + // the grid. + long n; + ! n = strtol(argv[3], &tail, 0); + // The dimension must be a multiple of the number of processors + // since we are using a UniformGridLayout. + --- 36,40 ---- + // the grid. + long n; + ! n = strtol(argv[3], &tail, 0); + // The dimension must be a multiple of the number of processors + // since we are using a UniformGridLayout. + *************** + *** 41,50 **** + + // Specify the fields' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<1> J(1,n-2); + + // Partition the fields' domains uniformly, i.e., each patch has the + --- 42,51 ---- + + // Specify the fields' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<1> J(1,n-2); + + // Partition the fields' domains uniformly, i.e., each patch has the + *************** + *** 52,74 **** + // dimension. Guard layers optimize communication between patches. + // Internal guards surround each patch. External guards surround + ! // the entire field domain. + ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), + ! GuardLayers<2>(1), // internal + ! GuardLayers<2>(0)); // external + ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); + + // Specify the fields' mesh, i.e., its spatial extent, and its + ! // centering type. + ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); + ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); + + // The template parameters indicate a mesh and a 'double' + // element type. MultiPatch indicates multiple computation patches, + // i.e., distributed computation. The UniformTag indicates the + ! // patches should have the same size. Each patch has Brick type. + ! Field, double, MultiPatch > > a(cell, layout, mesh); + ! Field, double, MultiPatch > > b(cell, layout, mesh); + + // Set up the initial conditions. + --- 53,75 ---- + // dimension. Guard layers optimize communication between patches. + // Internal guards surround each patch. External guards surround + ! // the entire field domain. + ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), + ! GuardLayers<2>(1), // internal + ! GuardLayers<2>(0)); // external + ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); + + // Specify the fields' mesh, i.e., its spatial extent, and its + ! // centering type. + ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); + ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); + + // The template parameters indicate a mesh and a 'double' + // element type. MultiPatch indicates multiple computation patches, + // i.e., distributed computation. The UniformTag indicates the + ! // patches should have the same size. Each patch has Brick type. + ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, + ! Remote<Brick> > > a(cell, layout, mesh); + ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, + ! Remote<Brick> > > b(cell, layout, mesh); + + // Set up the initial conditions. + *************** + *** 83,87 **** + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + // Read from b. Write to a. + a(I,J) = weight * + --- 84,88 ---- + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + // Read from b. Write to a. + a(I,J) = weight * + *************** + *** 99,103 **** + // Print out the final central value. + Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; + + // The fields are automatically deallocated. + --- 100,104 ---- + // Print out the final central value. + Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! output &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; + + // The fields are automatically deallocated. + *************** + *** 107,108 **** + --- 108,110 ---- + return EXIT_SUCCESS; + } + + Index: examples/Doof2d/Doof2d-Field-parallel-annotated.patch =================================================================== RCS file: Doof2d-Field-parallel-annotated.patch diff -N Doof2d-Field-parallel-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- Doof2d-Field-parallel-annotated.patch Fri Jan 4 10:53:56 2002 *************** *** 0 **** --- 1,120 ---- + *** Doof2d-Field-parallel.cpp Tue Dec 4 10:01:28 2001 + --- Doof2d-Field-parallel-annotated.cpp Tue Dec 4 11:04:26 2001 + *************** + *** 1,5 **** + ! #include // has std::cout, ... + ! #include // has EXIT_SUCCESS + ! #include "Pooma/Fields.h" // has Pooma's Field + + // Doof2d: Pooma Fields, data-parallel implementation + --- 1,6 ---- + ! + ! #include <iostream> // has std::cout, ... + ! #include <stdlib.h> // has EXIT_SUCCESS + ! #include "Pooma/Fields.h" // has Pooma's Field + + // Doof2d: Pooma Fields, data-parallel implementation + *************** + *** 12,17 **** + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout << "Please enter the number of averagings: "; + ! std::cin >> nuAveragings; + nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + --- 13,18 ---- + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout &openopen; "Please enter the number of averagings: "; + ! std::cin &closeclose; nuAveragings; + nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + *************** + *** 19,44 **** + // the grid. + long n; + ! std::cout << "Please enter the field size: "; + ! std::cin >> n; + + // Specify the fields' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<1> J(1,n-2); + + // Specify the fields' mesh, i.e., its spatial extent, and its + ! // centering type. + ! DomainLayout<2> layout(vertDomain); + ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); + ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); + + // Create the fields. + // The template parameters indicate a mesh, a 'double' element + ! // type, and ordinary 'Brick' storage. + ! Field, double, Brick> a(cell, layout, mesh); + ! Field, double, Brick> b(cell, layout, mesh); + + // Set up the initial conditions. + --- 20,45 ---- + // the grid. + long n; + ! std::cout &openopen; "Please enter the field size: "; + ! std::cin &closeclose; n; + + // Specify the fields' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<1> J(1,n-2); + + // Specify the fields' mesh, i.e., its spatial extent, and its + ! // centering type. + ! DomainLayout<2> layout(vertDomain); + ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); + ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); + + // Create the fields. + // The template parameters indicate a mesh, a 'double' element + ! // type, and ordinary 'Brick' storage. + ! Field<UniformRectilinearMesh<2>, double, Brick> a(cell, layout, mesh); + ! Field<UniformRectilinearMesh<2>, double, Brick> b(cell, layout, mesh); + + // Set up the initial conditions. + *************** + *** 51,56 **** + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(I,J) = weight * + (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + + --- 52,57 ---- + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(I,J) = weight * + (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + + *************** + *** 67,71 **** + // Print out the final central value. + Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; + + // The fields are automatically deallocated. + --- 68,72 ---- + // Print out the final central value. + Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; + + // The fields are automatically deallocated. + *************** + *** 75,76 **** + --- 76,78 ---- + return EXIT_SUCCESS; + } + + Index: examples/Doof2d/Makefile =================================================================== RCS file: Makefile diff -N Makefile *** /dev/null Fri Mar 23 21:37:44 2001 --- Makefile Fri Jan 4 10:53:56 2002 *************** *** 0 **** --- 1,13 ---- + ### Oldham, Jeffrey D. + ### 2001Nov27 + ### Pooma + ### + ### Produce Annotated Source Code + + all: Doof2d-C-element-annotated.cpp Doof2d-Array-element-annotated.cpp \ + Doof2d-Array-parallel-annotated.cpp Doof2d-Array-stencil-annotated.cpp \ + Doof2d-Array-distributed-annotated.cpp \ + Doof2d-Field-parallel-annotated.cpp Doof2d-Field-distributed-annotated.cpp + + %-annotated.cpp: %-annotated.patch %.cpp + patch -o $@ < $< Index: examples/Sequential/Makefile =================================================================== RCS file: Makefile diff -N Makefile *** /dev/null Fri Mar 23 21:37:44 2001 --- Makefile Fri Jan 4 10:53:56 2002 *************** *** 0 **** --- 1,10 ---- + ### Oldham, Jeffrey D. + ### 2001Nov27 + ### Pooma + ### + ### Produce Annotated Source Code + + all: initialize-finalize-annotated.cpp + + %-annotated.cpp: %-annotated.patch %.cpp + patch -o $@ < $< Index: examples/Sequential/initialize-finalize-annotated.patch =================================================================== RCS file: initialize-finalize-annotated.patch diff -N initialize-finalize-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- initialize-finalize-annotated.patch Fri Jan 4 10:53:56 2002 *************** *** 0 **** --- 1,14 ---- + *** initialize-finalize.cpp Sat Dec 15 15:35:57 2001 + --- initialize-finalize-annotated.cpp Sun Dec 16 14:24:43 2001 + *************** + *** 1,2 **** + --- 1,3 ---- + + + #include "Pooma/Pooma.h" + + *************** + *** 10,11 **** + --- 11,13 ---- + return 0; + } + + Index: examples/Templates/Makefile =================================================================== RCS file: Makefile diff -N Makefile *** /dev/null Fri Mar 23 21:37:44 2001 --- Makefile Fri Jan 4 10:53:56 2002 *************** *** 0 **** --- 1,10 ---- + ### Oldham, Jeffrey D. + ### 2002Jan04 + ### Pooma + ### + ### Produce Annotated Source Code + + all: pairs-templated-annotated.cpp pairs-untemplated-annotated.cpp + + %-annotated.cpp: %-annotated.patch %.cpp + patch -o $@ < $< Index: examples/Templates/pairs-templated-annotated.patch =================================================================== RCS file: pairs-templated-annotated.patch diff -N pairs-templated-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- pairs-templated-annotated.patch Fri Jan 4 10:53:56 2002 *************** *** 0 **** --- 1,37 ---- + *** pairs-templated.cpp Wed Dec 26 14:01:38 2001 + --- pairs-templated-annotated.cpp Wed Dec 26 14:12:51 2001 + *************** + *** 1,15 **** + ! // Declare a template class storing a pair of values with the same type. + ! template + struct pair { + ! pair(const int& left, const int& right) + : left_(left), right_(right) {} + + ! T left_; + T right_; + }; + + ! // Use a class storing a pair of integers. + ! pair pair1; + + // Use a class storing a pair of doubles; + ! pair pair2; + --- 1,17 ---- + ! + ! // Declare a template class storing a pair of values with the same type. + ! template <typename T> + struct pair { + ! pair(const T& left, const T& right) // + : left_(left), right_(right) {} + + ! T left_; // + T right_; + }; + + ! // Use a class storing a pair of integers. + ! pair<int> pair1; + + // Use a class storing a pair of doubles; + ! pair<double> pair2; + ! Index: examples/Templates/pairs-untemplated-annotated.patch =================================================================== RCS file: pairs-untemplated-annotated.patch diff -N pairs-untemplated-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- pairs-untemplated-annotated.patch Fri Jan 4 10:53:56 2002 *************** *** 0 **** --- 1,35 ---- + *** pairs-untemplated.cpp Wed Dec 26 13:48:10 2001 + --- pairs-untemplated-annotated.cpp Wed Dec 26 14:02:58 2001 + *************** + *** 1,5 **** + // Declare a class storing a pair of integers. + struct pairOfInts { + ! pairOfInts(const int& left, const int& right) + : left_(left), right_(right) {} + + --- 1,6 ---- + + + // Declare a class storing a pair of integers. + struct pairOfInts { + ! pairOfInts(const int& left, const int& right) + : left_(left), right_(right) {} + + *************** + *** 10,14 **** + // Declare a class storing a pair of doubles. + struct pairOfDoubles { + ! pairOfDoubles(const double& left, const double& right) + : left_(left), right_(right) {} + + --- 11,15 ---- + // Declare a class storing a pair of doubles. + struct pairOfDoubles { + ! pairOfDoubles(const double& left, const double& right) + : left_(left), right_(right) {} + + *************** + *** 16,17 **** + --- 17,19 ---- + double right_; + }; + + From oldham at codesourcery.com Thu Jan 10 22:12:02 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 10 Jan 2002 14:12:02 -0800 Subject: Index Domain Type Message-ID: <200201102212.g0AMC2j17703@oz.codesourcery.com> Was the Index domain type removed? Various comments refer to it and there is a forward declaration, but I found no definition. in Pooma's src/: find . -name *.h -print | xargs -n 10 grep '[[:space:]]Index[^[:alpha:]]' ./Domain/Grid.h:// however, like Index does, so it cannot be used in any kind of tensor-like ./Domain/Interval.h:// however, like Index does, so it cannot be used in any kind of tensor-like ./Domain/Loc.h:// like Index does, so it cannot be used in any kind of tensor-like ./Domain/NewDomain.h:template class Index; ./Domain/NewDomain.h:// of the slice = sum of dimensions of Interval, Range, Index objects ./Domain/Range.h:// however, like Index does, so it cannot be used in any kind of tensor-like ./Engine/DynamicEngine.h: // Index of the first point. ./Engine/IndexFunctionEngine.h:// Index-function-engine objects provide a way to make a function of indices ./Pooma/Indices.h: typedef typename ComponentView, Iota_t>::Type_t Index_t; Thanks for the information, Jeffrey D. Oldham oldham at codesourcery.com From jcrotinger at proximation.com Fri Jan 11 17:48:52 2002 From: jcrotinger at proximation.com (James Crotinger) Date: Fri, 11 Jan 2002 10:48:52 -0700 Subject: [pooma-dev] Index Domain Type Message-ID: Index was never implemented. The notion of Index was a domain with position information. In POOMA r1 you can do the following sort of thing: Index I, J; A[I][J] = B[J][I]; to assign the transpose of B to A. This does have some uses, but it adds a lot of complexity, so we never put it in. Jim > -----Original Message----- > From: Jeffrey Oldham [mailto:oldham at codesourcery.com] > Sent: Thursday, January 10, 2002 3:12 PM > To: pooma-dev at pooma.codesourcery.com > Subject: [pooma-dev] Index Domain Type > > > > Was the Index domain type removed? Various comments refer to > it and there is a forward declaration, but I found no definition. > > in Pooma's src/: > > find . -name *.h -print | xargs -n 10 grep > '[[:space:]]Index[^[:alpha:]]' > ./Domain/Grid.h:// however, like Index does, so it cannot be > used in any kind of tensor-like > ./Domain/Interval.h:// however, like Index does, so it cannot > be used in any kind of tensor-like > ./Domain/Loc.h:// like Index does, so it cannot be used in > any kind of tensor-like > ./Domain/NewDomain.h:template class Index; > ./Domain/NewDomain.h:// of the slice = sum of dimensions > of Interval, Range, Index objects > ./Domain/Range.h:// however, like Index does, so it cannot be > used in any kind of tensor-like > ./Engine/DynamicEngine.h: // Index of the first point. > ./Engine/IndexFunctionEngine.h:// Index-function-engine > objects provide a way to make a function of indices > ./Pooma/Indices.h: typedef typename ComponentView, > Iota_t>::Type_t Index_t; > > Thanks for the information, > Jeffrey D. Oldham > oldham at codesourcery.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oldham at codesourcery.com Fri Jan 11 20:01:13 2002 From: oldham at codesourcery.com (Jeffrey) Date: Fri, 11 Jan 2002 12:01:13 -0800 Subject: Grid and Monotonicity Message-ID: <200201112001.g0BK1DX00941@vaio.codesourcery.com> The comments in src/Domain/Grid.h describe a Grid as "any ascending or descending sequence." When constructing a Grid<1> domain from an IndirectionList<1> il, il's entries are not reordered to be ascending or descending. Will this cause any problems when using it? This program demonstrates the lack of monotonicity: #include "Pooma/Pooma.h" #include "Pooma/Domains.h" #include int main(int argc, char *argv[]) { Pooma::initialize(argc,argv); IndirectionList list(4); list(0) = 10; list(1) = 12; list(2) = 11; list(3) = 13; Grid<1> g(list); std::cout << g << std::endl; Pooma::finalize(); return 0; } Thanks for the information, Jeffrey D. Oldham oldham at codesourcery.com From jcrotinger at proximation.com Fri Jan 11 20:03:46 2002 From: jcrotinger at proximation.com (James Crotinger) Date: Fri, 11 Jan 2002 13:03:46 -0700 Subject: [pooma-dev] Grid and Monotonicity Message-ID: I'm pretty sure that we want these to be monotonic. I don't know if we want to reorder (would you order to ascending or descending?) or just assert. Jim > -----Original Message----- > From: Jeffrey [mailto:oldham at codesourcery.com] > Sent: Friday, January 11, 2002 1:01 PM > To: pooma-dev at pooma.codesourcery.com > Subject: [pooma-dev] Grid and Monotonicity > > > > The comments in src/Domain/Grid.h describe a Grid as "any ascending > or descending sequence." When constructing a Grid<1> domain from an > IndirectionList<1> il, il's entries are not reordered to be ascending > or descending. Will this cause any problems when using it? > > This program demonstrates the lack of monotonicity: > > #include "Pooma/Pooma.h" > #include "Pooma/Domains.h" > #include > > int main(int argc, char *argv[]) > { > Pooma::initialize(argc,argv); > > IndirectionList list(4); > list(0) = 10; > list(1) = 12; > list(2) = 11; > list(3) = 13; > Grid<1> g(list); > std::cout << g << std::endl; > > Pooma::finalize(); > return 0; > } > > Thanks for the information, > Jeffrey D. Oldham > oldham at codesourcery.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oldham at codesourcery.com Mon Jan 14 09:47:34 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Mon, 14 Jan 2002 01:47:34 -0800 Subject: Patch: Remove Non-Existent 'Index' From Comments Message-ID: <20020114014734.A10951@codesourcery.com> 2002-Jan-14 Jeffrey D. Oldham These changes remove mentions of the non-existent 'Index' type from comments. * Grid.h: Remove 'Index' from introductory comment. * Interval.h: Likewise. * Loc.h: Likewise. * NewDomain.h: Remove forward declaration for 'Index'. Remove 'Index' from NewDomain'N' comment. * Range.h: Remove 'Index' from introductory comment. Applied to mainline Not tested since only comments were changed. Approved by Stephen Smith Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Grid.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/Grid.h,v retrieving revision 1.12 diff -c -p -r1.12 Grid.h *** Grid.h 2001/04/27 22:58:09 1.12 --- Grid.h 2002/01/11 22:46:43 *************** *** 76,84 **** // Grid is a domain representing a set of N numeric sequences, one // for each dimension N. The sequences are lists of ascending or descending // numbers, but without any fixed stride - the list for each dimension is ! // an IndirectionList. It does not have any concept of loop variables, ! // however, like Index does, so it cannot be used in any kind of tensor-like ! // expression. // // You can construct a Grid object using other domain objects. // The constructors accept up to 7 domain objects of various types. --- 76,82 ---- // Grid is a domain representing a set of N numeric sequences, one // for each dimension N. The sequences are lists of ascending or descending // numbers, but without any fixed stride - the list for each dimension is ! // an IndirectionList. // // You can construct a Grid object using other domain objects. // The constructors accept up to 7 domain objects of various types. Index: Interval.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/Interval.h,v retrieving revision 1.18 diff -c -p -r1.18 Interval.h *** Interval.h 2001/04/27 22:58:13 1.18 --- Interval.h 2002/01/11 22:46:43 *************** *** 70,78 **** // // Interval is a domain representing a set of N numeric sequences, one // for each dimension N. The sequences have endpoints [a,b], and a ! // hard-coded stride of +1. It does not have any concept of loop variables, ! // however, like Index does, so it cannot be used in any kind of tensor-like ! // expression. // // You can construct an Interval object using other domain objects. // The constructors accept up to 7 domain objects of various types. --- 70,76 ---- // // Interval is a domain representing a set of N numeric sequences, one // for each dimension N. The sequences have endpoints [a,b], and a ! // hard-coded stride of +1. // // You can construct an Interval object using other domain objects. // The constructors accept up to 7 domain objects of various types. Index: Loc.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/Loc.h,v retrieving revision 1.24 diff -c -p -r1.24 Loc.h *** Loc.h 2001/04/13 02:12:59 1.24 --- Loc.h 2002/01/11 22:46:43 *************** *** 73,81 **** // Loc is a domain representing a single N-dimensional point. It has // a stride of one, endpoints which are the same, and a single element. // Otherwise, it acts very much like all other domain objects such as Range ! // or Interval. It does not have any concept of loop variables, however, ! // like Index does, so it cannot be used in any kind of tensor-like ! // expression. // // You can construct a Loc object using other Loc objects or integers. // The constructor for Loc accepts up to 7 domain objects of various types. --- 73,79 ---- // Loc is a domain representing a single N-dimensional point. It has // a stride of one, endpoints which are the same, and a single element. // Otherwise, it acts very much like all other domain objects such as Range ! // or Interval. // // You can construct a Loc object using other Loc objects or integers. // The constructor for Loc accepts up to 7 domain objects of various types. Index: NewDomain.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/NewDomain.h,v retrieving revision 1.30 diff -c -p -r1.30 NewDomain.h *** NewDomain.h 2001/04/13 02:12:59 1.30 --- NewDomain.h 2002/01/11 22:46:44 *************** template class Lo *** 70,76 **** template class Interval; template class Range; template class Grid; - template class Index; template class AllDomain; template class LeftDomain; template class RightDomain; --- 70,75 ---- *************** struct CombineSliceDomain { *** 337,343 **** // a lower-dimensional subdomain of the complete domain. Specifying // a Loc or int for one or more of the dimensions in the operator() will // result in that dimension being "sliced out", so that the total dim ! // of the slice = sum of dimensions of Interval, Range, Index objects // - sum dimensions of Loc and int objects. If slice rules are used, // and any Loc or int objects are being combined in, the resulting // domain object will be a SliceDomain subclass (e.g., SliceInterval, --- 336,342 ---- // a lower-dimensional subdomain of the complete domain. Specifying // a Loc or int for one or more of the dimensions in the operator() will // result in that dimension being "sliced out", so that the total dim ! // of the slice = sum of dimensions of Interval, Range objects // - sum dimensions of Loc and int objects. If slice rules are used, // and any Loc or int objects are being combined in, the resulting // domain object will be a SliceDomain subclass (e.g., SliceInterval, Index: Range.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/Range.h,v retrieving revision 1.19 diff -c -p -r1.19 Range.h *** Range.h 2001/04/27 22:58:17 1.19 --- Range.h 2002/01/11 22:46:44 *************** void fillRangeScalar(Range &r, cons *** 76,84 **** // // Range is a domain representing a set of N numeric sequences, one // for each dimension N. The sequences have endpoints [a,b], with a stride ! // s. It does not have any concept of loop variables, ! // however, like Index does, so it cannot be used in any kind of tensor-like ! // expression. // // You can construct a Range object using other domain objects. // The constructors accept up to 7 domain objects of various types. --- 76,82 ---- // // Range is a domain representing a set of N numeric sequences, one // for each dimension N. The sequences have endpoints [a,b], with a stride ! // s. // // You can construct a Range object using other domain objects. // The constructors accept up to 7 domain objects of various types. From mark at codesourcery.com Mon Jan 14 17:48:17 2002 From: mark at codesourcery.com (Mark Mitchell) Date: Mon, 14 Jan 2002 09:48:17 -0800 Subject: [pooma-dev] Grid and Monotonicity In-Reply-To: Message-ID: <16030000.1011030497@gandalf.codesourcery.com> --On Friday, January 11, 2002 01:03:46 PM -0700 James Crotinger wrote: > > I'm pretty sure that we want these to be monotonic. I don't know if we > want to reorder (would you order to ascending or descending?) or just > assert. I think we should just assert. The programmer should sort before setting this up. My two cents, -- Mark Mitchell mark at codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From oldham at codesourcery.com Tue Jan 15 17:53:19 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 15 Jan 2002 09:53:19 -0800 Subject: Pooma Manual: Array and Domain Chapter Message-ID: <20020115095319.A8680@codesourcery.com> This patch finishes the first draft of the Array and Domain chapter of the Pooma manual. 2002-Jan-15 Jeffrey D. Oldham * arrays.xml: New file containing the Array and Domain chapter. * concepts.xml: Add glossary links to "index" entry. * manual.xml: Replace "bookCap" entity with "bookcap". Add "dim", "domaintemplate", and "float" entities. Move Array (and Domain) chapter to new file 'arrays.xml'. Applied to mainline Approved by me! Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: arrays.xml =================================================================== RCS file: arrays.xml diff -N arrays.xml *** /dev/null Fri Mar 23 21:37:44 2001 --- arrays.xml Tue Jan 15 17:48:34 2002 *************** *** 0 **** --- 1,1738 ---- + + &array; Containers + + A container is a class holding objects. &array;s are one of + the two most widely used &pooma; containers since they model the + mathematical concept of mapping indices from domains to values. + &pooma; &array;s extend built-in &cc; arrays by supporting a wider + variety of domains, automatically handling memory allocations, and + supporting first-class status. For example, they may be used as + operands and in assignments. In this chapter, we introduce the + concept of containers, the mathematical concept of arrays, and the + &pooma; concept for &array;s. Before illustrating how to declare + &array;s, we introduce &domain;s, which specify the sets of + indices. After describing how to declare the various types of + &domain;s, we describe how to declare and use &array;s. This is + illustrated in a &doof2d; implementation using &array;s. We end + with a description of their implementation. + + +

+ Containers + + A container class + expression is a class with the main + purpose of holding objects. These stored objects, called + container + values or more simply + values or elements, may be accessed + and changed, usually using indices. Container + class is usually abbreviated + container. + + The six &pooma; containers can be categorized into two + groups. Mathematical containers include &tensor;s, &matrix;s, and + &vector;s, modeling tensors, matrices, and vectors, respectively. + Storage containers include &array;s, &dynamicarray;s, and + &field;s. In this chapter, we focus on simplest of these: + &array;s. The other containers will be described in subsequent + chapters. + + &c; has built-in arrays, and the &cc; Standard Library + provides maps, vectors, + stacks, and other containers, but the &pooma; + containers better model scientific computing concepts and provide + more functionality. They automatically handle memory allocation + and deallocation and can be used in expressions and on the + left-hand side of assignments. Since &pooma; containers separate + the container concepts of accessing and using values from storing + values, value storage can be optimized to specific needs. For + example, if most of an &array;'s values are known to be the same + most of the time, a compressible engine can be used. Whenever all + the array's values are the same, it stores only one value. At + other times, it stores all the values. Engines will be discussed + in . +

+ + +

+ &array;s + + Mathematically, an array maps indices from a domain to + values. Usually, the domain consists of a one-dimensional + integral interval or it may be multidimensional. &pooma;'s + &array; container class implements this idea. Given an index, + i.e., a position in an &array;'s &domain;, it returns the associated + value, either by returning a stored value or by computing it. The + use of indices, which are usually integral tuples but need not be + zero-based or even consist of all possible integral tuples in a + multidimensional range. Using indices permits constant-time + access to values although computing a particular value may require + significant time. + + &pooma; &array;s are first-class + types so they can be used more + widely than built-in &cc; arrays. For example, &array;s can be + used as operands and in assignment statements. The statement + a = a + b; adds corresponding elements of + &array;s a and b, assigning + the sums to the &array; a. The statement + treats each array as one object, rather than requiring the use of + one or more loops to access individual values. Data-parallel + statements are further discussed in . &array;s also handle their own + memory allocation and deallocation. For example, the &array; + declaration Array<2, double, Brick> + a(vertDomain) creates an + &array; a, allocating whatever memory it + needs. When a goes out of scope, it and its + memory is automatically deallocated. Automatic memory allocation + and deallocation also eases copying. As we mentioned above, an + &array;'s &engine; stores or computes its values so it, not the + &array; itself, is responsible for memory allocation and + deallocation. Fortunately, this distinction is usually hidden + from the &pooma; user. + + Individual &array; values can be accessed using parentheses, + not square brackets, as for &cc; arrays. For example, + a(3,4) yields the value at position (3,4) + of a's two-dimensional domain. +

+ + +

+ &domain;s + + A domain + specifies the set of points on which an &array; can define values. + These indices are the arguments placed within parentheses when + selecting particular values, as described previously. A domain + supported both by &array;s and by built-in &cc; arrays is an + interval [0,n-1] of integers containing all integers {0, 1, 2, + …, n-1}. For &cc;, every integer in the interval must be + included, and the minimum index must be zero. &pooma; expands the + set of permissible domains to support intervals with nonzero + minimal indices and strides and by adding other choices. + + In &pooma;, &domain;s implement domains. There are four + different categories: + + + &loc; + + &domain; with a single point. + + + + &interval; + + &domain; with an integral interval [a,b]. + + + + ⦥ + + &domain; with an integral interval [a,b] and an integral + stride s indicating the gap between indices: {a, a+s, + a+2s, …, b}. + + + + &grid; + + &domain; with an ascending or descending sequence of + integral values. The sequence elements must be individually + specified. + + + + One-dimensional and multidimensional versions of each categories + are supported. A multidimensional &domain; consists of the direct + product of one-dimensional &domain;s. For example, the first + dimension of a two-dimensional interval [0,3]x[2,9] is the + interval [0,3], and its second dimension is the + interval [2,9]. Its indices are ordered pairs such as (0,2), + (0,3), (1,2), (1,9), and (3,7). + + Many domains can be represented using domain triplets. A + domain + triplet + [begin:end:stride] + represents the mathematical set {begin, begin + stride, begin + + 2stride, …, end}, where end is in the + set only if it equals begin plus some integral + multiple of stride. If the + stride is negative, its beginning index + begin should at least be as large as + end if the interval is to be nonempty. The + stride can be zero only if begin and + end are equal. There are lots of ways to + represent an empty interval, e.g., [1:0:1] and [23,34,-1], and + &pooma; will accept them, but they are all equivalent. The domain + triplet notation is easily extended to multiple dimensions by + separating different dimension's intervals with commas. For + example, [2:4:2,6:4:-2] contains (2,6), (2,4), (4,6), + and (4,4). + + All the &domain; categories listed above except &grid; can be + represented using domain triplet notation. Since the triplet + [7:7:1] represents {7}, or more simply 7, it can also + represent Loc<1>(7). Multidimensional + &loc;s are similarly represented. For example, + [0:0:1,10:10:1,2:2:1] represents + Loc<3>(0,10,2), but it is frequently + abbreviated as [0,10,2]. An &interval; [a,b] has unit stride: + [a:b:1], while a ⦥ has specific stride s: + [a:b:s]. + + &domain;s can be constructed by combining &domain;s of smaller + dimension. For example, since a two-dimensional &interval; is the + direct product of two one-dimensional &interval;s, it can be + specified using two one-dimensional &interval;s. For example, + Interval<2>(Interval<1>(2,3), + Interval<1>(4,5)) creates a [2:3:1,4:5:1] + &domain;. The resulting dimensionality equals the sum of the + components' dimensions. For example, a four-dimension &loc; can + be specified using three- and one-dimension &loc;s or using four + one-dimension &loc;s. If fewer dimensions than the created + object's dimensionality, the last dimensions are unspecified and + uninitialized. &loc;s, &interval;s, ⦥s, and &grid;s can all + be composed from smaller similar components. + + A &domain; can be composed from smaller components with + different types. A &loc; object can be constructed from other + &loc; objects and integers. &interval;s, ⦥s, and &grid;s + can be constructed using any of these types, &loc;s, and integers. + For example, Interval<3> a(Loc<2>(1,2), + Interval<1>(3,5)) uses a two-dimensional &loc; + and a one-dimensional &interval; to create a [1:1:1,2:2:1,3:5:1] + &domain;. During creation of a &domain;, the type of each object + is changed to the &domain;'s type. In the example, + Loc<2>(1,2) is first converted to an + &interval;. + + &domain;s can participate in some arithmetic and comparison + operations. For example, a &domain;'s triplet can be shifted two + units to the right by adding two. Multiplying a &domain; by two + multiplies its triplet's beginnings, endings, and strides by two. + &pooma; users rarely need to compare &domain;s, but we describe + operating with the less-than operator on &interval;s. &interval; + d1 < &interval; d2 if the + length of d1's interval is less than + d2's or, if equal, its beginning value is + smaller. &domain; arithmetic is frequently used with data-parallel + statements and container views. These will be discussed in and . + + The current &pooma; implementation supports &domain;s with + dimensionality between one and seven, inclusive. Since most + scientific computations use one, two, or three dimensions, this is + usually sufficient. If more dimensions are needed, they can be + added to the source code. +

+ + +

+ Declaring &domain;s + + Since &domain;s are mainly used to declare container + domains, we focus on declaring &domain;s. Arithmetic operations + with &domain;s are described in . + + All &domain; declarations require a dimension template + parameter &dim;. This positive integer + specifies the number of dimensions, i.e., rank, of the &domain; and + determines the length of the tuples for points in the &domain;. For + example, a three-dimensional &domain; contains ordered triples, + while a one-dimensional &domain; contains singletons, or just + integers. Multidimensional &domain;s are just the direct products + of one-dimensional &domain;s so the techniques for declaring + one-dimensional &domain;s carry over to multi-dimensional + ones. + + To declare a &domain;, one must include the + Pooma/Domains.h header + file. However, most &pooma; programs declare &domain;s to use them + when constructing containers. The container header files + automatically include Pooma/Domains.h so no explicit + inclusion is usually necessary. + +

+ &loc;s + + A Loc<&dim;> is a &domain; with just a single + &dim;-dimensional point. Although it is + infrequently used as a container's domain, it is used to refer to + a single point within another domain. Its beginning and ending + points are the same, and its stride is one. One-dimensional + &loc;s and integers are frequently interchanged. + + + Declaring One-Dimensional &loc;s + + + + + constructor + result + + + + + &domaintemplate;1, &domaintemplate;2, and + &domaintemplate;3 are template parameters. + + + + + + Loc<1>() + points to zero. + + + Loc<1>(const Pooma::NoInit& no) + creates an uninitialized &locone;, to be assigned a value later. + + + Loc<1>(const &domaintemplate;1& t1) + creates a &locone; with the integer converted from t1. + + + Loc<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) + creates a &locone; with the integer converted from + t1. t2 must equal + t1. + + + Loc<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) + creates a &locone; with the integer converted from + t1. t2 must equal + t1, and t3 is + ignored. + + + +

+ + Constructors for one-dimensional &loc;s appear in . + The empty constructor yields the zero point. The constructor + taking a Pooma::Init object does not initialize the + resulting &loc; to any particular value. Presumably, the value + will be assigned later. For small &domain;s such as &loc;s, the + time savings from not initializing is small, but the + functionality is still available. The constructor taking one + argument with type &domaintemplate;1 converts this argument to + an integer to specify the point. The template + type &domaintemplate;1 may be any type that can be converted + to an integer, e.g., &bool;, &char;, ∫, or &double;. The + constructors taking two and three arguments of templatized types + facilitate converting an &interval; and a ⦥ into a &loc;. + Since a &loc; represents a single point, the &interval;'s or + ⦥'s first two arguments must be equal. The stride is + ignored. Again, the templatized types may be any type that can + be converted into an integer. + + + Declaring Multidimensional &loc;s + + + + + constructor + result + + + + + &dim; indicates the &loc;'s dimension. + &domaintemplate;1, &domaintemplate;2, … are + template parameters. + + + + + Loc<&dim;>() + points to zero. + + + Loc<&dim;>(const Pooma::NoInit& no) + creates an uninitialized &loc;, to be assigned a value later. + + + Loc<&dim;>(const &domaintemplate;1& t1) + creates a &loc; using the given &domain; object. + + + Loc<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) + creates a &loc; using the given &domain; objects. + + + Loc<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) + creates a &loc; using the given &domain; objects. + + + Loc<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) + creates a &loc; using the given &domain; objects. + + + Loc<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& + t5) + creates a &loc; using the given &domain; objects. + + + Loc<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& + t5, const &domaintemplate;6& t6) + creates a &loc; using the given &domain; objects. + + + Loc<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& + t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) + creates a &loc; using the given &domain; objects. + + + +

+ + Constructors for multidimensional &loc;s appear in . + &dim; indicates the &loc;'s dimension. The + first two constructors are similar to &locone;'s first two + constructors, returning a representation of the zero point and + returning an uninitialized point. The seven other constructors + create a &loc; using other &domain; objects. These &domain; objects, + having types &domaintemplate;1, …, &domaintemplate;7, can have + any type that can be converted into an integer, to a &locone;, or + to a multidimensional &domain; object that itself can be converted + into a &loc;. The total dimensionality of all the arguments' + types should be at most &dim;. For example, + Loc<5>(Range<1>(2,2,2), Loc<2>(2,3), + Interval<1>(4,4)) creates a five-dimensional &loc; + [2,2,3,4,1] using a one-dimensional ⦥, a two-dimensional + &loc;, and a one-dimensional &interval;. The final fifth + dimension has an unspecified value, in this case 1. The + one-dimensional ⦥ is converted into the single integer two; + its beginning and ending points must be the same. The + two-dimensional &loc; contributes values for the next two + dimensions, while the &interval; contributes its beginning point, + which must be the same as its ending point. Note that the + &locone; constructors taking two and three parameters ignore + their second and third arguments, but this is not true for the + multidimensional constructors. +

+ + +

+ &interval;s + + A one-dimensional &interval; represents a set of integers + within a mathematical interval. + Multidimensional &interval;s represent their multidimensional + generalization, i.e., the direct product of one-dimensional + intervals. &interval;s are arguably the most commonly used + &pooma; &domain;. A one-dimensional &interval; has integral + beginning and ending points and a unit stride. + + + Declaring One-Dimensional &interval;s + + + + + constructor + result + + + + + &domaintemplate;1, &domaintemplate;2, and + &domaintemplate;3 are template parameters. + + + + + + Interval<1>() + creates an empty, uninitialized interval. + + + Interval<1>(const Pooma::NoInit& no) + creates an uninitialized &intervalone;, to be assigned a value later. + + + Interval<1>(const &domaintemplate;1& t1) + creates a &intervalone;. See the text for an explanation. + + + Interval<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) + creates a &intervalone; with the integers converted from + t1 and t2. + + + Interval<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) + creates a &intervalone; with the integers converted from + t1 and t2. + t3 must equal 1. + + + +

+ + &intervalone; constructors are patterned on &locone; + constructors except that &intervalone;s can have differing + beginning and ending points. See . + The default constructor creates an empty, uninitialized interval, + which should not be used before assigning it values. If the + one-parameter constructor's argument is a &domain; object, it must + be a one-dimensional &domain; object which is copied into an + &interval; if possible; for example, it must have unit stride. + If the one-parameter constructor's argument is not a &domain; + object, it must be convertible to an + integer e and an interval [0:e-1:1] + starting at zero is constructed. If two arguments are specified, + they are assumed to be convertible to integers + b and e, specifying the + interval [b:e:1]. The three-parameter constructor is similar, + with the third argument specifying a stride, which must be + one. + + + Declaring Multidimensional &interval;s + + + + + constructor + result + + + + + &dim; indicates the &interval;'s dimension. + &domaintemplate;1, &domaintemplate;2, … are + template parameters. + + + + + Interval<&dim;>() + creates an empty, uninitialized &interval;, to be assigned a value later. + + + Interval<&dim;>(const Pooma::NoInit& no) + creates an empty, uninitialized &interval;, to be assigned a value later. + + + Interval<&dim;>(const &domaintemplate;1& t1) + creates a &interval; using the given &domain; object. + + + Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) + creates a &interval; using the given &domain; objects. + + + Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) + creates a &interval; using the given &domain; objects. + + + Interval<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) + creates a &interval; using the given &domain; objects. + + + Interval<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& + t5) + creates a &interval; using the given &domain; objects. + + + Interval<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& + t5, const &domaintemplate;6& t6) + creates a &interval; using the given &domain; objects. + + + Interval<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& + t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) + creates a &interval; using the given &domain; objects. + + + +

+ + Constructors for multidimensional &interval;s closely + follow constructors for multidimensional &loc;s. See . + &dim; indicates the &interval;'s + dimension. The first two constructors both return empty, + uninitialized intervals. The seven other constructors create an + &interval; using &domain; objects. These &domain; objects, + having types &domaintemplate;1, …, + &domaintemplate;7, can have any type that can be + converted into an integer, into a single-dimensional &domain; + object that can be converted into a single-dimensional + &interval;, or to a multidimensional &domain; object that itself + can be converted into an &interval;. The total dimensionality of + all the arguments' types should be at + most &dim;. One-dimensional &domain; + objects that can be converted into one-dimensional &interval;s + include &locone;s, &intervalone;s, and &rangeone;s with unit + strides. If the sum of the objects' dimensions is less + than &dim;, the intervals for the final + dimensions are unspecified. See the last paragraph of for an + analogous example. Note that the &intervalone; constructors + taking two and three parameters treat these arguments differently + than the multidimensional constructors do. +

+ + +

+ ⦥s + + A one-dimensional ⦥ generalizes an &interval; by + permitting a non-unit stride between integral members. A + range + is a set of integers in a mathematical interval [b,e] with a + stride s between them: {a, a+s, a+2s, …, b}. Ranges + are generalized to &dim; dimensions using the + direct product of one-dimensional ranges. + + + Declaring One-Dimensional ⦥s + + + + + constructor + result + + + + + &domaintemplate;1, &domaintemplate;2, and + &domaintemplate;3 are template parameters. + + + + + + Range<1>() + creates an empty, uninitialized range. + + + Range<1>(const Pooma::NoInit& no) + creates an uninitialized &rangeone;, to be assigned a value later. + + + Range<1>(const &domaintemplate;1& t1) + creates a &rangeone;. See the text for an explanation. + + + Range<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) + creates a &rangeone; with an interval specified by the + integers converted from t1 and + t2. + + + Range<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) + creates a &rangeone; by converting the arguments to + integers i1, i2, and + i3 and then making a range [i1:i2:i3]. + + + +

+ + &rangeone; constructors are the same as &intervalone; + constructors except they create ranges, not intervals. See . + The default constructor creates an empty, uninitialized range, + which should not be used before assigning it values. If the + one-parameter constructor's argument is a &domain; object, it must + be a one-dimensional &domain; object which is copied into a ⦥ + if possible. If the one-parameter constructor's argument is not + a &domain; object, it must be convertible to an + integer e and a range [0:e-1:1] starting + at zero is constructed. If two arguments are specified, they are + assumed to be convertible to integers b and + e, specifying the range [b:e:1]. The + three-parameter constructor is similar, with the third argument + specifying a stride. + + + Declaring Multidimensional ⦥s + + + + + constructor + result + + + + + &dim; indicates the ⦥'s dimension. + &domaintemplate;1, &domaintemplate;2, … are + template parameters. + + + + + Range<&dim;>() + creates an empty, uninitialized ⦥, to be assigned a value later. + + + Range<&dim;>(const Pooma::NoInit& no) + creates an empty, uninitialized ⦥, to be assigned a value later. + + + Range<&dim;>(const &domaintemplate;1& t1) + creates a ⦥ using the given &domain; object. + + + Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) + creates a ⦥ using the given &domain; objects. + + + Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) + creates a ⦥ using the given &domain; objects. + + + Range<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) + creates a ⦥ using the given &domain; objects. + + + Range<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& + t5) + creates a ⦥ using the given &domain; objects. + + + Range<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& + t5, const &domaintemplate;6& t6) + creates a ⦥ using the given &domain; objects. + + + Range<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& + t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) + creates a ⦥ using the given &domain; objects. + + + +

+ + Constructors for multidimensional ⦥s are the same as + multidimensional &interval; constructors except they create + ranges, not intervals. See . + &dim; indicates the ⦥'s dimension. The + first two constructors return empty, uninitialized ranges. + The seven other constructors create an ⦥ using &domain; + objects. These &domain; objects, having types &domaintemplate;1, + …, &domaintemplate;7, can have any type that can be + converted into an integer, into a single-dimensional &domain; + object that can be converted into a single-dimensional ⦥, + or to a multidimensional &domain; object that itself can be + converted into an ⦥. The total dimensionality of all the + arguments' types should be at most &dim;. + One-dimensional &domain; objects that can be converted into + one-dimensional ⦥s include &locone;s, &intervalone;s, and + &rangeone;s. If the sum of the objects' dimensions is less + than &dim;, the ranges for the final + dimensions are unspecified. See the last paragraph of for an + analogous example. Note that the &rangeone; constructors taking + two and three parameters treat these arguments differently than + the multidimensional constructors do. +

+ + +

+ &grid;s + + &loc;s, &interval;s, and ⦥s all have regularly spaced + integral values so they can be represented using domain triplets. + One-dimensional &grid; integral domains contain ascending or + descending sequences of integers, with no fixed stride. For + example, a &gridone; may represent {-13, 1, 4, 5, 34}. &gridone; + is generalized to multidimensional &grid;s using the direct + product of &gridone; &domain;s. + + &grid;s that can be represented using domain triplets can + be constructed using techniques similar to other &domain;s, but + irregularly spaced domains can be constructed using + &indirectionlistint;s. + + + Declaring One-Dimensional &grid;s + + + + + constructor + result + + + + + &domaintemplate;1, &domaintemplate;2, and + &domaintemplate;3 are template parameters. + + + + + + Grid<1>() + creates an empty, uninitialized grid. + + + Grid<1>(const &domaintemplate;1& t1) + creates a &gridone;. See the text for an explanation. + + + Grid<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) + creates a &gridone; from the interval specified by the + integers converted from t1 and + t2. + + + Grid<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) + creates a &gridone; from the domain triplet specified + by the integers converted from t1, + t2, and t3. + + + +

+ + To construct a &gridone; that can also be represented by a + domain triplet, use a &gridone; constructor similar to those for + &intervalone; and &rangeone;. See + and the text explanations following + or . + + &gridone;s with irregularly spaced points can be + constructed using &indirectionlistint;s. For example, + + IndirectionList<int> list(4); + list(0) = 2; + list(1) = 5; + list(2) = 6; + list(3) = 9; + Grid<1> g(list); + constructs an empty &indirectionlistint;, fills it + with ascending values, and then creates a &gridone; containing + {2, 5, 6, 9}. When creating a list, its size must be specified. + Subsequently, its values can be assigned. &indirectionlist;s can + also be initialized using one-dimensional &array;s: + + Array<1,int,Brick> a1(Interval<1>(0,3)); + a1(0) = 2; a1(1) = 5; a1(2) = 6; a1(3) = 9; + IndirectionList<int> il(a1); + Grid<1> g1(il); + The &array; stores the integral points to include + in the &gridone; and is used to create the &indirectionlistint;, + which itself is used to create the &gridone;. Since the points + are integers, the &array;'s type is ∫. Either a &brick; or + &compressiblebrick; &engine; should be used. + + + Declaring Multidimensional &grid;s + + + + + constructor + result + + + + + &dim; indicates the &grid;'s + dimension. &domaintemplate;1, + &domaintemplate;2, … are template + parameters. + + + + + Grid<&dim;>() + creates an empty, uninitialized &grid;, to be assigned a value later. + + + Grid<&dim;>(const &domaintemplate;1& t1) + creates a &grid; using the given &domain; object. + + + Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) + creates a &grid; using the given &domain; objects. + + + Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) + creates a &grid; using the given &domain; objects. + + + Grid<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) + creates a &grid; using the given &domain; objects. + + + Grid<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& + t5) + creates a &grid; using the given &domain; objects. + + + Grid<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& + t5, const &domaintemplate;6& t6) + creates a &grid; using the given &domain; objects. + + + Grid<&dim;>(const &domaintemplate;1& t1, const + &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& + t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) + creates a &grid; using the given &domain; objects. + + + +

+ + Constructors for multidimensional &grid;s are the same as + multidimensional &interval; constructors except they create + &grid;s, not intervals. See . + &dim; indicates the &grid;'s dimension. The + first constructor returns empty, uninitialized grids. The seven + other constructors create an &grid; using &domain; objects. These + &domain; objects, having types &domaintemplate;1, …, + &domaintemplate;7, can have any type that can be converted into an + integer, into a single-dimensional &domain; object that can be + converted into a single-dimensional &grid;, or to a + multidimensional &domain; object that itself can be converted into + an &grid;. The total dimensionality of all the arguments' types + should be at most &dim;. One-dimensional + &domain; objects that can be converted into one-dimensional &grid;s + include &locone;s, &intervalone;s, &rangeone;s, and &gridone;s. + If the sum of the objects' dimensions is less + than &dim;, the grids for the final + dimensions are unspecified. See the last paragraph of for an + analogous example. Note that the &gridone; constructors taking + two and three parameters treat these arguments differently than + the multidimensional constructors do. +

+ + +

+ Declaring &array;s + + A &pooma; &array; maps indices from its &domain; to values. + In this section, we describe first describe how to declare + &array;s. In the next section, we explain how to access + individual values stored within an &array; and &array; copy + semantics. + + &array; values need not just be stored values, as &c; arrays + have. They can also be computed using its engine. We defer + discussion of computing values to the next chapter discussing + engines (). To avoid being verbose + in this chapter, when we discuss stored values, the values might + instead be computed. + + Declaring an &array; requires four arguments: the domain's + dimensionality, the type of values stored or computed, a + specification how the values are stored, and a &domain;. The + first three arguments are template parameters since few scientific + programs (and no &pooma; programs) need to change these values + while a program executes. For example, an &array; cannot change + the type of the elements it stores. Alternatively, an &array;'s + values can be copied into another &array; having the desired type. + Although scientific programs do not frequently change an array's + domain, they do frequently request a subset of the array's values, + i.e., a view. The + subset is specified via a &domain; so it is a run-time value. + Views are presented in . + + An &array;'s first template parameter specifies its + dimensionality. This positive + integer &dim; specifies its rank. This is + the same value as its domain's dimensionality. Theoretically, an + &array; can have any positive integer, but the &pooma; code + currently supports &dim; at most seven. For + almost all scientific codes, a dimension of three or four is + sufficient, but the code can be extended to support higher + dimensions. + + An &array;'s second template parameter specifies the type of + its stored values. Common value types include ∫, &double;, + &complex;, and &vector;, but any type is permissible. For + example, an &array;'s values might be matrices or even other + &array;s. The parameter's default value is usually &double;, but + it may be changed when the &poomatoolkit; is configured. + + An &array;'s third parameter specifies how its data is + stored by an &engine; and its values accessed. The argument is a + tag indicating a particular type of &engine;. Permissible tags + include &brick;, &compressiblebrick;, and + ConstantFunction. The &brick; tag indicates all + &array; values will be explicitly stored, just as built-in &c; + arrays do. If the &array;s frequently stores exactly the same + value in every position, a &compressiblebrick; &engine;, which + reduces its space requirements to a constant whenever all its + values are the same, is appropriate. A + ConstantFunction &engine; returns the same value for + all indices. + + Even though every &array; container has an engine to store + its values and permit access to individual values, an &array; is + conceptually separated from engines. An engine's role is + low-level, storing values and permitting access to individual + values. As we indicated above, the storage can be optimized to + fit specific situations such as few nonzero values and computing + values using a function applied to another engine's values. An + &array;'s role is high-level, supporting access to groups of + values. They handle memory allocation and deallocation. &array;s + can be used in data-parallel expressions, e.g., adding all the + values in one &array; to all the values in another. (See for more information.) Subsets of + &array; values, frequently used in data-parallel statements, can + be obtained. (See for more + information.) Even though engines and &array;s are conceptually + separate, higher-level &array;s provide access to lower-level + &engine;s. Users usually have an &array; create its &engine;, + rarely explicitly creating &engine;s themselves. Also, &array;s + provide access to individual values. In short, &pooma; users use + &array;s, only dealing with how they are implemented (engines) + upon declaration. For more description of &engine;s, see . + + The engine parameter's default value is usually &brick;, but + it may be changed when the &poomatoolkit; is configured. + + An &array;'s one constructor argument is its domain. The + domain specifies its extent and simultaneously how many values it + can return. All the provided &domain; objects are combined to + yield an Interval<&dim;>, where &dim; matches + the &array;'s first template parameter. Since an &interval; + domain with its unit strides is used, there are no unaccessed + gaps within the domain, wasting storage space. To + use other domains to access an &array;, first create it using an + &interval; domain and then take a view of it, as described in + . As we mentioned above, the current + &pooma; code supports up to seven dimensions so at most seven + &domain; objects can be provided. If more dimensions are + required, the &pooma; code can be extended to the desired number + of dimensions. + + + Declaring &array;s + + + + + &array; declaration + result + + + + + Template parameters &dim;, + T, and E indicates the + &array;'s dimension, value type, and &engine; type, + respectively. DT1, …, + DT7 indicate domain types or + integers. + + + + + Array<&dim;,T,E>() + creates an empty, uninitialized &array; which must be + initialize()d before use. + + + + + Array<&dim;,T,E>(const DT1& t1) + creates an &array; using the given &domain; object or integer. + + + Array<&dim;,T,E>(const DT1& t1, const DT2& t2) + creates an &array; using the given &domain; objects and integers. + + + Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3) + creates an &array; using the given &domain; objects and integers. + + + Array<&dim;,T,E>(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4) + creates an &array; using the given &domain; objects and integers. + + + Array<&dim;,T,E>(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4, const DT5& + t5) + creates an &array; using the given &domain; objects and integers. + + + Array<&dim;,T,E>(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4, const DT5& + t5, const DT6& t6) + creates an &array; using the given &domain; objects and integers. + + + Array<&dim;,T,E>(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4, const DT5& + t5, const DT6& t6, const DT7& t7) + creates an &array; using the given &domain; objects and integers. + + + Array<&dim;,T,E>(const DT1& t1, + const ModelElement<T>& model) + creates an &array; using the given &domain; object or + integer and + then initializes all entries using model. + + + Array<&dim;,T,E>(const DT1& t1, const DT2& t2, + const ModelElement<T>& model) + creates an &array; using the given &domain; objects and + integers and + then initializes all entries using model. + + + Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, + const ModelElement<T>& model) + creates an &array; using the given &domain; objects and + integers and + then initializes all entries using model. + + + Array<&dim;,T,E>(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4, + const ModelElement<T>& model) + creates an &array; using the given &domain; objects and + integers and + then initializes all entries using model. + + + Array<&dim;,T,E>(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4, const DT5& + t5, + const ModelElement<T>& model) + creates an &array; using the given &domain; objects and + integers and + then initializes all entries using model. + + + Array<&dim;,T,E>(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4, const DT5& + t5, const DT6& t6, + const ModelElement<T>& model) + creates an &array; using the given &domain; objects and + integers and + then initializes all entries using model. + + + Array<&dim;,T,E>(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4, const DT5& + t5, const DT6& t6, const DT7& t7, + const ModelElement<T>& model) + creates an &array; using the given &domain; objects and + integers and + then initializes all entries using model. + + + +

+ + &array; constructors are listed in . An &array;s' + three template parameters for dimensionality, value type, and + engine type are abbreviated D, + T, and E. Template + parameters for domain types are named DT1, + …, DT7. The first constructor, with no + domain arguments, creates an empty, uninitialized &array; for + which a domain must be specified before it is used. Specify the + array's domain using its initialize function. + The next seven constructors combine their domain arguments to + compute the resulting &array;'s domain. These are combined in the + same way that multidimensional &interval;s are constructed. (See + + and the following text.) The domain objects, having types + &domaintemplate;1, …, + &domaintemplate;7, can have any type that can be + converted into an integer, into a single-dimensional &domain; + object that can be converted into a single-dimensional &interval;, + or to a multidimensional &domain; object that itself can be + converted into an &interval;. The total dimensionality of all the + arguments' types should + equal &dim;, unlike + &interval; construction which permits total dimensionality less + than or equal to &dim;. One-dimensional + &domain; objects that can be converted into one-dimensional + &interval;s include &locone;s, &intervalone;s, and &rangeone;s + with unit strides. To initialize all of an &array; values to a + specific value, use one of the final seven constructors, each + taking a particular value, wrapped as a ModelElement. + These constructors use the given domain objects the same way as + the preceding constructors but assign model to + every &array; value. model's type + ModelElement<T> rather than + T to differentiate it from an ∫, which can + also be used to specify a domain object. + ModelElement just stores an element of any type + T, which must match the &array;'s value + type. + + We illustrate creating &array;s. To create a + three-dimensional &array; a explicitly + storing &double; floating-point values, use + + Interval<1> D(6); + Interval<3> I3(D,D,D); + Array<3,double,Brick> a(I3);. + The template parameters specify its dimensionality, + the type of its values, and a &brick; &engine; type, which + explicitly stores values. Its domain, which must have three + dimensions, is specified by an Interval<3> + object which consists of a [0,5] intervals for all its three + dimensions. Since &double; and &brick; are usually the default + template parameters, they can be omitted so these declarations are + equivalent: + + Array<3,double> a_duplicate1(I3); + Array<3> a_duplicate2(I3);. + To create a similar &array; with a domain of + [0:1:1, 0:2:1, 0:0:1], use + + Array<3> b(2,3,1);. + Specifying an integer i + indicates a one-dimensional zero-based &interval; [0:i-1:1]. To + store &bool;s, specify &bool; as the second template argument: + + Array<2,bool> c(2,3);. + To specify a default &array; value of &true;, use + ModelElement<bool>(true): + + Array<2,bool> c(2,3, ModelElement<bool>(true));. + To create a one-dimensional &array; containing + seven &double;s all equaling π, use + + Array<1,double,CompressibleBrick> d(7, ModelElement<double>(4.0*atan(1.0)));. + We use a &compressiblebrick; &engine;, rather than + a &brick; &engine;, so all seven values will be stored once rather + than seven times when they are all the same. + + + Initializing &array;s' Domains + + + + + An &array;'s initialize member + functions sets its domain and should be invoked only for an + array created without a domain. It returns nothing. + + + initialize declaration + result + + + + + Template parameters DT1, …, + DT7 indicate domain types or + integers. + + + + + + + initialize(const DT1& t1) + creates the &array;'s domain using the given &domain; + object or integer. + + + initialize(const DT1& t1, const DT2& t2) + creates the &array;'s domain using the given &domain; objects and integers. + + + initialize(const DT1& t1, const DT2& t2, const DT3& t3) + creates the &array;'s domain using the given &domain; objects and integers. + + + initialize(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4) + creates the &array;'s domain using the given &domain; objects and integers. + + + initialize(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4, const DT5& + t5) + creates the &array;'s domain using the given &domain; objects and integers. + + + initialize(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4, const DT5& + t5, const DT6& t6) + creates the &array;'s domain using the given &domain; objects and integers. + + + initialize(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4, const DT5& + t5, const DT6& t6, const DT7& t7) + creates the &array;'s domain using the given &domain; objects and integers. + + + initialize(const DT1& t1, + const ModelElement<T>& model) + creates the &array;'s domain using the given &domain; object and + then initializes all entries using model. + + + initialize(const DT1& t1, const DT2& t2, + const ModelElement<T>& model) + creates the &array;'s domain using the given &domain; objects and + then initializes all entries using model. + + + initialize(const DT1& t1, const DT2& t2, const DT3& t3, + const ModelElement<T>& model) + creates the &array;'s domain using the given &domain; objects and + then initializes all entries using model. + + + initialize(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4, + const ModelElement<T>& model) + creates the &array;'s domain using the given &domain; objects and + then initializes all entries using model. + + + initialize(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4, const DT5& + t5, + const ModelElement<T>& model) + creates the &array;'s domain using the given &domain; objects and + then initializes all entries using model. + + + initialize(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4, const DT5& + t5, const DT6& t6, + const ModelElement<T>& model) + creates the &array;'s domain using the given &domain; objects and + then initializes all entries using model. + + + initialize(const DT1& t1, const + DT2& t2, const DT3& t3, const DT4& t4, const DT5& + t5, const DT6& t6, const DT7& t7, + const ModelElement<T>& model) + creates the &array;'s domain using the given &domain; objects and + then initializes all entries using model. + + + +

+ + An uninitialized &array;, created using the parameter-less + constructor, must have a specified domain before it can be used. + For example, one must use the parameter-less &array; constructor + when creating an array of &array;s using + new (although it would probably be + better to create an &array; of &array;s since memory allocation + and deallocation would automatically be handled) so their domains + must be specified. &array;'s initialize + functions accept the same set of domain object specifications and + model elements that the &array; constructors do, creating the + specified domain. See . + For example, both a and b + are two-dimensional &array;s of &float;s with a [2:7:1,-2:4:1] + domains: + + // Create an Array and its domain. + Array<2,float,Brick> a(Interval<1>(2,7), Interval<1>(-2,4)); + // Create an Array without a domain and then specify its domain. + Array<2,float,Brick> b(); + b.initialize(Interval<1>(2,7), Interval<1>(-2,4));. + Invoking initialize on an + &array; with an existing domain is unspecified. All &array; + values may be lost and memory may be leaked. +

+ + +

+ Using &array;s + + In the previous section, we explained how to declare and + initialize &array;s. In this section, we explain how to access + individual values stored within an &array; and how to copy + &array;s. In , we explain + how to use entire &array;s in data-parallel statements, including + how to print them. In , we extend + this capability to work on subsets. + + In its simplest form, an &array; stores individual values, + permitting access to these values. For a &cc; array, the desired + index is specified within square brackets following the array's + name. For &pooma; &array;s, the desired index is specified + within parentheses following the &array;'s name. The same + notation is used to read and write values. For example, the + following code prints the initial value at index (2,-2) and + increments its value, printing the new value: + + Array<2,int,Brick> a(Interval<1>(0,3), Interval<1>(-2,4), + ModelElement<int>(4)); + std::cout &openopen; a(2,-2) &openopen; std::endl; + ++a(2,-2); + std::cout &openopen; a(2,-2) &openopen; std::endl; + 4 and then + 5 are printed. An index + specification for an &array; usually has as many integers as + dimensions, all separated by commas, but the &array;'s engine may + permit other notation such as using strings or floating-point + numbers. + + For read-only access to a value, use the + read member function, which takes the + same index notation as its nameless read-write counterpart: + + std::cout &openopen; a.read(2,-2) &openopen; std::endl; + Using read sometimes + permits the optimizer to produce faster executing code. + + + Copying &array;s + &array-copy; + + + Copying &array;s requires little execution time because they + have reference semantics. That is, a copy of an &array; and the + &array; itself share the same underlying data. Changing a value + in one changes it in the other. illustrates this + behavior. Initially, all values in the array a + are 4. The b array is initialized using + a so it shares the same values as + a. Thus, changing the former's value also + changes the latter's value. Function arguments are also + initialized so changing their underlying values also changes the + calling function's values. For example, the + changeValue function changes the value with + index (0,0) of both its function argument + and a. + + The separation between a higher-level &array; and its + lower-level &engine; storage permits fast copying. An &array;'s + only data member is its engine, which itself has reference + semantics that increments a reference-counted pointer to its data. + Thus, copying an &array; requires creating a new object with one + data member and incrementing a pointer's reference count. + Destruction is similarly inexpensive. + + Array assignment does not have reference semantics. Thus, + the assignment a = b ensures that all of + a's values are the same as b + at the time of assignment only. Subsequent changes to + a's values do not change b's + values or vice versa. + + + &array; Internal Type Definitions and Compile-Time Constants + + + + + internal type or compile-time constant + meaning + + + + + This_t + the &array;'s type Array<&dim;,T,E>. + + + Engine_t + the &array;'s &engine; type Engine<&dim;,T,E>. + + + EngineTag_t + the &array;'s &engine;'s tag E. + + + Element_t + the type T of values stored in the &array;. + + + ElementRef_t + the type of references to values stored in the &array; + (usually T&). + + + Domain_t + the type of the &array;'s domain. + + + Layout_t + the type of the &array;'s layout. + + + + const + int + dimensions + the number &dim; of dimensions of the &array;. + + + + const + int + rank + synonym for dimensions. + + + +

+ + The &array; class has internal type definitions and + constants useful for both compile-time and run-time computations. + See . + These may be accessed using the &array;'s type and the scope + resolution operator (::). The table begins + with a list of internal type definitions, e.g., + Array<&dim;,T,E>::Domain_t. Member + functions use some of these types. A layout maps a domain index + to a particular processor and memory used to compute the + associated value. The two internal enumerations + dimensions and + rank both record + the &array;'s dimension. + + + &array; Accessors + + + + + &array; member function + result + + + + + Internal type definitions, e.g., Domain_t, + are listed without a class type prefix + Array<&dim;,T,E>::. + + + + + Domain_t domain() + returns the &array;'s domain. + + + Domain_t physicalDomain() + returns the &array;'s domain. + + + Domain_t totalDomain() + returns the &array;'s domain. + + + int first(int dim) + returns the first (smallest) index value for the + specified dimension. + + + int last(int dim) + returns the last (largest) index value for the + specified dimension. + + + int length(int dim) + returns the number of indices (including endpoints) for + the specified dimension. + + + Loc<Dim> firsts() + returns the first (smallest) index values for all the + dimensions. + + + Loc<Dim> lasts() + returns the last (largest) index values for all the + specified dimensions. + + + Loc<Dim> lengths() + returns the numbers of indices (including endpoints) + for all the specified dimensions. + + + long size() + returns the total number of indices in the domain. + + + Layout_t layout() + returns the &array;'s domain. + + + Engine_t engine() + returns the &array;'s engine. + + + const Engine_t engine() + returns the &array;'s engine. + + + +

+ + The &array; class has several member functions easing access + to its domain and engine. The first ten functions listed in ease access to + &array; domains. The first three functions are synonyms all + returning the &array;'s domain, which has type + Array<&dim;,T,E>::Domain_t, abbreviated + Domain_t in the table. The next seven functions + query the domain. first, + last, and length + return the smallest, largest, and number of indices for the + specified dimension. The domain's dimensions are numbered 0, 1, + …, + Array<&dim;,T,E>::dimensions-1. If + these values are needed for all dimensions, use + firsts, lasts, + and lengths. The returned + Loc<&dim;>s have &dim; entries, one for each + dimension. size returns the total number + of indices in the entire domain. This is the product of all the + dimensions' lengths. The + layout member function returns the + &array;'s layout, which specifies the mapping of indices to + processors and memory. The last two functions return the + &array;'s engine. + + + Using &array; Member Functions + &array-size; + + + The size is invoked by + prepending the &array;'s name followed by a period. This + assertion is unnecessary, but the + computeArraySize function further + illustrates using member functions. + + + These template parameters, used in the &array; + parameter's type, permit the function to work with any + &array;. + + + We invoke these three member functions using the + &array;'s name a, a period, and the + functions' names. These functions return &loc;s. + + + lens[d] returns a + Loc<1> for + dimension d's length. Invoking + Loc<1> firstmethod + yields its value. + + + This comparison is unnecessary but further illustrates + using member functions. + + + + + We illustrate using &array; member functions in . The program + computes the total number of &array;'s indices, comparing the + result with invoking its size method. + Since the &array;'s name is a, + a.size() returns its size. + computeArraySize also computes the &array;'s + size. This templated function uses its three template parameters + to accept any &array;, regardless of its dimension, value type, or + &engine; tag. It begins by obtaining the range of indices for all + dimensions and their lengths. Only the latter is necessary for + the computation, but the former further illustrate using member + functions. The domain's size is the product of the length of each + dimension. Since the lengths are stored in the + Loc<&dim> lens, + lens[d] is a Loc<1>, for + which its first extracts the length. The + length &array; member function is used in + the PAssert. +

+ + +

+ An &array; Implementation of &doof2d; + + mostly copy pp.35-38 from tutorial chapter +

+ + +

+ Implementing &array;s + + What to write? + + Do I need to describe the public interface of Domains? Do I need + to describe how a programmer would implement a new type of domain? + Probably not. +

+ + Index: concepts.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/concepts.xml,v retrieving revision 1.5 diff -c -p -r1.5 concepts.xml *** concepts.xml 2002/01/14 17:33:33 1.5 --- concepts.xml 2002/01/16 00:48:35 *************** *** 134,140 **** &array; ! container mapping indices to values and that may be used in expressions --- 134,140 ---- &array; ! container mapping indices to values and that may be used in expressions *************** *** 146,152 **** &field; ! container mapping indices to one or more values and residing in multi-dimensional space --- 146,152 ---- &field; ! container mapping indices to one or more values and residing in multi-dimensional space *************** *** 172,178 **** A &pooma; &array; generalizes a &c; array ! and maps indices to values. Given an index or position in an &array;'s domain, it returns the associated value, either by returning a stored value or by computing it. The use of indices, which are usually ordered tuples, permits constant-time access --- 172,178 ---- A &pooma; &array; generalizes a &c; array ! and maps indices to values. Given an index or position in an &array;'s domain, it returns the associated value, either by returning a stored value or by computing it. The use of indices, which are usually ordered tuples, permits constant-time access *************** *** 350,356 **** A layout ! maps domain indices to the processors and computer memory used by a container's engines. See . --- 350,356 ---- A layout ! maps domain indices to the processors and computer memory used by a container's engines. See . Index: manual.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/manual.xml,v retrieving revision 1.6 diff -c -p -r1.6 manual.xml *** manual.xml 2002/01/14 17:33:34 1.6 --- manual.xml 2002/01/16 00:48:38 *************** *** 15,21 **** ! C"> --- 15,21 ---- ! C"> *************** *** 32,37 **** --- 32,39 ---- + + Doof2d" > Fortran"> *************** *** 89,94 **** --- 91,98 ---- Domain"> + + double"> DynamicArray"> *************** *** 100,105 **** --- 104,111 ---- Field"> + float"> + Grid"> Grid<1>"> *************** *** 193,198 **** --- 199,206 ---- + + *************** *** 228,233 **** --- 236,245 ---- + + + + *************** *** 285,291 ****

! How to Read This &bookCap; FINISH: Write this section in a style similar to Lamport's LaTeX section 1.2. FINISH: Fix the book title and the section --- 297,303 ----

! How to Read This &bookcap; FINISH: Write this section in a style similar to Lamport's LaTeX section 1.2. FINISH: Fix the book title and the section *************** *** 338,1581 **** &tutorial-chapter; &concepts-chapter; - - - - &array; Containers - - A container is a class holding objects. &array;s are one of - the two most widely used &pooma; containers since they model the - mathematical concept of mapping indices from domains to values. - &pooma; &array;s extend built-in &cc; arrays by supporting a wider - variety of domains, automatically handling memory allocations, and - supporting first-class status. For example, they may be used as - operands and in assignments. In this chapter, we introduce the - concept of containers, the mathematical concept of arrays, and the - &pooma; concept for &array;s. Before illustrating how to declare - &array;s, we introduce &domain;s, which specify the sets of - indices. After describing how to declare the various types of - &domain;s, we describe how to declare and use &array;s. This is - illustrated in a &doof2d; implementation using &array;s. We end - with a description of their implementation. - - -

- Containers - - A container class - expression is a class with the main - purpose of holding objects. These stored objects, called - container - values or more simply - values or elements, may be accessed - and changed, usually using indices. Container - class is usually abbreviated - container. - - The six &pooma; containers can be categorized into two - groups. Mathematical containers include &tensor;s, &matrix;s, and - &vector;s, modeling tensors, matrices, and vectors, respectively. - Storage containers include &array;s, &dynamicarray;s, and - &field;s. In this chapter, we focus on simplest of these: - &array;s. The other containers will be described in subsequent - chapters. - - &c; has built-in arrays, and the &cc; Standard Library - provides maps, vectors, - stacks, and other containers, but the &pooma; - containers better model scientific computing concepts and provide - more functionality. They automatically handle memory allocation - and deallocation and can be used in expressions and on the - left-hand side of assignments. Since &pooma; containers separate - the container concepts of accessing and using values from storing - values, value storage can be optimized to specific needs. For - example, if most of an &array;'s values are known to be the same - most of the time, a compressible engine can be used. Whenever all - the array's values are the same, it stores only one value. At - other times, it stores all the values. Engines will be discussed - in . -

- - -

- &array;s - - Mathematically, an array maps indices from a domain to - values. Usually, the domain consists of a one-dimensional - integral interval or it may be multidimensional. &pooma;'s - &array; container class implements this idea. Given an index, - i.e., a position in an &array;'s &domain;, it returns the associated - value, either by returning a stored value or by computing it. The - use of indices, which are usually integral tuples but need not be - zero-based or even consist of all possible integral tuples in a - multidimensional range. Using indices permits constant-time - access to values although computing a particular value may require - significant time. - - &pooma; &array;s are first-class - types so they can be used more - widely than built-in &cc; arrays. For example, &array;s can be - used as operands and in assignment statements. The statement - a = a + b; adds corresponding elements of - &array;s a and b, assigning - the sums to the &array; a. The statement - treats each array as one object, rather than requiring the use of - one or more loops to access individual values. Data-parallel - statements are further discussed in . &array;s also handle their own - memory allocation and deallocation. For example, the &array; - declaration Array<2, double, Brick> - a(vertDomain) creates an - &array; a, allocating whatever memory it - needs. When a goes out of scope, it and its - memory is automatically deallocated. Automatic memory allocation - and deallocation also eases copying. As we mentioned above, an - &array;'s &engine; stores or computes its values so it, not the - &array; itself, is responsible for memory allocation and - deallocation. Fortunately, this distinction is usually hidden - from the &pooma; user. - - Individual &array; values can be accessed using parentheses, - not square brackets, as for &cc; arrays. For example, - a(3,4) yields the value at position (3,4) - of a's two-dimensional domain. -

- - -

- &domain;s - - A domain - specifies the set of points on which an &array; can define values. - These indices are the arguments placed within parentheses when - selecting particular values, as described previously. A domain - supported both by &array;s and by built-in &cc; arrays is an - interval [0,n-1] of integers containing all integers {0, 1, 2, - …, n-1}. For &cc;, every integer in the interval must be - included, and the minimum index must be zero. &pooma; expands the - set of permissible domains to support intervals with nonzero - minimal indices and strides and by adding other choices. - - In &pooma;, &domain;s implement domains. There are four - different categories: - - - &loc; - - &domain; with a single point. - - - - &interval; - - &domain; with an integral interval [a,b]. - - - - ⦥ - - &domain; with an integral interval [a,b] and an integral - stride s indicating the gap between indices: {a, a+s, - a+2s, …, b}. - - - - &grid; - - &domain; with an ascending or descending sequence of - integral values. The sequence elements must be individually - specified. - - - - One-dimensional and multidimensional versions of each categories - are supported. A multidimensional &domain; consists of the direct - product of one-dimensional &domain;s. For example, the first - dimension of a two-dimensional interval [0,3]x[2,9] is the - interval [0,3], and its second dimension is the - interval [2,9]. Its indices are ordered pairs such as (0,2), - (0,3), (1,2), (1,9), and (3,7). - - Many domains can be represented using domain triplets. A - domain - triplet - [begin:end:stride] - represents the mathematical set {begin, begin + stride, begin + - 2stride, …, end}, where end is in the - set only if it equals begin plus some integral - multiple of stride. If the - stride is negative, its beginning index - begin should at least be as large as - end if the interval is to be nonempty. The - stride can be zero only if begin and - end are equal. There are lots of ways to - represent an empty interval, e.g., [1:0:1] and [23,34,-1], and - &pooma; will accept them, but they are all equivalent. The domain - triplet notation is easily extended to multiple dimensions by - separating different dimension's intervals with commas. For - example, [2:4:2,6:4:-2] contains (2,6), (2,4), (4,6), - and (4,4). - - All the &domain; categories listed above except &grid; can be - represented using domain triplet notation. Since the triplet - [7:7:1] represents {7}, or more simply 7, it can also - represent Loc<1>(7). Multidimensional - &loc;s are similarly represented. For example, - [0:0:1,10:10:1,2:2:1] represents - Loc<3>(0,10,2), but it is frequently - abbreviated as [0,10,2]. An &interval; [a,b] has unit stride: - [a:b:1], while a ⦥ has specific stride s: - [a:b:s]. - - &domain;s can be constructed by combining &domain;s of smaller - dimension. For example, since a two-dimensional &interval; is the - direct product of two one-dimensional &interval;s, it can be - specified using two one-dimensional &interval;s. For example, - Interval<2>(Interval<1>(2,3), - Interval<1>(4,5)) creates a [2:3:1,4:5:1] - &domain;. The resulting dimensionality equals the sum of the - components' dimensions. For example, a four-dimension &loc; can - be specified using three- and one-dimension &loc;s or using four - one-dimension &loc;s. If fewer dimensions than the created - object's dimensionality, the last dimensions are unspecified and - uninitialized. &loc;s, &interval;s, ⦥s, and &grid;s can all - be composed from smaller similar components. - - A &domain; can be composed from smaller components with - different types. A &loc; object can be constructed from other - &loc; objects and integers. &interval;s, ⦥s, and &grid;s - can be constructed using any of these types, &loc;s, and integers. - For example, Interval<3> a(Loc<2>(1,2), - Interval<1>(3,5)) uses a two-dimensional &loc; - and a one-dimensional &interval; to create a [1:1:1,2:2:1,3:5:1] - &domain;. During creation of a &domain;, the type of each object - is changed to the &domain;'s type. In the example, - Loc<2>(1,2) is first converted to an - &interval;. - - &domain;s can participate in some arithmetic and comparison - operations. For example, a &domain;'s triplet can be shifted two - units to the right by adding two. Multiplying a &domain; by two - multiplies its triplet's beginnings, endings, and strides by two. - &pooma; users rarely need to compare &domain;s, but we describe - operating with the less-than operator on &interval;s. &interval; - d1 < &interval; d2 if the - length of d1's interval is less than - d2's or, if equal, its beginning value is - smaller. &domain; arithmetic is frequently used with data-parallel - statements and container views. These will be discussed in and . - - The current &pooma; implementation supports &domain;s with - dimensionality between one and seven, inclusive. Since most - scientific computations use one, two, or three dimensions, this is - usually sufficient. If more dimensions are needed, they can be - added to the source code. -

- !

! Declaring &domain;s - Since &domain;s are mainly used to declare container - domains, we focus on declaring &domain;s. Arithmetic operations - with &domain;s are described in . - - All &domain; declarations require a dimension template - parameter &dim;. This positive integer - specifies the number of dimensions, i.e., rank, of the &domain; and - determines the length of the tuples for points in the &domain;. For - example, a three-dimensional &domain; contains ordered triples, - while a one-dimensional &domain; contains singletons, or just - integers. Multidimensional &domain;s are just the direct products - of one-dimensional &domain;s so the techniques for declaring - one-dimensional &domain;s carry over to multi-dimensional - ones. - - To declare a &domain;, one must include the - Pooma/Domains.h header - file. However, most &pooma; programs declare &domain;s to use them - when constructing containers. The container header files - automatically include Pooma/Domains.h so no explicit - inclusion is usually necessary. - -

- &loc;s - - A Loc<&dim;> is a &domain; with just a single - &dim;-dimensional point. Although it is - infrequently used as a container's domain, it is used to refer to - a single point within another domain. Its beginning and ending - points are the same, and its stride is one. One-dimensional - &loc;s and integers are frequently interchanged. - - - Declaring One-Dimensional &loc;s - - - - - constructor - result - - - - - T1, T2, and - T3 are template parameters. - - - - - - Loc<1>() - points to zero. - - - Loc<1>(const Pooma::NoInit& no) - creates an uninitialized &locone;, to be assigned a value later. - - - Loc<1>(const T1& t1) - creates a &locone; with the integer converted from t1. - - - Loc<1>(const T1& t1, const T2& t2) - creates a &locone; with the integer converted from - t1. t2 must equal - t1. - - - Loc<1>(const T1& t1, const T2& t2, const T3& t3) - creates a &locone; with the integer converted from - t1. t2 must equal - t1, and t3 is - ignored. - - - -

- - Constructors for one-dimensional &loc;s appear in . - The empty constructor yields the zero point. The constructor - taking a Pooma::Init object does not initialize the - resulting &loc; to any particular value. Presumably, the value - will be assigned later. For small &domain;s such as &loc;s, the - time savings from not initializing is small, but the - functionality is still available. The constructor taking one - argument with type T1 converts this argument to - an integer to specify the point. The template - type T1 may be any type that can be converted - to an integer, e.g., &bool;, &char;, ∫, or &double;. The - constructors taking two and three arguments of templatized types - facilitate converting an &interval; and a ⦥ into a &loc;. - Since a &loc; represents a single point, the &interval;'s or - ⦥'s first two arguments must be equal. The stride is - ignored. Again, the templatized types may be any type that can - be converted into an integer. - - - Declaring Multidimensional &loc;s - - - - - constructor - result - - - - - &dim; indicates the &loc;'s dimension. - T1, T2, … are - template parameters. - - - - - Loc<&dim;>() - points to zero. - - - Loc<&dim;>(const Pooma::NoInit& no) - creates an uninitialized &loc;, to be assigned a value later. - - - Loc<&dim;>(const T1& t1) - creates a &loc; using the given &domain; object. - - - Loc<&dim;>(const T1& t1, const T2& t2) - creates a &loc; using the given &domain; objects. - - - Loc<&dim;>(const T1& t1, const T2& t2, const T3& t3) - creates a &loc; using the given &domain; objects. - - - Loc<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4) - creates a &loc; using the given &domain; objects. - - - Loc<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4, const T5& - t5) - creates a &loc; using the given &domain; objects. - - - Loc<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4, const T5& - t5, const T6& t6) - creates a &loc; using the given &domain; objects. - - - Loc<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4, const T5& - t5, const T6& t6, const T7& t7) - creates a &loc; using the given &domain; objects. - - - -

- - Constructors for multidimensional &loc;s appear in . - &dim; indicates the &loc;'s dimension. The - first two constructors are similar to &locone;'s first two - constructors, returning a representation of the zero point and - returning an uninitialized point. The seven other constructors - create a &loc; using other &domain; objects. These &domain; objects, - having types T1, …, T7, can have - any type that can be converted into an integer, to a &locone;, or - to a multidimensional &domain; object that itself can be converted - into a &loc;. The total dimensionality of all the arguments' - types should be at most &dim;. For example, - Loc<5>(Range<1>(2,2,2), Loc<2>(2,3), - Interval<1>(4,4)) creates a five-dimensional &loc; - [2,2,3,4,1] using a one-dimensional ⦥, a two-dimensional - &loc;, and a one-dimensional &interval;. The final fifth - dimension has an unspecified value, in this case 1. The - one-dimensional ⦥ is converted into the single integer two; - its beginning and ending points must be the same. The - two-dimensional &loc; contributes values for the next two - dimensions, while the &interval; contributes its beginning point, - which must be the same as its ending point. Note that the - &locone; constructors taking two and three parameters ignore - their second and third arguments, but this is not true for the - multidimensional constructors. -

- - -

- &interval;s - - A one-dimensional &interval; represents a set of integers - within a mathematical interval. - Multidimensional &interval;s represent their multidimensional - generalization, i.e., the direct product of one-dimensional - intervals. &interval;s are arguably the most commonly used - &pooma; &domain;. A one-dimensional &interval; has integral - beginning and ending points and a unit stride. - - - Declaring One-Dimensional &interval;s - - - - - constructor - result - - - - - T1, T2, and - T3 are template parameters. - - - - - - Interval<1>() - creates an empty, uninitialized interval. - - - Interval<1>(const Pooma::NoInit& no) - creates an uninitialized &intervalone;, to be assigned a value later. - - - Interval<1>(const T1& t1) - creates a &intervalone;. See the text for an explanation. - - - Interval<1>(const T1& t1, const T2& t2) - creates a &intervalone; with the integers converted from - t1 and t2. - - - Interval<1>(const T1& t1, const T2& t2, const T3& t3) - creates a &intervalone; with the integers converted from - t1 and t2. - t3 must equal 1. - - - -

- - &intervalone; constructors are patterned on &locone; - constructors except that &intervalone;s can have differing - beginning and ending points. See . - The default constructor creates an empty, uninitialized interval, - which should not be used before assigning it values. If the - one-parameter constructor's argument is a &domain; object, it must - be a one-dimensional &domain; object which is copied into an - &interval; if possible; for example, it must have unit stride. - If the one-parameter constructor's argument is not a &domain; - object, it must be convertible to an - integer e and an interval [0:e-1:1] - starting at zero is constructed. If two arguments are specified, - they are assumed to be convertible to integers - b and e, specifying the - interval [b:e:1]. The three-parameter constructor is similar, - with the third argument specifying a stride, which must be - one. - - - Declaring Multidimensional &interval;s - - - - - constructor - result - - - - - &dim; indicates the &interval;'s dimension. - T1, T2, … are - template parameters. - - - - - Interval<&dim;>() - creates an empty, uninitialized &interval;, to be assigned a value later. - - - Interval<&dim;>(const Pooma::NoInit& no) - creates an empty, uninitialized &interval;, to be assigned a value later. - - - Interval<&dim;>(const T1& t1) - creates a &interval; using the given &domain; object. - - - Interval<&dim;>(const T1& t1, const T2& t2) - creates a &interval; using the given &domain; objects. - - - Interval<&dim;>(const T1& t1, const T2& t2, const T3& t3) - creates a &interval; using the given &domain; objects. - - - Interval<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4) - creates a &interval; using the given &domain; objects. - - - Interval<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4, const T5& - t5) - creates a &interval; using the given &domain; objects. - - - Interval<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4, const T5& - t5, const T6& t6) - creates a &interval; using the given &domain; objects. - - - Interval<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4, const T5& - t5, const T6& t6, const T7& t7) - creates a &interval; using the given &domain; objects. - - - -

- - Constructors for multidimensional &interval;s closely - follow constructors for multidimensional &loc;s. See . - &dim; indicates the &interval;'s dimension. - The first two constructors both return empty, uninitialized - intervals. The seven other constructors create an &interval; - using &domain; objects. These &domain; objects, having types - T1, …, T7, can have any type - that can be converted into an integer, into a single-dimensional - &domain; object that can be converted into a single-dimensional - &interval;, or to a multidimensional &domain; object that itself - can be converted into an &interval;. The total dimensionality of - all the arguments' types should be at - most &dim;. One-dimensional &domain; objects - that can be converted into one-dimensional &interval;s include - &locone;s, &intervalone;s, and &rangeone;s with unit strides. If - the sum of the objects' dimensions is less - than &dim;, the intervals for the final - dimensions are unspecified. See the last paragraph of for an - analogous example. Note that the &intervalone; constructors - taking two and three parameters treat these arguments differently - than the multidimensional constructors do. -

- - -

- ⦥s - - A one-dimensional ⦥ generalizes an &interval; by - permitting a non-unit stride between integral members. A - range - is a set of integers in a mathematical interval [b,e] with a - stride s between them: {a, a+s, a+2s, …, b}. Ranges - are generalized to &dim; dimensions using the - direct product of one-dimensional ranges. - - - Declaring One-Dimensional ⦥s - - - - - constructor - result - - - - - T1, T2, and - T3 are template parameters. - - - - - - Range<1>() - creates an empty, uninitialized range. - - - Range<1>(const Pooma::NoInit& no) - creates an uninitialized &rangeone;, to be assigned a value later. - - - Range<1>(const T1& t1) - creates a &rangeone;. See the text for an explanation. - - - Range<1>(const T1& t1, const T2& t2) - creates a &rangeone; with an interval specified by the - integers converted from t1 and - t2. - - - Range<1>(const T1& t1, const T2& t2, const T3& t3) - creates a &rangeone; by converting the arguments to - integers i1, i2, and - i3 and then making a range [i1:i2:i3]. - - - -

- - &rangeone; constructors are the same as &intervalone; - constructors except they create ranges, not intervals. See . - The default constructor creates an empty, uninitialized range, - which should not be used before assigning it values. If the - one-parameter constructor's argument is a &domain; object, it must - be a one-dimensional &domain; object which is copied into a ⦥ - if possible. If the one-parameter constructor's argument is not - a &domain; object, it must be convertible to an - integer e and a range [0:e-1:1] starting - at zero is constructed. If two arguments are specified, they are - assumed to be convertible to integers b and - e, specifying the range [b:e:1]. The - three-parameter constructor is similar, with the third argument - specifying a stride. - - - Declaring Multidimensional ⦥s - - - - - constructor - result - - - - - &dim; indicates the ⦥'s dimension. - T1, T2, … are - template parameters. - - - - - Range<&dim;>() - creates an empty, uninitialized ⦥, to be assigned a value later. - - - Range<&dim;>(const Pooma::NoInit& no) - creates an empty, uninitialized ⦥, to be assigned a value later. - - - Range<&dim;>(const T1& t1) - creates a ⦥ using the given &domain; object. - - - Range<&dim;>(const T1& t1, const T2& t2) - creates a ⦥ using the given &domain; objects. - - - Range<&dim;>(const T1& t1, const T2& t2, const T3& t3) - creates a ⦥ using the given &domain; objects. - - - Range<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4) - creates a ⦥ using the given &domain; objects. - - - Range<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4, const T5& - t5) - creates a ⦥ using the given &domain; objects. - - - Range<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4, const T5& - t5, const T6& t6) - creates a ⦥ using the given &domain; objects. - - - Range<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4, const T5& - t5, const T6& t6, const T7& t7) - creates a ⦥ using the given &domain; objects. - - - -

- - Constructors for multidimensional ⦥s are the same as - multidimensional &interval; constructors except they create - ranges, not intervals. See . - &dim; indicates the ⦥'s dimension. The - first two constructors return empty, uninitialized ranges. - The seven other constructors create an ⦥ using &domain; - objects. These &domain; objects, having types T1, - …, T7, can have any type that can be - converted into an integer, into a single-dimensional &domain; - object that can be converted into a single-dimensional ⦥, - or to a multidimensional &domain; object that itself can be - converted into an ⦥. The total dimensionality of all the - arguments' types should be at most &dim;. - One-dimensional &domain; objects that can be converted into - one-dimensional ⦥s include &locone;s, &intervalone;s, and - &rangeone;s. If the sum of the objects' dimensions is less - than &dim;, the ranges for the final - dimensions are unspecified. See the last paragraph of for an - analogous example. Note that the &rangeone; constructors taking - two and three parameters treat these arguments differently than - the multidimensional constructors do. -

- - -

- &grid;s - - &loc;s, &interval;s, and ⦥s all have regularly spaced - integral values so they can be represented using domain triplets. - One-dimensional &grid; integral domains contain ascending or - descending sequences of integers, with no fixed stride. For - example, a &gridone; may represent {-13, 1, 4, 5, 34}. &gridone; - is generalized to multidimensional &grid;s using the direct - product of &gridone; &domain;s. - - &grid;s that can be represented using domain triplets can - be constructed using techniques similar to other &domain;s, but - irregularly spaced domains can be constructed using - &indirectionlistint;s. - - - Declaring One-Dimensional &grid;s - - - - - constructor - result - - - - - T1, T2, and - T3 are template parameters. - - - - - - Grid<1>() - creates an empty, uninitialized grid. - - - Grid<1>(const T1& t1) - creates a &gridone;. See the text for an explanation. - - - Grid<1>(const T1& t1, const T2& t2) - creates a &gridone; from the interval specified by the - integers converted from t1 and - t2. - - - Grid<1>(const T1& t1, const T2& t2, const T3& t3) - creates a &gridone; from the domain triplet specified - by the integers converted from t1, - t2, and t3. - - - -

- - To construct a &gridone; that can also be represented by a - domain triplet, use a &gridone; constructor similar to those for - &intervalone; and &rangeone;. See - and the text explanations following - or . - - &gridone;s with irregularly spaced points can be - constructed using &indirectionlistint;s. For example, - - IndirectionList<int> list(4); - list(0) = 2; - list(1) = 5; - list(2) = 6; - list(3) = 9; - Grid<1> g(list); - constructs an empty &indirectionlistint;, fills it - with ascending values, and then creates a &gridone; containing - {2, 5, 6, 9}. When creating a list, its size must be specified. - Subsequently, its values can be assigned. &indirectionlist;s can - also be initialized using one-dimensional &array;s: - - Array<1,int,Brick> a1(Interval<1>(0,3)); - a1(0) = 2; a1(1) = 5; a1(2) = 6; a1(3) = 9; - IndirectionList<int> il(a1); - Grid<1> g1(il); - The &array; stores the integral points to include - in the &gridone; and is used to create the &indirectionlistint;, - which itself is used to create the &gridone;. Since the points - are integers, the &array;'s type is ∫. Either a &brick; or - &compressiblebrick; &engine; should be used. - - - Declaring Multidimensional &grid;s - - - - - constructor - result - - - - - &dim; indicates the &grid;'s dimension. - T1, T2, … are - template parameters. - - - - - Grid<&dim;>() - creates an empty, uninitialized &grid;, to be assigned a value later. - - - Grid<&dim;>(const T1& t1) - creates a &grid; using the given &domain; object. - - - Grid<&dim;>(const T1& t1, const T2& t2) - creates a &grid; using the given &domain; objects. - - - Grid<&dim;>(const T1& t1, const T2& t2, const T3& t3) - creates a &grid; using the given &domain; objects. - - - Grid<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4) - creates a &grid; using the given &domain; objects. - - - Grid<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4, const T5& - t5) - creates a &grid; using the given &domain; objects. - - - Grid<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4, const T5& - t5, const T6& t6) - creates a &grid; using the given &domain; objects. - - - Grid<&dim;>(const T1& t1, const - T2& t2, const T3& t3, const T4& t4, const T5& - t5, const T6& t6, const T7& t7) - creates a &grid; using the given &domain; objects. - - - -

- - Constructors for multidimensional &grid;s are the same as - multidimensional &interval; constructors except they create - &grid;s, not intervals. See . - &dim; indicates the &grid;'s dimension. The - first constructor returns empty, uninitialized grids. The seven - other constructors create an &grid; using &domain; objects. These - &domain; objects, having types T1, …, - T7, can have any type that can be converted into an - integer, into a single-dimensional &domain; object that can be - converted into a single-dimensional &grid;, or to a - multidimensional &domain; object that itself can be converted into - an &grid;. The total dimensionality of all the arguments' types - should be at most &dim;. One-dimensional - &domain; objects that can be converted into one-dimensional &grid;s - include &locone;s, &intervalone;s, &rangeone;s, and &gridone;s. - If the sum of the objects' dimensions is less - than &dim;, the grids for the final - dimensions are unspecified. See the last paragraph of for an - analogous example. Note that the &gridone; constructors taking - two and three parameters treat these arguments differently than - the multidimensional constructors do. -

- - -

- Declaring and Using &array;s - - A &pooma; &array; maps indices from its &domain; to values. - In this section, we describe first describe how to declare - &array;s. Then, we explain how to access individual values stored - or computed by an &array; and their copy semantics. - - &array; values need not just be stored values, as &c; arrays - have. They can also be computed using its engine. We defer - discussion of computing values to the next chapter discussing - engines (). To avoid being verbose - in this chapter, when we discuss stored values, the values might - instead be computed. - - Declaring an &array; requires four arguments: the domain's - dimensionality, the type of values stored or computed, a - specification how the values are stored, and a &domain;. The - first three arguments are template parameters since few scientific - programs (and no &pooma; programs) need to change these values - while a program executes. For example, an &array; cannot change - the type of the elements it stores. Alternatively, an &array;'s - values can be copied into another &array; having the desired type. - Although scientific programs do not frequently change an array's - domain, they do frequently request a subset of the array's values, - i.e., a view. The - subset is specified via a &domain; so it is a run-time value. - Views are presented in . - - An &array;'s first template parameter specifies its - dimensionality. This positive - integer &dim; specifies its rank. This is - the same value as its domain's dimensionality. Theoretically, an - &array; can have any positive integer, but the &pooma; code - currently supports &dim; at most seven. For - almost all scientific codes, a dimension of three or four is - sufficient, but the code can be extended to support higher - dimensions. - - An &array;'s second template parameter specifies the type of - its stored values. Common value types include ∫, &double;, - &complex;, and &vector;, but any type is permissible. For - example, an &array;'s values might be matrices or even other - &array;s. - - An &array;'s third parameter specifies how its data is - stored by an &engine; and its values accessed. The argument is a - tag indicating a particular type of &engine;. Permissible tags - include &brick;, &compressiblebrick;, and - ConstantFunction. The &brick; tag indicates all - &array; values will be explicitly stored, just as built-in &c; - arrays do. If the &array;s frequently stores exactly the same - value in every position, a &compressiblebrick; &engine;, which - reduces its space requirements to a constant whenever all its - values are the same, is appropriate. A - ConstantFunction &engine; returns the same value for - all indices. - - Even though every &array; container has an engine to store - its values and permit access to individual values, an &array; is - conceptually separated from engines. An engine's role is - low-level, storing values and permitting access to individual - values. As we indicated above, the storage can be optimized to - fit specific situations such as few nonzero values and computing - values using a function applied to another engine's values. An - &array;'s role is high-level, supporting access to groups of - values. They handle memory allocation and deallocation. &array;s - can be used in data-parallel expressions, e.g., adding all the - values in one &array; to all the values in another. (See for more information.) Subsets of - &array; values, frequently used in data-parallel statements, can - be obtained. (See for more - information.) Even though engines and &array;s are conceptually - separate, higher-level &array;s provide access to lower-level - &engine;s. Users usually have an &array; create its &engine;, - rarely explicitly creating &engine;s themselves. Also, &array;s - provide access to individual values. In short, &pooma; users use - &array;s, only dealing with how they are implemented (engines) - upon declaration. For more description of &engine;s, see . - - An &array;'s one constructor argument is its domain. The - domain specifies its extent and simultaneously how many values it - can return. All the provided &domain; objects are combined to - yield an Interval<&dim;>, where &dim; matches - the &array;'s first template parameter. Since an &interval; - domain with its unit strides is used, there are no unaccessed - gaps within the domain, wasting storage space. To - use other domains to access an &array;, first create it using an - &interval; domain and then take a view of it, as described in - . As we mentioned above, the current - &pooma; code supports up to seven dimensions so at most seven - &domain; objects can be provided. If more dimensions are - required, the &pooma; code can be extended to the desired number - of dimensions. - - - Declaring &array;s - - - - - &array; declaration - result - - - - - Template parameters &dim;, - T, and E indicates the - &array;'s dimension, value type, and &engine; type, - respectively, as do D1, - T1, and E1. - DT1, …, DT7 - indicate domain types. - - - - - Array<&dim;,T,E>() - creates an empty, uninitialized &array;, which must be - initialize()d before use. - - - - Array<&dim;,T,E>(const Array<D1,T1,E1>& a) - creates an &array; by copying another one. - - - Array<&dim;,T,E>(const - Array<D1,T1,E1>& a, const Dom& d) - creates an &array; by copying another one but using the - specified domain. - - - Array<&dim;,T,E>(const DT1& t1) - creates an &array; using the given &domain; object. - - - Array<&dim;,T,E>(const DT1& t1, const DT2& t2) - creates a &array; using the given &domain; objects. - - - Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3) - creates a &array; using the given &domain; objects. - - - Array<&dim;,T,E>(const DT1& t1, const - DT2& t2, const DT3& t3, const DT4& t4) - creates a &array; using the given &domain; objects. - - - Array<&dim;,T,E>(const DT1& t1, const - DT2& t2, const DT3& t3, const DT4& t4, const DT5& - t5) - creates a &array; using the given &domain; objects. - - - Array<&dim;,T,E>(const DT1& t1, const - DT2& t2, const DT3& t3, const DT4& t4, const DT5& - t5, const DT6& t6) - creates a &array; using the given &domain; objects. - - - Array<&dim;,T,E>(const DT1& t1, const - DT2& t2, const DT3& t3, const DT4& t4, const DT5& - t5, const DT6& t6, const DT7& t7) - creates a &array; using the given &domain; objects. - - - Array<&dim;,T,E>(const DT1& t1, - const ModelElement<T>& model) - creates an &array; using the given &domain; object and - then initializes all entries using model. - - - Array<&dim;,T,E>(const DT1& t1, const DT2& t2, - const ModelElement<T>& model) - creates a &array; using the given &domain; objects and - then initializes all entries using model. - - - Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, - const ModelElement<T>& model) - creates a &array; using the given &domain; objects and - then initializes all entries using model. - - - Array<&dim;,T,E>(const DT1& t1, const - DT2& t2, const DT3& t3, const DT4& t4, - const ModelElement<T>& model) - creates a &array; using the given &domain; objects and - then initializes all entries using model. - - - Array<&dim;,T,E>(const DT1& t1, const - DT2& t2, const DT3& t3, const DT4& t4, const DT5& - t5, - const ModelElement<T>& model) - creates a &array; using the given &domain; objects and - then initializes all entries using model. - - - Array<&dim;,T,E>(const DT1& t1, const - DT2& t2, const DT3& t3, const DT4& t4, const DT5& - t5, const DT6& t6, - const ModelElement<T>& model) - creates a &array; using the given &domain; objects and - then initializes all entries using model. - - - Array<&dim;,T,E>(const DT1& t1, const - DT2& t2, const DT3& t3, const DT4& t4, const DT5& - t5, const DT6& t6, const DT7& t7, - const ModelElement<T>& model) - creates a &array; using the given &domain; objects and - then initializes all entries using model. - - - -

- - &array; constructors are listed in . An &array;s' three - template parameters for dimensionality, value type, and engine - type are abbreviated D, T, - and E. D1, - T1, and E1 are analogous. - Template parameters for &domain; types - - HERE - - list ?all? possible declarations - perhaps this involves copying all possible domain declarations - - table of initialize() versions - - use: (element-wise only for now) - how to assign and access particular elements - use a single set of parentheses, not multiple brackets - - semantics of copies and references - based on engines - - HERE -

- - -

- An &array; Implementation of &doof2d; - - mostly copy pp.35-38 from tutorial chapter - HERE -

- - -

- Implementing &array;s - - What to write? - - Do I need to describe the public interface of Domains? Do I need - to describe how a programmer would implement a new type of domain? - Probably not. - - HERE -

- - - - - - Engines ! ! HERE &data-parallel-chapter; --- 350,365 ---- &tutorial-chapter; &concepts-chapter; ! &arrays-chapter; Engines ! UNFINISHED + &data-parallel-chapter; *************** HERE *** 1584,1590 **** Be sure to list the various arithmetic operations on domains that can be used. This was deferred from the &array; and domain ! chapter. --- 368,374 ---- Be sure to list the various arithmetic operations on domains that can be used. This was deferred from the &array; and domain ! chapter. Explain &array;'s comp function. *************** HERE *** 1592,1605 **** Writing Sequential Programs ! FIXME: Explain the chapter's purpose. ! HERE ! FIXME: Explain the format of each section. ! HERE ! FIXME: Explain the order of the sections. ! HERE Proposed order. Basically follow the order in the proposed reference section. --- 376,386 ---- Writing Sequential Programs ! FIXME: Explain the chapter's purpose. ! FIXME: Explain the format of each section. ! FIXME: Explain the order of the sections. Proposed order. Basically follow the order in the proposed reference section. *************** HERE *** 1772,1778 **** Beginning and Ending &pooma; Programs Every &pooma; program must begin with a call to ! initialize and end with a call to finalize. These functions respectively prepare and shut down &pooma;'s run-time structures. --- 553,559 ---- Beginning and Ending &pooma; Programs Every &pooma; program must begin with a call to ! initialize and end with a call to finalize. These functions respectively prepare and shut down &pooma;'s run-time structures. *************** HERE *** 1822,1828 **** Description Before its use, the &poomatoolkit; must be initialized by a ! call to initialize. This usually occurs in the main function. The first form removes and processes any &pooma;-specific arguments from the command-line arguments argv and --- 603,609 ---- Description Before its use, the &poomatoolkit; must be initialized by a ! call to initialize. This usually occurs in the main function. The first form removes and processes any &pooma;-specific arguments from the command-line arguments argv and *************** HERE *** 1844,1850 **** architecture-specific initialization. The function always returns &true;. ! initialize's alternative form assumes the &pooma;-specific and architecture-specific command-line arguments have already been removed from argv and argc and stored in --- 625,631 ---- architecture-specific initialization. The function always returns &true;. ! initialize's alternative form assumes the &pooma;-specific and architecture-specific command-line arguments have already been removed from argv and argc and stored in *************** HERE *** 1872,1878 **** Example Program Since every &pooma; program must call ! initialize and finalize, the simplest &pooma; program also must call them. This program also illustrates their usual use. --- 653,659 ---- Example Program Since every &pooma; program must call ! initialize and finalize, the simplest &pooma; program also must call them. This program also illustrates their usual use. *************** HERE *** 1908,1914 **** &inform; pwarn ! HERE output stream used to print informative messages to the user while the program executes. The stream accepts a superset of standard output operations. --- 689,695 ---- &inform; pwarn ! FIXME: output stream used to print informative messages to the user while the program executes. The stream accepts a superset of standard output operations. *************** HERE *** 1918,1925 ****

- -

&pooma; Command-line Options --- 699,704 ---- *************** UNFINISHED *** 1944,1961 **** executes. ! FIXME: Be sure to list default values. ! ! - -

- -

--- 723,736 ---- executes. ! FIXME: Be sure to list default values. ! !

From oldham at codesourcery.com Tue Jan 22 15:55:42 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 22 Jan 2002 07:55:42 -0800 Subject: Manual Patch: DynamicArrays and Part of Engines Message-ID: <20020122075542.A32076@codesourcery.com> This patch mainly adds a description of DynamicArrays, an unfinished section on simple Domain accessors, and an unfinished chapter on Engines. (Mark, I was working on the Engines chapter, but the Dynamic Engine led me back to the Arrays chapter. Sorry.) 2002-Jan-22 Jeffrey D. Oldham * arrays.xml: Add (unfinished) Domain use section, making Domain declarations section a subsection of 'Domains' section. Add DynamicArray section. * concepts.xml: s/multi-dimensional/multidimensional/g * glossary.xml (function object): New definition. s/multi-dimensional/multidimensional/g * manual.xml: Add unfinished Engines chapter, explaining the concepts, a table of Engines, and descriptions of Brick and CompressibleBrick. s/initialize/initialize/ as appropriate. * tutorial.xml: s/multi-dimensional/multidimensional/g Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: arrays.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/arrays.xml,v retrieving revision 1.1 diff -c -p -r1.1 arrays.xml *** arrays.xml 2002/01/16 00:50:27 1.1 --- arrays.xml 2002/01/22 15:37:14 *************** *** 233,968 **** scientific computations use one, two, or three dimensions, this is usually sufficient. If more dimensions are needed, they can be added to the source code. -

- -

- Declaring &domain;s ! Since &domain;s are mainly used to declare container ! domains, we focus on declaring &domain;s. Arithmetic operations ! with &domain;s are described in . ! ! All &domain; declarations require a dimension template ! parameter &dim;. This positive integer ! specifies the number of dimensions, i.e., rank, of the &domain; and ! determines the length of the tuples for points in the &domain;. For ! example, a three-dimensional &domain; contains ordered triples, ! while a one-dimensional &domain; contains singletons, or just ! integers. Multidimensional &domain;s are just the direct products ! of one-dimensional &domain;s so the techniques for declaring ! one-dimensional &domain;s carry over to multi-dimensional ! ones. ! ! To declare a &domain;, one must include the ! Pooma/Domains.h header ! file. However, most &pooma; programs declare &domain;s to use them ! when constructing containers. The container header files ! automatically include Pooma/Domains.h so no explicit ! inclusion is usually necessary. ! !

! &loc;s ! ! A Loc<&dim;> is a &domain; with just a single ! &dim;-dimensional point. Although it is ! infrequently used as a container's domain, it is used to refer to ! a single point within another domain. Its beginning and ending ! points are the same, and its stride is one. One-dimensional ! &loc;s and integers are frequently interchanged. ! ! Declaring One-Dimensional &loc;s ! ! ! ! ! constructor ! result ! ! ! ! ! &domaintemplate;1, &domaintemplate;2, and ! &domaintemplate;3 are template parameters. ! ! ! ! ! ! Loc<1>() ! points to zero. ! ! ! Loc<1>(const Pooma::NoInit& no) ! creates an uninitialized &locone;, to be assigned a value later. ! ! ! Loc<1>(const &domaintemplate;1& t1) ! creates a &locone; with the integer converted from t1. ! ! ! Loc<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a &locone; with the integer converted from ! t1. t2 must equal ! t1. ! ! ! Loc<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates a &locone; with the integer converted from ! t1. t2 must equal ! t1, and t3 is ! ignored. ! ! ! !

! ! Constructors for one-dimensional &loc;s appear in . ! The empty constructor yields the zero point. The constructor ! taking a Pooma::Init object does not initialize the ! resulting &loc; to any particular value. Presumably, the value ! will be assigned later. For small &domain;s such as &loc;s, the ! time savings from not initializing is small, but the ! functionality is still available. The constructor taking one ! argument with type &domaintemplate;1 converts this argument to ! an integer to specify the point. The template ! type &domaintemplate;1 may be any type that can be converted ! to an integer, e.g., &bool;, &char;, ∫, or &double;. The ! constructors taking two and three arguments of templatized types ! facilitate converting an &interval; and a ⦥ into a &loc;. ! Since a &loc; represents a single point, the &interval;'s or ! ⦥'s first two arguments must be equal. The stride is ! ignored. Again, the templatized types may be any type that can ! be converted into an integer. ! ! ! Declaring Multidimensional &loc;s ! ! ! ! ! constructor ! result ! ! ! ! ! &dim; indicates the &loc;'s dimension. ! &domaintemplate;1, &domaintemplate;2, … are ! template parameters. ! ! ! ! ! Loc<&dim;>() ! points to zero. ! ! ! Loc<&dim;>(const Pooma::NoInit& no) ! creates an uninitialized &loc;, to be assigned a value later. ! ! ! Loc<&dim;>(const &domaintemplate;1& t1) ! creates a &loc; using the given &domain; object. ! ! ! Loc<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a &loc; using the given &domain; objects. ! ! ! Loc<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates a &loc; using the given &domain; objects. ! ! ! Loc<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) ! creates a &loc; using the given &domain; objects. ! ! ! Loc<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5) ! creates a &loc; using the given &domain; objects. ! ! ! Loc<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6) ! creates a &loc; using the given &domain; objects. ! ! ! Loc<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) ! creates a &loc; using the given &domain; objects. ! ! ! !

! ! Constructors for multidimensional &loc;s appear in . ! &dim; indicates the &loc;'s dimension. The ! first two constructors are similar to &locone;'s first two ! constructors, returning a representation of the zero point and ! returning an uninitialized point. The seven other constructors ! create a &loc; using other &domain; objects. These &domain; objects, ! having types &domaintemplate;1, …, &domaintemplate;7, can have ! any type that can be converted into an integer, to a &locone;, or ! to a multidimensional &domain; object that itself can be converted ! into a &loc;. The total dimensionality of all the arguments' ! types should be at most &dim;. For example, ! Loc<5>(Range<1>(2,2,2), Loc<2>(2,3), ! Interval<1>(4,4)) creates a five-dimensional &loc; ! [2,2,3,4,1] using a one-dimensional ⦥, a two-dimensional ! &loc;, and a one-dimensional &interval;. The final fifth ! dimension has an unspecified value, in this case 1. The ! one-dimensional ⦥ is converted into the single integer two; ! its beginning and ending points must be the same. The ! two-dimensional &loc; contributes values for the next two ! dimensions, while the &interval; contributes its beginning point, ! which must be the same as its ending point. Note that the ! &locone; constructors taking two and three parameters ignore ! their second and third arguments, but this is not true for the ! multidimensional constructors.

- -

- &interval;s - - A one-dimensional &interval; represents a set of integers - within a mathematical interval. - Multidimensional &interval;s represent their multidimensional - generalization, i.e., the direct product of one-dimensional - intervals. &interval;s are arguably the most commonly used - &pooma; &domain;. A one-dimensional &interval; has integral - beginning and ending points and a unit stride. ! ! Declaring One-Dimensional &interval;s ! ! ! ! ! constructor ! result ! ! ! ! ! &domaintemplate;1, &domaintemplate;2, and ! &domaintemplate;3 are template parameters. ! ! ! ! ! ! Interval<1>() ! creates an empty, uninitialized interval. ! ! ! Interval<1>(const Pooma::NoInit& no) ! creates an uninitialized &intervalone;, to be assigned a value later. ! ! ! Interval<1>(const &domaintemplate;1& t1) ! creates a &intervalone;. See the text for an explanation. ! ! ! Interval<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a &intervalone; with the integers converted from ! t1 and t2. ! ! ! Interval<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates a &intervalone; with the integers converted from ! t1 and t2. ! t3 must equal 1. ! ! ! !

! ! &intervalone; constructors are patterned on &locone; ! constructors except that &intervalone;s can have differing ! beginning and ending points. See . ! The default constructor creates an empty, uninitialized interval, ! which should not be used before assigning it values. If the ! one-parameter constructor's argument is a &domain; object, it must ! be a one-dimensional &domain; object which is copied into an ! &interval; if possible; for example, it must have unit stride. ! If the one-parameter constructor's argument is not a &domain; ! object, it must be convertible to an ! integer e and an interval [0:e-1:1] ! starting at zero is constructed. If two arguments are specified, ! they are assumed to be convertible to integers ! b and e, specifying the ! interval [b:e:1]. The three-parameter constructor is similar, ! with the third argument specifying a stride, which must be ! one. ! ! ! Declaring Multidimensional &interval;s ! ! ! ! ! constructor ! result ! ! ! ! ! &dim; indicates the &interval;'s dimension. ! &domaintemplate;1, &domaintemplate;2, … are ! template parameters. ! ! ! ! ! Interval<&dim;>() ! creates an empty, uninitialized &interval;, to be assigned a value later. ! ! ! Interval<&dim;>(const Pooma::NoInit& no) ! creates an empty, uninitialized &interval;, to be assigned a value later. ! ! ! Interval<&dim;>(const &domaintemplate;1& t1) ! creates a &interval; using the given &domain; object. ! ! ! Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a &interval; using the given &domain; objects. ! ! ! Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates a &interval; using the given &domain; objects. ! ! ! Interval<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) ! creates a &interval; using the given &domain; objects. ! ! ! Interval<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5) ! creates a &interval; using the given &domain; objects. ! ! ! Interval<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6) ! creates a &interval; using the given &domain; objects. ! ! ! Interval<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) ! creates a &interval; using the given &domain; objects. ! ! ! !

! ! Constructors for multidimensional &interval;s closely ! follow constructors for multidimensional &loc;s. See . ! &dim; indicates the &interval;'s ! dimension. The first two constructors both return empty, ! uninitialized intervals. The seven other constructors create an ! &interval; using &domain; objects. These &domain; objects, ! having types &domaintemplate;1, …, ! &domaintemplate;7, can have any type that can be ! converted into an integer, into a single-dimensional &domain; ! object that can be converted into a single-dimensional ! &interval;, or to a multidimensional &domain; object that itself ! can be converted into an &interval;. The total dimensionality of ! all the arguments' types should be at ! most &dim;. One-dimensional &domain; ! objects that can be converted into one-dimensional &interval;s ! include &locone;s, &intervalone;s, and &rangeone;s with unit ! strides. If the sum of the objects' dimensions is less ! than &dim;, the intervals for the final ! dimensions are unspecified. See the last paragraph of for an ! analogous example. Note that the &intervalone; constructors ! taking two and three parameters treat these arguments differently ! than the multidimensional constructors do. !

! ! !

! ⦥s ! ! A one-dimensional ⦥ generalizes an &interval; by ! permitting a non-unit stride between integral members. A ! range ! is a set of integers in a mathematical interval [b,e] with a ! stride s between them: {a, a+s, a+2s, …, b}. Ranges ! are generalized to &dim; dimensions using the ! direct product of one-dimensional ranges. ! ! ! Declaring One-Dimensional ⦥s ! ! ! ! ! constructor ! result ! ! ! ! ! &domaintemplate;1, &domaintemplate;2, and ! &domaintemplate;3 are template parameters. ! ! ! ! ! ! Range<1>() ! creates an empty, uninitialized range. ! ! ! Range<1>(const Pooma::NoInit& no) ! creates an uninitialized &rangeone;, to be assigned a value later. ! ! ! Range<1>(const &domaintemplate;1& t1) ! creates a &rangeone;. See the text for an explanation. ! ! ! Range<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a &rangeone; with an interval specified by the ! integers converted from t1 and ! t2. ! ! ! Range<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates a &rangeone; by converting the arguments to ! integers i1, i2, and ! i3 and then making a range [i1:i2:i3]. ! ! ! !

! &rangeone; constructors are the same as &intervalone; ! constructors except they create ranges, not intervals. See . ! The default constructor creates an empty, uninitialized range, ! which should not be used before assigning it values. If the ! one-parameter constructor's argument is a &domain; object, it must ! be a one-dimensional &domain; object which is copied into a ⦥ ! if possible. If the one-parameter constructor's argument is not ! a &domain; object, it must be convertible to an ! integer e and a range [0:e-1:1] starting ! at zero is constructed. If two arguments are specified, they are ! assumed to be convertible to integers b and ! e, specifying the range [b:e:1]. The ! three-parameter constructor is similar, with the third argument ! specifying a stride. ! Declaring Multidimensional ⦥s ! constructor result ! &dim; indicates the ⦥'s dimension. ! &domaintemplate;1, &domaintemplate;2, … are ! template parameters. ! ! Range<&dim;>() ! creates an empty, uninitialized ⦥, to be assigned a value later. ! Range<&dim;>(const Pooma::NoInit& no) ! creates an empty, uninitialized ⦥, to be assigned a value later. ! Range<&dim;>(const &domaintemplate;1& t1) ! creates a ⦥ using the given &domain; object. ! Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a ⦥ using the given &domain; objects. ! ! Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates a ⦥ using the given &domain; objects. ! Range<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) ! creates a ⦥ using the given &domain; objects. ! Range<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5) ! creates a ⦥ using the given &domain; objects. ! Range<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6) ! creates a ⦥ using the given &domain; objects. ! Range<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) ! creates a ⦥ using the given &domain; objects. - - -

- - Constructors for multidimensional ⦥s are the same as - multidimensional &interval; constructors except they create - ranges, not intervals. See . - &dim; indicates the ⦥'s dimension. The - first two constructors return empty, uninitialized ranges. - The seven other constructors create an ⦥ using &domain; - objects. These &domain; objects, having types &domaintemplate;1, - …, &domaintemplate;7, can have any type that can be - converted into an integer, into a single-dimensional &domain; - object that can be converted into a single-dimensional ⦥, - or to a multidimensional &domain; object that itself can be - converted into an ⦥. The total dimensionality of all the - arguments' types should be at most &dim;. - One-dimensional &domain; objects that can be converted into - one-dimensional ⦥s include &locone;s, &intervalone;s, and - &rangeone;s. If the sum of the objects' dimensions is less - than &dim;, the ranges for the final - dimensions are unspecified. See the last paragraph of for an - analogous example. Note that the &rangeone; constructors taking - two and three parameters treat these arguments differently than - the multidimensional constructors do. -

- - -

- &grid;s - - &loc;s, &interval;s, and ⦥s all have regularly spaced - integral values so they can be represented using domain triplets. - One-dimensional &grid; integral domains contain ascending or - descending sequences of integers, with no fixed stride. For - example, a &gridone; may represent {-13, 1, 4, 5, 34}. &gridone; - is generalized to multidimensional &grid;s using the direct - product of &gridone; &domain;s. - - &grid;s that can be represented using domain triplets can - be constructed using techniques similar to other &domain;s, but - irregularly spaced domains can be constructed using - &indirectionlistint;s. - - - Declaring One-Dimensional &grid;s - - - ! constructor ! result - - ! &domaintemplate;1, &domaintemplate;2, and ! &domaintemplate;3 are template parameters. ! - - - - Grid<1>() - creates an empty, uninitialized grid. - - - Grid<1>(const &domaintemplate;1& t1) - creates a &gridone;. See the text for an explanation. - ! Grid<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a &gridone; from the interval specified by the ! integers converted from t1 and ! t2. - - Grid<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) - creates a &gridone; from the domain triplet specified - by the integers converted from t1, - t2, and t3. -

! To construct a &gridone; that can also be represented by a ! domain triplet, use a &gridone; constructor similar to those for ! &intervalone; and &rangeone;. See ! and the text explanations following ! or . ! &gridone;s with irregularly spaced points can be ! constructed using &indirectionlistint;s. For example, ! ! IndirectionList<int> list(4); ! list(0) = 2; ! list(1) = 5; ! list(2) = 6; ! list(3) = 9; ! Grid<1> g(list); ! constructs an empty &indirectionlistint;, fills it ! with ascending values, and then creates a &gridone; containing ! {2, 5, 6, 9}. When creating a list, its size must be specified. ! Subsequently, its values can be assigned. &indirectionlist;s can ! also be initialized using one-dimensional &array;s: ! ! Array<1,int,Brick> a1(Interval<1>(0,3)); ! a1(0) = 2; a1(1) = 5; a1(2) = 6; a1(3) = 9; ! IndirectionList<int> il(a1); ! Grid<1> g1(il); ! The &array; stores the integral points to include ! in the &gridone; and is used to create the &indirectionlistint;, ! which itself is used to create the &gridone;. Since the points ! are integers, the &array;'s type is ∫. Either a &brick; or ! &compressiblebrick; &engine; should be used. ! ! ! Declaring Multidimensional &grid;s ! ! ! ! ! constructor ! result ! ! ! ! ! &dim; indicates the &grid;'s ! dimension. &domaintemplate;1, ! &domaintemplate;2, … are template ! parameters. ! ! ! ! ! Grid<&dim;>() ! creates an empty, uninitialized &grid;, to be assigned a value later. ! ! ! Grid<&dim;>(const &domaintemplate;1& t1) ! creates a &grid; using the given &domain; object. ! ! ! Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a &grid; using the given &domain; objects. ! ! ! Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates a &grid; using the given &domain; objects. ! ! ! Grid<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) ! creates a &grid; using the given &domain; objects. ! ! ! Grid<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5) ! creates a &grid; using the given &domain; objects. ! ! ! Grid<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6) ! creates a &grid; using the given &domain; objects. ! ! ! Grid<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) ! creates a &grid; using the given &domain; objects. ! ! ! !

! ! Constructors for multidimensional &grid;s are the same as ! multidimensional &interval; constructors except they create ! &grid;s, not intervals. See . ! &dim; indicates the &grid;'s dimension. The ! first constructor returns empty, uninitialized grids. The seven ! other constructors create an &grid; using &domain; objects. These ! &domain; objects, having types &domaintemplate;1, …, ! &domaintemplate;7, can have any type that can be converted into an ! integer, into a single-dimensional &domain; object that can be ! converted into a single-dimensional &grid;, or to a ! multidimensional &domain; object that itself can be converted into ! an &grid;. The total dimensionality of all the arguments' types ! should be at most &dim;. One-dimensional ! &domain; objects that can be converted into one-dimensional &grid;s ! include &locone;s, &intervalone;s, &rangeone;s, and &gridone;s. ! If the sum of the objects' dimensions is less ! than &dim;, the grids for the final ! dimensions are unspecified. See the last paragraph of for an ! analogous example. Note that the &gridone; constructors taking ! two and three parameters treat these arguments differently than ! the multidimensional constructors do. !

Declaring &array;s A &pooma; &array; maps indices from its &domain; to values. ! In this section, we describe first describe how to declare ! &array;s. In the next section, we explain how to access ! individual values stored within an &array; and &array; copy ! semantics. &array; values need not just be stored values, as &c; arrays have. They can also be computed using its engine. We defer --- 233,1063 ---- scientific computations use one, two, or three dimensions, this is usually sufficient. If more dimensions are needed, they can be added to the source code. !

! Declaring &domain;s ! Since &domain;s are mainly used to declare container ! domains, we focus on declaring &domain;s. We describe a few ! &domain; operations but most, including arithmetic operations with ! &domain;s, are described in . ! ! All &domain; declarations require a dimension template ! parameter &dim;. This positive integer ! specifies the number of dimensions, i.e., rank, of the &domain; and ! determines the length of the tuples for points in the &domain;. For ! example, a three-dimensional &domain; contains ordered triples, ! while a one-dimensional &domain; contains singletons, or just ! integers. Multidimensional &domain;s are just the direct products ! of one-dimensional &domain;s so the techniques for declaring ! one-dimensional &domain;s carry over to multidimensional ! ones. ! ! To declare a &domain;, one must include the ! Pooma/Domains.h header ! file. However, most &pooma; programs declare &domain;s to use them ! when constructing containers. The container header files ! automatically include Pooma/Domains.h so no explicit ! inclusion is usually necessary. ! ! !

! &loc;s ! ! A Loc<&dim;> is a &domain; with just a single ! &dim;-dimensional point. Although it is ! infrequently used as a container's domain, it is used to refer to ! a single point within another domain. Its beginning and ending ! points are the same, and its stride is one. One-dimensional ! &loc;s and integers are frequently interchanged. ! ! ! Declaring One-Dimensional &loc;s ! ! ! ! ! constructor ! result ! ! ! ! ! &domaintemplate;1, &domaintemplate;2, and ! &domaintemplate;3 are template parameters. ! ! ! ! ! ! Loc<1>() ! points to zero. ! ! ! Loc<1>(const Pooma::NoInit& no) ! creates an uninitialized &locone;, to be assigned a value later. ! ! ! Loc<1>(const &domaintemplate;1& t1) ! creates a &locone; with the integer converted from t1. ! ! ! Loc<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a &locone; with the integer converted from ! t1. t2 must equal ! t1. ! ! ! Loc<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates a &locone; with the integer converted from ! t1. t2 must equal ! t1, and t3 is ! ignored. ! ! ! !

! ! !

! &interval;s ! ! A one-dimensional &interval; represents a set of integers ! within a mathematical interval. ! Multidimensional &interval;s represent their multidimensional ! generalization, i.e., the direct product of one-dimensional ! intervals. &interval;s are arguably the most commonly used ! &pooma; &domain;. A one-dimensional &interval; has integral ! beginning and ending points and a unit stride. ! ! ! Declaring One-Dimensional &interval;s ! ! ! ! ! constructor ! result ! ! ! ! ! &domaintemplate;1, &domaintemplate;2, and ! &domaintemplate;3 are template parameters. ! ! ! ! ! ! Interval<1>() ! creates an empty, uninitialized interval. ! ! ! Interval<1>(const Pooma::NoInit& no) ! creates an uninitialized &intervalone;, to be assigned a value later. ! ! ! Interval<1>(const &domaintemplate;1& t1) ! creates a &intervalone;. See the text for an explanation. ! ! ! Interval<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a &intervalone; with the integers converted from ! t1 and t2. ! ! ! Interval<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates a &intervalone; with the integers converted from ! t1 and t2. ! t3 must equal 1. ! ! ! !

! ! !

! ! &rangeone; constructors are the same as &intervalone; ! constructors except they create ranges, not intervals. See . ! The default constructor creates an empty, uninitialized range, ! which should not be used before assigning it values. If the ! one-parameter constructor's argument is a &domain; object, it must ! be a one-dimensional &domain; object which is copied into a ⦥ ! if possible. If the one-parameter constructor's argument is not ! a &domain; object, it must be convertible to an ! integer e and a range [0:e-1:1] starting ! at zero is constructed. If two arguments are specified, they are ! assumed to be convertible to integers b and ! e, specifying the range [b:e:1]. The ! three-parameter constructor is similar, with the third argument ! specifying a stride. ! ! ! Declaring Multidimensional ⦥s ! ! ! ! ! constructor ! result ! ! ! ! ! &dim; indicates the ⦥'s dimension. ! &domaintemplate;1, &domaintemplate;2, … are ! template parameters. ! ! ! ! ! Range<&dim;>() ! creates an empty, uninitialized ⦥, to be assigned a value later. ! ! ! Range<&dim;>(const Pooma::NoInit& no) ! creates an empty, uninitialized ⦥, to be assigned a value later. ! ! ! Range<&dim;>(const &domaintemplate;1& t1) ! creates a ⦥ using the given &domain; object. ! ! ! Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a ⦥ using the given &domain; objects. ! ! ! Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates a ⦥ using the given &domain; objects. ! ! ! Range<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) ! creates a ⦥ using the given &domain; objects. ! ! ! Range<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5) ! creates a ⦥ using the given &domain; objects. ! ! ! Range<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6) ! creates a ⦥ using the given &domain; objects. ! ! ! Range<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) ! creates a ⦥ using the given &domain; objects. ! ! ! !

! ! Constructors for multidimensional ⦥s are the same as ! multidimensional &interval; constructors except they create ! ranges, not intervals. See . ! &dim; indicates the ⦥'s dimension. The ! first two constructors return empty, uninitialized ranges. ! The seven other constructors create an ⦥ using &domain; ! objects. These &domain; objects, having types &domaintemplate;1, ! …, &domaintemplate;7, can have any type that can be ! converted into an integer, into a single-dimensional &domain; ! object that can be converted into a single-dimensional ⦥, ! or to a multidimensional &domain; object that itself can be ! converted into an ⦥. The total dimensionality of all the ! arguments' types should be at most &dim;. ! One-dimensional &domain; objects that can be converted into ! one-dimensional ⦥s include &locone;s, &intervalone;s, and ! &rangeone;s. If the sum of the objects' dimensions is less ! than &dim;, the ranges for the final ! dimensions are unspecified. See the last paragraph of for an ! analogous example. Note that the &rangeone; constructors taking ! two and three parameters treat these arguments differently than ! the multidimensional constructors do. !

! ! !

! &grid;s ! ! &loc;s, &interval;s, and ⦥s all have regularly spaced ! integral values so they can be represented using domain triplets. ! One-dimensional &grid; integral domains contain ascending or ! descending sequences of integers, with no fixed stride. For ! example, a &gridone; may represent {-13, 1, 4, 5, 34}. &gridone; ! is generalized to multidimensional &grid;s using the direct ! product of &gridone; &domain;s. ! ! &grid;s that can be represented using domain triplets can ! be constructed using techniques similar to other &domain;s, but ! irregularly spaced domains can be constructed using ! &indirectionlistint;s. ! ! ! Declaring One-Dimensional &grid;s ! ! ! ! ! constructor ! result ! ! ! ! ! &domaintemplate;1, &domaintemplate;2, and ! &domaintemplate;3 are template parameters. ! ! ! ! ! ! Grid<1>() ! creates an empty, uninitialized grid. ! ! ! Grid<1>(const &domaintemplate;1& t1) ! creates a &gridone;. See the text for an explanation. ! ! ! Grid<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a &gridone; from the interval specified by the ! integers converted from t1 and ! t2. ! ! ! Grid<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates a &gridone; from the domain triplet specified ! by the integers converted from t1, ! t2, and t3. ! ! ! !

! ! To construct a &gridone; that can also be represented by a ! domain triplet, use a &gridone; constructor similar to those for ! &intervalone; and &rangeone;. See ! and the text explanations following ! or . ! ! &gridone;s with irregularly spaced points can be ! constructed using &indirectionlistint;s. For example, ! ! IndirectionList<int> list(4); ! list(0) = 2; ! list(1) = 5; ! list(2) = 6; ! list(3) = 9; ! Grid<1> g(list); ! constructs an empty &indirectionlistint;, fills it ! with ascending values, and then creates a &gridone; containing ! {2, 5, 6, 9}. When creating a list, its size must be specified. ! Subsequently, its values can be assigned. &indirectionlist;s can ! also be initialized using one-dimensional &array;s: ! ! Array<1,int,Brick> a1(Interval<1>(0,3)); ! a1(0) = 2; a1(1) = 5; a1(2) = 6; a1(3) = 9; ! IndirectionList<int> il(a1); ! Grid<1> g1(il); ! The &array; stores the integral points to include ! in the &gridone; and is used to create the &indirectionlistint;, ! which itself is used to create the &gridone;. Since the points ! are integers, the &array;'s type is ∫. Either a &brick; or ! &compressiblebrick; &engine; should be used. ! ! ! Declaring Multidimensional &grid;s ! ! ! ! ! constructor ! result ! ! ! ! ! &dim; indicates the &grid;'s ! dimension. &domaintemplate;1, ! &domaintemplate;2, … are template ! parameters. ! ! ! ! ! Grid<&dim;>() ! creates an empty, uninitialized &grid;, to be assigned a value later. ! ! ! Grid<&dim;>(const &domaintemplate;1& t1) ! creates a &grid; using the given &domain; object. ! ! ! Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a &grid; using the given &domain; objects. ! ! ! Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates a &grid; using the given &domain; objects. ! ! ! Grid<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) ! creates a &grid; using the given &domain; objects. ! ! ! Grid<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5) ! creates a &grid; using the given &domain; objects. ! ! ! Grid<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6) ! creates a &grid; using the given &domain; objects. ! ! ! Grid<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) ! creates a &grid; using the given &domain; objects. ! ! ! !

! Using &domain;s ! Since an &array; can be queried for its domain, we briefly ! describe some &domain; operations. A fuller description, ! including arithmetic operations, occur in . ! Some &domain; Accessors ! &domain; member function result ! Other &domain; accessors are described in . ! ! Multidimensional &domain; Accessors ! long size() ! returns the total number of indices. ! bool empty() ! returns &true; if and only if the &domain; has no indices. ! D<1> operator[](int dimension) ! returns the one-dimensional &domain; for the specified ! dimension. The return type is a one-dimensional version of ! the &domain;. ! ! One-dimensional &domain; Accessors ! long length() ! returns the number of indices. ! int first() ! returns the beginning of the domain. ! int last() ! returns the ending of the domain. ! int min() ! returns the minimum index in the domain. ! int max() ! returns the maximum index in the domain. ! D<1>::iterator begin() ! returns a bidirectional iterator pointing to the ! beginning domain index. ! D<1>::iterator end() ! returns a bidirectional iterator pointing to the ending ! domain index.

! &domain; member functions are listed in . Functions applicable ! to one-dimensional and multidimensional &domain;s are listed ! before functions that only applicable to one-dimensional ! &domain;s. The size member function ! yields the total number of indices in a given &domain;. If and ! only if this number is zero, empty will ! yield &true;. A multidimensional ! domain<&dim;> is the direct product of &dim; ! one-dimensional &domain;s. ! HERE

Declaring &array;s A &pooma; &array; maps indices from its &domain; to values. ! In this section, we first describe how to declare &array;s. In ! the next section, we explain how to access individual values ! stored within an &array; and &array; copy semantics. &array; values need not just be stored values, as &c; arrays have. They can also be computed using its engine. We defer *************** Grid<1> g1(il); *** 1195,1201 **** compute the resulting &array;'s domain. These are combined in the same way that multidimensional &interval;s are constructed. (See and the following text.) The domain objects, having types &domaintemplate;1, …, &domaintemplate;7, can have any type that can be --- 1290,1296 ---- compute the resulting &array;'s domain. These are combined in the same way that multidimensional &interval;s are constructed. (See and the following text.) The domain objects, having types &domaintemplate;1, …, &domaintemplate;7, can have any type that can be *************** std::cout &openopen; a.read(2,-2) &openo *** 1715,1720 **** --- 1810,2129 ---- which its first extracts the length. The length &array; member function is used in the PAssert. +

+ + +

+ &dynamicarray;s: Dynamically Changing Domain Sizes + + &array;s have fixed domains so the set of valid indices + remains fixed after declaration. The &dynamicarray; class + supports one-dimensional domains that can be resized even while + the array is used. + + &dynamicarray;'s interface extends the one-dimensional + interface of an &array; by adding member functions to change the + domain's size. It is declared in Pooma/DynamicArrays.h. A + &dynamicarray; has two, not three, template parameters, omitting + the array's dimensionality. The first + parameter T specifies the type of stored values. + Its default value is usually &double;, but it may be changed when + the &poomatoolkit; is configured. The second parameter specifies + an &engine; via a tag. The engine must support a domain with + dynamic resizing. For example, the &dynamic; &engine; is + analogous to a one-dimensional &brick; &engine; supporting a + dynamically-resizable domain. It is also usually the default + value for this tag. For example, DynamicArray<> + d0(1);, DynamicArray<double> + d1(1);, and DynamicArray<double, + Dynamic> d2(1); all declare the same + &dynamicarray;s explicitly storing one &double; value. A + &dynamicarray; automatically allocates its initial memory and + deallocates its final memory, just as an &array; does. + + + Changing a &dynamicarray;'s Domain + + + + + &dynamicarray; member function + description + + + + + This table omits member functions designed for + distributed computation. + + + + + void create(int num) + extend the current domain by the requested number of + elements. + + + void destroy(const Dom& killList) + remove the elements specified by the indices in the + given &domain; argument. Backfill moves + elements from the end of the domain to replace the deleted + elements. + + + void destroy(Iter killBegin, Iter killEnd) + remove the elements specified by the indices in the + container range [begin,end) specified by the random-access + iterators. Backfill moves elements from the + end of the domain to replace the deleted elements. + + + void destroy(const Dom& killList, const + DeleteMethod& method) + + remove the elements specified by the indices in the + given &domain; argument. Deleted elements can be replaced by + BackFill'ing, i.e., moving data from the domain's + end to fill removed elements, or by ShiftUp'ing, + i.e., compacting all data but maintaining relative ordering. + + + void destroy(Iter killBegin, Iter killEnd, + const DeleteMethod& method) + remove the elements specified by the indices in the + container range [begin,end) specified by the random-access + iterators. Deleted elements can be replaced by + BackFill'ing, i.e., moving data from the domain's + end to fill removed elements, or by ShiftUp'ing, + i.e., compacting all data but maintaining relative ordering. + + + +

+ + The create and + destroy member functions permit changing + a &dynamicarray;'s domain. lists these member + functions but omits functions exclusively used in distributed + computation. When making the domain larger, new indices are added + to the end of the one-dimensional domain and the corresponding + values are initialized with the default value + for T. Existing values are copied. + + + Changing a &dynamicarray;'s Domain + + + + + &dynamicarray; member function + description + + + + + This table omits member functions designed for + distributed computation. + + + + + void create(int num) + extend the current domain by the requested number of + elements. + + + void destroy(const Dom& killList) + remove the elements specified by the indices in the + given &domain; argument. Backfill moves + elements from the end of the domain to replace the deleted + elements. + + + void destroy(Iter killBegin, Iter killEnd) + remove the elements specified by the indices in the + container range [begin,end) specified by the random-access + iterators. Backfill moves elements from the + end of the domain to replace the deleted elements. + + + void destroy(const Dom& killList, const + DeleteMethod& method) + + remove the elements specified by the indices in the + given &domain; argument. Deleted elements can be replaced by + BackFill'ing, i.e., moving data from the domain's + end to fill removed elements, or by ShiftUp'ing, + i.e., compacting all data but maintaining relative ordering. + + + void destroy(Iter killBegin, Iter killEnd, + const DeleteMethod& method) + remove the elements specified by the indices in the + container range [begin,end) specified by the random-access + iterators. Deleted elements can be replaced by + BackFill'ing, i.e., moving data from the domain's + end to fill removed elements, or by ShiftUp'ing, + i.e., compacting all data but maintaining relative ordering. + + + +

+ + The destroy deletes specified + indices. The indices may be specified using either a &domain; + object (Interval<1>, + Range<1>, or IndirectionList) or + in a container specified using random-access iterators. For + example, every other element from a ten-element + array d might be removed using + Range<1>(0,9,2). Alternatively, + + int killList[] = {0, 2, 4, 6, 8}; + d.destroy(killList, killList+5); + performs the same deletions. As indices are + removed, other indices are moved into their positions. Using the + BackFill method moves the last index and its + associated value into deleted index's position. Thus, the total + number of indices is decreased by one, but the indices can be + reordered. Using the ShiftUp method ensures the + indices' orders are maintained by shifting all + elements left (or up) so all gaps between indices + disappear. For example, consider removing the first index from a + domain. + + + + + original indices: + 0 1 2 3 + + + destroy using BackFill + 3 1 2 + + + destroy using ShiftUp + 1 2 3 + + + + + The BackFill moves the rightmost index 3 into + the removed index 0's position. The ShiftUp + moves all the indices one position to the left. This illustrates + that BackFill moves exactly as many indices as are + deleted, while ShiftUp can shift all indices in a + domain. Thus, BackFill is the default method. When + multiple indices are deleted, they are deleted from the largest to + the smallest. When using the BackFill method, some + indices may be moved repeatedly. For example, consider removing + indices 0 and 2 from original indices of 0 1 2 3. Removing 2 + yields 0 1 3. Removing 0 yields 3 1. Using an object with the + desired type to indicate which fill method is desired, i.e., + BackFill() or + ShiftUp(). + + + Example Using &dynamicarray;s + + &dynamicarray-example; + + + This header file declares &dynamicarray;s. + + + These three declarations yield equivalent + &dynamicarray;s, storing one &double; value. + + + This create member function adds + five indices to the end of the domain. + + + &dynamicarray; values are accessed the same way as + &array; values. + + + The ⦥ object specifies that every other index + should be removed. The BackFill() + object is unnecessary since it is the default replacement + method. + + + This destroy call is equivalent + to the previous one but uses iterators. + + + + + We illustrate &dynamicarray; resizing in . &dynamicarray;s + are declared in Pooma/DynamicArrays.h, not Pooma/Arrays.h. Their declarations + require two, not three, template arguments because the array must + be one-dimensional. The three arrays, each having one &double; + value, are equivalent. (The &poomatoolkit; can be configured to + support different default values.) Invoking + d0's create with an + argument of five increases its domain size from one to six. The + additional indices are added to the end of the domain so the value + at index 0 is not changed. To illustrate which indices are + removed and which indices are reordered, the program first sets + all values equal to their indices. This illustrates that + &dynamicarray; values are accessed the same way as &array; values. + For example, d0(i) accesses the + ith value. The + destroy removes every other index from + the array. The one-dimensional ⦥ specifies these indices by + specifying the domain's entire interval and a stride of 2. + The BackFill function call creates a + BackFill object indicating the BackFill + method should be used. We illustrate the steps of this method: + + + + + original indices: + 0 1 2 3 4 5 + + + delete index 4 + 0 1 2 3 5 + + + delete index 2 + 0 1 5 3 + + + delete index 0 + 3 1 5 + + + + + Since multiple indices are specified, the rightmost one is removed + first, i.e., index 4. The rightmost index 5 is moved + into 4's position. When removing index 2, the index + originally at 5 is moved again into 2's position. Finally, + index 0 is replaced by index 3. The rest of the program + repeats the computation, using the random-access iterator version + of destroy. Since this &dynamicarray;'s + indices are specified using ∫s, the + killList explicitly lists the indices to + remove. The destroy call uses pointers + to the beginning and end of the killList array + to specify which of its indices to use. Since no replacement + method is specified, the default BackFill method is + used. All the &dynamicarray;s' unallocated memory is + deallocated.

Index: concepts.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/concepts.xml,v retrieving revision 1.6 diff -c -p -r1.6 concepts.xml *** concepts.xml 2002/01/16 00:50:27 1.6 --- concepts.xml 2002/01/22 15:37:14 *************** *** 147,158 **** &field; container mapping indices to one or more values and ! residing in multi-dimensional space &tensor; ! multi-dimensional mathematical tensor &field; container mapping indices to one or more values and ! residing in multidimensional space &tensor; ! multidimensional mathematical tensor &vector; ! multi-dimensional mathematical vector --- 162,168 ---- &vector; ! multidimensional mathematical vector *************** *** 210,216 **** A &tensor; ! implements a multi-dimensional mathematical tensor. Since it is a first-class type, it can be used in expressions such as adding two &tensor;s. --- 210,216 ---- A &tensor; ! implements a multidimensional mathematical tensor. Since it is a first-class type, it can be used in expressions such as adding two &tensor;s. *************** *** 224,230 **** A &vector; ! implements a multi-dimensional mathematical vector, which is an ordered tuple of components. Since it is a first-class type, it can be used in expressions such as adding two &vector;s and multiplying a &matrix; and a &vector;. --- 224,230 ---- A &vector; ! implements a multidimensional mathematical vector, which is an ordered tuple of components. Since it is a first-class type, it can be used in expressions such as adding two &vector;s and multiplying a &matrix; and a &vector;. *************** *** 263,269 **** use a &vector;, &matrix;, or &tensor;. ! If indices and values reside in multi-dimensional space &space;, use a &field;. --- 263,269 ---- use a &vector;, &matrix;, or &tensor;. ! If indices and values reside in multidimensional space &space;, use a &field;. Index: glossary.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/glossary.xml,v retrieving revision 1.6 diff -c -p -r1.6 glossary.xml *** glossary.xml 2002/01/14 17:33:34 1.6 --- glossary.xml 2002/01/22 15:37:16 *************** *** 369,374 **** --- 369,384 ---- + + function object + + object that can behave as a function. The object can store + values that the function uses. If its function is called + operator(), the object can be invoked as + a function. + + + function template *************** *** 547,553 **** point ! a location in multi-dimensional space &space;. In contrast, indices specify positions in container domains. &field; mesh --- 557,563 ---- point ! a location in multidimensional space &space;. In contrast, indices specify positions in container domains. &field; mesh *************** *** 694,700 **** &tensor; ! a &pooma; container implementing multi-dimensional mathematical tensors as first-class objects. &matrix; &vector; --- 704,710 ---- &tensor; ! a &pooma; container implementing multidimensional mathematical tensors as first-class objects. &matrix; &vector; *************** *** 750,756 **** &vector; ! a &pooma; container implementing multi-dimensional mathematical vectors, i.e., an ordered tuple of components, as first-class objects. &tensor; --- 760,766 ---- &vector; ! a &pooma; container implementing multidimensional mathematical vectors, i.e., an ordered tuple of components, as first-class objects. &tensor; Index: manual.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/manual.xml,v retrieving revision 1.7 diff -c -p -r1.7 manual.xml *** manual.xml 2002/01/16 00:50:27 1.7 --- manual.xml 2002/01/22 15:37:19 *************** *** 95,100 **** --- 95,102 ---- double"> + Dynamic"> + DynamicArray"> Engine"> *************** *** 156,167 **** - - d"> ! g++"> --- 158,167 ---- d"> ! g++"> *************** *** 234,245 **** - - --- 234,247 ---- + + + + *************** *** 353,362 **** &arrays-chapter; Engines ! UNFINISHED --- 355,692 ---- &arrays-chapter; + Engines ! Each container has one or more &engine;s to store or compute ! its values. As we mentioned in , a container's role is ! high-level, supporting access to groups of values, and an engine's ! role is low-level, storing or computing values and supporting ! access to individual values. This separation permits optimizing ! space and computation requirements. ! ! We begin this chapter by introducing the concept of an engine ! and how it is used. Then, we describe the various &engine;s that ! &pooma; provides, separating them into engines that store values ! and engines that compute values. Finally, we describe how the ! &engine;s are implemented, using tags to differentiate engines and ! reference-counted pointers to their underlying data. ! ! !

! The Concept ! ! An engine performs the low-level value storage, computation, ! and element-wise access for a container. The &pooma; &engine; ! class and its specializations implement the concept. An engine ! has a domain and accessor functions returning individual elements. ! Given an index within the domain, an engine's ! operator() function returns the ! associated value, which can be used or changed. Its ! read returns the same value for only use, ! not modification. The acceptable indices are determined by each ! &engine;. Most accept indices specified using ∫ and ! Loc<&dim;> parameters, but an &engine; might ! accept string or floating-point parameters. An &engine;'s layout ! specifies maps its domain indices to the processors and memory ! used to store and compute the associated values. ! ! Since an engine's main role is to return the individual ! values associated with specific domain indices, any implementation ! performing this task is an engine. &pooma; &engine;s fall into ! three categories: ! ! ! &engine;s that store values. ! ! ! &engine;s that compute their values using other &engine;s' ! values. ! ! ! &engine;s that support distributed computation. ! ! ! For example, the &brick; &engine; explicitly stores all its ! values, while the &compressiblebrick; engine adds the feature of ! reducing its storage requirements if all these values are ! identical. A UserFunction &engine; yields values by ! applying a function ! object to each value returned by another &engine;. A ! CompFwd &engine; projects components from another ! &engine;. For example, CompFwd will use the second ! components of each vector in an &array; to form its own &array;. ! Since each container has one or more &engine;s, we can also ! describe the latter category as containers that compute their ! values using other containers' values. A MultiPatch ! &engine; distributes its domain among various processors and ! memory spaces, each responsible for computing values associated ! with a portion, or patch, of the domain. ! ! Just as multiple containers can use the same engine, ! multiple &engine;s can use the same underlying data. As we ! mentioned in , &engine;s ! have reference semantics. So a copy of an &engine; has a ! reference-counted pointer to an &engine;'s data (if any exists). ! Thus, copying an &engine; or a container requires little execution ! time. If an &engine; has the same data as another &engine; but it ! needs its own data to modify, the ! makeOwnCopy creates such a copy. ! ! &engine;s are rarely explicitly declared. Instead a ! container is declared using an &engine; tag, and the container, ! creates the specified &engine; to deal with its values. For ! example, a &brick; &engine; is explicitly declared as ! Engine<&dim;,T,Brick>, but they are more ! frequently created by containers, e.g., ! Array<&dim;,T,Brick>. The first two template ! parameters specify the domain's dimensionality and the value type, ! as described in . Unlike container ! declarations, the third template parameter, the &engine; tag, ! specifies which &engine; specialization to use. For example, the ! &brick; engine tag indicates a brick &engine; should be used. ! Some &engine;s, such as CompFwd, are rarely declared ! even using &engine; tags. Instead the &array;'s ! comp and ! readComp methods return views of ! containers using CompFwd &engine;s. !

! ! !

! Types of &engine;s ! ! In this section, we describe the different types of ! &engine;s and illustrate their creation, when appropriate. First, ! we describe &engine;s that explicitly store values and then ! &engine;s that compute values. ! ! ! Types of &engine;s ! ! ! ! ! &engine; tag ! description ! ! ! ! ! &engine;s That Store ! ! ! &brick; ! explicitly stores all values; similar to &c; arrays. ! ! ! &compressiblebrick; ! stores all values, reducing storage requirements when ! all values are the same. ! ! ! &dynamic; ! is a one-dimensional &brick; with dynamically ! resizable domain. HERE ever explicitly declare these? ! ! ! &engine;s That Compute ! ! ! CompFwd ! extracts specified components of an engine's vectors, ! tensors, arrays, etc.; usually created using ! comp container function. ! ! ! ConstantFunction ! makes a scalar value behave like a container. ! ! ! IndexFunction<FunctionObject> ! makes the FunctionObject function of ! indices behave like a container. ! ! ! ExpressionTag<Expr> ! evaluates an expression tree; usually created by ! data-parallel expressions. ! ! ! Stencil<Function, ! Expression> ! applies a stencil computation (Function) ! to its input (Expression), usually a container; ! usually created by applying a Stencil object to ! a container. A stencil computation can use multiple ! neighboring input values. ! ! ! UserFunctionEngine<Function, ! Expression> ! applies the given function (or function ! object) to its input (Expression), ! usually a container; usually created by applying a ! UserFunction object to a container. The ! function implements a one-to-one mapping from its input to ! values. ! ! ! &engine;s for Distributed Computation ! ! ! MultiPatch<LayoutTag,EngineTag> ! runs a separate EngineTag &engine; on ! each context (patch) specified by the given layout. This is ! the usual &engine; for distributed computation. ! ! ! Remote<EngineTag> ! runs the &engine; specified by EngineTag ! on a specified context. ! ! ! Remote<Dynamic> ! runs a Dynamic one-dimensional, resizable ! &engine; on a specified context. This is a specialization of ! Remote. ! ! ! !

! ! &brick; &engine;s explicitly store values just like &c; ! arrays. &compressiblebrick; &engine;s optimize their storage ! requirements when all values are the same. Most &array;s use one ! of these two &engine;s. &brick;s are the default &engine;s for ! &array; and &field; containers because each of their values are ! explicitly stored. Explicitly storing all an engine's value can ! require a large amount of space, particularly if all these values ! are the same. If all a compressible brick &engine;'s values are ! the same, the engine stores that one value rather than many, many ! copies of the same value. These engines can both save time as ! well as space. Initializing a compressible engine requires ! setting only one value, not every value. Using less storage space ! may permit more useful values to be stored in cache, improving ! cache performance. Reading a value in a compressed &engine; using ! read is as fast as reading a value in a ! &brick; &engine;, but writing a value always requires an ! additional if conditional. Thus, if an ! &engine; occasionally has multiple different values during its ! life time, a &compressiblebrick; &engine; may be faster than a ! &brick; &engine;. If an &engine; is created and its values are ! mostly read, not written, a &compressiblebrick; &engine; may also ! be faster. Otherwise, a &brick; &engine; may be preferable. ! Timing the same program using the two different &engine; types ! will reveal which is faster for a particular situation. ! ! In distributed computing, many &engine;s may have few ! nonzero values so &compressiblebrick; &engine;s may be preferable. ! For distributed computing, a container's domain is partitioned ! into regions each computed by a separate processor and &engine;. ! If the computation is concentrated in sections of the domain, many ! &engine;s may have few, if any, nonzero values. Thus, ! &compressiblebrick; &engine;s may be preferable for distributed ! computing. ! ! Both &brick; and &compressiblebrick; &engine;s have ! read and ! operator() members with ∫ and &loc; ! parameters. The parameters should match the &array;'s ! dimensionality. For example, if &array; a has ! dimensionality 3, a.read(int, int, int) ! and a(int, int, int) should be used. The ! former returns a value that cannot be modified, while the latter ! can be changed. Using the read can lead ! to faster code. Alternatively, an index can be specified using a ! &loc;. For example, ! a.read(Loc<3>(1,-2,5)) and ! a(Loc<3>(1,-2,5)) are equivalent to ! a.read(1,-2,5)) and ! a(1,-2,5). ! ! The &dynamic; &engine; supports changing domain sizes while ! a program is executing. It is basically a one-dimensional ! &brick;, explicitly storing values, but permitting the number and ! order of stored values to change. Thus, it supports the same ! interface as &brick; except that all member functions are ! restricted to their one-dimensional versions. For example, ! read and ! operator() take Loc<1> ! or one ∫ parameter. In addition, the one-dimensional domain ! can be dynamically resized using create ! and destroy; see . ! ! HERE Dynamic. How does one change the domain size? What is the model? ! ! ! ! Types of &engine;s: ! Brick - explicitly store values ! CompressibleBrick - explicitly store values but store only one if all the same ! ConstantFunction - convert scalar into an array ! DynamicEngine - contiguous, local, resizable, 1D block ! ExpressionEngine - evaluate PETE expression ! CompFwd - array formed by extracted components from array ! ForwardEngine ! tut-02.html: use .comp() or .readComp() ! IndexFunctionEngine - convert function of indices into an array ! IndirectionEngine - incomplete ! MultiPatch - ?How do I describe this? ! RemoteDynamic - run a Dynamic engine on a specified context ! Remote - permit computations on specified context ! should discuss with MultiPatch ! Stencil - apply a stencil to an array, returning a new Array with the results ! UserFunction - Array = apply function to an Array ! ! ! How do I organize these engines into understandable ! categories? ! ! storage ! Brick ! CompressibleBrick ! Dynamic - resizable 1D block ! RemoteDynamic ! MultiPatch - ?WHAT? ! Remote ! ! computation ! CompFwd: project(array)->array ! .comp() and .readComp() ! view, not a copy ! ConstantFunction: scalar(array)->array ! explicitly use ! IndexFunctionEngine: function(indices)->array ! explicitly use ! ExpressionEngine: expression(array)->array ! created by data-parallel expression ! Stencil: stencil(array)->array ! implicitly used ! explicitly use Stencil<...> type ! UserFunction: function(array)->array ! explicitly use ! ! ! ! Element_t read(Loc<&dim;>) ! ElementRef_t operator()(Loc<&dim;>) ! Element_t read(int+) ! ElementRef_t operator()(int+) ! ! ! Explain the concept of an engine. How does an engine ! interact with a container or an &array;? Explain the different ! types of engines likely to be used by &pooma; programmers and how ! to declare containers using them. Should I list the other engines ! that are automatically created? ! !

*************** *** 553,559 **** Beginning and Ending &pooma; Programs Every &pooma; program must begin with a call to ! initialize and end with a call to finalize. These functions respectively prepare and shut down &pooma;'s run-time structures. --- 883,889 ---- Beginning and Ending &pooma; Programs Every &pooma; program must begin with a call to ! initialize and end with a call to finalize. These functions respectively prepare and shut down &pooma;'s run-time structures. *************** *** 603,609 **** Description Before its use, the &poomatoolkit; must be initialized by a ! call to initialize. This usually occurs in the main function. The first form removes and processes any &pooma;-specific arguments from the command-line arguments argv and --- 933,939 ---- Description Before its use, the &poomatoolkit; must be initialized by a ! call to initialize. This usually occurs in the main function. The first form removes and processes any &pooma;-specific arguments from the command-line arguments argv and *************** *** 625,631 **** architecture-specific initialization. The function always returns &true;. ! initialize's alternative form assumes the &pooma;-specific and architecture-specific command-line arguments have already been removed from argv and argc and stored in --- 955,961 ---- architecture-specific initialization. The function always returns &true;. ! initialize's alternative form assumes the &pooma;-specific and architecture-specific command-line arguments have already been removed from argv and argc and stored in *************** *** 653,659 **** Example Program Since every &pooma; program must call ! initialize and finalize, the simplest &pooma; program also must call them. This program also illustrates their usual use. --- 983,989 ---- Example Program Since every &pooma; program must call ! initialize and finalize, the simplest &pooma; program also must call them. This program also illustrates their usual use. *************** UNFINISHED *** 862,868 **** specifying N indices, which collectively specify a single point in the input domain: A(i1, i2, ..., iN). ! The &pooma; multi-dimensional Array concept is similar to the &fortran; 90 array facility, but extends it in several ways. Both &pooma; and &fortran; arrays can have up to seven dimensions, and can serve as containers for arbitrary --- 1192,1198 ---- specifying N indices, which collectively specify a single point in the input domain: A(i1, i2, ..., iN). ! The &pooma; multidimensional Array concept is similar to the &fortran; 90 array facility, but extends it in several ways. Both &pooma; and &fortran; arrays can have up to seven dimensions, and can serve as containers for arbitrary Index: tutorial.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/tutorial.xml,v retrieving revision 1.5 diff -c -p -r1.5 tutorial.xml *** tutorial.xml 2002/01/14 17:33:34 1.5 --- tutorial.xml 2002/01/22 15:37:20 *************** *** 856,862 **** multiple values. Like &array;s, &field;s can be accessed via data-parallel expressions and stencils and may be distributed across processors. Unlike &array; cells, &field; cells exist in a ! multi-dimensional volume so, e.g., distances between cells and normals to cells can be computed. In this section, we implement the &doof2d; two-dimensional --- 856,862 ---- multiple values. Like &array;s, &field;s can be accessed via data-parallel expressions and stencils and may be distributed across processors. Unlike &array; cells, &field; cells exist in a ! multidimensional volume so, e.g., distances between cells and normals to cells can be computed. In this section, we implement the &doof2d; two-dimensional From oldham at codesourcery.com Thu Jan 24 05:18:51 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Wed, 23 Jan 2002 21:18:51 -0800 Subject: Manual: Wordsmithing Changes to First Four Chapters Message-ID: <20020123211851.A4304@codesourcery.com> 2002-Jan-23 Jeffrey D. Oldham These changes move the manual toward delivery. Unfinished sections remain in the DocBook source code but are not printed. The first two chapters were indexed. Wordsmithing throughout the document (hopefully) improved the exposition. * arrays.xml: Wordsmithing. Finish describing the Domain use section. * concepts.xml: Wordsmithing. * data-parallel.xml: Rewrite "naive". * glossary.xml: Add some indexing. (stride): Fix definition. (template): New definition. * introduction.xml: Index. Wordsmith. * manual.xml: Add 'unfinished', 'temporary', and 'naive', and 'naivecap' entities. Change names of entities that used capital letters. Write short description of container views. Comment out unfinished sections. * template.xml: Index. s/< &array; Containers *************** *** 961,967 **** Since an &array; can be queried for its domain, we briefly describe some &domain; operations. A fuller description, including arithmetic operations, occur in . --- 962,973 ---- Since an &array; can be queried for its domain, we briefly describe some &domain; operations. A fuller description, including arithmetic operations, occur in . As we mentioned in , the Pooma/Domains.h header file ! declares &domain;s, but most container header files automatically ! include Pooma/Domains.h ! so no explicit inclusion of is usually necessary.

*************** *** 976,983 **** ! Other &domain; accessors are described in . --- 982,990 ---- ! D abbreviates the particular &domain; ! type, e.g., &interval; or &grid;. Other &domain; accessors ! are described in . *************** *** 1037,1053 **** &domain; member functions are listed in . Functions applicable ! to one-dimensional and multidimensional &domain;s are listed before functions that only applicable to one-dimensional &domain;s. The size member function yields the total number of indices in a given &domain;. If and only if this number is zero, empty will yield &true;. A multidimensional domain<&dim;> is the direct product of &dim; ! one-dimensional &domain;s. ! ! HERE ! --- 1044,1087 ---- &domain; member functions are listed in . Functions applicable ! to both one-dimensional and multidimensional &domain;s are listed before functions that only applicable to one-dimensional &domain;s. The size member function yields the total number of indices in a given &domain;. If and only if this number is zero, empty will yield &true;. A multidimensional domain<&dim;> is the direct product of &dim; ! one-dimensional &domain;s. The operator[](int ! dimension) operator extracts the one-dimensional ! &domain; corresponding to its parameter. For example, the three ! Range<1> (one-dimensional) &domain;s can be ! extracted from a Range<3> ! object r using ! r[0], r[1], and ! r[2]. ! ! &domain; accessors applicable only to one-dimensional ! &domain;s are listed in the second half of . The ! length member function, analogous to the ! multidimensional size function, returns ! the number of indices in the &domain;. The ! first and last ! member functions return the domain's beginning and ending ! indices. The begin and ! end member functions return input ! iterators pointing to these respective locations. They have type ! D<1>::iterator, where D ! abbreviates the &domain;'s type, e.g., &interval; or &grid;. ! The min and ! max member functions return the minimum ! and maximum indices in the &domain; object, respectively. For ! &locone; and &intervalone;, these are the same as ! first and last, ! but &rangeone; and &gridone; can have their largest index at the ! beginning of their &domain;s. ! *************** std::cout &openopen; a.read(2,-2) &openo *** 1814,1820 ****

! &dynamicarray;s: Dynamically Changing Domain Sizes &array;s have fixed domains so the set of valid indices remains fixed after declaration. The &dynamicarray; class --- 1848,1854 ----

! &dynamicarray;s &array;s have fixed domains so the set of valid indices remains fixed after declaration. The &dynamicarray; class Index: concepts.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/concepts.xml,v retrieving revision 1.7 diff -c -p -r1.7 concepts.xml *** concepts.xml 2002/01/22 15:48:49 1.7 --- concepts.xml 2002/01/24 04:56:32 *************** *** 1,3 **** --- 1,4 ---- + Overview of &pooma; Concepts *************** *** 13,22 **** separate categories: ! container ! data structure holding one or more values and usually addressed ! by indices --- 14,23 ---- separate categories: ! containers ! data structures holding one or more values and usually accessed ! using indices *************** *** 34,41 **** ! See . Many &pooma; programs ! select one possibility from each column. For example, used &array; containers and stencils for sequential computation, while used &field; --- 35,43 ---- ! categorizes the &pooma; ! concepts. Many &pooma; programs select one possibility from each ! category. For example, used &array; containers and stencils for sequential computation, while used &field; *************** *** 103,115 **** Most &pooma; programs use containers to store groups of values. &pooma; containers are objects that store other objects such as numbers or vectors. They control allocation ! and deallocation of and access to these stored objects. They are a ! generalization of &c; arrays, but &pooma; containers are first-class ! objects so they can be used directly in expressions. They are ! similar to &cc; containers such as vector, ! list, and stack. See for a summary of the ! containers. This section describes many concepts, but one need not understand them all to begin programming with the &poomatoolkit;. --- 105,117 ---- Most &pooma; programs use containers to store groups of values. &pooma; containers are objects that store other objects such as numbers or vectors. They control allocation ! and deallocation of these stored objects and access to them. They ! are a generalization of &c; arrays, but &pooma; containers are ! first-class objects so they can be used directly in expressions. ! They are also similar to &cc; containers such as ! vector, list, and stack. See ! for a summary of ! the containers. This section describes many concepts, but one need not understand them all to begin programming with the &poomatoolkit;. *************** *** 126,131 **** --- 128,137 ---- multiple processors. The programs in the previous chapter illustrate many of these concepts. + briefly + describes the six &pooma; containers. They are more fully described + in the paragraphs below. +

&pooma; Container Summary *************** *** 201,210 **** to &array;s, each cell may contain multiple values and multiple materials. A &field;'s mesh stores its spatial ! characteristics and can map yield, e.g., the cell at a particular ! point, the distance between two cells, or a cell's normals. A ! &field; should be used whenever geometric or spatial computations ! are needed, multiple values per index are desired, or a computation involves more than one material. --- 207,216 ---- to &array;s, each cell may contain multiple values and multiple materials. A &field;'s mesh stores its spatial ! characteristics and can yield, e.g., the cell at a particular point, ! the distance between two cells, or a cell's normals. A &field; ! should be used whenever geometric or spatial computations are ! needed, multiple values per index are desired, or a computation involves more than one material. *************** *** 230,254 **** multiplying a &matrix; and a &vector;.The data of an &array;, &dynamicarray;, or &field; can be ! viewed using more than one container by taking a view. A view of an existing container &container; is a container whose domain ! is a subset of &container;. The subset can equal the original ! domain. A view acts like a reference in that changing any of the ! view's values also changes the original container's and vice versa. ! While users sometimes explicitly create views, they are perhaps more ! frequently created as temporaries in expressions. For example, if ! A is an &array; and I is a ! domain, A(I) - A(I-1) uses two views to form ! the difference between adjacent values.

Choosing a Container The two most commonly used &pooma; containers are &array;s ! and &field;s, while &vector;, &matrix;, or &tensor; frequently ! represent mathematical objects. contains a decision tree describing how to choose an appropriate container. --- 236,262 ---- multiplying a &matrix; and a &vector;. The data of an &array;, &dynamicarray;, or &field; can be ! accessed using more than one container by taking a view. A ! view of an existing container &container; is a container whose domain ! is a subset of &container;'s domain. The subset can equal the ! original domain. A view acts like a reference in that changing any ! of the view's values also changes the original container's and vice ! versa. While users sometimes explicitly create views, they are ! perhaps more frequently created as temporaries in expressions. For ! example, if A is an &array; and ! I is a domain, A(I) - ! A(I-1) uses two views to form the difference between ! adjacent values.

Choosing a Container The two most commonly used &pooma; containers are &array;s ! and &field;s, while &vector;, &matrix;, and &tensor; represent ! mathematical objects. contains a decision tree describing how to choose an appropriate container. *************** *** 299,304 **** --- 307,324 ---- in declaring them. Concepts specific to distributed computation are described in the next section. + + illustrates the containers and the concepts involved in their + declarations. The containers are listed in the top row. Lines + connect these containers to the components necessary for their + declarations. For example, an &array; declaration requires an + engine and a layout. These, in turn, can depend on other &pooma; + concepts. Declarations necessary only for distributed, or + multiprocessor, computation are also indicated. Given a desired + container, one can use this figure to determine the concepts needed + to declare a particular container. +

Concepts For Declaring Containers *************** *** 311,328 **** - - illustrates the containers and the concepts involved in their - declarations. The containers are listed in the top row. Lines - connect these containers to the components necessary for their - declarations. For example, an &array; declaration requires an - &engine; and a layout. These, in turn, can depend on other &pooma; - concepts. Declarations necessary only for distributed, or - multiprocessor, computation are surrounded by dashed lines. These - dependences to indicate the concepts needed for a particular - container. - An engine stores and, if necessary, computes a container's values. A --- 331,336 ---- *************** *** 332,338 **** for all indices can use a constant engine, which need only store one value for the entire domain. A &compressiblebrick; &engine; reduces its space requirements to a constant whenever all its ! values are the same. The separation also permits taking views of containers without copying storage. --- 340,347 ---- for all indices can use a constant engine, which need only store one value for the entire domain. A &compressiblebrick; &engine; reduces its space requirements to a constant whenever all its ! values are the same. The separation between a container and its ! engine also permits taking views of containers without copying storage. *************** *** 350,360 **** A layout ! maps domain indices to the ! processors and computer memory used by a container's engines. See ! . ! A program computes a container's values using a processor and memory. The layout specifies the processors and memory to use for each particular index. A container's layout for a uniprocessor implementation consists of its domain, the processor, and its --- 359,369 ---- A layout ! maps domain indices to the processors and ! computer memory used by a container's engines. See . ! A program computes a container's values using these processors and memory. The layout specifies the processors and memory to use for each particular index. A container's layout for a uniprocessor implementation consists of its domain, the processor, and its *************** *** 378,388 **** interval [0,n). A domain need not contain all integral points between its endpoints. A stride ! is a subset of an interval consisting of regularly-spaced points. ! A range is a subset of an interval of regularly-spaced points specified by ! strides. A &field;'s mesh --- 387,396 ---- interval [0,n). A domain need not contain all integral points between its endpoints. A stride ! indicates a regular spacing between points. A range is a subset of an interval of regularly-spaced points specified by ! a stride. A &field;'s mesh *************** *** 399,422 **** linkend="glossary-point">point in &space; corresponding to the cell in the lower, left corner of its domain. Combining this, the ! domain, and the cell size fully specifies the mesh's map from ! indices to &space;. A mesh's cell ! size specifies the spatial dimensions of ! a &field; cell, e.g., its ! width, height, and depth, in &space;. Combining this, the ! domain, and the corner position fully specifies the mesh's map ! from indices to &space;.

Declaring Distributed Containers ! In the previous section, we introduced the concepts important ! when declaring containers for use on uniprocessor computers. When using multiprocessor computers, we augment these concepts with those for distributed computation. Reading this section is important only for running a program on multiple processors. Many --- 407,430 ---- linkend="glossary-point">point in &space; corresponding to the cell in the lower, left corner of its domain. Combining this, the ! domain, and the cell size can specify the mesh's map from indices ! to &space;. A mesh's cell ! size specifies the spatial dimensions of a ! &field; cell, e.g., its width, ! height, and depth, in &space;. Combining this, the domain, ! and the corner position can specify the mesh's map from indices to ! &space;.

Declaring Distributed Containers ! In the previous section, we introduced the important concepts ! for declaring containers for use on uniprocessor computers. When using multiprocessor computers, we augment these concepts with those for distributed computation. Reading this section is important only for running a program on multiple processors. Many *************** *** 457,463 **** linkend="glossary-external_guard_layer">external guard layer specifies values surrounding the entire domain. Its presence eases computation along the domain's ! edges by permitting the same computations as for more internal computations. An internal guard layer duplicates values from adjacent --- 465,471 ---- linkend="glossary-external_guard_layer">external guard layer specifies values surrounding the entire domain. Its presence eases computation along the domain's ! edges by permitting the same computations as for more-internal computations. An internal guard layer duplicates values from adjacent *************** *** 488,503 **** &pooma; computations can be expressed using a variety of modes. Many &pooma; computations involve &array; or &field; ! containers, but how their values are accessed and the associated ! algorithms using them varies. For example, element-wise computation involves explicitly accessing a container's values. A data-parallel ! computation uses expressions to represent larger subsets of a ! container's values. Stencil-based computations express a ! computation as repeatedly applying a local computation to each ! element of an array. A relation among containers establishes a ! dependency among them so the values of one container are updated ! whenever any other's values change. A program may use any or all of ! these styles, which are described below. Element-wise --- 496,511 ---- &pooma; computations can be expressed using a variety of modes. Many &pooma; computations involve &array; or &field; ! containers, but how their values are accessed and how the associated ! algorithms use them varies. For example, element-wise computation involves explicitly accessing a container's values. A data-parallel ! computation operates on larger subsets of a container's values. ! Stencil-based computations express a computation as repeatedly ! applying a local computation to each element of an array. A ! relation among containers establishes a dependency among them so the ! values of one container are updated whenever any other's values ! change. A program may use any or all of these styles, which are ! described below. Element-wise *************** *** 515,524 **** linkend="tutorial-array_parallel-doof2d">, a(I,J) represents the subset of &array; a's values having coordinates in the domain ! specified by the one-dimensional &interval;s I ! and J. Using data-parallel expressions ! frequently eliminates the need for writing explicit loops in ! code. A stencil --- 523,532 ---- linkend="tutorial-array_parallel-doof2d">, a(I,J) represents the subset of &array; a's values having coordinates in the domain ! specified by the direct product of one-dimensional &interval;s ! I and J. Using ! data-parallel expressions frequently eliminates the need for writing ! explicit loops. A stencil *************** *** 550,557 ****

Computation Environment ! A &pooma; program can execute on a wide variety of computers. ! The default sequential computing environment consists of one processor and its associated memory, as found on a personal computer. In --- 558,565 ----

Computation Environment ! The same &pooma; program can execute on a wide variety of ! computers. The default sequential computing environment consists of one processor and its associated memory, as found on a personal computer. In *************** *** 574,580 **** library. ! The &pooma; executable must be run using the library. All of these were illustrated in ! The &pooma; executable must be run using the ! communications library. All of these were illustrated in

--- 620,628 ---- contexts, all of which is hidden from both the programmer and the user. &pooma; works with the Message Passing Interface (&mpi;) Communications Library ! ! and the &mm; Shared Memory Library. See for ! details.

Index: data-parallel.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/data-parallel.xml,v retrieving revision 1.1 diff -c -p -r1.1 data-parallel.xml *** data-parallel.xml 2002/01/14 17:33:33 1.1 --- data-parallel.xml 2002/01/24 04:56:34 *************** *** 14,20 **** After introducing data-parallel expressions and statements, we present the corresponding &pooma; syntax. Then we present its ! implementation, which uses expression-template technology. A naive data-parallel implementation might generate temporary variables, cluttering a program's inner loops and slowing its execution. Instead, &pooma; uses &pete, the Portable Expression Template --- 14,20 ---- After introducing data-parallel expressions and statements, we present the corresponding &pooma; syntax. Then we present its ! implementation, which uses expression-template technology. A &naive; data-parallel implementation might generate temporary variables, cluttering a program's inner loops and slowing its execution. Instead, &pooma; uses &pete, the Portable Expression Template *************** *** 51,57 **** height h and to an entire field of particles with masses m and heights h. Our algorithm works with data-parallel syntax, and we would like to write the corresponding ! computer program using data-parallel syntax as well..

--- 51,57 ---- height h and to an entire field of particles with masses m and heights h. Our algorithm works with data-parallel syntax, and we would like to write the corresponding ! computer program using data-parallel syntax as well.

*************** std::cout << A-B << std::endl; *** 881,887 **** Data-parallel statements involving containers occur frequently in the inner loops of scientific programs so their ! efficient execution is important. A naive implementation for these statements may create and destroy containers holding intermediate values, slowing execution considerably. In 1995, Todd enumeration ! distinct &cc; integral type with named constants. These are frequently used in template programming because they can be used as template arguments. --- 314,327 ---- enumeration ! ! ! enumeration ! ! &cc; integral type with named constants. These are frequently used in template programming because they can be used as template arguments. *************** *** 324,330 **** external guard layer ! guard layer surrounding a container's domain used to ease computation along the domain's edges by permitting the same computations as for more internal computations. It is an optimization, not required --- 335,350 ---- external guard layer ! ! ! guard layer ! external ! ! ! external guard layer ! guard layer, external. ! ! guard layer surrounding a container's domain used to ease computation along the domain's edges by permitting the same computations as for more internal computations. It is an optimization, not required *************** *** 382,394 **** function template ! a definition of an unbounded set of related functions, all ! having the same name but whose parameter types can depend on ! template parameters. They are particularly useful when ! overloading operator ! functions to accept parameters that themselves depend ! on templates. --- 402,434 ---- function template ! ! ! function ! template ! ! a definition of an unbounded set of related functions, all having ! the same name but whose types can depend on template parameters. ! They are particularly useful when overloading ! ! overloaded function ! function, overloaded. ! ! ! function ! overloaded ! ! operator ! functions ! ! operator function ! function, operator. ! ! ! function ! operator ! ! to accept parameters that themselves depend on templates. *************** *** 399,417 **** guard layer ! domain surrounding each patch of a container's domain. It contains read-only values. External guard layers ease programming, while internal guard layers permit each patch's computation to be occur without copying values from adjacent patches. They are optimizations, not ! required for program correctness. external guard ! layer internal guard ! layer partition patch domain --- 439,460 ---- guard layer ! ! ! guard layer ! ! domain surrounding each patch of a container's domain. It contains read-only values. External guard layers ease programming, while internal guard layers permit each patch's computation to be occur without copying values from adjacent patches. They are optimizations, not ! required for program correctness. ! external guard layer ! internal ! guard layer ! partition patch domain *************** *** 448,454 **** internal guard layer ! guard layer containing copies of adjacent patches' values. These copies can permit an individual patch's computation to occur without asking adjacent patches for values. This can speed computation but are --- 491,506 ---- internal guard layer ! ! ! guard layer ! internal ! ! ! internal guard layer ! guard layer, internal. ! ! guard layer containing copies of adjacent patches' values. These copies can permit an individual patch's computation to occur without asking adjacent patches for values. This can speed computation but are *************** *** 498,503 **** --- 550,560 ---- M + + matrix + + + mesh *************** *** 516,524 **** operator function ! function defining an operator's code. For example, ! operator+ defines the result of using the ! +. --- 573,586 ---- operator function ! ! ! function ! operator ! ! function defining a function invoked using a &cc; operator. For ! example, the operator+ function defines the ! result of using the +. *************** *** 545,551 **** patch ! subset of a container's domain with values computed by a particular context. A partition splits a domain into patches. It may be surrounded by external and internal guard layers. partition --- 607,617 ---- patch ! ! ! patch ! ! subset of a container's domain with values computed by a particular context. A partition splits a domain into patches. It may be surrounded by external and internal guard layers. partition *************** *** 568,574 **** programming time ! time in the process from writing a program to executing it when the program is being written by a programmer. compile time run time --- 634,644 ---- programming time ! ! ! programming time ! ! in the process from writing a program to executing it, the time when the program is being written by a programmer. compile time run time *************** *** 613,619 **** run time ! time in the process from writing a program to executing it when the program is executed. This is also called execution time. compile time --- 683,697 ---- run time ! ! ! run time ! ! ! execution time ! run time. ! ! in the process from writing a program to executing it, the time when the program is executed. This is also called execution time. compile time *************** *** 654,665 **** stride ! a subset of regularly-spaced points in an integral ! interval. For example, the set of points a, a+2, a+4, …, ! b-2, b is specified by [a,b] with stride 2. It is a ! domain. range ! interval domain --- 732,743 ---- stride ! spacing between regularly-spaced points in a domain. For ! example, the set of points a, a+2, a+4, …, b-2, b is ! specified by [a,b] with stride 2. It is a domain. range ! interval domain *************** *** 681,690 **** T template instantiation ! applying a template class to template parameters to create a type. For example, foo<double,3> instantiates template <typename T, int n> class foo with the type &double; and the constant --- 759,788 ---- T + + template + + + + template + + class or function definition having template parameters. + These parameters' values are used at compile time, not run time, + so they may include types and other compile-time values. + + template instantiation + template specialization + + + template instantiation ! ! ! template instantiation ! ! applying a template class to template parameter arguments to create a type. For example, foo<double,3> instantiates template <typename T, int n> class foo with the type &double; and the constant *************** *** 696,702 **** template specialization ! class or function definition for a particular (special) subset of template arguments. --- 794,804 ---- template specialization ! ! ! template specialization ! ! class or function definition for a particular (special) subset of template arguments. *************** *** 724,730 **** trait ! a characteristic of a type. traits class --- 826,836 ---- trait ! ! ! trait ! ! a characteristic of a type. traits class *************** *** 732,739 **** traits class ! a class containing one or more traits all describing a ! particular type's chacteristics. trait --- 838,849 ---- traits class ! ! ! traits class ! ! a class containing one or more traits all describing a particular ! type's chacteristics. trait *************** *** 771,783 **** view of a container ! a container derived from another. The former's domain is a subset of the latter's, but, where the domains intersect, accessing a value through the view is the same as accessing it through the original container. In Fortran 90, these are called array sections. Only &array;s, &dynamicarray;s, and ! &field;s support views. container --- 881,893 ---- view of a container ! a container derived from another. The view's domain is a subset of the latter's, but, where the domains intersect, accessing a value through the view is the same as accessing it through the original container. In Fortran 90, these are called array sections. Only &array;s, &dynamicarray;s, and ! &field;s support views. ! container Index: introduction.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/introduction.xml,v retrieving revision 1.3 diff -c -p -r1.3 introduction.xml *** introduction.xml 2002/01/14 17:33:34 1.3 --- introduction.xml 2002/01/24 04:56:35 *************** *** 20,32 **** automatic creation of all interprocessor communication for ! parallel and distributed programs - several container storage classes to reduce a program's - storage requirements, and - - automatic out-of-order execution and loop rearrangement for fast program execution. --- 20,28 ---- automatic creation of all interprocessor communication for ! parallel and distributed programs, and automatic out-of-order execution and loop rearrangement for fast program execution. *************** *** 44,50 ****

&pooma; Goals ! The goals for the &poomatoolkit; have remained unchanged since its conception in 1994: --- 40,50 ----

&pooma; Goals ! ! &pooma; ! goals ! ! The goals for the &poomatoolkit; have remained unchanged since its conception in 1994: *************** *** 74,89 **** Code Portability for Sequential and Distributed Programs ! The same &pooma; programs run on sequential, distributed, and parallel computers. No change in source code is required. Two or ! three lines specifying how each container's domain should be distributed among available processors. Using these directives and run-time information about the computer's configuration, the &toolkit; automatically distributes pieces of the container domains, called patches, among the available processors. If a computation needs values from ! another patch, &pooma; automatically passes the value to the patch where it is needed. The same program, and even the same executable, works regardless of the number of the available processors and the size of the containers' domains. A programmer interested in only --- 74,92 ---- Code Portability for Sequential and Distributed Programs ! ! code portability ! ! The same &pooma; programs run on sequential, distributed, and parallel computers. No change in source code is required. Two or ! three lines specify how each container's domain should be distributed among available processors. Using these directives and run-time information about the computer's configuration, the &toolkit; automatically distributes pieces of the container domains, called patches, among the available processors. If a computation needs values from ! another patch, &pooma; automatically passes the values to the patch where it is needed. The same program, and even the same executable, works regardless of the number of the available processors and the size of the containers' domains. A programmer interested in only *************** *** 92,116 **** Rapid Application Development ! The &poomatoolkit; is designed to enable rapid development of scientific and distributed applications. For example, its vector, matrix, and tensor classes model the corresponding mathematical concepts. Its &array; and &field; classes model the discrete spaces ! and mathematical arrays frequently found in computational science and ! math. See . ! The left column indicates theoretical science and math concepts, the ! middle column computational science and math concepts, and the right ! column computer science implementations. For example, theoretical ! physics frequently uses continuous fields in three-dimension space, ! while algorithms for a corresponding computational physics problem ! usually uses discrete fields. &pooma; containers, classes, and ! functions ease engineering computer programs for these algorithms. ! For example, the &pooma; &field; container models discrete fields; ! both map locations in discrete space to values and permit ! computations of spatial distances and values. The &pooma; &array; ! container models the mathematical concept of an array, used in ! numerical analysis.

How &pooma; Fits Into the Scientific Process --- 95,125 ---- Rapid Application Development ! ! rapid development ! ! The &poomatoolkit; is designed to enable rapid development of scientific and distributed applications. For example, its vector, matrix, and tensor classes model the corresponding mathematical concepts. Its &array; and &field; classes model the discrete spaces ! and mathematical arrays frequently found in computational science ! and math. See . The left column ! indicates theoretical science and math concepts, the middle column ! computational science and math concepts, and the right column ! computer science implementations. For example, theoretical physics ! frequently uses continuous fields in three-dimension space, while ! algorithms for a corresponding computational physics problem usually ! uses discrete fields. &pooma; containers, classes, and functions ! ease engineering computer programs for these algorithms. For ! example, the &pooma; &field; container models discrete fields: both ! map locations in discrete space to values and permit computations of ! spatial distances and values. The &pooma; &array; container models ! the mathematical concept of an array, frequently used in numerical ! analysis. + +

How &pooma; Fits Into the Scientific Process *************** *** 121,129 **** &pooma; helps translate algorithms into programs.

--- 130,138 ---- &pooma; helps translate algorithms into programs. *************** *** 131,191 **** &pooma; containers support a variety of computation modes, easing translation of algorithms into code. For example, many algorithms for solving partial differential equations use ! stencil-based computations. &pooma; supports stencil-based ! computations on &array;s and &field;s. It also supports ! data-parallel computation similar to &fortran 90 syntax. For ! computations where one &field;'s values is a function of several ! other &field;'s values, the programmer can specify a relation. ! Relations are lazily evaluated: whenever the dependent &field;'s ! values are needed and it is dependent on a &field; whose values have ! changed, its values are computed. Lazy evaluation also assists ! correctness by eliminating the frequently forgotten need for a ! programmer to ensure a &field;'s values are up-to-date before being ! used.Efficient Code&pooma; incorporates a variety of techniques to ensure it ! produces code that executes as quickly as special-case, ! hand-written code. ! ! These techniques include extensive use of templates, out-of-order ! evaluation, use of guard layers, and production of fast inner loops. ! ! &pooma;'s uses of &cc; templates permits the expressiveness ! from using pointers and function arguments but ensures as much as ! work as possible occurs at compile time, not run time. This speeds ! programs' execution. Since more code is produced at compile time, ! more code is available to the compiler's optimizer, further speeding ! execution. The &pooma; &array; container benefits from the use of ! template parameters. Their use permits the use of specialized data ! storage classes called engines. An ! &array;'s &engine; template parameter specifies how data is stored and ! indexed. Some &array;s expect almost all values to be used, while ! others might be mostly vacant. In the latter case, using a specialized engine storing the few nonzero values greatly reduces ! space requirements. Using engines also permits fast creation of ! container views, known as array sections in ! Fortran 90. A view's engine is the same as the original ! container's engine, but the view object maps its restricted domain to ! the original domain. Space requirements and execution time to use ! views are minimal. Using templates also permits containers to ! support polymorphic indexing, e.g., indexing both by integers and by ! three-dimensional coordinates. A container defers indexing ! operations to its engine's templatized index operator. Since it uses ! templates, the &engine; can define indexing functions with different ! function arguments, without the need to add corresponding container ! functions. Some of these benefits of using templates can be ! expressed without them, but doing so increases execution time. For ! example, a container could have a pointer to an engine object, but ! this requires a pointer dereference for each operation. Implementing ! polymorphic indexing without templates would require adding virtual ! functions corresponding to each of the indexing functions. ! To ensure multiprocessor &pooma; programs execute quickly, it is important that interprocessor communication overlaps with intraprocessor computations as much as possible and that communication is minimized. Asynchronous communication, out-of-order --- 140,235 ---- &pooma; containers support a variety of computation modes, easing translation of algorithms into code. For example, many algorithms for solving partial differential equations use ! stencil-based computations so &pooma; supports stencil-based ! computations on &array;s and &field;s. &pooma; also supports ! data-parallel computation similar to &fortran 90 syntax. ! ! relation ! ! To ease implementing computations where one &field;'s values are a ! function of several other &field;'s values, the programmer can ! specify a relation. Relations are ! lazily evaluated: whenever the dependent &field;'s values are needed ! and they are dependent on a &field; whose values have changed, the ! values are computed. Relations also assists correctness by ! eliminating the frequently forgotten need for a programmer to ensure ! a &field;'s values are up-to-date before being used. Efficient Code &pooma; incorporates a variety of techniques to ensure it ! produces code that executes as quickly as special-case, hand-written ! code. These techniques include extensive use of templates, ! out-of-order evaluation, use of guard layers, and production of fast ! inner loops. ! ! ! templates ! use ! ! &pooma;'s uses of &cc; templates ensures as much as work as possible ! occurs at compile time, not run time. This speeds programs' ! execution. Since more code is produced at compile time, more code ! is available to the compiler's optimizer, further speeding ! execution. ! ! engines ! ! The &pooma; &array; container benefits from the use of template ! parameters. Their use permits the use of specialized data storage ! classes called engines. An ! &array;'s &engine; template parameter specifies how data is stored ! and indexed. Some &array;s expect almost all values to be used, ! while others might be mostly empty. In the latter case, using a specialized engine storing the few nonzero values greatly reduces ! storage requirements. Using engines also permits fast creation of ! container views, known as array ! sectionsarray sections ! in &fortran; 90. A view's engine is the same as the original ! container's engine, but the view object's restricted domain is a ! subset of the original domain. Space requirements and execution ! time to use views are minimal. ! + + + polymorphic indexing + + Using templates also permits containers to support polymorphic + indexing, e.g., indexing both by integers and by three-dimensional + coordinates. A container uses templatized indexing functions that + defer indexing operations to its engine's index operators. Since + the container uses templates, the &engine; can define indexing + functions with different function arguments, without the need to add + corresponding container functions. Some of these benefits of using + templates can be expressed without them, but doing so increases + execution time. For example, a container could have a pointer to an + engine object, but this requires a pointer dereference for each + operation. Implementing polymorphic indexing without templates + would require adding virtual functions corresponding to each of the + indexing functions. + + + ! ! ! asynchronous communication ! ! ! &cheetah; ! ! To ensure multiprocessor &pooma; programs execute quickly, it is important that interprocessor communication overlaps with intraprocessor computations as much as possible and that communication is minimized. Asynchronous communication, out-of-order *************** *** 199,241 **** sender to put and get data without synchronizing with the recipient processor, and it also permits invoking functions at remote sites to ensure desired data is up-to-date. Thus, out-of-order evaluation must be supported. Out-of-order evaluation also has another benefit: Only computations directly or indirectly related to values that are ! printed need occur. ! Surrounding a patch with guard layers can help reduce interprocessor communication. For distributed computation, each container's domain is split into pieces distributed among the available processors. Frequently, computing a container value is local, involving just the ! value itself and a few neighbors, but computing a value near the edge ! of a processor's domain may require knowing a few values from a neighboring domain. Guard layers permit these values to be copied locally so they need not be repeatedly communicated. ! &pooma; uses &pete; technology to ensure inner loops involving &pooma;'s object-oriented containers run as quickly as hand-coded ! ! loops. &pete; (the Portable Expression Template Engine) uses ! expression-template technology to convert data-parallel statements ! in the inner loops of programs into efficient loops ! without any intermediate computations. For example, consider ! evaluating the statement ! ! A += -B + 2 * C; ! where A and C are vector<double>s and B is a ! vector<int>. Naive evaluation might introduce intermediaries for -B, 2*C, and their sum. The presence of these ! intermediaries in inner loops can measurably slow evaluation. To produce a loop without intermediaries, &pete; stores each expression ! as a parse tree. The resulting parse trees can be combined into a ! larger parse tree. Using its templates, the parse tree is converted, ! at compile time, to a loop evaluating each component of the result. ! Thus, no intermediate values are computed or stored. For example, ! the code corresponding to the statement above is vector<double>::iterator iterA = A.begin(); vector<int>::const_iterator iterB = B.begin(); --- 243,308 ---- sender to put and get data without synchronizing with the recipient processor, and it also permits invoking functions at remote sites to ensure desired data is up-to-date. Thus, out-of-order evaluation + + out-of-order evaluation + + + evaluation + out-of-order + out-of-order evaluation. + + must be supported. Out-of-order evaluation also has another benefit: Only computations directly or indirectly related to values that are ! printed need occur. ! ! ! ! guard layer ! ! Surrounding a patch with guard layers can help reduce interprocessor communication. For distributed computation, each container's domain is split into pieces distributed among the available processors. Frequently, computing a container value is local, involving just the ! value itself and a few neighbors, but computing a value near the ! edge of a processor's domain may require knowing a few values from a neighboring domain. Guard layers permit these values to be copied locally so they need not be repeatedly communicated. ! ! ! &pete; ! ! ! Portable Expression Template Engine ! &pete;. ! ! ! inner-loop evaluation ! ! &pooma; uses &pete; technology to ensure inner loops involving &pooma;'s object-oriented containers run as quickly as hand-coded ! loops. &pete; (the Portable Expression Template ! Engine) uses expression-template technology to convert data-parallel ! statements into efficient loops without any intermediate ! computations. For example, consider evaluating the statement ! ! A += -B + 2 * C; ! where A and C are vector<double>s and B is a ! vector<int>. &naivecap; evaluation might introduce intermediaries for -B, 2*C, and their sum. The presence of these ! intermediaries in inner loops can measurably slow performance. To produce a loop without intermediaries, &pete; stores each expression ! as a parse tree. Using its templates, the parse tree is ! converted, at compile time, to a loop directly evaluating each component of ! the result without computing intermediate values. ! For example, the code corresponding to the statement above is vector<double>::iterator iterA = A.begin(); vector<int>::const_iterator iterB = B.begin(); *************** *** 244,267 **** *iterA += -*iterB + 2 * *iterC; ++iterA; ++iterB; ++iterC; } ! Furthermore, since the code is available at compile, not run, time, it can be further optimized, e.g., moving any loop-invariant code out of the loop. Used for Diverse Set of Scientific Problems &pooma; has been used to solve a wide variety of scientific problems. Most recently, physicists at Los Alamos National ! Laboratory implemented an entire library of hydrodynamics codes as part of the U.S. government's science-based Stockpile Stewardship ! Program to simulate nuclear weapons. Other applications include a matrix solver, an accelerator code simulating the dynamics of high-intensity charged particle beams in linear accelerators, and a ! Monte Carlo neutron transport code. Easy Implementation ! &pooma;'s tools greatly reduce the time to implement applications. As we noted above, &pooma;'s containers and expression syntax model the computational models and algorithms most frequently found in scientific programs. These high-level tools are known to be --- 311,357 ---- *iterA += -*iterB + 2 * *iterC; ++iterA; ++iterB; ++iterC; } ! Furthermore, since the code is available at compile time, not run time, it can be further optimized, e.g., moving any loop-invariant code out of the loop. + Used for Diverse Set of Scientific Problems &pooma; has been used to solve a wide variety of scientific problems. Most recently, physicists at Los Alamos National ! Laboratory ! ! Los Alamos National Laboratory ! ! implemented an entire library of hydrodynamics codes ! ! hydrodynamics ! ! as part of the U.S. government's science-based Stockpile Stewardship ! Program ! ! Stockpile Stewardship Program ! ! to simulate nuclear weapons. Other applications include a matrix solver, an accelerator code simulating the dynamics of high-intensity charged particle beams in linear accelerators, and a ! Monte Carlo ! ! Monte Carlo simulation ! ! neutron transport code. + Easy Implementation ! ! ! &pooma; ! ease of writing programs ! ! &pooma;'s tools greatly reduce the time to implement applications. As we noted above, &pooma;'s containers and expression syntax model the computational models and algorithms most frequently found in scientific programs. These high-level tools are known to be *************** *** 271,280 **** computers. With no additional work, the same program runs on computers with hundreds of processors; the code is exactly the same, and the &toolkit; automatically handles distribution of the data, all ! data communication, and all synchronization. The net results is a significant reduction in programming time. For example, a team of two physicists and two support people at Los Alamos National ! Laboratory implemented a suite of hydrodynamics kernels in six months. Their work replaced a previous suite of less-powerful kernels which had taken sixteen people several years to implement and debug. Despite not have previously implemented any of the kernels, --- 361,378 ---- computers. With no additional work, the same program runs on computers with hundreds of processors; the code is exactly the same, and the &toolkit; automatically handles distribution of the data, all ! data communication, and all synchronization. The net result is a significant reduction in programming time. For example, a team of two physicists and two support people at Los Alamos National ! Laboratory ! ! Los Alamos National Laboratory ! ! implemented a suite of hydrodynamics kernels ! ! hydrodynamics ! ! in six months. Their work replaced a previous suite of less-powerful kernels which had taken sixteen people several years to implement and debug. Despite not have previously implemented any of the kernels, *************** *** 283,352 ****

&pooma; Produces Fast Programs almost as fast as &c;. wide variety of configurations: one processor, many processors, give performance data for at least two ! different programs ! HERE ! describe &doof2d; here &doof2d; is a two-dimensional diffusion simulation program. Initially, all values in the square two-dimensional grid are zero ! except for the central value. ! ! HERE

&pooma; is Free, Open-Source Software The &poomatoolkit; is open-source software. Anyone may download, read, redistribute, and modify the &pooma; source code. ! If an application requires a specialized container, any programmer ! may add it. Any programmer can extend it to solve problems in ! previously unsupported domains. Companies using the &toolkit; can ! read the source code to ensure it has no hidden back doors or ! security holes. It may be downloaded for free and used for ! perpetuity. There are no annual licenses and no on-going costs. By ! keeping their own copies, companies are guaranteed the software will ! never disappear. In summary, the &poomatoolkit; is free, low-risk ! software.

History of &pooma; The &poomatoolkit; was developed at Los Alamos National ! Laboratory to assist nuclear fusion and fission research. In 1994, the &toolkit; grew out of the Object-Oriented Particle Simulation ! class library developed for particle-in-cell simulations. The goals of the Framework, as it was called at the time, were driven by the ! Numerical Tokamak's Parallel Platform Paradox:

The average time required to implement a moderate-sized application on a parallel computer architecture is equivalent to the half-life of the latest parallel supercomputer.

The framework's goal of being able to quickly write efficient scientific code that could be run on a wide variety of platforms remains unchanged today. Development, mainly at the ! Advanced Computing Laboratory at Los Alamos, proceeded rapidly. ! A matrix solver application was written using the framework. ! Support for hydrodynamics, Monte Carlo simulations, and molecular ! dynamics modeling soon followed. ! ! By 1998, &pooma; was part of the U.S. Department of ! Energy's Accelerated Strategic Computing Initiative ! (ASCI). The Comprehensive Test Ban Treaty forbid nuclear weapons testing so they were instead simulated using computers. ASCI's goal was to radically advance the state of the art in high-performance computing and numerical --- 381,516 ----

+ &pooma; Produces Fast Programs almost as fast as &c;. wide variety of configurations: one processor, many processors, give performance data for at least two ! different programs UNFINISHED ! describe &doof2d; at this location &doof2d; is a two-dimensional diffusion simulation program. Initially, all values in the square two-dimensional grid are zero ! except for the central value. UNFINISHED + ]]>

&pooma; is Free, Open-Source Software + + open-source software + + + &pooma; + open-source + + The &poomatoolkit; is open-source software. Anyone may download, read, redistribute, and modify the &pooma; source code. ! If an application requires a specialized container not already ! available, any programmer may add it. Any programmer can extend it ! to solve problems in previously unsupported domains. Companies ! using the &toolkit; can read the source code to ensure it has no ! security holes. It may be downloaded for free ! and used for perpetuity. There are no annual licenses and no ! on-going costs. By keeping their own copies, companies are ! guaranteed the software will never disappear. In summary, the ! &poomatoolkit; is free, low-risk software.

History of &pooma; + + &pooma; + history + + + Los Alamos National Laboratory + + The &poomatoolkit; was developed at Los Alamos National ! Laboratory to assist nuclear fusion ! ! fusion ! ! and fission ! ! fission ! ! research. In 1994, the &toolkit; grew out of the Object-Oriented Particle Simulation ! ! Object-Oriented Particle Simulation Library ! ! Class Library developed for particle-in-cell simulations. The goals of the Framework, as it was called at the time, were driven by the ! Numerical Tokamak's ! ! Tokamak ! ! Parallel Platform Paradox:

The average time required to implement a moderate-sized application on a parallel computer architecture is equivalent to the half-life of the latest parallel supercomputer.

+ + Parallel Platform Paradox + The framework's goal of being able to quickly write efficient scientific code that could be run on a wide variety of platforms remains unchanged today. Development, mainly at the ! Advanced Computing Laboratory ! ! Los Alamos National Laboratory ! Advanced Computing Laboratory ! ! at Los Alamos, proceeded rapidly. A matrix solver application was ! written using the framework. ! Support for hydrodynamics, ! ! hydrodynamics ! ! Monte Carlo simulations, ! ! Monte Carlo simulation ! ! and molecular dynamics ! ! molecular dynamics modeling ! ! modeling soon followed. ! ! ! By 1998, &pooma; was part of the U.S. Department of ! Energy's ! ! Department of Energy ! ! Accelerated Strategic Computing Initiative ! (ASCI). ! ! Department of Energy ! Accelerated Strategic Computing Initiative ! ! ! Accelerated Strategic Computing Initiative ! Department of Energy, Accelerated Strategic Computing Initiative. ! ! The Comprehensive Test Ban Treaty ! ! Comprehensive Test Ban Treaty ! ! forbid nuclear weapons testing so they were instead simulated using computers. ASCI's goal was to radically advance the state of the art in high-performance computing and numerical *************** HERE *** 361,388 **** &pooma; 2 involved a new conceptual framework and a complete rewriting of the source code to improve performance. The ! &array; class was introduced with its use of &engine;s, separating ! container use from container storage. An asynchronous scheduler ! permitted out-of-order execution to improve cache coherency. Incorporating the Portable Expression Template Engine (PETE) ! permitted faster loop execution. Soon, container views and ! ConstantFunction and IndexFunction ! &engine;s were added. Release 2.1.0 included &field;s with ! their spatial extent and &dynamicarray;s with the ability to ! dynamically change its domain size. Support for particles and their interaction with &field;s were added. The &pooma; messaging implementation was revised in release 2.3.0. Use of the ! &cheetah; Library separated &pooma; from the actual messaging library used, and support for applications running on clusters of computers was added. CodeSourcery, LLC, and ! Proximation, LLC, took over &pooma; development from Los Alamos National Laboratory. During the past two years, the &field; ! abstraction and implementation was improved to increase its flexibility, add support for multiple values and materials in the ! same cell, and permit lazy evaluation. Simultaneously, the execution speed of the inner loops was greatly increased.

--- 525,609 ---- &pooma; 2 involved a new conceptual framework and a complete rewriting of the source code to improve performance. The ! &array; class ! ! &array; ! ! was introduced with its use of &engine;s, ! ! &engine; ! ! separating ! container use from container storage. A new asynchronous scheduler ! permitted out-of-order execution ! ! out-of-order evaluation ! ! to improve cache coherency. Incorporating the Portable Expression Template Engine (PETE) ! ! &pete; ! ! permitted faster loop execution. Soon, container views ! ! container ! view ! ! and ! ConstantFunction ! ! &engine; ! ConstantFunction ! ! and IndexFunction ! ! &engine; ! IndexFunction ! ! &engine;s were added. Release 2.1.0 included &field;s ! ! &field; ! ! with ! their spatial extent and &dynamicarray;s ! ! &dynamicarray; ! ! with the ability to ! dynamically change domain size. Support for particles and their interaction with &field;s were added. The &pooma; messaging implementation was revised in release 2.3.0. Use of the ! &cheetah; Library ! ! &cheetah; ! ! separated &pooma; from the actual messaging library used, and support for applications running on clusters of computers was added. CodeSourcery, LLC, ! ! CodeSourcery, LLC ! ! and ! Proximation, LLC, ! ! Proximation, LLC ! ! took over &pooma; development from Los Alamos National Laboratory. During the past two years, the &field; ! abstraction ! ! &field; ! ! and implementation was improved to increase its flexibility, add support for multiple values and materials in the ! same cell, and permit lazy evaluation. ! ! lazy evaluation ! ! Simultaneously, the execution speed of the inner loops was greatly increased. Index: manual.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/manual.xml,v retrieving revision 1.8 diff -c -p -r1.8 manual.xml *** manual.xml 2002/01/22 15:48:49 1.8 --- manual.xml 2002/01/24 04:56:38 *************** *** 1,4 **** --- 1,6 ---- + + + + + + + + *************** *** 158,163 **** --- 166,173 ---- + + d"> *************** *** 173,194 **** ! http://pooma.codesourcery.com/pooma/download'> ! http://www.pooma.com/'> ! ! ! --- 183,210 ---- ! http://pooma.codesourcery.com/pooma/download'> ! http://www.pooma.com/'> ! ! ! ! + + + + + *************** *** 260,277 **** CodeSourcery, LLC ! 2001CodeSourcery, LLC () ! Los Alamos National Laboratory All rights reserved. This document may not be redistributed in any form without the express permission of the author. ! 0.01 ! 2002 Jan 14 jdo ! first draft --- 276,293 ---- CodeSourcery, LLC ! 2002CodeSourcery, LLC () ! Los Alamos National Laboratory All rights reserved. This document may not be redistributed in any form without the express permission of the author. ! 1.00 ! 2002 Jan 23 jdo ! First publication. *************** *** 279,284 **** --- 295,301 ---- + Preface *************** *** 338,349 **** --- 355,369 ---- + ]]> + Programming with &pooma; + ]]> &introductory-chapter; *************** *** 420,429 **** components of each vector in an &array; to form its own &array;. Since each container has one or more &engine;s, we can also describe the latter category as containers that compute their ! values using other containers' values. A MultiPatch ! &engine; distributes its domain among various processors and ! memory spaces, each responsible for computing values associated ! with a portion, or patch, of the domain. Just as multiple containers can use the same engine, multiple &engine;s can use the same underlying data. As we --- 440,449 ---- components of each vector in an &array; to form its own &array;. Since each container has one or more &engine;s, we can also describe the latter category as containers that compute their ! values using other containers' values. A &multipatch; &engine; ! distributes its domain among various processors and memory spaces, ! each responsible for computing values associated with a portion, ! or patch, of the domain. Just as multiple containers can use the same engine, multiple &engine;s can use the same underlying data. As we *************** *** 491,497 **** &dynamic; is a one-dimensional &brick; with dynamically ! resizable domain. HERE ever explicitly declare these? &engine;s That Compute --- 511,518 ---- &dynamic; is a one-dimensional &brick; with dynamically ! resizable domain. This should be used with &dynamicarray;, ! not &array;. &engine;s That Compute *************** *** 620,626 **** operator() take Loc<1> or one ∫ parameter. In addition, the one-dimensional domain can be dynamically resized using create ! and destroy; see . HERE Dynamic. How does one change the domain size? What is the model? --- 641,647 ---- operator() take Loc<1> or one ∫ parameter. In addition, the one-dimensional domain can be dynamically resized using create ! and destroy; see . HERE Dynamic. How does one change the domain size? What is the model? *************** HERE Dynamic. How does one change the do *** 696,708 **** --- 717,780 ---- Container Views + + container + view + + + view of a container + container, view. + + + A view of a + container &container; is a container + accessing a subset of &container;'s domain &containerdomain; + and values. The subset can include all of &containerdomain;. + A view is so named because it is a different way to + access, or view, another container's values. Both the container + and its view share the same underlying engine so changing values in + one also changes them in the other. + + A view is created by following a container's name by + parentheses containing a domain &containerdomain;. For + example, consider this code extracted from in . + + Interval<1> N(0, n-1); + Interval<2> vertDomain(N, N); + Interval<1> I(1,n-2); + Interval<1> J(1,n-2); + Array<2, double, Brick> a(vertDomain); + Array<2, double, Brick> b(vertDomain); + a(I,J) = (1.0/9.0) * + (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + + b(I ,J+1) + b(I ,J ) + b(I ,J-1) + + b(I-1,J+1) + b(I-1,J ) + b(I-1,J-1)); + The last statement creates ten views. For example, + + a(I,J) creates a view of + a using the smaller domain specified by + I and J. This omits the + outermost rows of columns of a. The views + of b illustrate the use of views in + data-parallel statements. b(I-1,J-1) has a + subset shifted up one row and left one column compared with + b(I,J). + ]]> + Be sure to list the various arithmetic operations on domains that can be used. This was deferred from the &array; and domain chapter. Explain &array;'s comp function. + ]]> + + Writing Sequential Programs *************** UNFINISHED *** 1086,1095 **** dependence computations, so the &author; recommends calling Pooma::blockAndEvaluate before each access to a particular value in an &array; or &field;. Omitting a necessary ! call may lead to a race condition. See for instructions how to diagnose and eliminate these race ! conditions.Where talk about various &pooma; streams? --- 1158,1171 ---- dependence computations, so the &author; recommends calling Pooma::blockAndEvaluate before each access to a particular value in an &array; or &field;. Omitting a necessary ! call may lead to a race condition. ! for instructions how to diagnose and eliminate these race ! conditions. ! ]]> ! Where talk about various &pooma; streams? *************** UNFINISHED *** 1193,1199 **** in the input domain: A(i1, i2, ..., iN).The &pooma; multidimensional Array concept is similar to ! the &fortran; 90 array facility, but extends it in several ways. Both &pooma; and &fortran; arrays can have up to seven dimensions, and can serve as containers for arbitrary types. Both support the notion of views of a portion of the --- 1269,1275 ---- in the input domain: A(i1, i2, ..., iN).The &pooma; multidimensional Array concept is similar to ! the &fortran; 90 array facility, but extends it in several ways. Both &pooma; and &fortran; arrays can have up to seven dimensions, and can serve as containers for arbitrary types. Both support the notion of views of a portion of the *************** UNFINISHED *** 1492,1498 **** &pooma; II's expression trees and expression engines. ! MultiPatch Engine From README: To actually use multiple contexts effectively, you need to use the MultiPatch engine with --- 1568,1574 ---- &pooma; II's expression trees and expression engines. ! &multipatch; Engine From README: To actually use multiple contexts effectively, you need to use the MultiPatch engine with *************** UNFINISHED *** 1508,1515 **** --- 1584,1593 ---- + ]]> + Writing Distributed Programs *************** UNFINISHED *** 1562,1569 **** --- 1640,1649 ---- + ]]> + Debugging and Profiling &pooma; Programs *************** UNFINISHED *** 1607,1615 **** --- 1687,1700 ---- region's size should reveal where calls are missing. + ]]> + + + ]]> + &pooma; Reference Manual *************** UNFINISHED *** 3489,3496 **** --- 3574,3583 ---- + ]]> + Future Development *************** UNFINISHED *** 3610,3615 **** --- 3697,3703 ---- + ]]> *************** UNFINISHED *** 3644,3650 **** Download the library from the &pooma; Download page ! available off the &pooma; home page (&poomaHomePage;). Extract the source code using tar xzvf --- 3732,3738 ---- Download the library from the &pooma; Download page ! available off the &pooma; home page (&poomahomepage;). Extract the source code using tar xzvf *************** UNFINISHED *** 3715,3721 **** Download the library from the &pooma; Download page ! available off the &pooma; home page (&poomaHomePage;). Extract the source code using tar xzvf --- 3803,3809 ---- Download the library from the &pooma; Download page ! available off the &pooma; home page (&poomahomepage;). Extract the source code using tar xzvf *************** UNFINISHED *** 3863,3868 **** --- 3951,3957 ---- + Dealing with Compilation Errors *************** UNFINISHED *** 4039,4044 **** --- 4128,4134 ---- + ]]> &bibliography-chapter; Index: template.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/template.xml,v retrieving revision 1.1 diff -c -p -r1.1 template.xml *** template.xml 2002/01/14 17:33:34 1.1 --- template.xml 2002/01/24 04:56:39 *************** *** 1,7 **** Programming with Templates ! &pooma; extensively uses &cc; templates to support type polymorphism without incurring any run-time cost. In this chapter, we briefly introduce using templates in &cc; programs by relating them to ordinary &cc; constructs such as values, --- 1,16 ---- Programming with Templates ! ! templates ! ! ! template programming ! templates ! ! ! &pooma; extensively uses &cc; templates to support type polymorphism without incurring any run-time cost. In this chapter, we briefly introduce using templates in &cc; programs by relating them to ordinary &cc; constructs such as values, *************** *** 9,69 **** templates will occur repeatedly: ! Template programming occurs at compile time, not run time. ! That is, template operations occur within the compiler, not when ! a program runs. ! Templates permit declaring families of classes using a ! single declaration. For example, the &array; template ! declaration permits using arrays with many different value types, e.g., arrays of integers, arrays of floating point numbers, and arrays of arrays. ! For those interested in the implementation of &pooma;, we close ! with a discussion of some template programming concepts used in the ! implementation but not likely to be used by &pooma; users.

! Templates Occur at Compile-Time &pooma; uses &cc; templates to support type polymorphism without incurring any run-time cost as a program executes. All template operations are performed at compile time by the compiler. ! Prior to the introduction of templates, almost all a program's interesting computation occurred when it was executed. When writing the program, the programmer, at programming ! time, would specify which statements and ! expressions would occur and which types to use. At compile time, the compiler would convert the program's source code into an executable program. Even though the compiler uses the types to produce the executable, no interesting computation would occur. At run ! time, the resulting executable program would actually perform the operations. The introduction of templates permits interesting computation to occur while the compiler produces the executable. ! Most interesting is template instantiation, which produces a type at compile time. For example, the &array; type definition requires template parameters Dim, T, and EngineTag, specifying ! its dimension, the type of its elements, and its &engine; type. To use this, a programmer specifies values for the template parameters: Array<2,double,Brick> ! specifies a dimension of 2, an element type of &double;, and the ! &brick; &engine; type. At compile time, the compiler creates a type ! definition by substituting the values for the template parameters ! in the template definition. The substitution is analogous to the ! run-time application of a function to specific values. All computation not involving run-time input or output can occur at program time, compile time, or run time, whichever is --- 18,107 ---- templates will occur repeatedly: ! Template programming constructs execute at compile time, ! not run time. That is, template operations occur within the ! compiler, not when a program runs. ! Templates permit declaring families of classes using a ! single declaration. For example, the &array; ! ! &array; ! ! ! type polymorphism ! ! template ! declaration permits using &array;s with many different value types, e.g., arrays of integers, arrays of floating point numbers, and arrays of arrays. ! For those interested in the implementation of &pooma;, we close the ! section with a discussion of some template programming concepts ! used in the implementation but not likely to be used by &pooma; ! users.

! Templates Execute at Compile-Time ! ! ! compile time ! ! ! compiler ! &pooma; uses &cc; templates to support type polymorphism without incurring any run-time cost as a program executes. All template operations are performed at compile time by the compiler. ! Prior to the introduction of templates, almost all of a program's interesting computation occurred when it was executed. When writing the program, the programmer, at programming ! time, ! ! programming time ! ! would specify which statements and expressions will occur and ! which types to use. At compile time, the compiler would convert the program's source code into an executable program. Even though the compiler uses the types to produce the executable, no interesting computation would occur. At run ! time, ! ! run time ! ! the resulting executable program would actually perform the operations. The introduction of templates permits interesting computation to occur while the compiler produces the executable. ! Most interesting is template instantiation, ! ! template ! instantiation ! ! which produces a type at compile time. For example, the &array; type definition requires template parameters Dim, T, and EngineTag, specifying ! its dimension, the type of its values, and its &engine; type. To use this, a programmer specifies values for the template parameters: Array<2,double,Brick> ! specifies a dimension of 2, a value type of &double;, and the ! &brick; &engine; type. At compile time, the compiler creates a ! type definition by substituting the values for the template ! parameters in the templatized type definition. The substitution ! is analogous to the run-time application of a function to specific ! values. All computation not involving run-time input or output can occur at program time, compile time, or run time, whichever is *************** *** 71,83 **** computations by hand rather than writing code to compute it. &cc; templates are Turing-complete so they can compute anything computable. Unfortunately, syntax for compile-time computation is ! more difficult than for run-time computation, and also current compilers are not as efficient as code executed by hardware. ! Run-time &cc; constructs are Turing-complete so using templates is unnecessary. Thus, we can shift computation to the time which best trades off the ease of expressing syntax with the speed of computation by programmer, compiler, or computer chip. For ! example, &pooma; uses expression template technology to speed run-time execution of data-parallel statements. The &pooma; developers decided to shift some of the computation from run-time to compile-time using template computations. The resulting --- 109,129 ---- computations by hand rather than writing code to compute it. &cc; templates are Turing-complete so they can compute anything computable. Unfortunately, syntax for compile-time computation is ! more difficult than for run-time computation. Also current compilers are not as efficient as code executed by hardware. ! Run-time &cc; constructs are Turing-complete ! ! Turing complete ! ! so using templates is unnecessary. Thus, we can shift computation to the time which best trades off the ease of expressing syntax with the speed of computation by programmer, compiler, or computer chip. For ! example, &pooma; uses expression template technology ! ! expression templates ! ! to speed run-time execution of data-parallel statements. The &pooma; developers decided to shift some of the computation from run-time to compile-time using template computations. The resulting *************** *** 100,111 **** parameters, both of which are used in this book. ! template instantiation, i.e., specifying a particular ! type by specifying values for template parameters. ! nested type names, which are types specified within a ! class definition. We discuss each of these below. --- 146,170 ---- parameters, both of which are used in this book. ! template instantiation, ! ! template ! instantiation ! ! i.e., specifying a particular type by specifying values for ! template parameters. ! nested type names, ! ! nested type ! type, nested. ! ! ! type ! nested ! ! which are types specified within a class definition. We discuss each of these below. *************** *** 174,179 **** --- 233,242 ---- brackets (<>). For example, pair<int> instantiates + + template + instantiation + the pair template class definition with T equal to ∫. That is, the compiler creates a definition for pair<int> by copying *************** *** 184,193 **** The result is a definition exactly the same as pairOfInts. !

! Correspondences Between Run-Time and Compile-Time Programming Constructs --- 247,286 ---- The result is a definition exactly the same as pairOfInts. ! As we mentioned above, template instantiation ! ! template ! instantiation ! ! is analogous to function application. ! ! function ! application ! ! A template class is analogous to a ! function. The analogy between compile-time and run-time ! programming constructs can be extended. ! lists these correspondences. For example, at run time, values ! consist of things such as integers, floating point numbers, ! pointers, functions, and objects. Programs compute by operating ! on these values. The compile-time values ! ! compile time ! value ! ! include types, and ! compile-time operations use these types. For both run-time and ! compile-time programming, &cc; defines default sets of values that ! all conforming compilers must support. For example, ! 3 and 6.022e+23 are ! run-time values that any &cc; compiler must accept. It must also ! accept the ∫, &bool;, and int* types. ! !

! Correspondences Between Run-Time and Compile-Time Programming Constructs *************** *** 198,204 **** compile time ! values integers, strings, objects, functions, … --- 291,297 ---- compile time ! values integers, strings, objects, functions, … *************** *** 222,236 **** packaging repeated operations ! A function generalizes a particular operation applied to ! different values. The function parameters are placeholders ! for particular values. ! A template class generalizes a particular class ! definition using different types. The template parameters are ! placeholders for particular values. ! application Use a function by appending function arguments surrounded by parentheses. Use a template class by appending template arguments --- 315,342 ---- packaging repeated operations ! A function ! ! function ! ! generalizes a particular operation applied to different ! values. The function parameters are placeholders for ! particular values. ! A template class generalizes a particular class ! definition using different types. The template parameters ! are placeholders for particular values. ! application ! ! function ! application ! ! ! application ! function, application. ! ! Use a function by appending function arguments surrounded by parentheses. Use a template class by appending template arguments *************** *** 239,262 ****

- - As we mentioned above, template instantiation is analogous - to function application. A template class is analogous to a - function. The analogy between compile-time and run-time - programming constructs can be extended. - lists these correspondences. For example, at run time, values - consist of things such as integers, floating point numbers, - pointers, functions, and objects. Programs compute by operating - on these values. The compile-time values include types, and - compile-time operations use these types. For both run-time and - compile-time programming, &cc; defines default sets of values that - all conforming compilers must support. For example, - 3 and 6.022e+23 are - run-time values that any &cc; compiler must accept. It must also - accept the ∫, &bool;, and int* types. ! The set of supported run-time and compile-time values can be extended. Run-time values can be extended by creating new objects. Although not part of the default set of values, these objects are treated and operated on as values. To extend the set --- 345,359 ---- ! ! ! object ! ! ! class definition ! ! The set of supported run-time and compile-time values can be extended. Run-time values can be extended by creating new objects. Although not part of the default set of values, these objects are treated and operated on as values. To extend the set *************** *** 268,282 **** built-in types, these types can be used in the same way that any other types can be used, e.g., declaring variables. ! Functions generalize similar run-time operations, while template class generalize similar class definitions. A function definition generalizes a repeated run-time operation. For example, consider repeatedly printing the largest of two numbers: ! std::cout << (3 > 4 ? 3 : 4) << std::endl; ! std::cout << (4 > -13 ? 4 : -13) << std::endl; ! std::cout << (23 > 4 ? 23 : 4) << std::endl; ! std::cout << (0 > 3 ? 0 : 3) << std::endl; Each statement is exactly the same except for the repeated two values. Thus, we can generalize these statements writing a function: --- 365,383 ---- built-in types, these types can be used in the same way that any other types can be used, e.g., declaring variables. ! ! ! function ! ! Functions generalize similar run-time operations, while template class generalize similar class definitions. A function definition generalizes a repeated run-time operation. For example, consider repeatedly printing the largest of two numbers: ! std::cout &openopen; (3 > 4 ? 3 : 4) &openopen; std::endl; ! std::cout &openopen; (4 > -13 ? 4 : -13) &openopen; std::endl; ! std::cout &openopen; (23 > 4 ? 23 : 4) &openopen; std::endl; ! std::cout &openopen; (0 > 3 ? 0 : 3) &openopen; std::endl; Each statement is exactly the same except for the repeated two values. Thus, we can generalize these statements writing a function: *************** void maxOut(int a, int b) *** 285,294 **** { std::cout &openopen; (a > b ? a : b) &openopen; std::endl; } The function's body consists of the statement with variables substituted for the two particular values. Each parameter ! is a placeholder that, when used, holds one particular value among the ! set of possible integral values. The function must be named to permit ! its use, and declarations for its two parameters follow. Using the ! function simplifies the code: maxOut(3, 4); maxOut(4, -13); --- 386,395 ---- { std::cout &openopen; (a > b ? a : b) &openopen; std::endl; } The function's body consists of the statement with variables substituted for the two particular values. Each parameter ! variable is a placeholder that, when used, holds one particular value ! among the set of possible integral values. The function must be named ! to permit its use, and declarations for its two parameters follow. ! Using the function simplifies the code: maxOut(3, 4); maxOut(4, -13); *************** maxOut(0, 3); *** 298,306 **** parentheses surrounding specific values for its parameters, but the function's return type is omitted. ! A template class definition generalizes repeated class definitions. If two class definitions differ only in a few types, ! template parameters can be substituted. Each parameter is a placeholder that, when used, holds one particular value, i.e., type, among the set of possible values. The class definition is named to permit its use, and declarations for its parameters --- 399,417 ---- parentheses surrounding specific values for its parameters, but the function's return type is omitted. ! ! ! template ! definition ! ! A template class definition generalizes repeated class definitions. If two class definitions differ only in a few types, ! template parameters ! ! template ! parameter ! ! can be substituted. Each parameter is a placeholder that, when used, holds one particular value, i.e., type, among the set of possible values. The class definition is named to permit its use, and declarations for its parameters *************** maxOut(0, 3); *** 313,323 **** Note the notation for the template class parameters. template <typename T> precedes the class definition. The keyword ! typename indicates the template parameter is a type. T is the template parameter's name. (We could have used any other identifier such as pairElementType or foo.) ! Note that using class is equivalent to using typename so template <class T> is equivalent to template <typename T>. While declaring a template class --- 424,442 ---- Note the notation for the template class parameters. template <typename T> precedes the class definition. The keyword ! typename ! ! typename ! ! indicates the template parameter is a type. T is the template parameter's name. (We could have used any other identifier such as pairElementType or foo.) ! Note that using class ! ! class ! ! is equivalent to using typename so template <class T> is equivalent to template <typename T>. While declaring a template class *************** maxOut(0, 3); *** 327,336 **** for its parameters. As we showed above, pair<int> instantiates the template class pair with ∫ for its type parameter T. ! In template programming, nested type names store compile-time data that can be used within template classes. Since compile-time class definitions are analogous to run-time objects and the latter stores named values, nested type names are values, --- 446,468 ---- for its parameters. As we showed above, pair<int> instantiates + + template + instantiation + the template class pair with ∫ for its type parameter T. ! ! ! type ! nested ! ! ! nested type ! type, nested. ! ! In template programming, nested type names store compile-time data that can be used within template classes. Since compile-time class definitions are analogous to run-time objects and the latter stores named values, nested type names are values, *************** maxOut(0, 3); *** 338,349 **** template class &array; has an nested type name for the type of its domain: ! typedef typename Engine_t::Domain_t Domain_t; ! This typedef, i.e., type definition, defines the type Domain_t as equivalent to Engine_t::Domain_t. The ! :: operator selects the ! Domain_t nested type from inside the Engine_t type. This illustrates how to access &array;'s Domain_t when not within &array;'s scope: Array<Dim, T, EngineTag>::Domain_t. The --- 470,493 ---- template class &array; has an nested type name for the type of its domain: ! typedef typename Engine_t::Domain_t Domain_t; ! This typedef, ! ! typedef ! type, definition. ! ! ! type ! definition ! ! i.e., type definition, defines the type Domain_t as equivalent to Engine_t::Domain_t. The ! :: operator ! ! :: operator ! ! selects the Domain_t nested type from inside the Engine_t type. This illustrates how to access &array;'s Domain_t when not within &array;'s scope: Array<Dim, T, EngineTag>::Domain_t. The *************** maxOut(0, 3); *** 363,371 **** &poomatoolkit;. In this section, we present template programming techniques used to implement &pooma;. We extend the correspondence between compile-time template programming ! constructs and run-time constructs. Reading this section is not ! necessary unless you wish to understand how &pooma; is ! implemented. In the previous section, we used a correspondence between run-time and compile-time programming constructs to introduce --- 507,515 ---- &poomatoolkit;. In this section, we present template programming techniques used to implement &pooma;. We extend the correspondence between compile-time template programming ! constructs and run-time constructs started in the previous ! section. Reading this section is not necessary unless you wish to ! understand how &pooma; is implemented. In the previous section, we used a correspondence between run-time and compile-time programming constructs to introduce *************** maxOut(0, 3); *** 390,396 **** compile time ! values integers, strings, objects, functions, … --- 534,540 ---- compile time ! values integers, strings, objects, functions, … *************** maxOut(0, 3); *** 414,430 **** values stored in a collection An object stores values. A traits ! class contains values describing a type. extracting values from collections An object's named values are extracted using the ! . operator A class's nested types and classes are extracted using ! the :: operator. ! control flow to choose among operations if, while, goto, … template class specializations with pattern matching --- 558,595 ---- values stored in a collection An object stores values. A traits ! class ! ! traits class ! ! ! class ! traits ! traits class ! ! contains values describing a type. extracting values from collections An object's named values are extracted using the ! . operator. ! ! . operator ! ! A class's nested types and classes are extracted using ! the :: operator. ! ! :: operator ! ! ! control flow ! ! control flow ! ! to choose among operations if, while, goto, … template class specializations with pattern matching *************** maxOut(0, 3); *** 432,444 **** ! The only compile-time value described in the previous ! section was types, but any compile-time constant can also be used. Integral literals, const variables, and other constructs can be used, but the main use is enumerations. An enumeration ! enumeration is a distinct integral type with named constants. For example, the &array; declaration declares two separate enumerations: --- 597,619 ---- ! ! ! enumeration ! ! ! compile time ! value ! ! The only compile-time values described in the previous ! section were types, but any compile-time constant can also be used. Integral literals, const variables, and other constructs can be used, but the main use is enumerations. An enumeration ! is a distinct integral type with named constants. For example, the &array; declaration declares two separate enumerations: *************** enum { dimensionPlusRank = dimensions + *** 480,502 **** The use of non-integral constant values such as floating-point ! numbers at compile time is restricted. ! ! Other compile-time values include pointers and references to ! objects and functions and executable code. For example, a pointer ! to a function sometimes is passed to a template function to ! perform a specific task. Even though executable code cannot be ! directly represented in a program, it is a compile-time value ! which the compiler uses. A simple example is a class that is ! created by template instantiation, e.g., ! pair<int>. Conceptually, the ∫ template argument is substituted throughout the pair template class to produce a class definition. Although neither the programmer nor the user sees this class definition, it is represented inside the compiler, which can use and manipulate the code. ! ! Through template programming, the compiler's optimizer can transform complicated code into much simpler code. In , we describe the complicated template code used to implement efficiently --- 655,723 ---- The use of non-integral constant values such as floating-point ! numbers at compile time is restricted. ! ! ! ! ! Other compile-time values include pointers ! ! pointer ! ! to objects and ! functions, references ! ! reference ! ! to objects and functions, and executable ! code. For example, a pointer to a function ! ! pointer ! function ! ! ! function pointer ! pointer, function. ! ! sometimes is passed to ! a template function to perform a specific task. Even though ! executable code ! ! executable code ! ! cannot be directly represented in a program, it is ! a compile-time value which the compiler uses. A simple example is ! a class that is created by template instantiation, ! ! template ! instantiation ! ! e.g., pair<int>. Conceptually, the ∫ template argument is substituted throughout the pair template class to produce a class definition. Although neither the programmer nor the user sees this class definition, it is represented inside the compiler, which can use and manipulate the code. ! ! ! ! ! Through template programming, the compiler's optimizer ! ! optimizer ! compiler, optimizer. ! ! ! optimization ! compiler, optimizer. ! ! ! compiler ! optimizer ! ! can transform complicated code into much simpler code. In , we describe the complicated template code used to implement efficiently *************** struct usuallySimpleClass<false> { *** 537,544 **** compilers that translate &cc; code into &c; code may permit inspecting the resulting code. For example, using the command-line option with the ! KAI &cc; compiler creates a file ! containing the result of intermediate code. Unfortunately, reading and understanding the code is frequently difficult. Perhaps future &cc; compilers will support easy inspection of optimized code. --- 758,775 ---- compilers that translate &cc; code into &c; code may permit inspecting the resulting code. For example, using the command-line option with the ! KAI &cc; compiler ! ! ! compiler ! KAI ! ! ! KAI &cc; compiler ! compiler, KAI. ! ! creates a file ! containing the intermediate code. Unfortunately, reading and understanding the code is frequently difficult. Perhaps future &cc; compilers will support easy inspection of optimized code. *************** struct usuallySimpleClass<false> { *** 550,556 **** > and ==. At run time, the category of strings can be compared using == and characters can be extracted using ! subscripts and the [] operator. Compile-time operations are more limited. Types may be declared and used. The sizeof operator yields the number of bytes to represent an object of the specified type. Enumerations, --- 781,787 ---- > and ==. At run time, the category of strings can be compared using == and characters can be extracted using ! subscripts with the [] operator. Compile-time operations are more limited. Types may be declared and used. The sizeof operator yields the number of bytes to represent an object of the specified type. Enumerations, *************** struct usuallySimpleClass<false> { *** 562,582 **** used as template arguments. At compile time, pointers and references to objects and functions can be used as template arguments, while the category of executable code supports no ! operations. (The compiler's optimizer may simplify it, ! though.) ! ! At run time, an object can store multiple values, each having its own name. For example, a pair<int> object p stores two ∫s named left_ and right_. The . ! operator extracts a named member from an object: p.left_. At compile time, a class can store multiple values, each having its own name. These are sometimes called traits classes. For example, implementing ! data-parallel operations requiring storing the a tree of types. The ExpressionTraits<BinaryNode<Op, Left, Right&closeclose; traits class stores the types of a binary node representing the operation of Op on left --- 793,829 ---- used as template arguments. At compile time, pointers and references to objects and functions can be used as template arguments, while the category of executable code supports no ! operations. (The compiler's optimizer ! ! compiler ! optimizer ! ! may simplify it, though.) ! ! ! ! traits class ! ! At run time, an object ! ! object ! ! can store multiple values, each having its own name. For example, a pair<int> object p stores two ∫s named left_ and right_. The . ! operator ! ! . operator ! ! extracts a named member from an object: p.left_. At compile time, a class can store multiple values, each having its own name. These are sometimes called traits classes. For example, implementing ! data-parallel operations requiring storing a tree of types. The ExpressionTraits<BinaryNode<Op, Left, Right&closeclose; traits class stores the types of a binary node representing the operation of Op on left *************** struct ExpressionTraits<BinaryNode< *** 590,629 **** typedef typename CombineExpressionTraits<Left_t, Right_t>::Type_t Type_t; }; consists of a class definition and internal type ! ! definitions. This traits class contains three values, all types, ! named Left_t, Right_t, and Type_t, representing the type of the left child, the ! right child, and the entire node, respectively. No enumerations ! or constant values occur. See for more details ! regarding the implementation of data-parallel operators. Many ! traits classes, such as this one, use internal type definitions to ! store values. ! ! The example also illustrates using the ! :: operator to extract a member of a traits ! class. The type ExpressionTraits<Left> ! contains an internal type definition of Type_t. ! Using the :: operator extracts it: ExpressionTraits<Left>::Type_t. Enumerations and other values can also be extracted. For example, Array<2, int, Brick>::dimensions yields the dimension of the array's domain. ! Control flow determines which code is used. At run time, control-flow statements such as if, while, and goto determine which statements to execute. Template programming uses two mechanisms: template class specializations and pattern matching. These are similar to ! control flow for functional programming languages. A template class specialization is a class definition specific to one or more template arguments. For example, the ! implementation for data-parallel operations uses the templated ! CreateLeaf. The default definition works for any ! template argument T: template<class T> struct CreateLeaf --- 837,891 ---- typedef typename CombineExpressionTraits<Left_t, Right_t>::Type_t Type_t; }; consists of a class definition and internal type ! definitions. This traits class contains three values, all types ! and named Left_t, Right_t, and Type_t, representing the type of the left child, the ! right child, and the entire node, respectively. Many traits ! classes, such as this one, use internal type definitions to store ! values. No enumerations or constant values occur in this traits ! class, but other such classes include them. See for more details ! regarding the implementation of data-parallel operators. ! ! ! ! :: operator ! ! The example also illustrates using the :: ! operator to extract a member of a traits class. The type ! ExpressionTraits<Left> contains an internal ! type definition of Type_t. Using the ! :: operator extracts it: ExpressionTraits<Left>::Type_t. Enumerations and other values can also be extracted. For example, Array<2, int, Brick>::dimensions yields the dimension of the array's domain. ! ! ! template ! specialization ! ! ! control flow ! ! Control flow determines which code is used. At run time, control-flow statements such as if, while, and goto determine which statements to execute. Template programming uses two mechanisms: template class specializations and pattern matching. These are similar to ! control flow in functional programming languages. A template class specialization is a class definition specific to one or more template arguments. For example, the ! implementation for data-parallel operations ! ! data-parallel operation ! ! uses the templated CreateLeaf. The default ! definition works for any template ! argument T: template<class T> struct CreateLeaf *************** struct CreateLeaf<Expression<T&clo *** 644,650 **** CreateLeaf's template argument is an Expression type. ! Pattern matching of template arguments to template parameters determines which template code is used. The code associated with the match that is most specific is the one that is used. For example, CreateLeaf<int> uses the --- 906,921 ---- CreateLeaf's template argument is an Expression type. ! ! ! template ! pattern matching ! ! ! pattern matching ! template, pattern matching. ! ! Pattern matching of template arguments to template parameters determines which template code is used. The code associated with the match that is most specific is the one that is used. For example, CreateLeaf<int> uses the *************** struct CreateLeaf<Expression<T&clo *** 663,672 **** Control flow using template specializations and pattern matching is similar to switch ! statements. A switch statement has a condition and one or more pairs of case labels and associated code. The code associated with the the case label whose value ! matched the condition is executed. If no case label matches the condition, the default code, if present, is used. In template programming, instantiating a template, e.g., CreateLeaf<Expression<int&closeclose; serves as --- 934,947 ---- Control flow using template specializations and pattern matching is similar to switch ! statements. ! ! switch ! ! A switch statement has a condition and one or more pairs of case labels and associated code. The code associated with the the case label whose value ! matches the condition is executed. If no case label matches the condition, the default code, if present, is used. In template programming, instantiating a template, e.g., CreateLeaf<Expression<int&closeclose; serves as *************** struct CreateLeaf<Expression<T&clo *** 681,689 **** default label since it matches any arguments. If no set of template parameters match (which is impossible for our example) or if more than one set are best matches, the code is ! incorrect. ! ! Functions as well as classes may be templated. All the concepts needed to understand function templates have already been introduced so we illustrate using an example. The templated function f takes one parameter of any type: --- 956,975 ---- default label since it matches any arguments. If no set of template parameters match (which is impossible for our example) or if more than one set are best matches, the code is ! incorrect. ! ! ! ! ! ! template ! function ! ! ! function template ! function, template. ! ! Functions as well as classes may be templated. All the concepts needed to understand function templates have already been introduced so we illustrate using an example. The templated function f takes one parameter of any type: *************** void f(const T& t) { … } *** 697,704 **** functions equivalent to f(const int&), f(const bool&), f(const int*&), …. Using a templated class ! definition with a static member function, we can define an ! equivalent function: template <typename T> class F { --- 983,1008 ---- functions equivalent to f(const int&), f(const bool&), f(const int*&), …. Using a templated class ! definition with a static member function, ! ! function ! static member ! ! ! static member function ! function, static member ! ! we can define an equivalent function: ! ! function ! static member ! equivalence with function template ! ! ! template ! function ! equivalence with static member function ! template <typename T> class F { *************** class F { *** 706,735 **** }; Both the templated class and the templated function take the same template arguments, but the class uses a static ! member function so the notation to invoke it is slightly more ! verbose: F<T>::f(t). The advantage ! of a function template is that it can be overloaded, particularly ! operator functions. For example, the + ! operator is overloaded to add two &array;s, which require template ! parameters to specify: template <int D1,class T1,class E1,int D2,class T2,class E2> // complicated return type omitted operator+(const Array<D1,T1,E1> & l,const Array<D2,T2,E2> & r); Without using function templates, it would not be - possible to write expressions such as a1 + a2. Member functions can also be templated. This permits, for example, overloading of assignment operators defined ! within templated classes. ! ! Function objects are frequently useful in run-time code. They consist of a function plus some additional storage and are usually implemented as structures with data members and a function ! call operator. Analogous classes can be used at compile time. ! Using the transformation introduced in the previous paragraph, we see that any function can be transformed into a class containing a ! static member function. Internal type definitions, enumerations, and static constant values can be added to the class. The static member function can use these values during its computation. The CreateLeaf structure, introduced above, illustrates this. --- 1010,1077 ---- }; Both the templated class and the templated function take the same template arguments, but the class uses a static ! member function. Thus, the notation to invoke it is slightly more ! verbose: F<T>::f(t). ! ! ! ! function ! overloaded ! ! ! function ! operator ! ! The advantage of a function template is that it can be overloaded, ! particularly operator functions. For example, the ! + operator is overloaded to add two &array;s, ! which require template parameters to specify: template <int D1,class T1,class E1,int D2,class T2,class E2> // complicated return type omitted operator+(const Array<D1,T1,E1> & l,const Array<D2,T2,E2> & r); Without using function templates, it would not be possible to write expressions such as a1 + a2. Member functions can also be templated. This permits, for example, overloading of assignment operators defined ! within templated classes. ! ! ! ! ! Function objects ! ! function ! object ! ! are frequently useful in run-time code. They consist of a function plus some additional storage and are usually implemented as structures with data members and a function ! call operator. ! ! function ! call operator ! ! Analogous classes can be used at compile time. ! Using the transformation ! ! function ! static member ! equivalence with function template ! ! ! template ! function ! equivalence with static member function ! ! introduced in the previous paragraph, we see that any function can be transformed into a class containing a ! static member function. ! ! function ! static member ! ! Internal type definitions, enumerations, and static constant values can be added to the class. The static member function can use these values during its computation. The CreateLeaf structure, introduced above, illustrates this. Index: tutorial.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/tutorial.xml,v retrieving revision 1.6 diff -c -p -r1.6 tutorial.xml *** tutorial.xml 2002/01/22 15:48:49 1.6 --- tutorial.xml 2002/01/24 04:56:40 *************** *** 1,17 **** A Tutorial Introduction - UPDATE: In the following paragraph, fix the cross-reference - to the actual section. - &pooma; provides different containers and processor configurations and supports different implementation styles, as ! described in . In this ! chapter, we present several different implementations of the ! &doof2d; two-dimensional diffusion simulation program: ! a C-style implementation omitting any use of &pooma; computing each array element individually, --- 1,15 ---- + A Tutorial Introduction &pooma; provides different containers and processor configurations and supports different implementation styles, as ! described in . In this ! chapter, we present several different implementations of the &doof2d; ! two-dimensional diffusion simulation program: ! a C-style implementation omitting any use of &pooma; and computing each array element individually, *************** *** 40,52 **** ! These illustrate the &array;, &field;, &engine;, layout, ! mesh, and domain data types. They also illustrate various ! immediate computation styles (element-wise accesses, data-parallel ! expressions, and stencil computation) and various processor ! configurations (one sequential processor and multiple ! processors).

&doof2d; Averagings --- 38,68 ---- ! These illustrate the &array;, &field;, &engine;, layout, mesh, ! and &domain; data types. They also illustrate various immediate ! computation styles (element-wise accesses, data-parallel expressions, ! and stencil computation) and various processor configurations (one ! processor and multiple processors). ! ! The &doof2d; diffusion program starts with a two-dimensional ! grid of values. To model an initial density, all grid values are ! zero except for one nonzero value in the center. Each averaging, ! each grid element, except the outermost ones, updates its value by ! averaging its value and its eight neighbors. To avoid overwriting ! grid values before all their uses occur, we use two arrays, reading ! the first and writing the second and then reversing their roles ! within each iteration. ! ! We illustrate the averagings in . Initially, only the ! center element has nonzero value. To form the first averaging, each ! element's new value equals the average of its and its neighbors' ! previous values. Thus, the initial nonzero value spreads to a ! three-by-three grid. The averaging continues, spreading to a ! five-by-five grid of nonzero values. Values in the outermost grid cells ! are always zero. +

&doof2d; Averagings *************** *** 75,177 **** ! The &doof2d; diffusion program starts with a two-dimensional ! grid of values. To model an initial density, all grid values are ! zero except for one nonzero value in the center. Each averaging, ! each grid element, except the outermost ones, updates its value by ! averaging its value and its eight neighbors. To avoid overwriting ! grid values before all their uses occur, we use two arrays, reading ! the first and writing the second and then reversing their roles ! within each iteration. ! ! Figure ! illustrates the averagings. Initially, only the center element has ! nonzero value. To form the first averaging, each element's new ! value equals the average of its and its neighbors' previous values. ! Thus, the initial nonzero value spreads to a three-by-three grid. ! The averaging continues, spreading to a five-by-five grid of ! nonzero values. Values in outermost grid cells are always ! zero. ! ! Before presenting various implementations of %doof2d;, we explain how to install the &poomatoolkit;. REMOVE: &doof2d; algorithm and code is illustrated in Section 4.1 of pooma-publications/pooma.ps. It includes a figure illustrating parallel communication of data.

Installing &pooma; ADD: How does one install &pooma; using Windows or Mac? UPDATE: Make a more recent &pooma; source code file ! available on &poomaDownloadPage;. For example, LINUXgcc.conf is not available. In this section, we describe how to obtain, build, and install the &poomatoolkit;. We focus on installing under the ! Unix operating system. Instructions for installing on computers running Microsoft Windows or MacOS, as well as more extensive instructions for Unix, appear in . Obtain the &pooma; source code &poomaSourceFile; ! from the &pooma; download page (&poomaDownloadPage;) available off ! the &pooma; home page (&poomaHomePage;). The tgz indicates this is a compressed tar archive file. To extract the ! source files, use tar xzvf &poomaSourceFile;. Move into the source code directory &poomaSource; directory; e.g., ! cd &poomaSource;. ! Configuring the source code prepares the necessary paths for ! compilation. First, determine a configuration file in ! corresponding to your operating system and compiler in the ! config/arch/ directory. ! For example, LINUXgcc.conf supports compiling ! under a &linux; operating system with &gcc; and SGI64KCC.conf supports compiling ! under a 64-bit SGI Unix operating ! system with &kcc;. Then, configure the source code: ! ./configure &dashdash;arch LINUXgcc &dashdash;opt &dashdash;suite LINUXgcc-opt. The architecture argument to the ! &dashdash;arch option is the name of the corresponding ! configuration file, omitting its .conf suffix. The &dashdash;opt indicates the &poomatoolkit; will ! contain optimized source code, which makes the code run more ! quickly but may impede debugging. Alternatively, the ! &dashdash;debug option supports debugging. The ! suite name can be any arbitrary string. We chose ! LINUXgcc-opt to remind us of the architecture ! and optimization choice. configure creates subdirectories ! named by the suite name LINUXgcc-opt for use when ! compiling the source files. Comments at the beginning of ! lib/suiteName/PoomaConfiguration.h record the configuration arguments. ! To compile the source code, set the ! POOMASUITE environment variable to the suite name ! and then type make. To set the environment ! variable for the bash shell use ! export POOMASUITE=suiteName, ! substituting the suite name's ! suiteName. For the ! csh shell, use setenv POOMASUITE LINUXgcc-opt. Issuing the make command compiles the &pooma; source code files to create the &pooma; library. The &pooma; makefiles assume ! the GNU &make; so substitute the proper ! command if necessary. The &pooma; library can be found in, e.g., ! lib/LINUXgcc-opt/libpooma-gcc.a.

--- 91,183 ---- ! Before presenting the various implementations of &doof2d;, we explain how to install the &poomatoolkit;. + REMOVE: &doof2d; algorithm and code is illustrated in Section 4.1 of pooma-publications/pooma.ps. It includes a figure illustrating parallel communication of data. + ]]> +

Installing &pooma; + ADD: How does one install &pooma; using Windows or Mac? UPDATE: Make a more recent &pooma; source code file ! available on &poomadownloadpage;. For example, LINUXgcc.conf is not available. + ]]> In this section, we describe how to obtain, build, and install the &poomatoolkit;. We focus on installing under the ! Unix operating system. ! . ! ]]> ! Obtain the &pooma; source code &poomasourcefile; ! from the &pooma; download page (&poomadownloadpage;) available off ! the &pooma; home page (&poomahomepage;). The tgz indicates this is a compressed tar archive file. To extract the ! source files, use tar xzvf &poomasourcefile;. Move into the source code directory &poomasource; directory; e.g., ! cd &poomasource;. ! Configuring the source code determines file names needed for ! compilation. First, determine a configuration file in the config/arch/ directory corresponding to ! your operating system and compiler. For example, LINUXgcc.conf supports compiling ! under a &linux; operating system with &gcc;, while SGI64KCC.conf supports compiling ! under a 64-bit SGI Unix operating system ! ! with &kcc;. Next, configure the source code: ./configure ! &dashdash;arch LINUXgcc &dashdash;opt &dashdash;suite LINUXgcc-opt. The architecture argument to the ! &dashdash;arch option is the name of the ! corresponding configuration file, omitting its .conf suffix. The &dashdash;opt indicates the &poomatoolkit; will ! contain optimized source code, which makes the code run more quickly ! but may impede debugging. Alternatively, use the ! &dashdash;debug option which supports debugging. ! The suite name can be any arbitrary string. We chose ! LINUXgcc-opt to remind us of the architecture and ! optimization choice. configure creates subdirectories ! named LINUXgcc-opt for use when compiling the source ! files. Comments at the beginning of lib/suiteName/PoomaConfiguration.h record the configuration arguments. ! To compile the source code, set the POOMASUITE ! environment variable to the suite name and then type ! make. To set the environment variable for the ! ! bash shell use export POOMASUITE=suiteName, ! substituting the suite name's suiteName. ! ! For the csh shell, use setenv POOMASUITE LINUXgcc-opt. Issuing the make command compiles the &pooma; source code files to create the &pooma; library. The &pooma; makefiles assume ! the GNU &make; is available so substitute the ! proper command to run GNU &make; if ! necessary. The &pooma; library can be found in, e.g., lib/LINUXgcc-opt/libpooma-gcc.a.

*************** *** 181,209 **** Before implementing &doof2d; using the &poomatoolkit;, we present a hand-coded implementation of &doof2d;. See . After querying the ! user for the number of averagings, the arrays' memory is ! allocated. Since the arrays' size is not known at compile time, ! the arrays are accesses via pointers to allocated dynamic memory. ! This memory is deallocated at the program's end to avoid memory ! leaks. The arrays are initialized with initial conditions. For ! the b array, all values except the central ones ! have nonzero values. Only the outermost values of the a array need be initialized to zero, but we ! instead initialize them all using the loop used by ! b. ! The simulation's kernel consists of triply nested loops. ! The outermost loop controls the number of iterations. The inner nested loops iterate through the arrays' elements, excepting the ! outermost elements; note the loop indices range from 1 to n-2 ! while the array indices range from 0 to n-1. Each ! a value is assigned the average of its ! corresponding value in b and the latter's ! neighbors. Values in the two-dimensional grids are accessed using ! two sets of brackets, e.g., a[i][j]. After ! assigning values to a, a second averaging reads ! values in a, writing values in ! b. After the kernel finishes, the final central value is printed. If the desired number of averagings is even, the value --- 187,214 ---- Before implementing &doof2d; using the &poomatoolkit;, we present a hand-coded implementation of &doof2d;. See . After querying the ! user for the number of averagings, the arrays' memory is allocated. ! Since the arrays' size is not known at compile time, the arrays are ! accessed via pointers to allocated dynamic memory. This memory is ! deallocated at the program's end to avoid memory leaks. The arrays ! are initialized with initial conditions. For the ! b array, all values except the central ones have ! nonzero values. Only the outermost values of the a array need be initialized to zero, but we ! instead initialize them all using the same loop ! initializing b. ! The simulation's kernel consists of triply nested loops. The ! outermost loop controls the number of iterations. The two inner nested loops iterate through the arrays' elements, excepting the ! outermost elements; note the loop indices range from 1 to n-2 while ! the array indices range from 0 to n-1. Each a ! value is assigned the average of its corresponding value in ! b and the latter's neighbors. Values in the ! two-dimensional grids are accessed using two sets of brackets, e.g., ! a[i][j]. After assigning values to ! a, a second averaging reads values in ! a, writing values in b. After the kernel finishes, the final central value is printed. If the desired number of averagings is even, the value *************** *** 241,248 **** a array. ! These constants indicate the number of iterations, and ! the average weighting. Each a value, except an outermost one, --- 246,252 ---- a array. ! This constants indicates the average's weighting. Each a value, except an outermost one, *************** *** 268,289 **** To compile the executable, change directories to the &pooma; &poomaExampleDirectory;/Doof2d directory. Ensure the POOMASUITE environment variable specifies the desired suite name suiteName, as we did when compiling ! &pooma; in the previous section . Issuing the ! make Doof2d-C-element command creates the executable suiteName/Doof2d-C-element. ! When running the executable, specify the desired a ! nonnegative number of averagings and the nonnegative number of ! grid cells along any dimension. The resulting grid has the same ! number of cells along each dimension. After the executable ! finishes, the resulting value of the central element is ! printed. --- 272,291 ---- To compile the executable, change directories to the &pooma; &poomaexampledirectory;/Doof2d directory. Ensure the POOMASUITE environment variable specifies the desired suite name suiteName, as we did when compiling ! &pooma; in . Issuing ! the make Doof2d-C-element command creates the executable suiteName/Doof2d-C-element. ! When running the executable, specify the desired nonnegative ! number of averagings and the nonnegative number of grid cells along ! any dimension. The resulting grid has the same number of cells ! along each dimension. After the executable finishes, the resulting ! value of the central element is printed. *************** *** 314,323 **** Before creating an &array;, its domain must be specified. ! The N interval represents the ! one-dimensional integral set {0, 1, 2, …, n-1}. An ! Interval<2> object represents the entire ! two-dimensional index domain. An &array;'s template parameters indicate its dimension, --- 316,325 ---- Before creating an &array;, its domain must be specified. ! The N &interval; represents the ! one-dimensional integral set {0, 1, 2, …, n-1}. The ! Interval<2> vertDomain ! object represents the entire two-dimensional index domain. An &array;'s template parameters indicate its dimension, *************** *** 330,349 **** domain. ! The first statement initializes all &array; values to the ! same scalar value. This is possible because each &array; ! knows its domain. The second statement ! illustrates &array; element access. Indices, separated by commas, are surrounded by parentheses rather than surrounded by square brackets ([]). &array; element access uses parentheses, rather than ! square brackets ! Since &array;s are first-class objects, they ! automatically deallocate any memory they require, eliminating memory leaks. --- 332,349 ---- domain. ! The first loop initializes all &array; values to the ! same scalar value. The second statement ! illustrates assigning one &array; value. Indices, separated by commas, are surrounded by parentheses rather than surrounded by square brackets ([]). &array; element access uses parentheses, rather than ! square brackets. ! The &array;s deallocate any memory they require, eliminating memory leaks. *************** *** 364,370 **** The creation of the a and b &array;s requires an object specifying their index domains. Since these are two-dimensional arrays, their ! index domains are also two dimensional. The two-dimensional Interval<2> object is the Cartesian product of two one-dimensional Interval<1> objects, each specifying the integral set {0, 1, 2, …, n-1}. --- 364,370 ---- The creation of the a and b &array;s requires an object specifying their index domains. Since these are two-dimensional arrays, their ! index domains are also two-dimensional. The two-dimensional Interval<2> object is the Cartesian product of two one-dimensional Interval<1> objects, each specifying the integral set {0, 1, 2, …, n-1}. *************** *** 373,387 **** type of its values, and how the values are stored. Both a and b are two-dimension arrays storing &double;s so their dimension ! is 2 and its element type is &double;. An &engine; stores an ! &array;'s values. For example, a &brick; &engine; explicitly ! stores all values. A &compressiblebrick; &engine; also explicitly ! stores values if more than value is present, but, if all values ! are the same, storage for just that value is required. Since an ! engine can store its values any way it desires, it might instead ! compute its values using a function or compute the values stored ! in separate engines. In practice, most explicitly specified ! &engine;s are either &brick; or &compressiblebrick;. &array;s support both element-wise access and scalar assignment. Element-wise access uses parentheses, not square --- 373,387 ---- type of its values, and how the values are stored. Both a and b are two-dimension arrays storing &double;s so their dimension ! is 2 and their value type is &double;. An &engine; stores an ! &array;'s values. For example, a &brick; &engine; explicitly stores ! all values. A &compressiblebrick; &engine; also explicitly stores ! values if more than one value is present, but, if all values are the ! same, storage for just that value is required. Since an engine can ! store its values any way it desires, it might instead compute its ! values using a function or compute using values stored in separate ! engines. In practice, most explicitly specified &engine;s are ! either &brick; or &compressiblebrick;. &array;s support both element-wise access and scalar assignment. Element-wise access uses parentheses, not square *************** *** 389,405 **** specifies the central element. The scalar assignment b = 0.0 assigns the same 0.0 value to all array elements. This is possible because the array knows the extent of ! its domain. Any program using the &poomatoolkit; must initialize the &toolkit;'s data structures using ! Pooma::initialize(argc,argv). This ! extracts &pooma;-specific command-line options from the ! command-line arguments in argv and initializes ! the inter-processor communication and other data structures. When ! finished, Pooma::finalize() ensures all ! computation has finished and the communication and other data ! structures are destructed. --- 389,406 ---- specifies the central element. The scalar assignment b = 0.0 assigns the same 0.0 value to all array elements. This is possible because the array knows the extent of ! its domain. We illustrate these data-parallel statements in the ! next section. Any program using the &poomatoolkit; must initialize the &toolkit;'s data structures using ! Pooma::initialize(argc,argv). This extracts ! &pooma;-specific command-line options from the program's ! command-line arguments and initializes the interprocessor ! communication and other data structures. When finished, ! Pooma::finalize() ensures all computation and ! communication has finished and the data structures are ! destructed. *************** *** 408,437 **** &pooma; supports data-parallel &array; accesses. Many algorithms are more easily expressed using data-parallel ! expressions. Also, the &poomatoolkit; might be able to reorder ! the data-parallel computations to be more efficient or distribute ! them among various processors. In this section, we concentrate ! the differences between the data-parallel implementation of ! &doof2d; listed in and the ! element-wise implementation listed in the previous section . Data-Parallel &array; Implementation of &doof2d; &doof2d-array-parallel; &pooma; may reorder computation of statements. Calling Pooma::blockAndEvaluate ensures all computation finishes before accessing a particular array element. - - These variables specify one-dimensional domains {1, 2, - …, n-2}. Their Cartesian product specifies the domain - of the array values that are modified. - Data-parallel expressions replace nested loops and array element accesses. For example, a(I,J) --- 409,437 ---- &pooma; supports data-parallel &array; accesses. Many algorithms are more easily expressed using data-parallel ! expressions. Also, the &poomatoolkit; can sometimes reorder the ! data-parallel computations to be more efficient or distribute them ! among various processors. In this section, we concentrate on the ! differences between the data-parallel implementation of &doof2d; ! listed in and ! the element-wise implementation listed in the previous ! section. Data-Parallel &array; Implementation of &doof2d; &doof2d-array-parallel; + + These variables specify one-dimensional domains {1, 2, + …, n-2}. Their Cartesian product specifies the domain + of the array values that are modified. + &pooma; may reorder computation of statements. Calling Pooma::blockAndEvaluate ensures all computation finishes before accessing a particular array element. Data-parallel expressions replace nested loops and array element accesses. For example, a(I,J) *************** *** 443,462 **** ! Data-parallel expressions apply domain objects to containers ! to indicate a set of parallel expressions. For example, in the ! program listed above, a(I,J) specifies all ! of a array excepting the outermost elements. ! The array's vertDomain domain consists of the ! Cartesian product of {0, 1, 2, …, n-1} and itself, while I and J each specify {1, 2, …, n-2}. Thus, a(I,J) is the subset ! with a domain of the Cartesian product of {1, 2, …, n-2} ! and itself. It is called a view of an ! array. It is itself an array, with a domain and supporting ! element access, but its storage is the same as ! a's. Changing a value in ! a(I,J) also changes the same value in a. Changing a value in the latter also changes the former if the value is not one of a's outermost elements. The expression --- 443,461 ---- ! Data-parallel expressions use containers and domain objects to ! indicate a set of parallel expressions. For example, in the program ! listed above, a(I,J) specifies the subset of ! a array omitting the outermost elements. The ! array's vertDomain domain consists of the ! Cartesian product of {0, 1, 2, …, n-1} with itself, while I and J each specify {1, 2, …, n-2}. Thus, a(I,J) is the subset ! with a domain of the Cartesian product of {1, 2, …, n-2} with ! itself. It is called a view of an array. It ! is itself an &array;, with a domain and supporting element access, but ! its storage is the same as a's. Changing a value ! in a(I,J) also changes the same value in a. Changing a value in the latter also changes the former if the value is not one of a's outermost elements. The expression *************** *** 465,474 **** product of {2, 3, …, n-1}, i.e., the same domain as a(I,J) but shifted up one unit and to the right one unit. Only an &interval;'s value, not its name, is ! important. Thus, all uses of J in this program could be replaced by I without changing the semantics.

Adding &array;s --- 464,483 ---- product of {2, 3, …, n-1}, i.e., the same domain as a(I,J) but shifted up one unit and to the right one unit. Only an &interval;'s value, not its name, is ! important so all uses of J in this program could be replaced by I without changing the semantics. + The statement assigning to a(I,J) + illustrates that &array;s may participate in expressions. Each + addend is a view of an array, which is itself an array. The views' + indices are zero-based so their sum can be formed by adding + identically indexed elements of each array. For example, the lower, + left element of the result equals the sum of the lower, left + elements of the addend arrays. + illustrates adding two arrays. +

Adding &array;s *************** *** 476,528 **** ! Adding two arrays with different domains is supported. ! When adding arrays, values in corresponding positions are ! added even if they have different indices, indicated by the ! small numbers adjacent to the arrays. - The statement assigning to a(I,J) - illustrates that &array;s may participate in expressions. Each - addend is a view of an array, which is itself an array. Each view - has the same domain size so their sum can be formed by - corresponding elements of each array. For example, the lower, - left element of the result equals the sum of the lower, left - elements of the addend arrays. For the computation, indices are - ignored; only the relative positions within each domain are used. - - illustrates adding two arrays with different domain indices. The - indices are indicated by the small numbers to the left and the - bottom of the arrays. Even though 9 and 3 have different indices - (1,1) and (2,0), they are added to each other because they have - the same relative positions within the addends. - Just before accessing individual &array; values, the code contains calls to Pooma::blockAndEvaluate. &pooma; may reorder computation or distribute them among various processors. Before reading an individual &array; value, calling ! the function ensures all computations affecting its value have ! finished, i.e., it has the correct value. Calling this function ! is necessary only when accessing individual array elements because ! &pooma; cannot determine when to call the function itself. For ! example, before printing an array, &pooma; will call ! blockAndEvaluate itself.

Stencil &array; Implementation ! Many computations are local, computing an &array;'s value by ! using close-by &array; values. Encapsulating this computation in ! a stencil can yield faster code because the compiler can determine ! all accesses come from the same array. Each stencil consists of a ! function object and an indication of the stencil's extent. Stencil &array; Implementation of &doof2d; --- 485,523 ---- ! Adding two arrays is supported. ! When adding arrays, values with the same indices, indicated ! by the small numbers adjacent to the arrays, are added.

Just before accessing individual &array; values, the code contains calls to Pooma::blockAndEvaluate. &pooma; may reorder computation or distribute them among various processors. Before reading an individual &array; value, calling ! this function ensures all computations affecting its value have ! finished, i.e., it has the correct value. Calling this function is ! necessary only when accessing individual array elements. For ! example, before the data-parallel operation of printing an array, ! &pooma; will call blockAndEvaluate ! itself.

Stencil &array; Implementation ! Many scientific computations are localized, computing an ! array's value by using neighboring values. Encapsulating this local ! computation in a stencil ! can yield faster code because the compiler can determine that all ! array accesses use the same array. Each stencil consists of a ! function object and an indication of which neighbors participate in ! the function's computation. Stencil &array; Implementation of &doof2d; *************** *** 546,552 **** These two functions indicate the stencil's size. For each dimension, the stencil extends one cell to the left of (or ! below) its center and also one call to the right (or above) its center. These two functions indicate the stencil's size. For each dimension, the stencil extends one cell to the left of (or ! below) its center and also one cell to the right (or above) its center. ! Before we describe how to create a stencil, we describe how ! to apply a stencil to an array, yielding values. To compute the ! value associated with index position (1,3), the stencil's center ! is placed at (1,3). The stencil's ! upperExtent and ! lowerExtent functions indicate which &array; ! values the stencil's function will use. See . ! Applying the stencil's function call ! operator() yields the computed value. To ! compute multiple &array; values, apply a stencil to the array and ! a domain object: stencil(b, ! interiorDomain). This applies the stencil to each ! position in the domain. The user must ensure that applying the ! stencil does not access nonexistent &array; values.

Applying a Stencil to an &array; --- 559,578 ---- ! Before we describe how to create a stencil, we describe how to ! apply a stencil to an array, yielding computed values. To compute ! the value associated with index position (1,3), the stencil's center ! is placed at (1,3). The stencil's upperExtent ! and lowerExtent functions indicate which ! &array; values the stencil's function will use. See . ! Applying the stencil's function call operator() ! yields the computed value. To compute multiple &array; values, ! apply a stencil to the array and a domain object: ! stencil(b, interiorDomain). This applies the ! stencil to each position in the domain. The user must ensure that ! applying the stencil does not access nonexistent &array; ! values.

Applying a Stencil to an &array; *************** *** 592,598 **** To compute the value associated with index position (1,3) of an array, place the stencil's center, indicated with dashed ! lines, at the position. The computation involves the array values covered by the array and delineated by upperExtent and lowerExtent. --- 586,592 ---- To compute the value associated with index position (1,3) of an array, place the stencil's center, indicated with dashed ! lines, at the position (1,3). The computation involves the array values covered by the array and delineated by upperExtent and lowerExtent. *************** *** 607,625 **** must define a function call operator() with a container parameter and index parameters. The number of index parameters, indicating the stencil's center, must equal the ! container's dimension. For example, DoofNinePt ! defines operator()(const C& c, int i, int ! j). We templated the container type ! C although this is not strictly necessary. The ! two index parameters i and j ! ensure the stencil works with two-dimensional containers. The ! lowerExtent indicates how far to the left ! (or below) the stencil extends beyond its center. Its parameter ! indicates a particular dimension. Index parameters i and j are in dimension 0 and 1. upperExtent serves an analogous purpose. The &poomatoolkit; uses these functions when ! distribution computation among various processors, but it does not use these functions to ensure nonexistent &array; values are not accessed. Caveat stencil user!

--- 601,619 ---- must define a function call operator() with a container parameter and index parameters. The number of index parameters, indicating the stencil's center, must equal the ! container's dimension. For example, DoofNinePt defines ! operator()(const C& c, int i, int j). We ! templated the container type C although this is ! not strictly necessary. The two index parameters ! i and j ensure the stencil ! works with two-dimensional containers. The ! lowerExtent function indicates how far to ! the left (or below) the stencil extends beyond its center. Its ! parameter indicates a particular dimension. Index parameters i and j are in dimension 0 and 1. upperExtent serves an analogous purpose. The &poomatoolkit; uses these functions when ! distributing computation among various processors, but it does not use these functions to ensure nonexistent &array; values are not accessed. Caveat stencil user! *************** *** 634,640 **** only specify how each container's domain should be split into patches. The &poomatoolkit; automatically distributes the data among the available processors and handles ! any required communication among processors. Distributed Stencil &array; Implementation of &doof2d; --- 628,637 ---- only specify how each container's domain should be split into patches. The &poomatoolkit; automatically distributes the data among the available processors and handles ! any required communication among processors. illustrates how ! to write a distributed version of the stencil program (). Distributed Stencil &array; Implementation of &doof2d; *************** *** 644,655 **** Multiple copies of a distributed program may simultaneously run, perhaps each having its own input and output. Thus, we use command-line arguments to pass input to ! the program. Using an &inform; object ensures only one program produces output. The UniformGridPartition declaration ! specifies how an array's domain will be partition, of split, into patches. Guard layers are an optimization that can reduce data communication between patches. The UniformGridLayout declaration applies the --- 641,652 ---- Multiple copies of a distributed program may simultaneously run, perhaps each having its own input and output. Thus, we use command-line arguments to pass input to ! the program. Using an &inform; object ensures only one copy produces output. The UniformGridPartition declaration ! specifies how an array's domain will be partitioned, or split, into patches. Guard layers are an optimization that can reduce data communication between patches. The UniformGridLayout declaration applies the *************** *** 657,664 **** patches among various processors. ! The MultiPatch &engine; distributes requests ! for &array; values to the associated patch. Since a patch may associated with a different processor, its remote &engine; has type Remote<Brick>. &pooma; automatically --- 654,661 ---- patches among various processors. ! The &multipatch; &engine; distributes requests ! for &array; values to the associated patches. Since a patch may associated with a different processor, its remote &engine; has type Remote<Brick>. &pooma; automatically *************** *** 675,690 **** Supporting distributed computation requires only minor code changes. These changes specify how each container's domain is ! distributed among the available processors and how input and ! output occurs. The rest of the program, including all the ! computations, remains the same. When running, the &pooma; ! executable interacts with the run-time library to determine which ! processors are available, distributes the containers' domains, and ! automatically handles all necessary interprocessor communication. ! The same executable runs on one or many processors. Thus, the ! programmer can write one program, debugging it on a uniprocessor ! computer and running it on a supercomputer.

The &pooma; Distributed Computation Model --- 672,713 ---- Supporting distributed computation requires only minor code changes. These changes specify how each container's domain is ! distributed among the available processors and how input and output ! occurs. The rest of the program, including all the computations, ! remains the same. When running, the &pooma; executable interacts ! with the run-time library to determine which processors are ! available, distributes the containers' domains, and automatically ! handles all necessary interprocessor communication. The same ! executable runs on one or many processors. Thus, the programmer can ! write one program, debugging it on a uniprocessor computer and run ! it on a supercomputer. ! ! &pooma;'s distributed computing model separates container ! domain concepts from computer configuration concepts. See . ! The statements in the program indicate how each container's domain ! will be partitioned. This process is represented in the upper left ! corner of the figure. A user-specified ! partition specifies how to split the domain ! into pieces. For example, the illustrated partition splits the ! domain into three equal-sized pieces along the x-dimension and two ! equal-sized pieces along the y-dimension. Applying the partition to ! the domain creates patches. The partition ! also specifies external and internal guard layers. A ! guard layer is a domain surrounding a patch. ! A patch's computation only reads but does not write these guarded ! values. An external guard layer conceptually ! surrounds the entire container domain with boundary values whose ! presence permits all domain computations to be performed the same ! way even for computed values along the domain's edge. An ! internal guard layer duplicates values from ! adjacent patches so communication need not occur during a patch's ! computation. The use of guard layers is an optimization; using ! external guard layers eases programming and using internal guard ! layers reduces communication among processors. Their use is not ! required. +

The &pooma; Distributed Computation Model *************** *** 695,732 **** the &pooma; distributed computation model ! The &pooma; distributed computation model combines ! partitioning containers' domains and the computer configuration ! to create a layout. - &pooma;'s distributed computing model separates container - domain concepts from computer configuration concepts. See . - The program indicates how each container's domain will be - partitioned. This process is represented in the upper left corner - of the figure. A user-specified partition - specifies how to split the domain into pieces. For example, the - illustrated partition splits the domain into three equal-sized - pieces along the x-dimension and two equal-sized pieces along the - y-dimension. Thus, the domain is split into - patches. The partition also specifies - external and internal guard layers. A guard - layer is a domain surrounding a patch. A patch's - computation only reads but does not write these guarded values. - An external guard layer conceptually - surrounds the entire container domain with boundary values whose - presence permits all domain computations to be performed the same - way even for values along the domain's edge. An - internal guard layer duplicates values from - adjacent patches so communication need not occur during a patch's - computation. The use of guard layers is an optimization; using - external guard layers eases programming and using internal guard - layers reduces communication among processors. Their use is not - required. - The computer configuration of shared memory and processors is determined by the run-time system. See the upper right portion of the &pooma; distributed computation model ! The &pooma; distributed computation model creates a layout ! by combining a partitioning of the containers' domains and the ! computer configuration. The computer configuration of shared memory and processors is determined by the run-time system. See the upper right portion of ) or the &mm; Shared Memory Library (), communicates the available contexts to the executable. &pooma; must be ! configured for the particular run-time system. See . A layout combines patches with contexts so the program can be executed. If &distributedtag; is specified, the patches are distributed among the available contexts. If ! &replicatedtag; is specified, each set of patches is replicated ! among each context. Regardless, the containers' domains are now distributed among the contexts so the program can run. When a patch needs data from another patch, the &poomatoolkit; sends messages to ! the desired patch uses a message-passing library. All such ! communication is automatically performed by the &toolkit; with no need ! for programmer or user input. ! ! FIXME: The two previous paragraphs demonstrate confusion ! between run-time system and message-passing ! library. Incorporating &pooma;'s distributed computation model into a program requires writing very few lines of code. --> or the &mm; Shared Memory Library (), communicates the available contexts to the executable. &pooma; must be ! configured for the particular run-time system in use. See . A layout combines patches with contexts so the program can be executed. If &distributedtag; is specified, the patches are distributed among the available contexts. If ! &replicatedtag; is specified, each set of patches is replicated on ! each context. Regardless, the containers' domains are now distributed among the contexts so the program can run. When a patch needs data from another patch, the &poomatoolkit; sends messages to ! the desired patch uses the message-passing library. All such ! communication is automatically performed by the &toolkit; with no ! need for programmer or user input. Incorporating &pooma;'s distributed computation model into a program requires writing very few lines of code. GuardLayers argument specifies no external guard layer. External guard layers ! simplify computing values along the edges of domains. Since the ! program already uses only the interior domain for computation, we ! do not use this feature. The layout declaration creates a UniformGridLayout layout. As GuardLayers argument specifies no external guard layer. External guard layers ! simplify computing values along the edges of domains. Since our ! program already uses only the interior domain for computation, we do ! not use this feature. The layout declaration creates a UniformGridLayout layout. As layout's three parameters; the contexts are implicitly supplied by the run-time system. ! To create a distributed &array;, it should be created using ! a &layout; object and have a &multipatch; &engine;. Prior ! implementations designed for uniprocessors constructed the ! container using a &domain; object. A distributed implementation ! uses a &layout; object, which conceptually specifies a &domain; ! object and its distribution throughout the computer. A ! &multipatch; &engine; supports computations using multiple patches. ! The UniformTag indicates the patches all have the ! same size. Since patches may reside on different contexts, the ! second template parameter is Remote. Its ! Brick template parameter specifies the &engine; for a ! particular patch on a particular context. Most distributed ! programs use MultiPatch<UniformTag, Remote<Brick> ! > or MultiPatch<UniformTag, ! Remote<CompressibleBrick> > &engine;s. The computations for a distributed implementation are exactly the same as for a sequential implementation. The &poomatoolkit; and ! a message-passing library automatically perform all computation. Input and output for distributed programs is different than ! for sequential programs. Although the same instructions run on ! each context, each context may have its own input and output ! streams. To avoid dealing with multiple input streams, we pass ! the input via command-line arguments, which are replicated for ! each context. Using &inform; streams avoids having multiple ! output streams print. Any context can print to an &inform; stream ! but only text sent to context 0 is sent. At the beginning of ! the program, we create an &inform; object. Throughout the rest of ! the program, we use it instead of std::cout and std::cerr. The command to run the program is dependent on the run-time system. To use &mpi; with the Irix 6.5 operating system, one can use the mpirun command. For example, ! mpirun -np 4 Doof2d-Array-distributed -mpi 2 10 ! 1000 invokes the &mpi; run-time system with four ! processors. The -mpi option tells the ! &pooma; executable Doof2d-Array-distributed to ! use the &mpi; Library. The remaining arguments specify the number ! of processors, the number of averagings, and the array size. The ! first and last values are used for each dimension. For example, ! if three processors are specified, then the x-dimension will have ! three processors and the y-dimension will have three processors, ! totalling nine processors. The command ! Doof2d-Array-distributed -shmem -np 4 2 10 ! 1000 uses the &mm; Shared Memory Library ! (-shmem) and four processors. As for ! &mpi;, the remaining command-line arguments are specified on a ! per-dimension basis for the two-dimensional program. --- 781,837 ---- comprise layout's three parameters; the contexts are implicitly supplied by the run-time system. ! To create a distributed &array;, it should be created using a ! &layout; object and have a &multipatch; &engine; rather than using a ! &domain; object and a &brick; &engine; as we did for the ! uniprocessor implementations. A distributed implementation uses a ! &layout; object, which conceptually specifies a &domain; object and ! its distribution throughout the computer. A &multipatch; &engine; ! supports computations using multiple patches. The ! UniformTag indicates the patches all have the same ! size. Since patches may reside on different contexts, the second ! template parameter is Remote. Its Brick ! template parameter specifies the &engine; for a particular patch on ! a particular context. Most distributed programs use ! MultiPatch<UniformTag, Remote<Brick> > or ! MultiPatch<UniformTag, Remote<CompressibleBrick> ! > &engine;s. The computations for a distributed implementation are exactly the same as for a sequential implementation. The &poomatoolkit; and ! a message-passing library automatically perform all the computation. Input and output for distributed programs is different than ! for sequential programs. Although the same instructions run on each ! context, each context may have its own input and output streams. To ! avoid dealing with multiple input streams, we pass the input via ! command-line arguments, which are replicated for each context. ! Using &inform; streams avoids having multiple output streams print. ! Any context can print to an &inform; stream but only text sent to ! context 0 is displayed. At the beginning of the program, we ! create an &inform; object named output. ! Throughout the rest of the program, we use it instead of ! std::cout and std::cerr. The command to run the program is dependent on the run-time system. To use &mpi; with the Irix 6.5 operating system, one can use the mpirun command. For example, ! mpirun -np 4 Doof2d-Array-distributed -mpi 2 10 ! 1000 invokes the &mpi; run-time system with four ! processors. The option tells the &pooma; ! executable Doof2d-Array-distributed to use the ! &mpi; Library. The remaining arguments specify the number of ! processors, the number of averagings, and the array size. The first ! and last values are the same for each dimension. For example, if three ! processors are specified, then the x-dimension will have three ! processors and the y-dimension will have three processors, totaling ! nine processors. The command Doof2d-Array-distributed ! -shmem -np 4 2 10 1000 uses the &mm; Shared Memory Library ! () and four processors. As for &mpi;, the ! remaining command-line arguments are specified on a per-dimension ! basis for the two-dimensional program. *************** *** 845,851 **** Data-Parallel &field; Implementation &pooma; &array;s support many scientific computations, but ! many scientific computations require values distributed throughout space, and &array;s have no spatial extent. &pooma; &field;s, supporting a superset of &array; functionality, model values distributed throughout space. --- 839,845 ---- Data-Parallel &field; Implementation &pooma; &array;s support many scientific computations, but ! other scientific computations require values distributed throughout space, and &array;s have no spatial extent. &pooma; &field;s, supporting a superset of &array; functionality, model values distributed throughout space. *************** *** 861,869 **** In this section, we implement the &doof2d; two-dimensional diffusion simulation program using &field;s. This simulation does ! not require any &field;-specific features, but we chose to present this program rather than one using &field;-specific features to ! permit comparisons with the &array; versions, especially . --- 855,863 ---- In this section, we implement the &doof2d; two-dimensional diffusion simulation program using &field;s. This simulation does ! not require any &field;-specific features, but we present this program rather than one using &field;-specific features to ! facilitate comparison with the &array; versions, especially . *************** *** 876,886 **** included. ! These statements specify the spacing and number of ! &field; values. First, a layout is explicitly. Then, a mesh, ! which specifies the spacing between cells, is created. The ! &field;'s centering specifies one cell-centered value per ! cell. &field;'s first template parameter specifies the type of --- 870,879 ---- included. ! These statements specify the spacing and number of &field; ! values. First, a layout is specified. Then, a mesh, which ! specifies the spacing between cells, is created. The &field;'s ! centering specifies one cell-centered value per cell. &field;'s first template parameter specifies the type of *************** *** 907,931 **** Since the above program is designed for uniprocessor computation, specifying the domain specifies the layout. A &field;'s mesh specifies its spatial extent. For ! example, one can ask the mesh for the distance between two cells ! or for the normals to a particular cell. Cells in a UniformRectilinearMesh all have the same size and are ! parallelepipeds. To create the mesh, one specifies the layout, ! the location of the spatial point corresponding to the lower, left domain location, and the size of a particular cell. Since this ! program does not use mesh computations, our choices do not much ! matter. We specify the domain's lower, left corner is at spatial ! location (0.0, 0.0) and each cell's width and height is 1. ! Thus, the middle of the cell at domain position (3,4) is (3.5, ! 4.5). A &field; cell can contain one or more values although each ! cell must have the same arrangement. For this simulation, we ! desire one value per cell so we place that position at the cell's center, i.e., a cell centering. The canonicalCentering function returns such a ! centering. We defer discussion of the latter two arguments to ! . A &field; declaration is analogous to an &array; declaration but must also specify a centering and a mesh. In mesh specifies its spatial extent. For ! example, one can ask the mesh for the distance between two cells or ! for the normals to a particular cell. Cells in a UniformRectilinearMesh all have the same size and are ! parallelepipeds. To create the mesh, one specifies the layout, the ! location of the spatial point corresponding to the lower, left domain location, and the size of a particular cell. Since this ! program does not use mesh computations, our choices do not matter. ! We specify the domain's lower, left corner as spatial location (0.0, ! 0.0) and each cell's width and height as 1. Thus, the middle ! of the cell at domain position (3,4) is (3.5, 4.5). A &field; cell can contain one or more values although each ! cell must have the same arrangement of values. For this simulation, ! we desire one value per cell so we place that position at the cell's center, i.e., a cell centering. The canonicalCentering function returns such a ! centering. ]]> . A &field; declaration is analogous to an &array; declaration but must also specify a centering and a mesh. In ! &field; operations are a superset of &array; operations so ! the &doof2d; computations are the same as for . &field; ! accesses require parentheses, not square brackets, and accesses to ! particular values should be preceded by calls to Pooma::blockAndEvaluate. To summarize, &field;s support multiple values per cell and have spatial extent. Thus, their declarations must specify a centering and a mesh. Otherwise, a &field; program is similar to ! one with &array;s. --- 931,947 ---- the &engine; type. Since a &field; has a centering and a mesh in addition to a layout, those arguments are also necessary. ! &field; operations are a superset of &array; operations so the ! &doof2d; computations are the same as in . &field; accesses ! require parentheses, not square brackets, and accesses to individual ! values should be preceded by calls to Pooma::blockAndEvaluate. To summarize, &field;s support multiple values per cell and have spatial extent. Thus, their declarations must specify a centering and a mesh. Otherwise, a &field; program is similar to ! one using &array;s. *************** *** 956,970 **** Distributed &field; Implementation A &pooma; program using &field;s can execute on one or more ! processors. In , we demonstrated how ! to modify a uniprocessor stencil &array; implementation to run on ! multiple processors. In this section, we demonstrate that the ! uniprocessor data-parallel &field; implementation of the previous ! section can be converted. Only the container declarations change; ! the computations do not. Since the changes are exactly analogous ! to those in , ! our exposition here will be shorter. Distributed Data-Parallel &field; Implementation of &doof2d; --- 949,963 ---- Distributed &field; Implementation A &pooma; program using &field;s can execute on one or more ! processors. In , ! we demonstrated how to modify a uniprocessor stencil &array; ! implementation to run on multiple processors. In this section, we ! demonstrate that the uniprocessor data-parallel &field; ! implementation of the previous section can be similarly converted. ! Only the container declarations change; the computations do not. ! Since the changes are exactly analogous to those in , our exposition here ! will be shorter. Distributed Data-Parallel &field; Implementation of &doof2d; *************** *** 974,985 **** Multiple copies of a distributed program may simultaneously run, perhaps each having its own input and output. Thus, we use command-line arguments to pass input to ! the program. Using an &inform; stream ensures only one program produces output. The UniformGridPartition declaration ! specifies how an array's domain will be partition, of split, into patches. Guard layers are an optimization that can reduce data communication between patches. The UniformGridLayout declaration applies the --- 967,978 ---- Multiple copies of a distributed program may simultaneously run, perhaps each having its own input and output. Thus, we use command-line arguments to pass input to ! the program. Using an &inform; stream ensures only one copy produces output. The UniformGridPartition declaration ! specifies how an array's domain will be partitioned, or split, into patches. Guard layers are an optimization that can reduce data communication between patches. The UniformGridLayout declaration applies the *************** *** 991,998 **** uniprocessor and multiprocessor implementations. ! The MultiPatch &engine; distributes requests ! for &array; values to the associated patch. Since a patch may associated with a different processor, its remote engine has type Remote<Brick>. &pooma; automatically --- 984,991 ---- uniprocessor and multiprocessor implementations. ! The &multipatch; &engine; distributes requests ! for &field; values to the associated patch. Since a patch may associated with a different processor, its remote engine has type Remote<Brick>. &pooma; automatically *************** *** 1038,1051 **** The command to invoke a distributed program is ! system-dependent. For example, the mpirun -np 4 ! Doof2d-Field-distributed -mpi 2 10 1000 command might use &mpi; communication. ! Doof2d-Field-distributed -shmem -np 4 2 10 ! 1000 might use the &mm; Shared Memory Library. ! --- 1031,1044 ---- The command to invoke a distributed program is ! system-dependent. For example, the mpirun -np 4 ! Doof2d-Field-distributed -mpi 2 10 1000 command might use &mpi; communication. ! Doof2d-Field-distributed -shmem -np 4 2 10 ! 1000 might use the &mm; Shared Memory Library. ! From jcrotinger at proximation.com Thu Jan 24 20:58:05 2002 From: jcrotinger at proximation.com (James Crotinger) Date: Thu, 24 Jan 2002 13:58:05 -0700 Subject: [pooma-dev] Manual: Wordsmithing Changes to First Four Chapte rs Message-ID: > Applied to mainline. > Approved by Bill Clinton. > Define "Approved". 8-) BTW, are there instructions or tools included to print the manual? I haven't looked at it lately, but I'd like to look it over at least briefly now that it is approaching delivery. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From oldham at codesourcery.com Fri Jan 25 02:33:33 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 24 Jan 2002 18:33:33 -0800 Subject: Manual: Second Half Revised Message-ID: <20020124183333.B7684@codesourcery.com> 2002-Jan-24 Jeffrey D. Oldham These changes continue moving the manual toward delivery. Unfinished sections remain in the DocBook source code but are not printed. Wordsmithing concentrated on the Arrays, Engines, data-parallel, container views, and glossary chapters. The incomplete index and unformatted bibliography sections are not printed. * Makefile (manual.dvi): Update dependences. (%.dvi): Improve rule. (clean): Add generated index. * arrays.xml: Wordsmithing, some format fixes, and some glossary links added. * bibliography.xml: Prevent printing of incomplete bibliography. * concepts.xml: Ensure table cells are aligned at the top of the rows. * data-parallel.xml: Wordsmithing, some format fixes, and some glossary links added. * glossary.xml: Wordsmithing and new 'see also' links added. (reference semantics): New entry. * manual.xml: Wordsmith partially-completed Engine chapter. Ensure table cells are aligned at the top of the rows. Add introductory statement to POOMA installation appendix. Turn off index. Applied to the mainline. Approved by you. Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Makefile =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/Makefile,v retrieving revision 1.1 diff -c -p -r1.1 Makefile *** Makefile 2002/01/14 17:33:33 1.1 --- Makefile 2002/01/25 02:15:02 *************** CXXFLAGS= -g -Wall -pedantic -W -Wstrict *** 25,32 **** all: manual.ps ! manual.dvi: manual.xml introduction.xml tutorial.xml concepts.xml \ ! data-parallel.xml glossary.xml bibliography.xml %.all: %.ps %.pdf %.html chmod 644 $*.ps $*.pdf --- 25,33 ---- all: manual.ps ! manual.dvi: manual.xml introduction.xml template.xml tutorial.xml \ ! concepts.xml arrays.xml data-parallel.xml glossary.xml \ ! bibliography.xml %.all: %.ps %.pdf %.html chmod 644 $*.ps $*.pdf *************** manual.dvi: manual.xml introduction.xml *** 50,58 **** # This rule assumes index creation. %.dvi: %.xml genindex.sgm ! jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) -V html-index $(XML) $< ! perl collateindex.pl $(INDEXOPTIONS) -o genindex.sgm HTML.index ! jade -D$(JADEDIR) -t tex -d $(PRINTDOCBOOKDSL) $(XML) $< && jadetex $*.tex && jadetex $*.tex && jadetex $*.tex genindex.sgm: perl collateindex.pl $(INDEXOPTIONS) -N -o $@ --- 51,59 ---- # This rule assumes index creation. %.dvi: %.xml genindex.sgm ! jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) -V html-index $(XML) $< && \ ! perl collateindex.pl $(INDEXOPTIONS) -o genindex.sgm HTML.index && \ ! jade -D$(JADEDIR) -t tex -d $(PRINTDOCBOOKDSL) -V tex-backend $(XML) $< && jadetex $*.tex && jadetex $*.tex && jadetex $*.tex genindex.sgm: perl collateindex.pl $(INDEXOPTIONS) -N -o $@ *************** mproof-%.ps: %.mp *** 70,73 **** detex $< > $@ clean: ! rm -f *.dvi *.aux *.log *.toc *.bak *.blg *.bbl *.glo *.idx *.lof *.lot *.htm *.mpx mpxerr.tex HTML.index manual.tex --- 71,74 ---- detex $< > $@ clean: ! rm -f *.dvi *.aux *.log *.toc *.bak *.blg *.bbl *.glo *.idx *.lof *.lot *.htm *.mpx mpxerr.tex HTML.index manual.tex genindex.sgm Index: arrays.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/arrays.xml,v retrieving revision 1.3 diff -c -p -r1.3 arrays.xml *** arrays.xml 2002/01/24 05:11:21 1.3 --- arrays.xml 2002/01/25 02:15:03 *************** *** 2,44 **** &array; Containers ! A container is a class holding objects. &array;s are one of ! the two most widely used &pooma; containers since they model the ! mathematical concept of mapping indices from domains to values. &pooma; &array;s extend built-in &cc; arrays by supporting a wider ! variety of domains, automatically handling memory allocations, and ! supporting first-class status. For example, they may be used as operands and in assignments. In this chapter, we introduce the concept of containers, the mathematical concept of arrays, and the ! &pooma; concept for &array;s. Before illustrating how to declare ! &array;s, we introduce &domain;s, which specify the sets of indices. After describing how to declare the various types of ! &domain;s, we describe how to declare and use &array;s. This is ! illustrated in a &doof2d; implementation using &array;s. We end ! with a description of their implementation.

Containers A container class ! expression is a class with the main ! purpose of holding objects. These stored objects, called ! container values or more simply ! values or elements, may be accessed and changed, usually using indices. Container ! class is usually abbreviated container. The six &pooma; containers can be categorized into two groups. Mathematical containers include &tensor;s, &matrix;s, and ! &vector;s, modeling tensors, matrices, and vectors, respectively. Storage containers include &array;s, &dynamicarray;s, and &field;s. In this chapter, we focus on simplest of these: ! &array;s. The other containers will be described in subsequent ! chapters. &c; has built-in arrays, and the &cc; Standard Library provides maps, vectors, --- 2,46 ---- &array; Containers ! A container is an object holding objects. &array;s are one ! of the two most widely used &pooma; containers since they model the ! mathematical concept of mapping from domain indices to values. &pooma; &array;s extend built-in &cc; arrays by supporting a wider ! variety of domains, automatically handling memory allocation, and ! having first-class status. For example, they may be used as operands and in assignments. In this chapter, we introduce the concept of containers, the mathematical concept of arrays, and the ! &pooma; implementation of &array;s. Before illustrating how to ! declare &array;s, we introduce &domain;s, which specify the sets of indices. After describing how to declare the various types of ! &domain;s, we describe how to declare and use &array;s. ! !

Containers A container ! class is a class whose main purpose is to ! hold objects. These stored objects, called container values or more simply ! values or elements, may be accessed and changed, usually using indices. Container ! class is usually abbreviated as container. The six &pooma; containers can be categorized into two groups. Mathematical containers include &tensor;s, &matrix;s, and ! &vector;s, which model tensors, matrices, and vectors, respectively. Storage containers include &array;s, &dynamicarray;s, and &field;s. In this chapter, we focus on simplest of these: ! &array;s. &dynamicarray;s are also described. &c; has built-in arrays, and the &cc; Standard Library provides maps, vectors, *************** *** 47,100 **** more functionality. They automatically handle memory allocation and deallocation and can be used in expressions and on the left-hand side of assignments. Since &pooma; containers separate ! the container concepts of accessing and using values from storing ! values, value storage can be optimized to specific needs. For ! example, if most of an &array;'s values are known to be the same ! most of the time, a compressible engine can be used. Whenever all ! the array's values are the same, it stores only one value. At ! other times, it stores all the values. Engines will be discussed ! in .

&array;s ! Mathematically, an array maps indices from a domain to ! values. Usually, the domain consists of a one-dimensional ! integral interval or it may be multidimensional. &pooma;'s &array; container class implements this idea. Given an index, ! i.e., a position in an &array;'s &domain;, it returns the associated ! value, either by returning a stored value or by computing it. The ! use of indices, which are usually integral tuples but need not be ! zero-based or even consist of all possible integral tuples in a ! multidimensional range. Using indices permits constant-time access to values although computing a particular value may require significant time. &pooma; &array;s are first-class ! types so they can be used more ! widely than built-in &cc; arrays. For example, &array;s can be ! used as operands and in assignment statements. The statement ! a = a + b; adds corresponding elements of &array;s a and b, assigning the sums to the &array; a. The statement ! treats each array as one object, rather than requiring the use of one or more loops to access individual values. Data-parallel ! statements are further discussed in . &array;s also handle their own memory allocation and deallocation. For example, the &array; declaration Array<2, double, Brick> a(vertDomain) creates an &array; a, allocating whatever memory it needs. When a goes out of scope, it and its ! memory is automatically deallocated. Automatic memory allocation ! and deallocation also eases copying. As we mentioned above, an ! &array;'s &engine; stores or computes its values so it, not the ! &array; itself, is responsible for memory allocation and ! deallocation. Fortunately, this distinction is usually hidden ! from the &pooma; user. Individual &array; values can be accessed using parentheses, not square brackets, as for &cc; arrays. For example, --- 49,98 ---- more functionality. They automatically handle memory allocation and deallocation and can be used in expressions and on the left-hand side of assignments. Since &pooma; containers separate ! the concepts of accessing and using values from the concept of ! storing values, value storage can be optimized to specific needs. ! For example, if most of an &array;'s values are known to be ! identical most of the time, a compressible engine can be used. ! Whenever all the array's values are identical, it stores only one ! value. At other times, it stores all the values. Engines will be ! discussed in .

&array;s ! Mathematically, an array maps domain indices to values. ! Usually, the domain consists of a one-dimensional integral ! interval or it may be a multidimensional domain. &pooma;'s &array; container class implements this idea. Given an index, ! i.e., a position in an &array;'s &domain;, it returns the ! associated value, either by returning a stored value or by ! computing it. The indices are usually integral tuples but need ! not be zero-based or even consist of all possible integral tuples ! in a multidimensional range. Using indices permits constant-time access to values although computing a particular value may require significant time. &pooma; &array;s are first-class ! objects so they can be used ! more easily than built-in &cc; arrays. For example, &array;s can ! be used as operands and in assignment statements. The statement ! a = a + b; adds corresponding values of &array;s a and b, assigning the sums to the &array; a. The statement ! treats each array as an object, rather than requiring the use of one or more loops to access individual values. Data-parallel ! statements such as this are further discussed in . &array;s also handle their own memory allocation and deallocation. For example, the &array; declaration Array<2, double, Brick> a(vertDomain) creates an &array; a, allocating whatever memory it needs. When a goes out of scope, it and its ! memory are automatically deallocated. Automatic memory allocation ! and deallocation also eases copying. Individual &array; values can be accessed using parentheses, not square brackets, as for &cc; arrays. For example, *************** *** 108,125 **** A domain ! specifies the set of points on which an &array; can define values. ! These indices are the arguments placed within parentheses when ! selecting particular values, as described previously. A domain ! supported both by &array;s and by built-in &cc; arrays is an interval [0,n-1] of integers containing all integers {0, 1, 2, …, n-1}. For &cc;, every integer in the interval must be included, and the minimum index must be zero. &pooma; expands the set of permissible domains to support intervals with nonzero ! minimal indices and strides and by adding other choices. ! In &pooma;, &domain;s implement domains. There are four ! different categories: &loc; --- 106,123 ---- A domain ! specifies the set of points on which an array can define values. ! These indices are the arguments placed within parentheses to ! select particular values, as described previously. A domain ! supported both by &array;s and by built-in &cc; arrays is the interval [0,n-1] of integers containing all integers {0, 1, 2, …, n-1}. For &cc;, every integer in the interval must be included, and the minimum index must be zero. &pooma; expands the set of permissible domains to support intervals with nonzero ! minimal indices, nonzero strides, and other options. ! In &pooma;, &domain; classes implement domains. There are ! four different categories: &loc; *************** *** 150,156 **** ! One-dimensional and multidimensional versions of each categories are supported. A multidimensional &domain; consists of the direct product of one-dimensional &domain;s. For example, the first dimension of a two-dimensional interval [0,3]x[2,9] is the --- 148,154 ---- ! One-dimensional and multidimensional versions of the categories are supported. A multidimensional &domain; consists of the direct product of one-dimensional &domain;s. For example, the first dimension of a two-dimensional interval [0,3]x[2,9] is the *************** *** 178,198 **** example, [2:4:2,6:4:-2] contains (2,6), (2,4), (4,6), and (4,4). ! All the &domain; categories listed above except &grid; can be ! represented using domain triplet notation. Since the triplet [7:7:1] represents {7}, or more simply 7, it can also ! represent Loc<1>(7). Multidimensional ! &loc;s are similarly represented. For example, [0:0:1,10:10:1,2:2:1] represents Loc<3>(0,10,2), but it is frequently abbreviated as [0,10,2]. An &interval; [a,b] has unit stride: ! [a:b:1], while a ⦥ has specific stride s: [a:b:s]. ! &domain;s can be constructed by combining &domain;s of smaller ! dimension. For example, since a two-dimensional &interval; is the ! direct product of two one-dimensional &interval;s, it can be ! specified using two one-dimensional &interval;s. For example, Interval<2>(Interval<1>(2,3), Interval<1>(4,5)) creates a [2:3:1,4:5:1] &domain;. The resulting dimensionality equals the sum of the --- 176,197 ---- example, [2:4:2,6:4:-2] contains (2,6), (2,4), (4,6), and (4,4). ! All the &domain; categories listed above except &grid; can ! be represented using domain triplet notation. Since the triplet [7:7:1] represents {7}, or more simply 7, it can also ! represent the one-dimensional Loc<1>(7). ! Multidimensional &loc;s are similarly represented. For example, [0:0:1,10:10:1,2:2:1] represents Loc<3>(0,10,2), but it is frequently abbreviated as [0,10,2]. An &interval; [a,b] has unit stride: ! [a:b:1], while a ⦥ has specific stride s, e.g., [a:b:s]. ! &domain;s can be constructed by combining &domain;s with ! smaller dimension. For example, since a two-dimensional ! &interval; is the direct product of two one-dimensional ! &interval;s, it can be specified using two one-dimensional ! &interval;s. For example, Interval<2>(Interval<1>(2,3), Interval<1>(4,5)) creates a [2:3:1,4:5:1] &domain;. The resulting dimensionality equals the sum of the *************** *** 220,248 **** units to the right by adding two. Multiplying a &domain; by two multiplies its triplet's beginnings, endings, and strides by two. &pooma; users rarely need to compare &domain;s, but we describe ! operating with the less-than operator on &interval;s. &interval; d1 < &interval; d2 if the length of d1's interval is less than d2's or, if equal, its beginning value is ! smaller. &domain; arithmetic is frequently used with data-parallel ! statements and container views. These will be discussed in and . The current &pooma; implementation supports &domain;s with dimensionality between one and seven, inclusive. Since most scientific computations use one, two, or three dimensions, this is ! usually sufficient. If more dimensions are needed, they can be ! added to the source code.

Declaring &domain;s Since &domain;s are mainly used to declare container ! domains, we focus on declaring &domain;s. We describe a few ! &domain; operations but most, including arithmetic operations with ! &domain;s, are described in . All &domain; declarations require a dimension template parameter &dim;. This positive integer --- 219,248 ---- units to the right by adding two. Multiplying a &domain; by two multiplies its triplet's beginnings, endings, and strides by two. &pooma; users rarely need to compare &domain;s, but we describe ! operating with the less-than operator on &interval;s: &interval; d1 < &interval; d2 if the length of d1's interval is less than d2's or, if equal, its beginning value is ! smaller. &domain; arithmetic is frequently used with ! data-parallel statements and container views. These will be ! discussed in and . The current &pooma; implementation supports &domain;s with dimensionality between one and seven, inclusive. Since most scientific computations use one, two, or three dimensions, this is ! usually sufficient. If more dimensions than seven are needed, ! they can be added to the source code.

Declaring &domain;s Since &domain;s are mainly used to declare container ! domains, we focus on declaring &domain;s. We subsequently ! describe a few &domain; operations but most, including arithmetic ! operations with &domain;s, are described in . All &domain; declarations require a dimension template parameter &dim;. This positive integer *************** *** 255,267 **** one-dimensional &domain;s carry over to multidimensional ones. ! To declare a &domain;, one must include the ! Pooma/Domains.h header ! file. However, most &pooma; programs declare &domain;s to use them ! when constructing containers. The container header files ! automatically include Pooma/Domains.h so no explicit ! inclusion is usually necessary.

--- 255,266 ---- one-dimensional &domain;s carry over to multidimensional ones. ! To declare a &domain;, one must include the Pooma/Domains.h header file. ! However, most &pooma; programs use &domain;s when constructing ! containers. The storage container header files automatically ! include Pooma/Domains.h ! so no explicit inclusion is usually necessary.

*************** *** 292,301 **** ! Loc<1>() ! points to zero. Loc<1>(const Pooma::NoInit& no) --- 291,300 ---- ! Loc<1>() ! indicates zero. Loc<1>(const Pooma::NoInit& no) *************** *** 330,345 **** will be assigned later. For small &domain;s such as &loc;s, the time savings from not initializing is small, but the functionality is still available. The constructor taking one ! argument with type &domaintemplate;1 converts this argument to ! an integer to specify the point. The template ! type &domaintemplate;1 may be any type that can be converted ! to an integer, e.g., &bool;, &char;, ∫, or &double;. The ! constructors taking two and three arguments of templatized types ! facilitate converting an &interval; and a ⦥ into a &loc;. ! Since a &loc; represents a single point, the &interval;'s or ! ⦥'s first two arguments must be equal. The stride is ! ignored. Again, the templatized types may be any type that can ! be converted into an integer. --- 329,344 ---- will be assigned later. For small &domain;s such as &loc;s, the time savings from not initializing is small, but the functionality is still available. The constructor taking one ! argument with type &domaintemplate;1 converts ! this argument to an integer to specify the point. The template ! type &domaintemplate;1 may be any type that ! can be converted to an integer, e.g., &bool;, &char;, ∫, or ! &double;. The constructors taking two and three arguments of ! templatized types facilitate converting an &intervalone; and a ! &rangeone; into a &locone;. Since a &loc; represents a single ! point, the &interval;'s or ⦥'s first two arguments must be ! equal. The stride is ignored. Again, the templatized types may ! be any type that can be converted into an integer.

*************** *** 359,368 **** template parameters. ! Loc<&dim;>() ! points to zero. Loc<&dim;>(const Pooma::NoInit& no) --- 358,367 ---- template parameters. ! Loc<&dim;>() ! indicates zero. Loc<&dim;>(const Pooma::NoInit& no) *************** *** 465,471 **** ! Interval<1>() creates an empty, uninitialized interval. --- 464,470 ---- ! Interval<1>() creates an empty, uninitialized interval. *************** *** 476,491 **** Interval<1>(const &domaintemplate;1& t1) ! creates a &intervalone;. See the text for an explanation. Interval<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a &intervalone; with the integers converted from t1 and t2. Interval<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates a &intervalone; with the integers converted from t1 and t2. t3 must equal 1. --- 475,490 ---- Interval<1>(const &domaintemplate;1& t1) ! creates an &intervalone;. See the text for an explanation. Interval<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates an &intervalone; with the integers converted from t1 and t2. Interval<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates an &intervalone; with the integers converted from t1 and t2. t3 must equal 1. *************** *** 497,512 **** constructors except that &intervalone;s can have differing beginning and ending points. See . ! The default constructor creates an empty, uninitialized interval, ! which should not be used before assigning it values. If the ! one-parameter constructor's argument is a &domain; object, it must ! be a one-dimensional &domain; object which is copied into an ! &interval; if possible; for example, it must have unit stride. ! If the one-parameter constructor's argument is not a &domain; ! object, it must be convertible to an integer e and an interval [0:e-1:1] ! starting at zero is constructed. If two arguments are specified, ! they are assumed to be convertible to integers b and e, specifying the interval [b:e:1]. The three-parameter constructor is similar, with the third argument specifying a stride, which must be --- 496,512 ---- constructors except that &intervalone;s can have differing beginning and ending points. See . ! The default constructor creates an empty, uninitialized ! interval, which should not be used before assigning it values. ! If the one-parameter constructor's argument is a &domain; ! object, it must be a one-dimensional &domain; object which is ! converted into an &interval; if possible; for example, it must have ! unit stride. If the one-parameter constructor's argument is not ! a &domain; object, it must be convertible to an integer e and an interval [0:e-1:1] ! starting at zero is constructed. Note e-1, not e, is used so ! the &intervalone; has e indices. If two arguments are ! specified, they are assumed to be convertible to integers b and e, specifying the interval [b:e:1]. The three-parameter constructor is similar, with the third argument specifying a stride, which must be *************** *** 530,536 **** template parameters. ! Interval<&dim;>() creates an empty, uninitialized &interval;, to be assigned a value later. --- 530,536 ---- template parameters. ! Interval<&dim;>() creates an empty, uninitialized &interval;, to be assigned a value later. *************** *** 541,578 **** Interval<&dim;>(const &domaintemplate;1& t1) ! creates a &interval; using the given &domain; object. Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates a &interval; using the given &domain; objects. Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates a &interval; using the given &domain; objects. Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) ! creates a &interval; using the given &domain; objects. Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& t5) ! creates a &interval; using the given &domain; objects. Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& t5, const &domaintemplate;6& t6) ! creates a &interval; using the given &domain; objects. Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) ! creates a &interval; using the given &domain; objects. --- 541,578 ---- Interval<&dim;>(const &domaintemplate;1& t1) ! creates an &interval; using the given &domain; object. Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) ! creates an &interval; using the given &domain; objects. Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) ! creates an &interval; using the given &domain; objects. Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) ! creates an &interval; using the given &domain; objects. Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& t5) ! creates an &interval; using the given &domain; objects. Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& t5, const &domaintemplate;6& t6) ! creates an &interval; using the given &domain; objects. Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) ! creates an &interval; using the given &domain; objects. *************** *** 635,641 **** ! Range<1>() creates an empty, uninitialized range. --- 635,641 ---- ! Range<1>() creates an empty, uninitialized range. *************** *** 665,684 ****

&rangeone; constructors are the same as &intervalone; ! constructors except they create ranges, not intervals. See . The default constructor creates an empty, uninitialized range, which should not be used before assigning it values. If the ! one-parameter constructor's argument is a &domain; object, it must ! be a one-dimensional &domain; object which is copied into a ⦥ ! if possible. If the one-parameter constructor's argument is not ! a &domain; object, it must be convertible to an integer e and a range [0:e-1:1] starting ! at zero is constructed. If two arguments are specified, they are ! assumed to be convertible to integers b and ! e, specifying the range [b:e:1]. The ! three-parameter constructor is similar, with the third argument ! specifying a stride. --- 665,686 ----

&rangeone; constructors are the same as &intervalone; ! constructors except they create ranges, not intervals. See ! . The default constructor creates an empty, uninitialized range, which should not be used before assigning it values. If the ! one-parameter constructor's argument is a &domain; object, it ! must be a one-dimensional &domain; object which is converted ! into a ⦥ if possible. If the one-parameter constructor's ! argument is not a &domain; object, it must be convertible to an integer e and a range [0:e-1:1] starting ! at zero is constructed. Note e-1, not e, is used so the ! &intervalone; has e indices. If two arguments are specified, ! they are assumed to be convertible to integers ! b and e, specifying the ! range [b:e:1]. The three-parameter constructor is similar, with ! the third argument specifying a stride. *************** *** 698,704 **** template parameters. ! Range<&dim;>() creates an empty, uninitialized ⦥, to be assigned a value later. --- 700,706 ---- template parameters. ! Range<&dim;>() creates an empty, uninitialized ⦥, to be assigned a value later. *************** *** 807,813 **** ! Grid<1>() creates an empty, uninitialized grid. --- 809,815 ---- ! Grid<1>() creates an empty, uninitialized grid. *************** *** 843,856 **** &gridone;s with irregularly spaced points can be constructed using &indirectionlistint;s. For example, ! ! IndirectionList<int> list(4); ! list(0) = 2; ! list(1) = 5; ! list(2) = 6; ! list(3) = 9; ! Grid<1> g(list); ! constructs an empty &indirectionlistint;, fills it with ascending values, and then creates a &gridone; containing {2, 5, 6, 9}. When creating a list, its size must be specified. Subsequently, its values can be assigned. &indirectionlist;s can --- 845,858 ---- &gridone;s with irregularly spaced points can be constructed using &indirectionlistint;s. For example, ! ! IndirectionList<int> list(4); ! list(0) = 2; ! list(1) = 5; ! list(2) = 6; ! list(3) = 9; ! Grid<1> g(list); ! constructs an empty &indirectionlistint;, fills it with ascending values, and then creates a &gridone; containing {2, 5, 6, 9}. When creating a list, its size must be specified. Subsequently, its values can be assigned. &indirectionlist;s can *************** *** 885,891 **** parameters. ! Grid<&dim;>() creates an empty, uninitialized &grid;, to be assigned a value later. --- 887,893 ---- parameters. ! Grid<&dim;>() creates an empty, uninitialized &grid;, to be assigned a value later. *************** *** 961,973 **** Since an &array; can be queried for its domain, we briefly describe some &domain; operations. A fuller description, ! including arithmetic operations, occur in . As we mentioned in , the Pooma/Domains.h header file ! declares &domain;s, but most container header files automatically ! include Pooma/Domains.h ! so no explicit inclusion of is usually necessary.

--- 963,976 ---- Since an &array; can be queried for its domain, we briefly describe some &domain; operations. A fuller description, ! including arithmetic operations, occurs in . As we mentioned in , the Pooma/Domains.h header file ! declares &domain;s, but most storage container header files ! automatically include Pooma/Domains.h so no explicit ! inclusion is usually necessary.

*************** *** 982,993 **** ! D abbreviates the particular &domain; ! type, e.g., &interval; or &grid;. Other &domain; accessors ! are described in . ! Multidimensional &domain; Accessors --- 985,996 ---- ! D abbreviates a particular &domain; type, ! e.g., &interval; or &grid;. Other &domain; accessors are ! described in . ! Multidimensional &domain; Accessors *************** *** 1030,1041 **** D<1>::iterator begin() ! returns a bidirectional iterator pointing to the beginning domain index. D<1>::iterator end() ! returns a bidirectional iterator pointing to the ending domain index. --- 1033,1044 ---- D<1>::iterator begin() ! returns a forward iterator pointing to the beginning domain index. D<1>::iterator end() ! returns a forward iterator pointing to the ending domain index. *************** *** 1054,1060 **** one-dimensional &domain;s. The operator[](int dimension) operator extracts the one-dimensional &domain; corresponding to its parameter. For example, the three ! Range<1> (one-dimensional) &domain;s can be extracted from a Range<3> object r using r[0], r[1], and --- 1057,1063 ---- one-dimensional &domain;s. The operator[](int dimension) operator extracts the one-dimensional &domain; corresponding to its parameter. For example, the three ! one-dimensional Range<1> &domain;s can be extracted from a Range<3> object r using r[0], r[1], and *************** *** 1069,1075 **** first and last member functions return the domain's beginning and ending indices. The begin and ! end member functions return input iterators pointing to these respective locations. They have type D<1>::iterator, where D abbreviates the &domain;'s type, e.g., &interval; or &grid;. --- 1072,1078 ---- first and last member functions return the domain's beginning and ending indices. The begin and ! end member functions return forward iterators pointing to these respective locations. They have type D<1>::iterator, where D abbreviates the &domain;'s type, e.g., &interval; or &grid;. *************** *** 1077,1086 **** --> The min and max member functions return the minimum and maximum indices in the &domain; object, respectively. For ! &locone; and &intervalone;, these are the same as first and last, ! but &rangeone; and &gridone; can have their largest index at the ! beginning of their &domain;s. --- 1080,1089 ---- --> The min and max member functions return the minimum and maximum indices in the &domain; object, respectively. For ! &locone; and &intervalone;, these yield the same values as first and last, ! but &rangeone; and &gridone; can have their numerically largest ! index at the beginning of their &domain;s. *************** *** 1088,1100 ****

Declaring &array;s ! A &pooma; &array; maps indices from its &domain; to values. ! In this section, we first describe how to declare &array;s. In ! the next section, we explain how to access individual values ! stored within an &array; and &array; copy semantics. &array; values need not just be stored values, as &c; arrays ! have. They can also be computed using its engine. We defer discussion of computing values to the next chapter discussing engines (). To avoid being verbose in this chapter, when we discuss stored values, the values might --- 1091,1105 ----

Declaring &array;s ! A &pooma; &array; maps &domain; indices to values. In this ! section, we describe how to declare &array;s. In the next ! section, we explain how to access individual values stored within ! an &array; and how to copy &array;s. + + &array; values need not just be stored values, as &c; arrays ! have. They can also be computed by its engine. We defer discussion of computing values to the next chapter discussing engines (). To avoid being verbose in this chapter, when we discuss stored values, the values might *************** *** 1102,1177 **** Declaring an &array; requires four arguments: the domain's dimensionality, the type of values stored or computed, a ! specification how the values are stored, and a &domain;. The ! first three arguments are template parameters since few scientific ! programs (and no &pooma; programs) need to change these values ! while a program executes. For example, an &array; cannot change ! the type of the elements it stores. Alternatively, an &array;'s ! values can be copied into another &array; having the desired type. ! Although scientific programs do not frequently change an array's ! domain, they do frequently request a subset of the array's values, ! i.e., a view. The ! subset is specified via a &domain; so it is a run-time value. ! Views are presented in . An &array;'s first template parameter specifies its dimensionality. This positive ! integer &dim; specifies its rank. This is the same value as its domain's dimensionality. Theoretically, an &array; can have any positive integer, but the &pooma; code ! currently supports &dim; at most seven. For ! almost all scientific codes, a dimension of three or four is ! sufficient, but the code can be extended to support higher dimensions. An &array;'s second template parameter specifies the type of ! its stored values. Common value types include ∫, &double;, ! &complex;, and &vector;, but any type is permissible. For ! example, an &array;'s values might be matrices or even other &array;s. The parameter's default value is usually &double;, but it may be changed when the &poomatoolkit; is configured. An &array;'s third parameter specifies how its data is ! stored by an &engine; and its values accessed. The argument is a ! tag indicating a particular type of &engine;. Permissible tags ! include &brick;, &compressiblebrick;, and ConstantFunction. The &brick; tag indicates all &array; values will be explicitly stored, just as built-in &c; ! arrays do. If the &array;s frequently stores exactly the same ! value in every position, a &compressiblebrick; &engine;, which ! reduces its space requirements to a constant whenever all its ! values are the same, is appropriate. A ! ConstantFunction &engine; returns the same value for ! all indices. Even though every &array; container has an engine to store ! its values and permit access to individual values, an &array; is ! conceptually separated from engines. An engine's role is ! low-level, storing values and permitting access to individual ! values. As we indicated above, the storage can be optimized to ! fit specific situations such as few nonzero values and computing ! values using a function applied to another engine's values. An ! &array;'s role is high-level, supporting access to groups of ! values. They handle memory allocation and deallocation. &array;s ! can be used in data-parallel expressions, e.g., adding all the ! values in one &array; to all the values in another. (See for more information.) Subsets of ! &array; values, frequently used in data-parallel statements, can ! be obtained. (See for more ! information.) Even though engines and &array;s are conceptually ! separate, higher-level &array;s provide access to lower-level ! &engine;s. Users usually have an &array; create its &engine;, ! rarely explicitly creating &engine;s themselves. Also, &array;s ! provide access to individual values. In short, &pooma; users use ! &array;s, only dealing with how they are implemented (engines) ! upon declaration. For more description of &engine;s, see . - - The engine parameter's default value is usually &brick;, but - it may be changed when the &poomatoolkit; is configured. ! An &array;'s one constructor argument is its domain. The ! domain specifies its extent and simultaneously how many values it can return. All the provided &domain; objects are combined to yield an Interval<&dim;>, where &dim; matches the &array;'s first template parameter. Since an &interval; --- 1107,1186 ---- Declaring an &array; requires four arguments: the domain's dimensionality, the type of values stored or computed, a ! specification how the values are stored or computed, and a ! &domain;. The first three arguments are template parameters since ! few scientific programs need to (and no &pooma; programs can) ! change these values while a program executes. For example, an ! &array; cannot change the type of the values it stores, but an ! &array;'s values can be copied into another &array; having the ! desired type. Although scientific programs do not frequently ! change an array's domain, they do frequently request a subset of ! the array's values, i.e., a view. The subset is specified ! via a &domain; so it is a run-time value. Views are presented in ! . An &array;'s first template parameter specifies its dimensionality. This positive ! integer &dim; specifies its rank and has the same value as its domain's dimensionality. Theoretically, an &array; can have any positive integer, but the &pooma; code ! currently supports a dimensionality of at most seven. For almost ! all scientific codes, a dimension of three or four is sufficient, ! but the &pooma; code can be extended to support higher dimensions. An &array;'s second template parameter specifies the type of ! its stored or computed values. Common value types include ∫, ! &double;, &complex;, and &vector;, but any type is permissible. ! For example, an &array;'s values might be matrices or even other &array;s. The parameter's default value is usually &double;, but it may be changed when the &poomatoolkit; is configured. An &array;'s third parameter specifies how its data is ! stored or computed by an &engine; and its values accessed. The ! argument is a tag indicating a particular type of &engine;. ! Permissible tags include &brick;, &compressiblebrick;, and ConstantFunction. The &brick; tag indicates all &array; values will be explicitly stored, just as built-in &c; ! arrays do. If an &array; frequently stores exactly the same value ! in every position, a &compressiblebrick; &engine;, which reduces ! its space requirements to a constant whenever all its values are ! the same, is appropriate. A ConstantFunction ! &engine; returns the same value for all indices. Some &engine;s ! compute values, e.g., applying a function to every value in ! another &engine;. These &engine;s are discussed in . To avoid being verbose in the rest of ! this chapter, we abbreviate store or compute values ! as store values. The engine parameter's default ! value is usually &brick;, but it may be changed when the ! &poomatoolkit; is configured. Even though every &array; container has an engine to store ! its values and permit access to individual values, the concept of ! an &array; is conceptually separate from the concept of an engine. ! An engine's role is low-level, storing values and permitting ! access to individual values. As we indicated above, the storage ! can be optimized to fit specific situations such as few nonzero ! values and computing values using a function applied to another ! engine's values. An &array;'s role is high-level, supporting ! access to groups of values. &array;s can be used in data-parallel ! expressions, e.g., adding all the values in one &array; to all the ! values in another. (See for ! more information.) Subsets of &array; values, frequently used in ! data-parallel statements, can be obtained. (See for more information.) Even though ! engines and &array;s are conceptually separate, higher-level ! &array;s provide access to lower-level &engine;s. Users usually ! have an &array; create its &engine;(s), rarely explicitly creating ! &engine;s themselves. Also, &array;s support access to individual ! values. In short, &pooma; users use &array;s, only dealing with ! how they are implemented (engines) when declaring them. For a ! description of &engine;s, see . ! An &array;'s one run-time argument is its domain. The ! domain specifies its extent and consequently how many values it can return. All the provided &domain; objects are combined to yield an Interval<&dim;>, where &dim; matches the &array;'s first template parameter. Since an &interval; *************** *** 1185,1190 **** --- 1194,1240 ---- required, the &pooma; code can be extended to the desired number of dimensions. + &array; constructors are listed in . An &array;'s + three template parameters for dimensionality, value type, and + engine type are abbreviated D, + T, and E. Template + parameters for domain types are named DT1, + …, DT7. The first constructor, with no + domain arguments, creates an empty, uninitialized &array; for + which a domain must be specified before it is used. Specify the + array's domain using its initialize + function. The next seven constructors combine their domain + arguments to compute the resulting &array;'s domain. These are + combined in the same way that multidimensional &interval;s are + constructed. (See + and the following text.) The domain objects, having types + &domaintemplate;1, …, + &domaintemplate;7, can have any type that can be + converted into an integer, into a single-dimensional &domain; + object that can be converted into a single-dimensional &interval;, + or to a multidimensional &domain; object that itself can be + converted into an &interval;. The total dimensionality of all the + arguments' types should + equal &dim;, unlike + &interval; construction which permits total dimensionality less + than or equal to &dim;. One-dimensional + &domain; objects that can be converted into one-dimensional + &interval;s include &locone;s, &intervalone;s, and &rangeone;s + with unit strides. To initialize all of an &array;'s values to a + specific value, use one of the final seven constructors, each + taking a particular value, wrapped as a ModelElement. + These constructors use the given domain objects the same way as + the preceding constructors but assign model to + every &array; value. model's type is + ModelElement<T>, rather than + T, to differentiate it from an ∫, which can + also be used to specify a domain object. + ModelElement just stores an element of any type + T, which must match the &array;'s value + type T. +

Declaring &array;s *************** *** 1206,1212 **** integers. ! Array<&dim;,T,E>() creates an empty, uninitialized &array; which must be --- 1256,1262 ---- integers. ! Array<&dim;,T,E>() creates an empty, uninitialized &array; which must be *************** *** 1310,1368 ****

- &array; constructors are listed in . An &array;s' - three template parameters for dimensionality, value type, and - engine type are abbreviated D, - T, and E. Template - parameters for domain types are named DT1, - …, DT7. The first constructor, with no - domain arguments, creates an empty, uninitialized &array; for - which a domain must be specified before it is used. Specify the - array's domain using its initialize function. - The next seven constructors combine their domain arguments to - compute the resulting &array;'s domain. These are combined in the - same way that multidimensional &interval;s are constructed. (See - - and the following text.) The domain objects, having types - &domaintemplate;1, …, - &domaintemplate;7, can have any type that can be - converted into an integer, into a single-dimensional &domain; - object that can be converted into a single-dimensional &interval;, - or to a multidimensional &domain; object that itself can be - converted into an &interval;. The total dimensionality of all the - arguments' types should - equal &dim;, unlike - &interval; construction which permits total dimensionality less - than or equal to &dim;. One-dimensional - &domain; objects that can be converted into one-dimensional - &interval;s include &locone;s, &intervalone;s, and &rangeone;s - with unit strides. To initialize all of an &array; values to a - specific value, use one of the final seven constructors, each - taking a particular value, wrapped as a ModelElement. - These constructors use the given domain objects the same way as - the preceding constructors but assign model to - every &array; value. model's type - ModelElement<T> rather than - T to differentiate it from an ∫, which can - also be used to specify a domain object. - ModelElement just stores an element of any type - T, which must match the &array;'s value - type. - We illustrate creating &array;s. To create a three-dimensional &array; a explicitly storing &double; floating-point values, use Interval<1> D(6); Interval<3> I3(D,D,D); ! Array<3,double,Brick> a(I3);. The template parameters specify its dimensionality, the type of its values, and a &brick; &engine; type, which explicitly stores values. Its domain, which must have three dimensions, is specified by an Interval<3> ! object which consists of a [0,5] intervals for all its three dimensions. Since &double; and &brick; are usually the default template parameters, they can be omitted so these declarations are equivalent: --- 1360,1377 ---- We illustrate creating &array;s. To create a three-dimensional &array; a explicitly storing &double; floating-point values, use Interval<1> D(6); Interval<3> I3(D,D,D); ! Array<3,double,Brick> a(I3); The template parameters specify its dimensionality, the type of its values, and a &brick; &engine; type, which explicitly stores values. Its domain, which must have three dimensions, is specified by an Interval<3> ! object which consists of [0,5] intervals for all its three dimensions. Since &double; and &brick; are usually the default template parameters, they can be omitted so these declarations are equivalent: *************** Array<3> a_duplicate2(I3);. *** 1372,1383 **** To create a similar &array; with a domain of [0:1:1, 0:2:1, 0:0:1], use ! Array<3> b(2,3,1);. ! Specifying an integer i indicates a one-dimensional zero-based &interval; [0:i-1:1]. To ! store &bool;s, specify &bool; as the second template argument: ! Array<2,bool> c(2,3);. To specify a default &array; value of &true;, use ModelElement<bool>(true): --- 1381,1392 ---- To create a similar &array; with a domain of [0:1:1, 0:2:1, 0:0:1], use ! Array<3> b(2,3,1); ! since specifying an integer i indicates a one-dimensional zero-based &interval; [0:i-1:1]. To ! store booleans, specify &bool; as the second template argument: ! Array<2,bool> c(2,3); To specify a default &array; value of &true;, use ModelElement<bool>(true): *************** Array<2,bool> c(2,3, ModelElement& *** 1385,1395 **** To create a one-dimensional &array; containing seven &double;s all equaling π, use ! Array<1,double,CompressibleBrick> d(7, ModelElement<double>(4.0*atan(1.0)));. We use a &compressiblebrick; &engine;, rather than ! a &brick; &engine;, so all seven values will be stored once rather ! than seven times when they are all the same. Initializing &array;s' Domains --- 1394,1432 ---- To create a one-dimensional &array; containing seven &double;s all equaling π, use ! const double pi = 4.0*atan(1.0); ! Array<1,double,CompressibleBrick> d(7, ModelElement<double>(pi));. We use a &compressiblebrick; &engine;, rather than ! a &brick; &engine;, so all seven values will be stored in one ! location rather than in seven separate locations when they are all the ! same. + An uninitialized &array;, created using its parameter-less + constructor, must have a specified domain before it can be used. + For example, one must use the parameter-less &array; constructor + when creating an array of &array;s using + new so their domains must be specified. + (It would probably be better to create an &array; of &array;s + since memory allocation and deallocation would automatically be + handled.) &array;'s initialize functions + accept the same set of domain object specifications and model + elements that the &array; constructors do, creating the specified + domain. See . + For example, both a and b + are two-dimensional &array;s of &float;s with a [2:7:1,-2:4:1] + domains: + + // Create an Array and its domain. + Array<2,float,Brick> a(Interval<1>(2,7), Interval<1>(-2,4)); + + // Create an Array without a domain and then specify its domain. + Array<2,float,Brick> b(); + b.initialize(Interval<1>(2,7), Interval<1>(-2,4));. + Invoking initialize on an + &array; with an existing domain yields unspecified behavior. All + &array; values may be lost and memory may be leaked. +

Initializing &array;s' Domains *************** Array<1,double,CompressibleBrick> *** 1413,1419 **** integers. ! --- 1450,1456 ---- integers. ! *************** object or integer. *** 1455,1480 **** initialize(const DT1& t1, const ModelElement<T>& model) ! creates the &array;'s domain using the given &domain; object and then initializes all entries using model. initialize(const DT1& t1, const DT2& t2, const ModelElement<T>& model) ! creates the &array;'s domain using the given &domain; objects and then initializes all entries using model. initialize(const DT1& t1, const DT2& t2, const DT3& t3, const ModelElement<T>& model) ! creates the &array;'s domain using the given &domain; objects and then initializes all entries using model. initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const ModelElement<T>& model) ! creates the &array;'s domain using the given &domain; objects and then initializes all entries using model. --- 1492,1520 ---- initialize(const DT1& t1, const ModelElement<T>& model) ! creates the &array;'s domain using the given &domain; ! object or integer and then initializes all entries using model. initialize(const DT1& t1, const DT2& t2, const ModelElement<T>& model) ! creates the &array;'s domain using the given &domain; ! objects and integers and then initializes all entries using model. initialize(const DT1& t1, const DT2& t2, const DT3& t3, const ModelElement<T>& model) ! creates the &array;'s domain using the given &domain; ! objects and integers and then initializes all entries using model. initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const ModelElement<T>& model) ! creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. *************** object or integer. *** 1482,1488 **** DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, const ModelElement<T>& model) ! creates the &array;'s domain using the given &domain; objects and then initializes all entries using model. --- 1522,1528 ---- DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, const ModelElement<T>& model) ! creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. *************** object or integer. *** 1490,1496 **** DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, const DT6& t6, const ModelElement<T>& model) ! creates the &array;'s domain using the given &domain; objects and then initializes all entries using model. --- 1530,1536 ---- DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, const DT6& t6, const ModelElement<T>& model) ! creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. *************** object or integer. *** 1498,1534 **** DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, const DT6& t6, const DT7& t7, const ModelElement<T>& model) ! creates the &array;'s domain using the given &domain; objects and then initializes all entries using model.

- - An uninitialized &array;, created using the parameter-less - constructor, must have a specified domain before it can be used. - For example, one must use the parameter-less &array; constructor - when creating an array of &array;s using - new (although it would probably be - better to create an &array; of &array;s since memory allocation - and deallocation would automatically be handled) so their domains - must be specified. &array;'s initialize - functions accept the same set of domain object specifications and - model elements that the &array; constructors do, creating the - specified domain. See . - For example, both a and b - are two-dimensional &array;s of &float;s with a [2:7:1,-2:4:1] - domains: - - // Create an Array and its domain. - Array<2,float,Brick> a(Interval<1>(2,7), Interval<1>(-2,4)); - // Create an Array without a domain and then specify its domain. - Array<2,float,Brick> b(); - b.initialize(Interval<1>(2,7), Interval<1>(-2,4));. - Invoking initialize on an - &array; with an existing domain is unspecified. All &array; - values may be lost and memory may be leaked.

--- 1538,1549 ---- DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, const DT6& t6, const DT7& t7, const ModelElement<T>& model) ! creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model.

*************** std::cout &openopen; a(2,-2) &openopen; *** 1571,1586 **** std::cout &openopen; a.read(2,-2) &openopen; std::endl; Using read sometimes permits the optimizer to produce faster executing code. - - - Copying &array;s - &array-copy; - ! Copying &array;s requires little execution time because they ! have reference semantics. That is, a copy of an &array; and the ! &array; itself share the same underlying data. Changing a value ! in one changes it in the other. illustrates this behavior. Initially, all values in the array a are 4. The b array is initialized using --- 1586,1598 ---- std::cout &openopen; a.read(2,-2) &openopen; std::endl; Using read sometimes permits the optimizer to produce faster executing code. ! Copying &array;s requires little execution time because ! &array;s have reference ! semantics. That is, a copy of an &array; ! and the &array; itself share the same underlying data. Changing a ! value in one changes it in the other. illustrates this behavior. Initially, all values in the array a are 4. The b array is initialized using *************** std::cout &openopen; a.read(2,-2) &openo *** 1589,1598 **** changes the latter's value. Function arguments are also initialized so changing their underlying values also changes the calling function's values. For example, the ! changeValue function changes the value with ! index (0,0) of both its function argument and a. The separation between a higher-level &array; and its lower-level &engine; storage permits fast copying. An &array;'s only data member is its engine, which itself has reference --- 1601,1615 ---- changes the latter's value. Function arguments are also initialized so changing their underlying values also changes the calling function's values. For example, the ! changeValue function changes the value at ! index (0,0) for both its function argument and a. + + Copying &array;s + &array-copy; + + The separation between a higher-level &array; and its lower-level &engine; storage permits fast copying. An &array;'s only data member is its engine, which itself has reference *************** std::cout &openopen; a.read(2,-2) &openo *** 1608,1613 **** --- 1625,1645 ---- a's values do not change b's values or vice versa. + The &array; class has internal type definitions and + constants useful for both compile-time and run-time computations. + See . + These may be accessed using the &array;'s type and the scope + resolution operator (::). The table begins + with a list of internal type definitions, e.g., + Array<&dim;,T,E>::This_t. A + layout maps a + domain index to a particular processor and memory used to compute + the associated value. The two internal enumerations + dimensions and + rank both record + the &array;'s dimension. + &array; Internal Type Definitions and Compile-Time Constants *************** std::cout &openopen; a.read(2,-2) &openo *** 1619,1625 **** meaning ! This_t the &array;'s type Array<&dim;,T,E>. --- 1651,1657 ---- meaning ! This_t the &array;'s type Array<&dim;,T,E>. *************** std::cout &openopen; a.read(2,-2) &openo *** 1650,1687 **** the type of the &array;'s layout. ! ! const ! int ! dimensions the number &dim; of dimensions of the &array;. ! ! const ! int ! rank synonym for dimensions.

! The &array; class has internal type definitions and ! constants useful for both compile-time and run-time computations. ! See . ! These may be accessed using the &array;'s type and the scope ! resolution operator (::). The table begins ! with a list of internal type definitions, e.g., ! Array<&dim;,T,E>::Domain_t. Member ! functions use some of these types. A layout maps a domain index ! to a particular processor and memory used to compute the ! associated value. The two internal enumerations ! dimensions and ! rank both record ! the &array;'s dimension. --- 1682,1723 ---- the type of the &array;'s layout. ! const int dimensions the number &dim; of dimensions of the &array;. ! const int rank synonym for dimensions.

! The &array; class has several member functions easing access ! to its domain and engine. The first ten functions listed in ease access to ! &array; domains. The first three functions are synonyms all ! returning the &array;'s domain, which has type ! Array<&dim;,T,E>::Domain_t (abbreviated ! Domain_t in the table). The next seven functions ! query the domain. first, ! last, and length ! return the first index, last index, and number of indices for the ! specified dimension. The domain's dimensions are numbered 0, 1, ! …, ! Array<&dim;,T,E>::dimensions-1. If ! these values are needed for all dimensions, use ! firsts, lasts, ! and lengths. The returned ! Loc<&dim;>s have &dim; entries, one for each ! dimension. size returns the total number ! of indices in the entire domain. This is the product of all the ! dimensions' lengths. The ! layout member function returns the ! &array;'s layout, which specifies the mapping of indices to ! processors and memory. The last two functions return the ! &array;'s engine. *************** std::cout &openopen; a.read(2,-2) &openo *** 1697,1707 **** Internal type definitions, e.g., Domain_t, ! are listed without a class type prefix Array<&dim;,T,E>::. ! Domain_t domain() returns the &array;'s domain. --- 1733,1743 ---- Internal type definitions, e.g., Domain_t, ! are listed here without the class type prefix Array<&dim;,T,E>::. ! Domain_t domain() returns the &array;'s domain. *************** std::cout &openopen; a.read(2,-2) &openo *** 1716,1728 **** int first(int dim) ! returns the first (smallest) index value for the ! specified dimension. int last(int dim) ! returns the last (largest) index value for the ! specified dimension. int length(int dim) --- 1752,1764 ---- int first(int dim) ! returns the first index value for the specified ! dimension. int last(int dim) ! returns the last index value for the specified ! dimension. int length(int dim) *************** std::cout &openopen; a.read(2,-2) &openo *** 1731,1743 **** Loc<Dim> firsts() ! returns the first (smallest) index values for all the dimensions. Loc<Dim> lasts() ! returns the last (largest) index values for all the ! specified dimensions. Loc<Dim> lengths() --- 1767,1779 ---- Loc<Dim> firsts() ! returns the first index values for all the dimensions. Loc<Dim> lasts() ! returns the last index values for all the specified ! dimensions. Loc<Dim> lengths() *************** std::cout &openopen; a.read(2,-2) &openo *** 1750,1756 **** Layout_t layout() ! returns the &array;'s domain. Engine_t engine() --- 1786,1792 ---- Layout_t layout() ! returns the &array;'s layout. Engine_t engine() *************** std::cout &openopen; a.read(2,-2) &openo *** 1764,1806 ****

! The &array; class has several member functions easing access ! to its domain and engine. The first ten functions listed in ease access to ! &array; domains. The first three functions are synonyms all ! returning the &array;'s domain, which has type ! Array<&dim;,T,E>::Domain_t, abbreviated ! Domain_t in the table. The next seven functions ! query the domain. first, ! last, and length ! return the smallest, largest, and number of indices for the ! specified dimension. The domain's dimensions are numbered 0, 1, ! …, ! Array<&dim;,T,E>::dimensions-1. If ! these values are needed for all dimensions, use ! firsts, lasts, ! and lengths. The returned ! Loc<&dim;>s have &dim; entries, one for each ! dimension. size returns the total number ! of indices in the entire domain. This is the product of all the ! dimensions' lengths. The ! layout member function returns the ! &array;'s layout, which specifies the mapping of indices to ! processors and memory. The last two functions return the ! &array;'s engine. Using &array; Member Functions &array-size; - - The size is invoked by - prepending the &array;'s name followed by a period. This - assertion is unnecessary, but the - computeArraySize function further - illustrates using member functions. - These template parameters, used in the &array; parameter's type, permit the function to work with any --- 1800,1830 ---- ! We illustrate using &array; member functions in . The program ! computes the total number of &array;'s indices, comparing the ! result with invoking its size method. ! Since the &array;'s name is a, ! a.size() returns its size. The ! computeArraySize function also computes the ! &array;'s size. This templated function uses its three template ! parameters to accept any &array;, regardless of its dimension, ! value type, or &engine; tag. It begins by obtaining the range of ! indices for all dimensions and their lengths. Only the latter is ! necessary for the computation, but using the former further ! illustrates using member functions. The domain's size is the ! product of the length of each dimension. Since the lengths are ! stored in the Loc<&dim> ! lens, lens[d] is a ! Loc<1>, for which its ! first member function extracts the ! length. The length &array; member ! function is used in the PAssert. Using &array; Member Functions &array-size; These template parameters, used in the &array; parameter's type, permit the function to work with any *************** std::cout &openopen; a.read(2,-2) &openo *** 1815,1849 **** lens[d] returns a Loc<1> for dimension d's length. Invoking ! Loc<1> firstmethod yields its value. This comparison is unnecessary but further illustrates using member functions. - - We illustrate using &array; member functions in . The program - computes the total number of &array;'s indices, comparing the - result with invoking its size method. - Since the &array;'s name is a, - a.size() returns its size. - computeArraySize also computes the &array;'s - size. This templated function uses its three template parameters - to accept any &array;, regardless of its dimension, value type, or - &engine; tag. It begins by obtaining the range of indices for all - dimensions and their lengths. Only the latter is necessary for - the computation, but the former further illustrate using member - functions. The domain's size is the product of the length of each - dimension. Since the lengths are stored in the - Loc<&dim> lens, - lens[d] is a Loc<1>, for - which its first extracts the length. The - length &array; member function is used in - the PAssert.

--- 1839,1860 ---- lens[d] returns a Loc<1> for dimension d's length. Invoking ! Loc<1> first method yields its value. This comparison is unnecessary but further illustrates using member functions. + + The size is invoked by + prepending the &array;'s name followed by a period. This + assertion is unnecessary, but the + computeArraySize function further + illustrates using member functions. +

*************** std::cout &openopen; a.read(2,-2) &openo *** 1851,1942 **** &dynamicarray;s &array;s have fixed domains so the set of valid indices ! remains fixed after declaration. The &dynamicarray; class ! supports one-dimensional domains that can be resized even while ! the array is used. &dynamicarray;'s interface extends the one-dimensional interface of an &array; by adding member functions to change the domain's size. It is declared in Pooma/DynamicArrays.h. A &dynamicarray; has two, not three, template parameters, omitting ! the array's dimensionality. The first parameter T specifies the type of stored values. ! Its default value is usually &double;, but it may be changed when ! the &poomatoolkit; is configured. The second parameter specifies ! an &engine; via a tag. The engine must support a domain with ! dynamic resizing. For example, the &dynamic; &engine; is ! analogous to a one-dimensional &brick; &engine; supporting a ! dynamically-resizable domain. It is also usually the default ! value for this tag. For example, DynamicArray<> ! d0(1);, DynamicArray<double> ! d1(1);, and DynamicArray<double, ! Dynamic> d2(1); all declare the same ! &dynamicarray;s explicitly storing one &double; value. A ! &dynamicarray; automatically allocates its initial memory and ! deallocates its final memory, just as an &array; does. - - Changing a &dynamicarray;'s Domain - - - - - &dynamicarray; member function - description - - - - - This table omits member functions designed for - distributed computation. - - - - - void create(int num) - extend the current domain by the requested number of - elements. - - - void destroy(const Dom& killList) - remove the elements specified by the indices in the - given &domain; argument. Backfill moves - elements from the end of the domain to replace the deleted - elements. - - - void destroy(Iter killBegin, Iter killEnd) - remove the elements specified by the indices in the - container range [begin,end) specified by the random-access - iterators. Backfill moves elements from the - end of the domain to replace the deleted elements. - - - void destroy(const Dom& killList, const - DeleteMethod& method) - - remove the elements specified by the indices in the - given &domain; argument. Deleted elements can be replaced by - BackFill'ing, i.e., moving data from the domain's - end to fill removed elements, or by ShiftUp'ing, - i.e., compacting all data but maintaining relative ordering. - - - void destroy(Iter killBegin, Iter killEnd, - const DeleteMethod& method) - remove the elements specified by the indices in the - container range [begin,end) specified by the random-access - iterators. Deleted elements can be replaced by - BackFill'ing, i.e., moving data from the domain's - end to fill removed elements, or by ShiftUp'ing, - i.e., compacting all data but maintaining relative ordering. - - - -

- The create and destroy member functions permit changing a &dynamicarray;'s domain. &dynamicarray;s &array;s have fixed domains so the set of valid indices ! remains fixed after creation. The &dynamicarray; ! class supports ! one-dimensional domains that can be resized even while the array ! is used. &dynamicarray;'s interface extends the one-dimensional interface of an &array; by adding member functions to change the domain's size. It is declared in Pooma/DynamicArrays.h. A &dynamicarray; has two, not three, template parameters, omitting ! the array's dimensionality which must be one. The first parameter T specifies the type of stored values. ! Its default value is usually &double;, but this may be changed ! when the &poomatoolkit; is configured. The second parameter ! specifies an &engine; via an &engine; tag. The engine must ! support a domain with dynamic resizing. For example, the ! &dynamic; &engine; is analogous to a one-dimensional &brick; ! &engine; supporting a dynamically-resizable domain. It is also ! usually the default value for this tag. For example, ! DynamicArray<> d0(1);, ! DynamicArray<double> d1(1);, and ! DynamicArray<double, Dynamic> d2(1); ! all declare the same &dynamicarray;s explicitly storing one ! &double; value. A &dynamicarray; automatically allocates its ! initial memory and deallocates its final memory, just as an ! &array; does. The create and destroy member functions permit changing a &dynamicarray;'s domain. T. Existing values are copied. Changing a &dynamicarray;'s Domain --- 1901,1907 ---- for T. Existing values are copied.

Changing a &dynamicarray;'s Domain *************** std::cout &openopen; a.read(2,-2) &openo *** 1964,1970 **** distributed computation. ! void create(int num) extend the current domain by the requested number of --- 1917,1923 ---- distributed computation. ! void create(int num) extend the current domain by the requested number of *************** std::cout &openopen; a.read(2,-2) &openo *** 1972,2019 **** void destroy(const Dom& killList) ! remove the elements specified by the indices in the ! given &domain; argument. Backfill moves ! elements from the end of the domain to replace the deleted ! elements. void destroy(Iter killBegin, Iter killEnd) ! remove the elements specified by the indices in the container range [begin,end) specified by the random-access ! iterators. Backfill moves elements from the ! end of the domain to replace the deleted elements. void destroy(const Dom& killList, const DeleteMethod& method) ! remove the elements specified by the indices in the ! given &domain; argument. Deleted elements can be replaced by BackFill'ing, i.e., moving data from the domain's ! end to fill removed elements, or by ShiftUp'ing, ! i.e., compacting all data but maintaining relative ordering. void destroy(Iter killBegin, Iter killEnd, const DeleteMethod& method) ! remove the elements specified by the indices in the container range [begin,end) specified by the random-access ! iterators. Deleted elements can be replaced by BackFill'ing, i.e., moving data from the domain's ! end to fill removed elements, or by ShiftUp'ing, ! i.e., compacting all data but maintaining relative ordering.

! The destroy deletes specified ! indices. The indices may be specified using either a &domain; ! object (Interval<1>, Range<1>, or IndirectionList) or ! in a container specified using random-access iterators. For ! example, every other element from a ten-element array d might be removed using Range<1>(0,9,2). Alternatively, --- 1925,1975 ---- void destroy(const Dom& killList) ! remove the values specified by the indices in the given ! &domain; argument. The Backfill method moves ! values from the end of the domain to replace the deleted ! values. void destroy(Iter killBegin, Iter killEnd) ! remove the values specified by the indices in the container range [begin,end) specified by the random-access ! iterators. The Backfill method moves values ! from the end of the domain to replace the deleted ! values. void destroy(const Dom& killList, const DeleteMethod& method) ! remove the values specified by the indices in the ! given &domain; argument. Deleted values can be replaced by BackFill'ing, i.e., moving data from the domain's ! end to fill removed values, or by ShiftUp'ing, ! i.e., compacting all data but maintaining the relative ! ordering. void destroy(Iter killBegin, Iter killEnd, const DeleteMethod& method) ! remove the values specified by the indices in the container range [begin,end) specified by the random-access ! iterators. Deleted values can be replaced by BackFill'ing, i.e., moving data from the domain's ! end to fill removed values, or by ShiftUp'ing, ! i.e., compacting all data but maintaining the relative ! ordering. ! The destroy member function deletes ! the specified indices. The indices may be specified using either ! a &domain; object (Interval<1>, Range<1>, or IndirectionList) or ! by random-access iterators pointing into a container. For ! example, every other value from a ten-value array d might be removed using Range<1>(0,9,2). Alternatively, *************** d.destroy(killList, killList+5); *** 2023,2048 **** removed, other indices are moved into their positions. Using the BackFill method moves the last index and its associated value into deleted index's position. Thus, the total ! number of indices is decreased by one, but the indices can be reordered. Using the ShiftUp method ensures the ! indices' orders are maintained by shifting all ! elements left (or up) so all gaps between indices disappear. For example, consider removing the first index from a domain. ! original indices: 0 1 2 3 ! destroy using BackFill 3 1 2 ! destroy using ShiftUp 1 2 3 --- 1979,2004 ---- removed, other indices are moved into their positions. Using the BackFill method moves the last index and its associated value into deleted index's position. Thus, the total ! number of indices is decreased by one, but the indices are reordered. Using the ShiftUp method ensures the ! order of the indices is preserved by shifting all ! values left (or up) so all gaps between indices disappear. For example, consider removing the first index from a domain. ! original indices: 0 1 2 3 ! destroy using BackFill: 3 1 2 ! destroy using ShiftUp: 1 2 3 *************** d.destroy(killList, killList+5); *** 2054,2101 **** that BackFill moves exactly as many indices as are deleted, while ShiftUp can shift all indices in a domain. Thus, BackFill is the default method. When ! multiple indices are deleted, they are deleted from the largest to ! the smallest. When using the BackFill method, some ! indices may be moved repeatedly. For example, consider removing ! indices 0 and 2 from original indices of 0 1 2 3. Removing 2 ! yields 0 1 3. Removing 0 yields 3 1. Using an object with the ! desired type to indicate which fill method is desired, i.e., ! BackFill() or ShiftUp(). - - Example Using &dynamicarray;s - - &dynamicarray-example; - - - This header file declares &dynamicarray;s. - - - These three declarations yield equivalent - &dynamicarray;s, storing one &double; value. - - - This create member function adds - five indices to the end of the domain. - - - &dynamicarray; values are accessed the same way as - &array; values. - - - The ⦥ object specifies that every other index - should be removed. The BackFill() - object is unnecessary since it is the default replacement - method. - - - This destroy call is equivalent - to the previous one but uses iterators. - - - - We illustrate &dynamicarray; resizing in . &dynamicarray;s are declared in BackFill moves exactly as many indices as are deleted, while ShiftUp can shift all indices in a domain. Thus, BackFill is the default method. When ! multiple indices are deleted, they are deleted from the last ! (largest) to the first (smallest). When using the ! BackFill method, some indices may be moved ! repeatedly. For example, consider removing indices 0 and 2 from ! original indices of 0 1 2 3. Removing 2 yields 0 1 3 because 3 is ! moved into 2's position. Removing 0 yields 3 1 because 3 is again ! moved. Use an object with the desired type to indicate which fill ! method is desired, i.e., BackFill() or ShiftUp(). We illustrate &dynamicarray; resizing in . &dynamicarray;s are declared in d0's create with an argument of five increases its domain size from one to six. The additional indices are added to the end of the domain so the value --- 2028,2034 ---- require two, not three, template arguments because the array must be one-dimensional. The three arrays, each having one &double; value, are equivalent. (The &poomatoolkit; can be configured to ! support different default template values.) Invoking d0's create with an argument of five increases its domain size from one to six. The additional indices are added to the end of the domain so the value *************** d.destroy(killList, killList+5); *** 2113,2143 **** all values equal to their indices. This illustrates that &dynamicarray; values are accessed the same way as &array; values. For example, d0(i) accesses the ! ith value. The ! destroy removes every other index from ! the array. The one-dimensional ⦥ specifies these indices by ! specifying the domain's entire interval and a stride of 2. The BackFill function call creates a BackFill object indicating the BackFill method should be used. We illustrate the steps of this method: ! original indices: 0 1 2 3 4 5 ! delete index 4 0 1 2 3 5 ! delete index 2 0 1 5 3 ! delete index 0 3 1 5 --- 2037,2067 ---- all values equal to their indices. This illustrates that &dynamicarray; values are accessed the same way as &array; values. For example, d0(i) accesses the ! ith value. The ! destroy member function removes every ! other index from the array because the one-dimensional ⦥ ! specifies the domain's entire interval with a stride of 2. The BackFill function call creates a BackFill object indicating the BackFill method should be used. We illustrate the steps of this method: ! original indices: 0 1 2 3 4 5 ! delete index 4: 0 1 2 3 5 ! delete index 2: 0 1 5 3 ! delete index 0: 3 1 5 *************** d.destroy(killList, killList+5); *** 2146,2152 **** Since multiple indices are specified, the rightmost one is removed first, i.e., index 4. The rightmost index 5 is moved into 4's position. When removing index 2, the index ! originally at 5 is moved again into 2's position. Finally, index 0 is replaced by index 3. The rest of the program repeats the computation, using the random-access iterator version of destroy. Since this &dynamicarray;'s --- 2070,2076 ---- Since multiple indices are specified, the rightmost one is removed first, i.e., index 4. The rightmost index 5 is moved into 4's position. When removing index 2, the index ! originally at 5 is again moved into 2's position. Finally, index 0 is replaced by index 3. The rest of the program repeats the computation, using the random-access iterator version of destroy. Since this &dynamicarray;'s *************** d.destroy(killList, killList+5); *** 2158,2166 **** --- 2082,2125 ---- method is specified, the default BackFill method is used. All the &dynamicarray;s' unallocated memory is deallocated. + + + Example Using &dynamicarray;s + + &dynamicarray-example; + + + This header file declares &dynamicarray;s. + + + These three declarations yield equivalent + &dynamicarray;s, storing one &double; value. + + + This create member function call + adds five indices to the end of the domain. + + + &dynamicarray; values are accessed the same way as + &array; values. + + + The ⦥ object specifies that every other index + should be removed. The BackFill() + object is unnecessary since it is the default replacement + method. + + + This destroy call is equivalent + to the previous one but uses iterators. + + + +

+ An &array; Implementation of &doof2d; *************** d.destroy(killList, killList+5); *** 2177,2181 **** --- 2136,2141 ---- to describe how a programmer would implement a new type of domain? Probably not.

+ ]]> Index: bibliography.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/bibliography.xml,v retrieving revision 1.1 diff -c -p -r1.1 bibliography.xml *** bibliography.xml 2002/01/04 17:42:43 1.1 --- bibliography.xml 2002/01/25 02:15:03 *************** *** 1,5 **** --- 1,7 ---- + Bibliography *************** Array. 1995. unpublished. Available a *** 275,277 **** --- 277,281 ---- + + ]]> Index: concepts.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/concepts.xml,v retrieving revision 1.8 diff -c -p -r1.8 concepts.xml *** concepts.xml 2002/01/24 05:11:21 1.8 --- concepts.xml 2002/01/25 02:15:04 *************** *** 57,63 **** Computation Environment ! &array; element-wise --- 57,63 ---- Computation Environment ! &array; element-wise *************** *** 136,142 **** orient="port" pgwide="0" id="concepts-containers-table"> &pooma; Container Summary ! &array; --- 136,142 ---- orient="port" pgwide="0" id="concepts-containers-table"> &pooma; Container Summary ! &array; *************** *** 265,271 **** orient="port" pgwide="0" id="concepts-containers-choice_table"> Choosing a &pooma; Container ! If modeling mathematical entries, use a &vector;, &matrix;, or &tensor;. --- 265,271 ---- orient="port" pgwide="0" id="concepts-containers-choice_table"> Choosing a &pooma; Container ! If modeling mathematical entries, use a &vector;, &matrix;, or &tensor;. Index: data-parallel.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/data-parallel.xml,v retrieving revision 1.2 diff -c -p -r1.2 data-parallel.xml *** data-parallel.xml 2002/01/24 05:11:21 1.2 --- data-parallel.xml 2002/01/25 02:15:05 *************** *** 1,16 **** Data-Parallel Expressions ! In the previous sections, we accessed container values one at a time. Accessing more than one value in a container required a writing an explicit loop. Scientists and engineers commonly operate on sets of values, treated as an aggregate. For example, a vector is a one-dimension collection of data and two vectors can be added together. A matrix is a two-dimensional collection of data, ! and a scalar and a matrix are multiplied. A data-parallel expression simultaneously uses multiple ! container values. &pooma; supports data-parallel syntax. After introducing data-parallel expressions and statements, we present the corresponding &pooma; syntax. Then we present its --- 1,17 ---- Data-Parallel Expressions ! In the previous chapters, we accessed container values one at a time. Accessing more than one value in a container required a writing an explicit loop. Scientists and engineers commonly operate on sets of values, treated as an aggregate. For example, a vector is a one-dimension collection of data and two vectors can be added together. A matrix is a two-dimensional collection of data, ! and a scalar and a matrix can be multiplied. A data-parallel expression simultaneously uses multiple ! container values. &pooma; supports data-parallel ! expressions. After introducing data-parallel expressions and statements, we present the corresponding &pooma; syntax. Then we present its *************** *** 61,73 **** &pooma; containers can be used in data-parallel expressions and statements. The basic guidelines are simple: ! ! The &cc; built-in and mathematical operators operate on an entire container by operating element-wise on its values. ! Binary operators operate only on containers with the same ! domain types by combining values with the same indices. If the result is a container, it has a domain equal to the left operand's domain. --- 62,74 ---- &pooma; containers can be used in data-parallel expressions and statements. The basic guidelines are simple: ! ! The &cc; built-in and mathematical operators operate on an entire container by operating element-wise on its values. ! Binary operators operate only on containers with the same ! domain types and by combining values with the same indices. If the result is a container, it has a domain equal to the left operand's domain. *************** *** 79,86 **** ! The operators operate element-wise on containers' values. ! For example, if A is a one-dimensional array, -A is a one-dimensional array with the same size such that the value at the ith position equals -A(i). If --- 80,88 ---- ! The data-parallel operators operate element-wise on ! containers' values. For example, if A is a ! one-dimensional array, -A is a one-dimensional array with the same size such that the value at the ith position equals -A(i). If *************** *** 91,114 **** corresponding values in A and B. -

- Adding &array;s with Different Domains - - - - - - Adding two arrays with different domains adds values - with the same indices. - - - Adding &array;s with different domains is supported. - Solid lines indicate the domains' extent. Values with the same - indices are added. - - - - Binary operators operate on containers with the same domain types. The domain's indices need not be the same, but the result will have a domain equal to the left operand. For example, the --- 93,98 ---- *************** Interval<1> H(0,2), I(1,3), J(2,4); *** 131,155 **** Array<2, double, Brick> A(I,I), B(J,H); // ... fill A and B with values ... ... = A + B; ! Both A and ! B have domains of two-dimensional intervals so ! they may be added, but their domains' extent differ, as indicated ! by the solid lines in the figure. The sum has domain equal to the ! left operand's domain. Values with the same indices are added. For ! example, A(2,2) and ! B(2,2) are added. B's ! domain does not include index (1,1) so, when adding ! A(1,1) and B(1,1), ! the default value for B's value type is used. ! Usually this is 0. Thus, A(1,1) + ! B(1,1) equals 9 + 0. ! ! Operations with &array;s and scalar values are supported. ! Conceptually, a scalar value can be thought of as an &array; with ! any desired domain and having the same value everywhere. For ! example, consider ! Array<1, double, Brick> D(Interval<1>(7,10)); D += 2*D + 7; 2*D obeys the guidelines because the scalar 2 can be thought of as --- 115,159 ---- Array<2, double, Brick> A(I,I), B(J,H); // ... fill A and B with values ... ... = A + B; ! ! !

! Adding &array;s with Different Domains ! ! ! ! ! ! Adding two arrays with different domains adds values ! with the same indices. ! ! ! Adding &array;s with different domains is supported. ! Solid lines indicate the domains' extent. Values with the same ! indices are added. ! ! ! ! ! Both A and B have ! domains of two-dimensional intervals so they may be added, but ! their domains' extent differ, as indicated by the solid lines in ! the figure. The sum has domain equal to the left operand's ! domain. Values with the same indices are added. For example, ! A(2,2) and B(2,2) ! are added. B's domain does not include index ! (1,1) so, when adding A(1,1) and ! B(1,1), the default value for ! B's value type is used. Usually this ! is 0. Thus, A(1,1) + B(1,1) equals ! 9 + 0. ! ! Operations with both &array;s and scalar values are ! supported. Conceptually, a scalar value can be thought of as an ! &array; with any desired domain and having the same value ! everywhere. For example, consider ! Array<1, double, Brick> D(Interval<1>(7,10)); D += 2*D + 7; 2*D obeys the guidelines because the scalar 2 can be thought of as *************** D += 2*D + 7; *** 163,180 **** not first convert scalar values to arrays but instead uses them directly in expressions. ! Assignment to containers is also supported. The domain types of the assignment's left-hand side and its right-hand side must be the same. Their indices need not be the same, but they must correspond. That is, the domains must be conformable ! domains, or have the same ! shape, i.e., have the same number of indices for each ! dimension. For example, the one-dimensional interval [0,3] is ! conformable to the one-dimensional interval [1,4] because they ! both have the same number of indices in each dimension. The ! domains of A and B, as ! declared Interval<1> H(0,2), I(1,3), J(2,4), K(0,4); Array<2, double, Brick> A(I,I), B(H,J), C(I,K); --- 167,183 ---- not first convert scalar values to arrays but instead uses them directly in expressions. ! Assignments to containers are also supported. The domain types of the assignment's left-hand side and its right-hand side must be the same. Their indices need not be the same, but they must correspond. That is, the domains must be conformable, ! or have the same shape, i.e., have the same number ! of indices for each dimension. For example, the one-dimensional ! interval [0,3] is conformable to the one-dimensional interval ! [1,4] because they both have the same number of indices in each ! dimension. The domains of A and ! B, as declared Interval<1> H(0,2), I(1,3), J(2,4), K(0,4); Array<2, double, Brick> A(I,I), B(H,J), C(I,K); *************** Array<2, double, Brick> A(I,I), B(H,J), *** 182,188 **** number of indices. A and C are not conformable because, while their first dimensions are conformable, their second dimensions are not conformable. It has ! three indices while the other has four. We define conformable containers to be containers with conformable domains. --- 185,191 ---- number of indices. A and C are not conformable because, while their first dimensions are conformable, their second dimensions are not conformable. It has ! three indices while the other has five. We define conformable containers to be containers with conformable domains. *************** Array<1, double, Brick> A(Interval<1>(0, *** 222,228 **** Array<1, double, Brick> B(Interval<1>(1,3)); A = 1.0; B = 2.0; ! std::cout << A-B << std::endl; yields (000:002:001) = 1 -1 -1. The initial --- 225,231 ---- Array<1, double, Brick> B(Interval<1>(1,3)); A = 1.0; B = 2.0; ! std::cout &openopen; A-B &openopen; std::endl; yields (000:002:001) = 1 -1 -1. The initial *************** std::cout << A-B << std::endl; *** 233,261 **** The following four tables list the data-parallel operators that operate on &array;s. lists standard ! &cc; operators that can be applied to &array;s and constant values ! if appropriate. Each unary operator takes an &array; parameter ! and returns an &array;. The types of the two &array;s need not be ! the same. For example, ! can take an ! Array<bool>, Array<int>, ! Array<long>, or any other value type to which ! ! can be applied. The result is an ! Array<bool>. Each binary operator also returns ! an &array;. When specifying two &array;s or an &array; and a ! constant value, a full set of operators is supported. When ! specifying an &array; and a &tensor;, &matrix;, or &vector;, a ! more limited set of operators is supported. For example, ! == can take two &array;s, an &array; and a ! constant value, or a constant value and an &array;. If given two ! &array;s, corresponding values are used. If a parameter is a ! constant value, its same value is the used with each &array; ! value. The + supports the same set of ! parameters but also supports adding an &array; and a &tensor;, an ! &array; and a &matrix;, an &array; and a &vector;, a &tensor; and ! an &array;, a &matrix; and an &array;, and a &vector; and an ! &array;. For these cases, the &array; must have a value type that ! can be added to the other argument. For example, a &vector; can ! be added to an &array; of &vector;s. --- 236,264 ---- The following four tables list the data-parallel operators that operate on &array;s. lists standard ! &cc; operators that can be applied to &array;s and also scalar ! values if appropriate. Each unary operator takes an &array; ! parameter and returns an &array;. The types of the two &array;s ! need not be the same. For example, ! can ! take an Array<bool>, ! Array<int>, Array<long>, or ! any other value type to which ! can be ! applied. The result is an Array<bool>. Each ! binary operator also returns an &array;. When specifying two ! &array;s or an &array; and a scalar value, a full set of operators ! is supported. When specifying an &array; and a &tensor;, ! &matrix;, or &vector;, a more limited set of operators is ! supported. For example, == can take two ! &array;s, an &array; and a scalar value, or a scalar value and an ! &array;. If given two &array;s, corresponding values are used. ! If an argument is a scalar value, its same value is the used with ! each &array; value. The + supports the same ! set of parameters but also supports adding an &array; and a ! &tensor;, an &array; and a &matrix;, an &array; and a &vector;, a ! &tensor; and an &array;, a &matrix; and an &array;, and a &vector; ! and an &array;. For these cases, the &array; must have a value ! type that can be added to the other argument. For example, a ! &vector; can be added to an &array; of &vector;s.

*************** std::cout << A-B << std::endl; *** 268,287 **** supported operators ! unary operators +, -, ~, ! ! binary operators with at least one array and at most ! one value +, -, *, /, %, &, |, ^, <, <=, >=, >, ==, !=, &&, ||, &openopen;, &closeclose; ! binary operators with at least one array and at most one &tensor;, &matrix;, or &vector; ! +, -, *, /, %, &, |, ^, ==, != --- 271,294 ---- supported operators ! unary operators +, -, ~, ! ! binary operators with at least one &array; and at most ! one scalar value +, -, *, /, %, &, |, ^, <, <=, >=, >, ==, !=, &&, ||, &openopen;, &closeclose; ! binary operators with at least one &array; and at most one &tensor;, &matrix;, or &vector; ! +, -, ! *, /, ! %, &, ! |, ^, ! ==, != *************** std::cout << A-B << std::endl; *** 291,302 **** expressions appear in . For example, applying cos to an &array; of values ! with type T yields an array of the same type. ! The functions are split into five sections: ! ! ! trigonometric and hyperbolic functions, ! functions computing absolute values, rounding functions, and modulus functions, --- 298,309 ---- expressions appear in . For example, applying cos to an &array; of values ! with type T yields an &array; with the same ! type. The functions are split into five sections: ! ! ! trigonometric and hyperbolic functions, ! functions computing absolute values, rounding functions, and modulus functions, *************** std::cout << A-B << std::endl; *** 312,326 **** Several data-parallel functions require inclusion of header files ! declaring the underlying element-wise function. These header files are listed at the beginning of each section. For the data-parallel operator to be applicable, it must operate on the &array;'s type. For example, cos can be ! applied on &array;s of ∫, &double;, and even &bool;, but applying on &array;s of pointers is not supported because ! cos cannot be called with a pointer argument. ! A few functions deserve explanation. The PETE_identity function applies the identity operation to the array. That is, the returned array has values equaling the argument's values. pow2, --- 319,334 ---- Several data-parallel functions require inclusion of header files ! declaring their underlying element-wise function. These header files are listed at the beginning of each section. For the data-parallel operator to be applicable, it must operate on the &array;'s type. For example, cos can be ! applied on &array;s of ∫, &double;, and even &bool;, but applying on &array;s of pointers is not supported because ! cos cannot be called with a pointer ! argument. ! Two functions deserve special explanation. The PETE_identity function applies the identity operation to the array. That is, the returned array has values equaling the argument's values. pow2, *************** std::cout << A-B << std::endl; *** 347,380 **** choices for the template type parameters. ! Trigonometric and Hyperbolic Functions #include <math.h> Array<T> cos (const Array<T>& A) ! Returns the cosines of the array's values. Array<T> sin (const Array<T>& A) ! Returns the sines of the array's values. Array<T> tan (const Array<T>& A) ! Returns the tangents of the array's values. Array<T> acos (const Array<T1>& A) ! Returns the arc cosines of the array's values. Array<T> asin (const Array<T1>& A) ! Returns the arc sines of the array's values. Array<T> atan (const Array<T1>& A) ! Returns the arc tangents of the array's values. Array<T> atan2 (const Array<T1>& A, const Array<T2>& B) --- 355,388 ---- choices for the template type parameters. ! Trigonometric and Hyperbolic Functions #include <math.h> Array<T> cos (const Array<T>& A) ! Returns the cosines of the &array;'s values. Array<T> sin (const Array<T>& A) ! Returns the sines of the &array;'s values. Array<T> tan (const Array<T>& A) ! Returns the tangents of the &array;'s values. Array<T> acos (const Array<T1>& A) ! Returns the arc cosines of the &array;'s values. Array<T> asin (const Array<T1>& A) ! Returns the arc sines of the &array;'s values. Array<T> atan (const Array<T1>& A) ! Returns the arc tangents of the &array;'s values. Array<T> atan2 (const Array<T1>& A, const Array<T2>& B) *************** std::cout << A-B << std::endl; *** 398,412 **** Array<T> cosh (const Array<T>& A) ! Returns the hyperbolic cosines of the array's values. Array<T> sinh (const Array<T>& A) ! Returns the hyperbolic sines of the array's values. Array<T> tanh (const Array<T>& A) ! Returns the hyperbolic tangents of the array's values. Absolute Value, Rounding, and Modulus Functions --- 406,420 ---- Array<T> cosh (const Array<T>& A) ! Returns the hyperbolic cosines of the &array;'s values. Array<T> sinh (const Array<T>& A) ! Returns the hyperbolic sines of the &array;'s values. Array<T> tanh (const Array<T>& A) ! Returns the hyperbolic tangents of the &array;'s values. Absolute Value, Rounding, and Modulus Functions *************** std::cout << A-B << std::endl; *** 415,435 **** Array<T> fabs (const Array<T1>& A) Returns the absolute values of the floating point ! numbers in the array. ! ! ! Array<T> ceil (const Array<T1>& A) ! For each of the array's values, return the integer ! larger than or equal to it (as a floating point number). Array<T> ceil (const Array<T1>& A) ! For each of the array's values, return the integer larger than or equal to it (as a floating point number). Array<T> floor (const Array<T1>& A) ! For each of the array's values, return the integer smaller than or equal to it (as a floating point number). --- 423,438 ---- Array<T> fabs (const Array<T1>& A) Returns the absolute values of the floating point ! numbers in the &array;. Array<T> ceil (const Array<T1>& A) ! For each of the &array;'s values, return the integer larger than or equal to it (as a floating point number). Array<T> floor (const Array<T1>& A) ! For each of the &array;'s values, return the integer smaller than or equal to it (as a floating point number). *************** std::cout << A-B << std::endl; *** 438,444 **** A's values with the corresponding value in B. The results have the same signs as A and absolute values less than the ! absolute values of values in B. Array<T> fmod (const Array<T1>& A, const T2& r) --- 441,447 ---- A's values with the corresponding value in B. The results have the same signs as A and absolute values less than the ! absolute values of B. Array<T> fmod (const Array<T1>& A, const T2& r) *************** std::cout << A-B << std::endl; *** 453,459 **** l with the values in B. The results have the same signs as l and absolute values less than the ! absolute values of values in B. Powers, Exponentiation, and Logarithmic Functions --- 456,462 ---- l with the values in B. The results have the same signs as l and absolute values less than the ! absolute values of B. Powers, Exponentiation, and Logarithmic Functions *************** std::cout << A-B << std::endl; *** 461,471 **** Array<T> PETE_identity (const Array<T>& A) ! Returns the array. That is, it applies the identity operation. Array<T> sqrt (const Array<T>& A) ! Returns the square roots of the array's values. Array<T> pow (const Array<T1>& A, const Array<T2>& B) --- 464,474 ---- Array<T> PETE_identity (const Array<T>& A) ! Returns the &array;. That is, it applies the identity operation. Array<T> sqrt (const Array<T>& A) ! Returns the square roots of the &array;'s values. Array<T> pow (const Array<T1>& A, const Array<T2>& B) *************** std::cout << A-B << std::endl; *** 501,507 **** Array<T> ldexp (const Array<T1>& A, int r) Multiplies A's values by two raised ! to the r'th power. Array<T> ldexp (const T1& l, const Array<int>& B) --- 504,511 ---- Array<T> ldexp (const Array<T1>& A, int r) Multiplies A's values by two raised ! to the rth ! power. Array<T> ldexp (const T1& l, const Array<int>& B) *************** std::cout << A-B << std::endl; *** 510,524 **** Array<T> exp (const Array<T>& A) ! Returns the exponentiations of the array's values. Array<T> log (const Array<T>& A) ! Returns the natural logarithms of the array's values. Array<T> log10 (const Array<T>& A) ! Returns the base-10 logarithms of the array's values. Functions Involving Complex Numbers --- 514,528 ---- Array<T> exp (const Array<T>& A) ! Returns the exponentiations of the &array;'s values. Array<T> log (const Array<T>& A) ! Returns the natural logarithms of the &array;'s values. Array<T> log10 (const Array<T>& A) ! Returns the base-10 logarithms of the &array;'s values. Functions Involving Complex Numbers *************** std::cout << A-B << std::endl; *** 561,578 **** Array<complex<T&closeclose; polar (const Array<T1>& A, const Array<T2>& B) Returns the complex numbers created from polar coordinates (magnitudes and phase angles) in corresponding ! arrays. Array<complex<T&closeclose; polar (const T1& l, const Array<T2>& A) Returns the complex numbers created from polar coordinates with magnitude l and ! phase angles in the array. Array<complex<T&closeclose; polar (const Array<T1>& A, const T2& r) Returns the complex numbers created from polar ! coordinates with magnitudes in the array and phase angle r. --- 565,582 ---- Array<complex<T&closeclose; polar (const Array<T1>& A, const Array<T2>& B) Returns the complex numbers created from polar coordinates (magnitudes and phase angles) in corresponding ! &array;s. Array<complex<T&closeclose; polar (const T1& l, const Array<T2>& A) Returns the complex numbers created from polar coordinates with magnitude l and ! phase angles in the &array;. Array<complex<T&closeclose; polar (const Array<T1>& A, const T2& r) Returns the complex numbers created from polar ! coordinates with magnitudes in the &array; and phase angle r. *************** std::cout << A-B << std::endl; *** 599,612 **** Array<T> dot (const Array<T1>& A, const Array<T2>& B) ! Returns the dot products of values in the two arrays. Value type T equals the type of the dot operating on T1 and T2. Array<T> dot (const Array<T1>& A, const T2& r) ! Returns the dot products of values in the array with r. Value type T equals the type of the dot operating on T1 --- 603,616 ---- Array<T> dot (const Array<T1>& A, const Array<T2>& B) ! Returns the dot products of values in the two &array;s. Value type T equals the type of the dot operating on T1 and T2. Array<T> dot (const Array<T1>& A, const T2& r) ! Returns the dot products of values in the &array; with r. Value type T equals the type of the dot operating on T1 *************** std::cout << A-B << std::endl; *** 615,635 **** Array<T> dot (const T1& l, const Array<T2>& A) Returns the dot products of l with ! values in the array. Value type T equals the type of the dot operating on T1 and T2. - Array<T> dot (const Array<T1>& A, const T2& B) - Returns the dot products of values in the array - Value type T equals the type of the - dot operating on T1 - and T2. - - Array<Tensor<T&closeclose; outerProduct (const Array<T1>& A, const Array<T2>& B) Returns tensors created by computing the outer product ! of corresponding vectors in the two arrays. Value type T equals the type of the product of T1 and T2. The vectors must have the same length. --- 619,632 ---- Array<T> dot (const T1& l, const Array<T2>& A) Returns the dot products of l with ! values in the &array;. Value type T equals the type of the dot operating on T1 and T2. Array<Tensor<T&closeclose; outerProduct (const Array<T1>& A, const Array<T2>& B) Returns tensors created by computing the outer product ! of corresponding vectors in the two &array;s. Value type T equals the type of the product of T1 and T2. The vectors must have the same length. *************** std::cout << A-B << std::endl; *** 637,643 **** Array<Tensor<T&closeclose; outerProduct (const T1& l, const Array<T2>& A) Returns tensors created by computing the outer product ! of l with the vectors in the array. Value type T equals the type of the product of T1 and T2. The vectors must have the same length. --- 634,640 ---- Array<Tensor<T&closeclose; outerProduct (const T1& l, const Array<T2>& A) Returns tensors created by computing the outer product ! of l with the vectors in the &array;. Value type T equals the type of the product of T1 and T2. The vectors must have the same length. *************** std::cout << A-B << std::endl; *** 645,651 **** Array<Tensor<T&closeclose; outerProduct (const Array<T1>& A, const T2& r) Returns tensors created by computing the outer product ! of vectors in the array with r. Value type T equals the type of the product of T1 and T2. The vectors must have the same length. --- 642,648 ---- Array<Tensor<T&closeclose; outerProduct (const Array<T1>& A, const T2& r) Returns tensors created by computing the outer product ! of vectors in the &array; with r. Value type T equals the type of the product of T1 and T2. The vectors must have the same length. *************** std::cout << A-B << std::endl; *** 654,660 **** TinyMatrix<T> outerProductAsTinyMatrix (const Array<T1>& A, const Array<T2>& B) Returns matrices created by computing the outer product ! of corresponding vectors in the two arrays. Value type T equals the type of the product of T1 and T2. The vectors must have the same length. --- 651,657 ---- TinyMatrix<T> outerProductAsTinyMatrix (const Array<T1>& A, const Array<T2>& B) Returns matrices created by computing the outer product ! of corresponding vectors in the two &array;s. Value type T equals the type of the product of T1 and T2. The vectors must have the same length. *************** std::cout << A-B << std::endl; *** 663,669 **** TinyMatrix<T> outerProductAsTinyMatrix (const T1& l, const Array<T2>& A) Returns matrices created by computing the outer ! product of l with the vectors in the array. Value type T equals the type of the product of T1 and T2. The vectors must have the same length. --- 660,666 ---- TinyMatrix<T> outerProductAsTinyMatrix (const T1& l, const Array<T2>& A) Returns matrices created by computing the outer ! product of l with the vectors in the &array;. Value type T equals the type of the product of T1 and T2. The vectors must have the same length. *************** std::cout << A-B << std::endl; *** 672,678 **** TinyMatrix<T> outerProductAsTinyMatrix (const Array<T1>& A, const T2& r) Returns matrices created by computing the outer ! product of the vectors in the array with r. Value type T equals the type of the product of T1 and T2. The vectors must --- 669,675 ---- TinyMatrix<T> outerProductAsTinyMatrix (const Array<T1>& A, const T2& r) Returns matrices created by computing the outer ! product of the vectors in the &array; with r. Value type T equals the type of the product of T1 and T2. The vectors must *************** std::cout << A-B << std::endl; *** 701,828 **** effect ! Array<T> max (const Array<T1>& A, const Array<T2>& B) ! Returns the maximum of corresponding array values. Array<T> max (const T1& l, const Array<T2>& A) ! Returns the maximums of l with the array's values. Array<T> max (const Array<T1>& A, const T2& r) ! Returns the maximums of the array's values with r. Array<T> min (const Array<T1>& A, const Array<T2>& B) ! Returns the minimum of corresponding array values. Array<T> min (const T1& l, const Array<T2>& A) ! Returns the minimums of l with the array's values. Array<T> min (const Array<T1>& A, const T2& r) ! Returns the minimums of the array's values with r. Array<bool> LT (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the less-than ! operator < to compare corresponding array values in A and B. Array<bool> LT (const T1& r, const Array<T2>& A) Returns booleans from using the less-than ! operator < to compare l with the array's values. Array<bool> LT (const Array<T1>& A, const T2& r) Returns booleans from using the less-than ! operator < to compare the array's values with r. Array<bool> LE (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the less-than-or-equal ! operator ≤ to compare array values in A and B. Array<bool> LE (const T1& l, const Array<T2>& A) Returns booleans from using the less-than-or-equal ! operator ≤ to compare l with the array's values. Array<bool> LE (const Array<T1>& A, const T2& r) Returns booleans from using the less-than-or-equal ! operator ≤ to compare the array's values with r. Array<bool> GE (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the greater-than-or-equal ! operator ≥ to compare array values in A and B. Array<bool> GE (const T1& l, const Array<T2>& A) Returns booleans from using the greater-than-or-equal ! operator ≥ to compare l with the array's values. Array<bool> GE (const Array<T1>& A, const T2& r) Returns booleans from using the greater-than-or-equal ! operator ≥ to compare the array's values with r. Array<bool> GT (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the greater-than ! operator > to compare array values in A and B. Array<bool> GT (const T1& l, const Array<T2>& A) Returns booleans from using the greater-than ! operator > to compare l with the array's values. Array<bool> GT (const Array<T1>& A, const T2& r) Returns booleans from using the greater-than ! operator > to compare the array's values with r. Array<bool> EQ (const Array<T1>& A, const Array<T2>& B) Returns booleans from determining whether ! corresponding array values in A and B are equal. Array<bool> EQ (const T1& l, const Array<T2>& A) Returns booleans from determining whether ! l equals the array's values.. Array<bool> EQ (const Array<T1>& A, const T2& r) ! Returns booleans from determining whether the array's values equal r. Array<bool> NE (const Array<T1>& A, const Array<T2>& B) Returns booleans from determining whether ! corresponding array values in A and B are not equal. Array<bool> NE (const T1& l, const Array<T2>& A) Returns booleans from determining whether ! l does not equal the array's values. Array<bool> NE (const Array<T1>& A, const T2& r) Returns booleans from determining whether the ! array's values are not equal to r. --- 698,825 ---- effect ! Array<T> max (const Array<T1>& A, const Array<T2>& B) ! Returns the maximum of corresponding &array; values. Array<T> max (const T1& l, const Array<T2>& A) ! Returns the maximums of l with the &array;'s values. Array<T> max (const Array<T1>& A, const T2& r) ! Returns the maximums of the &array;'s values with r. Array<T> min (const Array<T1>& A, const Array<T2>& B) ! Returns the minimum of corresponding &array; values. Array<T> min (const T1& l, const Array<T2>& A) ! Returns the minimums of l with the &array;'s values. Array<T> min (const Array<T1>& A, const T2& r) ! Returns the minimums of the &array;'s values with r. Array<bool> LT (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the less-than ! operator < to compare corresponding &array; values in A and B. Array<bool> LT (const T1& r, const Array<T2>& A) Returns booleans from using the less-than ! operator < to compare l with the &array;'s values. Array<bool> LT (const Array<T1>& A, const T2& r) Returns booleans from using the less-than ! operator < to compare the &array;'s values with r. Array<bool> LE (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the less-than-or-equal ! operator <= to compare &array; values in A and B. Array<bool> LE (const T1& l, const Array<T2>& A) Returns booleans from using the less-than-or-equal ! operator <= to compare l with the &array;'s values. Array<bool> LE (const Array<T1>& A, const T2& r) Returns booleans from using the less-than-or-equal ! operator <= to compare the &array;'s values with r. Array<bool> GE (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the greater-than-or-equal ! operator >= to compare &array; values in A and B. Array<bool> GE (const T1& l, const Array<T2>& A) Returns booleans from using the greater-than-or-equal ! operator >= to compare l with the &array;'s values. Array<bool> GE (const Array<T1>& A, const T2& r) Returns booleans from using the greater-than-or-equal ! operator >= to compare the &array;'s values with r. Array<bool> GT (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the greater-than ! operator > to compare &array; values in A and B. Array<bool> GT (const T1& l, const Array<T2>& A) Returns booleans from using the greater-than ! operator > to compare l with the &array;'s values. Array<bool> GT (const Array<T1>& A, const T2& r) Returns booleans from using the greater-than ! operator > to compare the &array;'s values with r. Array<bool> EQ (const Array<T1>& A, const Array<T2>& B) Returns booleans from determining whether ! corresponding &array; values in A and B are equal. Array<bool> EQ (const T1& l, const Array<T2>& A) Returns booleans from determining whether ! l equals the &array;'s values. Array<bool> EQ (const Array<T1>& A, const T2& r) ! Returns booleans from determining whether the &array;'s values equal r. Array<bool> NE (const Array<T1>& A, const Array<T2>& B) Returns booleans from determining whether ! corresponding &array; values in A and B are not equal. Array<bool> NE (const T1& l, const Array<T2>& A) Returns booleans from determining whether ! l does not equal the &array;'s values. Array<bool> NE (const Array<T1>& A, const T2& r) Returns booleans from determining whether the ! &array;'s values are not equal to r. *************** std::cout << A-B << std::endl; *** 832,838 **** The table of miscellaneous functions () contains two functions. peteCast casts all values in ! an array to the type specified by the first parameter. The where function generalizes the trinary ?: operator. Using its first &array; argument as boolean values, it returns an &array; of just two --- 829,835 ---- The table of miscellaneous functions () contains two functions. peteCast casts all values in ! an &array; to the type specified by its first parameter. The where function generalizes the trinary ?: operator. Using its first &array; argument as boolean values, it returns an &array; of just two *************** std::cout << A-B << std::endl; *** 849,863 **** effect ! Array<T> peteCast (const T1&, const Array<T>& A) ! Returns the casting of the array's values to type T1. Array<T> where (const Array<T1>& A, const T2& t, const T3& f) Generalizes the ?: operator, ! returning an array of t and f values depending on whether A's values are true or false, respectively. --- 846,860 ---- effect ! Array<T> peteCast (const T1&, const Array<T>& A) ! Returns the casting of the &array;'s values to type T1. Array<T> where (const Array<T1>& A, const T2& t, const T3& f) Generalizes the ?: operator, ! returning an &array; of t and f values depending on whether A's values are true or false, respectively. *************** std::cout << A-B << std::endl; *** 871,878 **** values. Frequently, operating on a subset is useful. In &pooma;, a subset of a container's values is called a view. Combining views and data-parallel expressions will enable us to more ! succinctly and more easily write the diffusion program. Views are ! discussed in the next chapter. --- 868,875 ---- values. Frequently, operating on a subset is useful. In &pooma;, a subset of a container's values is called a view. Combining views and data-parallel expressions will enable us to more ! succinctly and more easily write the &doof2d; diffusion program. ! Views are discussed in the next chapter. *************** std::cout << A-B << std::endl; *** 885,915 **** these statements may create and destroy containers holding intermediate values, slowing execution considerably. In 1995, Todd Veldhuizen and David Vandevoorde developed an ! expression-template technique to transform arithmetic expressions ! involving array-like containers into efficient loops without using ! temporaries. Despite its perceived complexity, &pooma; ! incorporated the technology. The framework called &pete, the ! Portable Expression Template Engine ! framework, is also available separately from &pooma; at ! . ! In this section, we first describe how a &naive; implementation may slow execution. Then, we describe &pete;'s ! faster implementation. A data-parallel statement is converted into a parse tree, rather than immediately evaluating it. The parse tree has two representations. Its run-time representation holds run-time values. Its compile-time representation records the types of the tree's values. After a parse tree for the entire statement is constructed, it is evaluated. Since it is a data-parallel statement, this evaluation involves at least one ! loop. At run time, each loop iteration, the value of one container value is computed and assigned. At compile time, when the code for the loop iteration is produced, the parse tree's types are traversed and code is produced without the need for any intermediate values. We present the implementation in , but first we ! explain the difficulties caused by the &naive; implementation.

&naivecap; Implementation --- 882,913 ---- these statements may create and destroy containers holding intermediate values, slowing execution considerably. In 1995, Todd Veldhuizen and David Vandevoorde each developed ! an expression-template technique to transform arithmetic ! expressions involving array-like containers into efficient loops ! without using temporaries. Despite its perceived complexity, ! &pooma; incorporated the technology. The framework called &pete, ! the Portable Expression Template Engine ! framework, is also available separately from &pooma; at . ! In this chapter, we first describe how a &naive; implementation may slow execution. Then, we describe &pete;'s ! faster implementation. &pete; converts a data-parallel statement into a parse tree, rather than immediately evaluating it. The parse tree has two representations. Its run-time representation holds run-time values. Its compile-time representation records the types of the tree's values. After a parse tree for the entire statement is constructed, it is evaluated. Since it is a data-parallel statement, this evaluation involves at least one ! loop. At run time, for each loop iteration, the value of one container value is computed and assigned. At compile time, when the code for the loop iteration is produced, the parse tree's types are traversed and code is produced without the need for any intermediate values. We present the implementation in , but first we ! explain the difficulties caused by the &naive; ! implementation.

&naivecap; Implementation *************** Array<1, double, Brick> A(I), B(I); *** 923,933 **** A = 1.0; B = 2.0; A += -A + 2*B; ! std::cout << A << std::endl; Our goal is to transform the data-parallel statement A += -A + 2*B into a single ! loop, preferably without intermediary containers. To simplify ! notation, let Ar abbreviate the type Array<1, double, Brick>. Using overloaded arithmetic operators would require using --- 921,931 ---- A = 1.0; B = 2.0; A += -A + 2*B; ! std::cout &openopen; A &openopen; std::endl; Our goal is to transform the data-parallel statement A += -A + 2*B into a single ! loop, preferably without using intermediary containers. To ! simplify notation, let Ar abbreviate the type Array<1, double, Brick>. Using overloaded arithmetic operators would require using *************** std::cout << A << std::endl; *** 952,967 **** Template Engine framework, to evaluate data-parallel statements using efficient loops without intermediate values. &pete; uses expression-template technology. ! Instead of aggressively evaluating a data-parallel statement's ! subexpressions, it defers evaluation, instead building a parse ! tree of the required computations. The parse tree's type records ! the types of each of its subtrees. Then, the parse tree is ! evaluated using an evaluator determined by the left-hand side's ! type. This container type determines how to loop through its ! domain. Each loop iteration, the corresponding value of the ! right-hand side is evaluated. No intermediate loops or temporary ! values are needed.

Annotated Parse Tree for <statement>-A + 2*B</statement> --- 950,983 ---- Template Engine framework, to evaluate data-parallel statements using efficient loops without intermediate values. &pete; uses expression-template technology. ! Instead of evaluating a data-parallel statement's subexpressions ! at solely at run time, it evaluates the code at both run time and ! at compile time. At compile time, it builds a parse tree of the ! required computations. The parse tree's type records the types ! of each of its subtrees. Then, the parse tree is evaluated at ! compile time using an evaluator determined by the left-hand ! side's type. This container type determines how to loop through ! its domain. Each loop iteration of the resulting run time code, ! the corresponding value of the right-hand side is evaluated. No ! intermediate loops or temporary values are needed. + Before explaining the implementation, let us illustrate + using our example statement A += -A + 2*B. + Evaluating the right-hand side creates a parse tree similar to + the one in . + For example, the overloaded unary minus operator yields a tree + node representing -A, having a unary-minus + function object, and having type + Expression<UnaryNode<OpMinus,Ar&closeclose;. + The binary nodes continue the construction process yielding a + parse tree object for the entire right-hand side and having type + Expression<BinaryNode<OpAdd, UnaryNode<OpMinus, + Ar>, + BinaryNode<OpMultiply<Scalar<int>,Ar&closecloseclose;. + Evaluating the left-hand side yields an object + representing A. +

Annotated Parse Tree for <statement>-A + 2*B</statement> *************** std::cout << A << std::endl; *** 979,1025 **** - Before explaining the implementation, let us illustrate - using our example statement A += -A + 2*B. - Evaluating the right-hand side creates a parse tree similar to - the one in . - For example, the overloaded unary minus operator yields a tree - node representing -A, having a unary-minus - function object, and having type - Expression<UnaryNode<OpMinus,Ar&closeclose;. - The binary nodes continue the construction process yielding a - parse tree object for the entire right-hand side and having type - Expression<BinaryNode<OpAdd, UnaryNode<OpMinus, - Ar>, - BinaryNode<OpMultiply<Scalar<int>,Ar&closecloseclose;. - Evaluating the left-hand side yields an object - representing A. - Finally, the assignment operator += calls the evaluate function corresponding to the left-hand side's type. At compile time, it produces the code for the computation. Since this templated function is specialized on the type of the left-hand side, it generates a ! loop through the left-hand side's container. In the loop body, ! the forEach function produces code for the ! right-hand side expression at a specific position using a ! post-order parse-tree traversal. At a leaf, this evaluation ! queries the leaf's container for a specified value or extracts a ! scalar value. At an interior node, its children's results are ! combined using its function operator. One loop performs the ! entire assignment. It is important to note that the type of the ! entire right-hand side is known at compile time. Thus, all of ! these evaluate, forEach, and function operator function calls can be inlined at compile time to yield simple code without any temporary containers and hopefully as fast as hand-written loops! ! To implement this scheme, we need &pooma; code to both ! create the parse tree and to evaluate it. We describe parse tree ! creation first. Parse trees consist of leaves, ! UnaryNodes, BinaryNodes, and TrinaryNodes. Since TrinaryNodes are similar to BinaryNodes, we omit describing them. A BinaryNode's three template parameters correspond to --- 995,1024 ---- Finally, the assignment operator += calls the evaluate function corresponding to the left-hand side's type. At compile time, it produces the code for the computation. Since this templated function is specialized on the type of the left-hand side, it generates a ! loop iterating through the left-hand side's container. To ! produce the loop body, the forEach function ! produces code for the right-hand side expression at a specific ! position using a post-order parse-tree traversal. At a leaf, ! this evaluation queries the leaf's container for a specified ! value or extracts a scalar value. At an interior node, its ! children's results are combined using its function operator. One ! loop performs the entire assignment. It is important to note ! that the type of the entire right-hand side is known at compile ! time. Thus, all of these evaluate, forEach, and function operator function calls can be inlined at compile time to yield simple code without any temporary containers and hopefully as fast as hand-written loops! ! To implement this scheme, we need &pooma; (really &pete;) ! code to both create the parse tree and to evaluate it. We ! describe parse tree creation first. Parse trees consist of ! leaves, UnaryNodes, BinaryNodes, and TrinaryNodes. Since TrinaryNodes are similar to BinaryNodes, we omit describing them. A BinaryNode's three template parameters correspond to *************** std::cout << A << std::endl; *** 1050,1056 **** BinaryNode does not need to store any representation of the node's operation. Instead the ! Op type is an empty structure declaring a function object. For example, OpAdd's function object is declared as --- 1049,1055 ---- BinaryNode does not need to store any representation of the node's operation. Instead the ! Op type is an empty structure defining a function object. For example, OpAdd's function object is declared as *************** struct CreateLeaf<Array<Dim, T, En *** 1116,1127 **** Now that we have defined the node classes, the &cc; arithmetic operators must be overloaded to return the appropriate ! parse tree. For example, unary minus operator ! operator- overloaded to accept an &array; ! argument should create a UnaryNode having an &array; as its child, which will be a leaf: ! template<int D1,class T1,class E1> inline typename MakeReturn<UnaryNode<OpUnaryMinus, typename CreateLeaf<Array<D1,T1,E1> >::Leaf_t> >::Expression_t operator-(const Array<D1,T1,E1> & l) --- 1115,1126 ---- Now that we have defined the node classes, the &cc; arithmetic operators must be overloaded to return the appropriate ! parse tree. For example, the unary minus operator ! operator- is overloaded to accept an &array; ! argument. It should create a UnaryNode having an &array; as its child, which will be a leaf: ! template<int D1,class T1,class E1> inline typename MakeReturn<UnaryNode<OpUnaryMinus, typename CreateLeaf<Array<D1,T1,E1> >::Leaf_t> >::Expression_t operator-(const Array<D1,T1,E1> & l) *************** operator-(const Array<D1,T1,E1> &a *** 1144,1183 **** type from Expression's internal Expression_t type. ! Specialized all the operators for &array;s using such ! complicated is likely to be error-prone so &pete; provides a way ! to automate it. Using its MakeOperators ! command with this input: ! classes ----- ARG = "int D[n],class T[n],class E[n]" CLASS = "Array<D[n],T[n],E[n]>" automatically generates code for all the needed operators. The [n] strings are used to number arguments for binary and ternary operators. ! Assignment operators must also be specialized for &array;. Inside the &array; class definition, each such operator just ! invokes the assign function with a corresponding ! function object. For example, operator+= ! invokes assign(*this, rhs, OpAddAssign()). ! rhs is the parse tree object for the right-hand ! side. Calling this function invokes ! evaluate, which begins the evaluation. ! Before we explain the evaluation, let us summarize the effect of the code so far described. If we are considering run ! time, parse trees for the left-hand and right-hand sides have been ! constructed. If we are considering compile time, the types of ! these parse trees are known. At compile time, the ! evaluate function described below will ! generate a loop through the left-hand side container's domain. ! The loop's body will have code computing a container's value. At ! run time, this code will read values from containers, but the ! run-time parse tree object itself will not traversed! ! We now explore the evaluation, concentrating on compile time, not run time. evaluate is an overloaded function specialized on the type of the left-hand side. In our example, the left-hand side is a one-dimensional &array;, --- 1143,1185 ---- type from Expression's internal Expression_t type. ! Specializing all the operators for &array;s using such ! complicated functions is likely to be error-prone so &pete; ! provides a way to automate their creation. Using its ! MakeOperators command with this input: ! classes ----- ARG = "int D[n],class T[n],class E[n]" CLASS = "Array<D[n],T[n],E[n]>" automatically generates code for all the needed operators. The [n] strings are used to number arguments for binary and ternary operators. + ! Assignment operators must also be specialized for &array;. Inside the &array; class definition, each such operator just ! invokes the assign function with a ! corresponding function object. For example, ! operator+= invokes assign(*this, ! rhs, OpAddAssign()). rhs is the ! parse tree object for the right-hand side. Calling this function ! invokes evaluate, which begins the ! evaluation. ! Before we explain the evaluation, let us summarize the effect of the code so far described. If we are considering run ! time evaluation, parse trees for the left-hand and right-hand ! sides have been constructed. If we are considering compile time ! evaluation, the types of these parse trees are known. At compile ! time, the evaluate function described below ! will generate a loop iterating through the left-hand side ! container's domain. The loop's body will have code computing a ! container's value. At run time, this code will read values from ! containers, but the run-time parse tree object itself will not ! traversed! ! We now explore the evaluation, concentrating on compile time, not run time. evaluate is an overloaded function specialized on the type of the left-hand side. In our example, the left-hand side is a one-dimensional &array;, *************** forEach(const Expression& e, const L *** 1205,1211 **** nodes, it combines the results using the CombineTag operator c. It inlines into a call to ! ForEach<Expression, LeafTag, CombineTag>::apply(e, f, c). The apply function continues the traversal through the tree. For our example, LeafTag equals EvalLeaf<1>, and --- 1207,1213 ---- nodes, it combines the results using the CombineTag operator c. It inlines into a call to ! ForEach<Expression, LeafTag, CombineTag>::apply(e, f, c). The apply function continues the traversal through the tree. For our example, LeafTag equals EvalLeaf<1>, and *************** for (int i = A.domain[0].first(); i < en *** 1282,1292 **** code. &pete;'s expression template technology may be complicated, ! using parse trees and their types, but the code they produce is ! not. Using the technology is also easy. All data-parallel ! statements are automatically converted. In the next chapter, we ! explore views of containers, permitting use of container subsets ! and making data-parallel expressions even more useful.

--- 1284,1294 ---- code. &pete;'s expression template technology may be complicated, ! using parse trees and their types, but the produced code is not. ! Using the technology is also easy. All data-parallel statements ! are automatically converted. In the next chapter, we explore ! views of containers, permitting use of container subsets and ! making data-parallel expressions even more useful. Index: glossary.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/glossary.xml,v retrieving revision 1.8 diff -c -p -r1.8 glossary.xml *** glossary.xml 2002/01/24 05:11:21 1.8 --- glossary.xml 2002/01/25 02:15:05 *************** *** 11,19 **** --- 11,21 ---- should finish a sentence. The rest of the definition should consist of complete sentences. --> + ADD: Make sure all entries are indexed and perhaps point back to their first use. WARNING: This is constructed by hand so it is likely to be full of inconsistencies and errors. + ]]> A *************** *** 29,42 **** &array; ! a &pooma; container generalizing &c; arrays and mapping ! indices to values. Constant-time access to values is supported, ! ignoring the time to compute the values if applicable. &array;s ! are first-class ! objects. &dynamicarray;s and &field;s generalize &array;. &dynamicarray; &field; --- 31,46 ---- &array; ! a &pooma; container generalizing &c; ! arrays and mapping indices to values. Constant-time access to ! values is supported, ignoring the time to compute the values if ! applicable. &array;s are first-class objects. &dynamicarray;s and &field;s generalize &array;. + container &dynamicarray; &field; *************** *** 63,82 **** a domain element of a &field;. Both &array; and &field; domain elements are denoted by indices, but a cell exists in space. For example, it might be a rectangle or rectangular parallelepiped. &field; cell size ! specifies a &field; cell's dimensions e.g., its width, height, and depth, in &space;. This is frequently used to specify a mesh. mesh corner position --- 67,90 ---- a domain element of a &field;. Both &array; and &field; domain elements are denoted by indices, but a cell exists in space. For example, it might be a rectangle or rectangular parallelepiped. + cell size &field; + mesh cell size ! specifies a &field; ! cell's dimensions e.g., its width, height, and depth, in &space;. This is frequently used to specify a mesh. + cell mesh corner position *************** *** 85,99 **** communication library ! software library passing information among contexts, usually ! using messages. ! distributed computing environment compilation time ! --- 93,109 ---- communication library ! software library passing information among contexts, usually using ! messages. distributed computing ! environment compilation time ! *************** *** 141,147 **** domains with the same shape so that corresponding dimensions have the same number of elements. Scalars, deemed conformable with any domain, get ! expanded to the domain's shape. Binary operators can operate on containers with conformable domains. conformable containers data parallel --- 151,157 ---- domains with the same shape so that corresponding dimensions have the same number of elements. Scalars, deemed conformable with any domain, get ! expanded to the domain's shape. Assignment can operate on containers with conformable domains. conformable containers data parallel *************** *** 178,184 **** context a collection of shared memory and processors that can execute ! a program of a portion of a program. It can have one or more processors, but all these processors must access the same shared memory. Usually the computer and its operating system, not the programmer, determine the available contexts. --- 188,194 ---- context a collection of shared memory and processors that can execute ! a program or a portion of a program. It can have one or more processors, but all these processors must access the same shared memory. Usually the computer and its operating system, not the programmer, determine the available contexts. *************** *** 193,198 **** --- 203,209 ---- indicates how a container's patches are mapped to processors and shared memory. Two common choices are distribution among the various processors and replication. + context patch *************** *** 214,221 **** data parallel ! describes an expression representing a subset of a ! container's values. For example, sin(&container;) is an expression indicating that the sin is applied to each value in container &container;. --- 225,232 ---- data parallel ! describes an expression involving a (non-singleton) subset ! of a container's values. For example, sin(&container;) is an expression indicating that the sin is applied to each value in container &container;. *************** *** 258,264 **** 2stride, …, end}. end is in the set only if it equals begin plus some integral multiple of stride. This notation can ! abbreviate most domains. It is extended to multiple dimensions by separating the dimensions' sets with commas: [begin0:end0:stride0,begin1:end1:stride1]. domain --- 269,275 ---- 2stride, …, end}. end is in the set only if it equals begin plus some integral multiple of stride. This notation can ! abbreviate many domains. It is extended to multiple dimensions by separating the dimensions' sets with commas: [begin0:end0:stride0,begin1:end1:stride1]. domain *************** *** 268,279 **** &dynamicarray; ! a &pooma; container generalizing one-dimensional &array;s by supporting domain ! resizing at run-time. It maps indices to values in constant-time ! access, ignoring the time to compute the values if applicable. ! &dynamicarray;s are first-class objects. &array; &field; --- 279,292 ---- &dynamicarray; ! a &pooma; container generalizing ! one-dimensional &array;s by ! supporting domain resizing at run-time. It maps indices to values ! in constant time, ignoring the time to compute the values if ! applicable. &dynamicarray;s are first-class objects. + container &array; &field; *************** *** 292,298 **** element wise describes accesses to individual values within a container. ! For example, &container(i,j) represents one particular value in the container &container;. data parallel relation --- 305,311 ---- element wise describes accesses to individual values within a container. ! For example, &container(-4,3) represents one particular value in the container &container;. data parallel relation *************** *** 303,314 **** engine ! stores and, if necessary, computes a container's values. These can be specialized, e.g., to minimize storage when a domain has few distinct values. Separating a container and its storage also permits views of a container. &engine; view of a container --- 316,328 ---- engine ! stores or computes a container's values. These can be specialized, e.g., to minimize storage when a domain has few distinct values. Separating a container and its storage also permits views of a container. + &brick; &engine; &engine; view of a container *************** *** 362,375 **** &field; ! a &pooma; container representing an &array; with spatial ! extent. It also supports multiple values and multiple materials ! indexed by the same value. It maps indices to values in constant ! time, ignoring the time to compute the values if applicable. It ! also supports geometric computations such as the distance between ! two cells and normals to a ! cell. &field;s are first-class objects. &array; &dynamicarray; --- 376,394 ---- &field; ! a &pooma; container representing an ! &array; with spatial extent. It also supports multiple values and ! multiple materials having the same index. It maps indices to ! values in constant time, ignoring the time to compute the values ! if applicable. It also supports geometric computations such as ! the distance between two cells and normals to a cell. ! &field;s are first-class ! objects. ! container ! cell ! mesh &array; &dynamicarray; *************** *** 379,385 **** first-class type a type of object with all the capabilities of the built-in ! type with the most capabilities. For example, char and int are first-class types in &cc; because they may be declared anywhere, stored in automatic variables, accessed anywhere, copied, and passed by both value and reference. --- 398,404 ---- first-class type a type of object with all the capabilities of the built-in ! type having the most capabilities. For example, char and int are first-class types in &cc; because they may be declared anywhere, stored in automatic variables, accessed anywhere, copied, and passed by both value and reference. *************** guard layer *** 477,483 **** instantiation ! template instantiation --- 496,502 ---- instantiation ! template instantiation *************** guard layer *** 559,567 **** mesh a &field;'s map from indices to geometric values such as ! cell size, edge length, and cell normals. In other words, it specifies a &field;'s spatial extent. &field; layout --- 578,589 ---- mesh a &field;'s map from indices to geometric values such as ! cell size, edge length, and cell normals. In other words, it specifies a &field;'s spatial extent. &field; + cell + cell size + corner position layout *************** guard layer *** 657,663 **** linkend="glossary-range">domain triplets [b:e:s], can also be represented mathematically as an integral interval [b,e] with stride s, i.e., {a, a+s, a+2s, …, b}. It is ! generalized to &n;-dimensional range as the direct product of one-dimensional ranges. stride interval --- 679,685 ---- linkend="glossary-range">domain triplets [b:e:s], can also be represented mathematically as an integral interval [b,e] with stride s, i.e., {a, a+s, a+2s, …, b}. It is ! generalized to an &n;-dimensional range as the direct product of one-dimensional ranges. stride interval *************** guard layer *** 665,670 **** --- 687,702 ---- + + reference semantics + + a copy of an object o refers to the + object o such that changing either one + also changes the other. This is the opposite of value + semantics. + + + relation *************** guard layer *** 717,728 **** stencil ! set of values neighboring a container value and a function using those values to compute it. For example, the stencil in a ! two-dimensional Conway game of life consists of a value's eight ! neighbors and a function that sets the value to ! live if it is already live or it has exactly three ! live neighbors. data parallel element wise relation --- 749,760 ---- stencil ! set of values neighboring a container index and a function using those values to compute it. For example, the stencil in a ! two-dimensional Conway game of life consists of an index's eight ! neighbors and a function that sets its value to ! live if it is already live and it has two neighbors ! or it has exactly three live neighbors. data parallel element wise relation *************** guard layer *** 768,775 **** class or function definition having template parameters. These parameters' values are used at compile time, not run time, ! so they may include types and other compile-time values. ! template instantiation template specialization --- 800,806 ---- class or function definition having template parameters. These parameters' values are used at compile time, not run time, ! so they may include types and other compile-time values. template instantiation template specialization *************** guard layer *** 788,793 **** --- 819,825 ---- foo with the type &double; and the constant integer 3. Template instantiation is analogous to applying a function to function arguments. + template *************** guard layer *** 800,805 **** --- 832,838 ---- class or function definition for a particular (special) subset of template arguments. + template *************** guard layer *** 843,849 **** traits class a class containing one or more traits all describing a particular ! type's chacteristics. trait --- 876,882 ---- traits class a class containing one or more traits all describing a particular ! type's characteristics. trait Index: manual.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/manual.xml,v retrieving revision 1.9 diff -c -p -r1.9 manual.xml *** manual.xml 2002/01/24 05:11:21 1.9 --- manual.xml 2002/01/25 02:15:08 *************** *** 150,155 **** --- 150,157 ---- Range<1>"> + Remote"> + ReplicatedTag"> Stencil"> *************** *** 390,417 **** We begin this chapter by introducing the concept of an engine and how it is used. Then, we describe the various &engine;s that &pooma; provides, separating them into engines that store values ! and engines that compute values. Finally, we describe how the &engine;s are implemented, using tags to differentiate engines and ! reference-counted pointers to their underlying data.

The Concept An engine performs the low-level value storage, computation, ! and element-wise access for a container. The &pooma; &engine; ! class and its specializations implement the concept. An engine ! has a domain and accessor functions returning individual elements. ! Given an index within the domain, an engine's operator() function returns the associated value, which can be used or changed. Its ! read returns the same value for only use, ! not modification. The acceptable indices are determined by each ! &engine;. Most accept indices specified using ∫ and ! Loc<&dim;> parameters, but an &engine; might ! accept string or floating-point parameters. An &engine;'s layout ! specifies maps its domain indices to the processors and memory ! used to store and compute the associated values. Since an engine's main role is to return the individual values associated with specific domain indices, any implementation --- 392,424 ---- We begin this chapter by introducing the concept of an engine and how it is used. Then, we describe the various &engine;s that &pooma; provides, separating them into engines that store values ! and engines that compute values. ! !

The Concept An engine performs the low-level value storage, computation, ! and element-wise access for a container. An engine has a domain ! and accessor functions returning individual elements. The &pooma; ! &engine; class and its specializations implement the engine ! concept. Given an index within the domain, an &engine;'s operator() function returns the associated value, which can be used or changed. Its ! read member function returns the same ! value but permitting only use, not modification. The acceptable ! indices are determined by each &engine;. Most accept indices ! specified using ∫ and Loc<&dim;> ! parameters, but an &engine; might accept string or floating-point ! parameters. An &engine;'s layout specifies maps its domain ! indices to the processors and memory used to store and compute the ! associated values. Since an engine's main role is to return the individual values associated with specific domain indices, any implementation *************** *** 437,477 **** object to each value returned by another &engine;. A CompFwd &engine; projects components from another &engine;. For example, CompFwd will use the second ! components of each vector in an &array; to form its own &array;. ! Since each container has one or more &engine;s, we can also describe the latter category as containers that compute their values using other containers' values. A &multipatch; &engine; distributes its domain among various processors and memory spaces, each responsible for computing values associated with a portion, ! or patch, of the domain. Just as multiple containers can use the same engine, multiple &engine;s can use the same underlying data. As we mentioned in , &engine;s ! have reference semantics. So a copy of an &engine; has a ! reference-counted pointer to an &engine;'s data (if any exists). Thus, copying an &engine; or a container requires little execution time. If an &engine; has the same data as another &engine; but it needs its own data to modify, the ! makeOwnCopy creates such a copy. &engine;s are rarely explicitly declared. Instead a ! container is declared using an &engine; tag, and the container, creates the specified &engine; to deal with its values. For example, a &brick; &engine; is explicitly declared as Engine<&dim;,T,Brick>, but they are more frequently created by containers, e.g., ! Array<&dim;,T,Brick>. The first two template ! parameters specify the domain's dimensionality and the value type, ! as described in . Unlike container declarations, the third template parameter, the &engine; tag, specifies which &engine; specialization to use. For example, the ! &brick; engine tag indicates a brick &engine; should be used. Some &engine;s, such as CompFwd, are rarely declared even using &engine; tags. Instead the &array;'s comp and ! readComp methods return views of containers using CompFwd &engine;s.

--- 444,487 ---- object to each value returned by another &engine;. A CompFwd &engine; projects components from another &engine;. For example, CompFwd will use the second ! components of each &vector; in an &array; to form its own &array;. ! Since each container has at least one &engine;, we can also describe the latter category as containers that compute their values using other containers' values. A &multipatch; &engine; distributes its domain among various processors and memory spaces, each responsible for computing values associated with a portion, ! or patch, of the domain. The &remote; &engine; also supports ! distributed computation. Just as multiple containers can use the same engine, multiple &engine;s can use the same underlying data. As we mentioned in , &engine;s ! have reference ! semantics. A copy of an &engine; has a ! reference-counted pointer to the &engine;'s data (if any exists). Thus, copying an &engine; or a container requires little execution time. If an &engine; has the same data as another &engine; but it needs its own data to modify, the ! makeOwnCopy member function creates such ! a copy. &engine;s are rarely explicitly declared. Instead a ! container is declared using an &engine; tag, and the container creates the specified &engine; to deal with its values. For example, a &brick; &engine; is explicitly declared as Engine<&dim;,T,Brick>, but they are more frequently created by containers, e.g., ! Array<&dim;,T,Brick>. An &engine;'s first two ! template parameters specify the domain's dimensionality and the ! value type, as described in . Unlike container declarations, the third template parameter, the &engine; tag, specifies which &engine; specialization to use. For example, the ! &brick; &engine; tag indicates a &brick; &engine; should be used. Some &engine;s, such as CompFwd, are rarely declared even using &engine; tags. Instead the &array;'s comp and ! readComp member functions return views of containers using CompFwd &engine;s.

*************** *** 482,501 **** In this section, we describe the different types of &engine;s and illustrate their creation, when appropriate. First, we describe &engine;s that explicitly store values and then ! &engine;s that compute values. !

! Types of &engine;s ! &engine; tag description ! &engine;s That Store --- 492,512 ---- In this section, we describe the different types of &engine;s and illustrate their creation, when appropriate. First, we describe &engine;s that explicitly store values and then ! &engine;s that compute values. See . !

! Types of &engine;s ! &engine; tag description ! &engine;s That Store *************** *** 506,512 **** &compressiblebrick; stores all values, reducing storage requirements when ! all values are the same. &dynamic; --- 517,523 ---- &compressiblebrick; stores all values, reducing storage requirements when ! all values are identical. &dynamic; *************** *** 520,526 **** CompFwd extracts specified components of an engine's vectors, ! tensors, arrays, etc.; usually created using comp container function. --- 531,537 ---- CompFwd extracts specified components of an engine's vectors, ! tensors, arrays, etc.; usually created using the comp container function. *************** *** 529,535 **** IndexFunction<FunctionObject> ! makes the FunctionObject function of indices behave like a container. --- 540,546 ---- IndexFunction<FunctionObject> ! makes the FunctionObject's function of indices behave like a container. *************** *** 538,558 **** data-parallel expressions. ! Stencil<Function, ! Expression> applies a stencil computation (Function) ! to its input (Expression), usually a container; ! usually created by applying a Stencil object to ! a container. A stencil computation can use multiple ! neighboring input values. UserFunctionEngine<Function, Expression> applies the given function (or function ! object) to its input (Expression), ! usually a container; usually created by applying a UserFunction object to a container. The function implements a one-to-one mapping from its input to values. --- 549,568 ---- data-parallel expressions. ! Stencil<Function, Expression> applies a stencil computation (Function) ! to its input (Expression) which is usually a ! container; usually created by applying a Stencil ! object to a container. A stencil computation can use ! multiple neighboring input values. UserFunctionEngine<Function, Expression> applies the given function (or function ! object) to its input (Expression) ! which is usually a container; usually created by applying a UserFunction object to a container. The function implements a one-to-one mapping from its input to values. *************** *** 581,631 ****

! &brick; &engine;s explicitly store values just like &c; arrays. &compressiblebrick; &engine;s optimize their storage ! requirements when all values are the same. Most &array;s use one of these two &engine;s. &brick;s are the default &engine;s for ! &array; and &field; containers because each of their values are ! explicitly stored. Explicitly storing all an engine's value can ! require a large amount of space, particularly if all these values ! are the same. If all a compressible brick &engine;'s values are ! the same, the engine stores that one value rather than many, many ! copies of the same value. These engines can both save time as ! well as space. Initializing a compressible engine requires ! setting only one value, not every value. Using less storage space ! may permit more useful values to be stored in cache, improving ! cache performance. Reading a value in a compressed &engine; using ! read is as fast as reading a value in a ! &brick; &engine;, but writing a value always requires an ! additional if conditional. Thus, if an ! &engine; occasionally has multiple different values during its ! life time, a &compressiblebrick; &engine; may be faster than a ! &brick; &engine;. If an &engine; is created and its values are ! mostly read, not written, a &compressiblebrick; &engine; may also ! be faster. Otherwise, a &brick; &engine; may be preferable. ! Timing the same program using the two different &engine; types ! will reveal which is faster for a particular situation. ! ! In distributed computing, many &engine;s may have few ! nonzero values so &compressiblebrick; &engine;s may be preferable. ! For distributed computing, a container's domain is partitioned ! into regions each computed by a separate processor and &engine;. ! If the computation is concentrated in sections of the domain, many ! &engine;s may have few, if any, nonzero values. Thus, ! &compressiblebrick; &engine;s may be preferable for distributed ! computing. Both &brick; and &compressiblebrick; &engine;s have read and ! operator() members with ∫ and &loc; ! parameters. The parameters should match the &array;'s dimensionality. For example, if &array; a has dimensionality 3, a.read(int, int, int) and a(int, int, int) should be used. The former returns a value that cannot be modified, while the latter ! can be changed. Using the read can lead ! to faster code. Alternatively, an index can be specified using a ! &loc;. For example, a.read(Loc<3>(1,-2,5)) and a(Loc<3>(1,-2,5)) are equivalent to a.read(1,-2,5)) and --- 591,642 ---- ! ! &brick; ! &engine;s explicitly store values just like &c; arrays. &compressiblebrick; &engine;s optimize their storage ! requirements when all values are identical. Many &array;s use one of these two &engine;s. &brick;s are the default &engine;s for ! &array; and &field; containers because they explicitly store each ! value. This explicit storage can require a large amount of space, ! particularly if all these values are the same. If all a ! compressible brick &engine;'s values are identical, the &engine; ! stores that one value rather than many, many copies of the same ! value. These engines can both save time as well as space. ! Initializing a compressible engine requires setting only one ! value, not every value. Using less storage space may also permit ! more useful values to be stored in cache, improving cache ! performance. Reading a value in a compressed &engine; using the ! read member function is as fast as ! reading a value in a &brick; &engine;, but writing a value always ! requires executing an additional if ! conditional. Thus, if an &engine; infrequently has multiple ! different values during its life time, a &compressiblebrick; ! &engine; may be faster than a &brick; &engine;. If an &engine; is ! created and its values are mostly read, not written, a ! &compressiblebrick; &engine; may also be faster. Otherwise, a ! &brick; &engine; may be preferable. Timing the same program using ! the two different &engine; types will reveal which is faster for a ! particular situation. In distributed computing, many &engine;s ! may have few nonzero values so &compressiblebrick; &engine;s may ! be preferable. For distributed computing, a container's domain is ! partitioned into regions each computed by a separate processor and ! &engine;. If the computation is concentrated in sections of the ! domain, many &engine;s may have few, if any, nonzero values. ! Thus, &compressiblebrick; &engine;s may be preferable for ! distributed computing. Both &brick; and &compressiblebrick; &engine;s have read and ! operator() member functions taking ∫ ! and &loc; parameters. The parameters should match the &array;'s dimensionality. For example, if &array; a has dimensionality 3, a.read(int, int, int) and a(int, int, int) should be used. The former returns a value that cannot be modified, while the latter ! can be changed. Using the read member ! function can lead to faster code. Alternatively, an index can be ! specified using a &loc;. For example, a.read(Loc<3>(1,-2,5)) and a(Loc<3>(1,-2,5)) are equivalent to a.read(1,-2,5)) and *************** *** 641,650 **** operator() take Loc<1> or one ∫ parameter. In addition, the one-dimensional domain can be dynamically resized using create ! and destroy; see . ! HERE Dynamic. How does one change the domain size? What is the model? Types of &engine;s: --- 652,666 ---- operator() take Loc<1> or one ∫ parameter. In addition, the one-dimensional domain can be dynamically resized using create ! and destroy. ! ! + Types of &engine;s: *************** HERE Dynamic. How does one change the do *** 706,711 **** --- 722,728 ---- types of engines likely to be used by &pooma; programmers and how to declare containers using them. Should I list the other engines that are automatically created? + ]]> *************** HERE Dynamic. How does one change the do *** 729,745 **** A view of a ! container &container; is a container ! accessing a subset of &container;'s domain &containerdomain; ! and values. The subset can include all of &containerdomain;. ! A view is so named because it is a different way to ! access, or view, another container's values. Both the container ! and its view share the same underlying engine so changing values in ! one also changes them in the other. A view is created by following a container's name by ! parentheses containing a domain &containerdomain;. For ! example, consider this code extracted from in . --- 746,762 ---- A view of a ! container is a container accessing a subset ! of &container;'s domain and values. The subset can include all of ! the container's domain. A view is so named because ! it is a different way to access, or view, another container's ! values. Both the container and its view share the same underlying ! engine so changing values in one also changes them in the ! other. A view is created by following a container's name by ! parentheses containing a domain. For example, consider this code ! extracted from in . *************** a(I,J) = (1.0/9.0) * *** 922,928 **** create, copy, and destroy operations (mostly table) ! nonmodifying operations (mostly table) assignments (mostly table) --- 939,945 ---- create, copy, and destroy operations (mostly table) ! non-modifying operations (mostly table) assignments (mostly table) *************** a(I,J) = (1.0/9.0) * *** 1082,1088 **** description ! &inform; pinfo output stream used to print informative messages to the --- 1099,1105 ---- description ! &inform; pinfo output stream used to print informative messages to the *************** UNFINISHED *** 1939,1945 **** Interpretation ! Dim dimension --- 1956,1962 ---- Interpretation ! Dim dimension *************** UNFINISHED *** 1971,1977 **** Interpretation ! This_t the &array; object's type --- 1988,1994 ---- Interpretation ! This_t the &array; object's type *************** UNFINISHED *** 2032,2038 **** Effect ! --- 2049,2055 ---- Effect ! *************** UNFINISHED *** 2104,2110 **** Effect ! --- 2121,2127 ---- Effect ! *************** UNFINISHED *** 2187,2193 **** Effect ! --- 2204,2210 ---- Effect ! *************** UNFINISHED *** 2223,2229 **** Effect ! --- 2240,2246 ---- Effect ! *************** UNFINISHED *** 2269,2275 **** Effect ! --- 2286,2292 ---- Effect ! *************** UNFINISHED *** 2307,2313 **** Meaning ! --- 2324,2330 ---- Meaning ! *************** UNFINISHED *** 2433,2439 **** Value ! --- 2450,2456 ---- Value ! *************** UNFINISHED *** 2914,2920 **** Description ! NoMesh<Dim> no physical spacing, causing a &field; to mimic --- 2931,2937 ---- Description ! NoMesh<Dim> no physical spacing, causing a &field; to mimic *************** UNFINISHED *** 2992,2998 **** Description ! Brick Brick --- 3009,3015 ---- Description ! Brick Brick *************** UNFINISHED *** 3585,3591 **** Particles docs/ParticlesDoc.txt has out-of-date information. See Section 3.2.3 of --- 3602,3608 ---- Particles docs/ParticlesDoc.txt has out-of-date information. See Section 3.2.3 of *************** UNFINISHED *** 3703,3711 **** --- 3720,3736 ---- Obtaining and Installing &pooma; + In , we described + how to install &pooma;. In the following section, we describe how + to install &pooma; to support distributed computation. + ]]> + + ADD: Write this section, including extensive instructions for Unix, MS Windows, and MacOS. List the configuration options. Be sure to describe configuring for parallel execution. + ]]>

Supporting Distributed Computation *************** UNFINISHED *** 3724,3743 **** &cheetah;, and thus &pooma;, can use Ralf Engelschall's &mm; Shared Memory Library to pass messages between processors. For example, the &author; uses this library on a two-processor ! computer running &linux;. The library, available at ! http://www.engelschall.com/sw/mm/, is available for free and has ! been successfully tested on a variety of Unix platforms. We describe how to download and install the &mm; library. ! ! Download the library from the &pooma; Download page ! available off the &pooma; home page (&poomahomepage;). ! Extract the source code using tar xzvf ! mm-1.1.3.tar.gz. Move into the resulting source ! code directory mm-1.1.3. --- 3749,3770 ---- &cheetah;, and thus &pooma;, can use Ralf Engelschall's &mm; Shared Memory Library to pass messages between processors. For example, the &author; uses this library on a two-processor ! computer running &linux;. The library, available at http://www.engelschall.com/sw/mm/, ! is available for free and has been successfully tested on a ! variety of Unix platforms. We describe how to download and install the &mm; library. ! ! Download the library from the &pooma; Download page ! (&poomadownloadpage;) available off the &pooma; home page ! (&poomahomepage;). ! Extract the source code using tar xzvf ! mm-1.1.3.tar.gz. Change directories into the ! resulting source code directory mm-1.1.3. *************** UNFINISHED *** 3754,3763 **** &dashdash;prefix=${HOME}/pooma/mm-1.1.3. ! Create the library by issuing the make ! command. This compiles the source code using a &c; compiler. To ! use a different compiler than the &mm; configuration chooses, set ! the CC to the compiler before configuring. Optionally test the library by issuing the make --- 3781,3792 ---- &dashdash;prefix=${HOME}/pooma/mm-1.1.3. ! Create the library by issuing the ! make command. This compiles the source ! code using a &c; compiler. To use a different compiler than ! the &mm; configuration chooses, set the CC ! environment variable to the desired compiler before ! configuring. Optionally test the library by issuing the make *************** UNFINISHED *** 3791,3798 **** &cheetah;'s messaging is implemented using an underlying messaging library such as the Message Passing Interface (&mpi;) ! Communications Library (FIXME: xref linkend="mpi99", ) or the &mm; Shared Memory Library. &mpi; works on a wide variety of platforms and has achieved widespread usage. &mm; works under Unix on any computer with shared memory. Both libraries are available for --- 3820,3831 ---- &cheetah;'s messaging is implemented using an underlying messaging library such as the Message Passing Interface (&mpi;) ! Communications Library ! ) ! ]]> ! or the &mm; Shared Memory Library. &mpi; works on a wide variety of platforms and has achieved widespread usage. &mm; works under Unix on any computer with shared memory. Both libraries are available for *************** UNFINISHED *** 3803,3814 **** Download the library from the &pooma; Download page ! available off the &pooma; home page (&poomahomepage;). Extract the source code using tar xzvf ! cheetah-1.0.tgz. Move into the resulting source code ! directory cheetah-1.0. --- 3836,3848 ---- Download the library from the &pooma; Download page ! (&poomadownloadpage;) available off the &pooma; home page ! (&poomahomepage;). Extract the source code using tar xzvf ! cheetah-1.0.tgz. Change directories into the ! resulting source code directory cheetah-1.0. *************** UNFINISHED *** 3935,3941 **** installed &cheetah; library. For example, declare -x CHEETAHDIR=${HOME}/pooma/cheetah-1.0 specifies the ! installation directory used in the previous section. When configuring &pooma;, specify the --- 3969,3977 ---- installed &cheetah; library. For example, declare -x CHEETAHDIR=${HOME}/pooma/cheetah-1.0 specifies the ! installation directory used in the previous section. If using ! the csh shell, use setenv ! CHEETAHDIR ${HOME}/pooma/cheetah-1.0. When configuring &pooma;, specify the *************** UNFINISHED *** 4137,4142 **** --- 4173,4180 ---- + From oldham at codesourcery.com Fri Jan 25 03:05:26 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 24 Jan 2002 19:05:26 -0800 Subject: Manual Figures Message-ID: <20020124190526.A7778@codesourcery.com> These are updates to the MetaPost figures for the POOMA manual. 2002-Jan-24 Jeffrey D. Oldham * doof2d.mp (210): Fix operator layout. Modify indices. Add indices for lhs. * introduction.mp (101): Add comments of unfinished work. * macros.ltx: Add many new definitions. * makefile: Several minor changes. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: doof2d.mp =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/doof2d.mp,v retrieving revision 1.3 diff -c -p -r1.3 doof2d.mp *** doof2d.mp 2002/01/04 17:42:43 1.3 --- doof2d.mp 2002/01/25 02:53:47 *************** beginfig(210) *** 127,134 **** for t = 0 upto 2: drawGrid(nuCells, unit, z[t]); endfor ! label(btex = etex, z1 + unit*(-0.9operatorWidth, 0.5nuCells)); ! label(btex + etex, z2 + unit*(-0.9operatorWidth, 0.5nuCells)); %% Label the grid cells' values. % Label b(I,J) grid values. --- 127,134 ---- for t = 0 upto 2: drawGrid(nuCells, unit, z[t]); endfor ! label(btex = etex, z1 + unit*(-0.6operatorWidth, 0.5nuCells)); ! label(btex + etex, z2 + unit*(-0.6operatorWidth, 0.5nuCells)); %% Label the grid cells' values. % Label b(I,J) grid values. *************** beginfig(210) *** 164,182 **** %% Label the indices. % Label b(I,J) grid indices. ! labelCellBottom(btex \footnotesize 1 etex, (0,0), z1); ! labelCellBottom(btex \footnotesize 2 etex, (1,0), z1); ! labelCellBottom(btex \footnotesize 3 etex, (2,0), z1); ! labelCellLeft(btex \footnotesize 1 etex, (0,0), z1); ! labelCellLeft(btex \footnotesize 2 etex, (0,1), z1); ! labelCellLeft(btex \footnotesize 3 etex, (0,2), z1); % Label b(I+1,J-1) grid indices. ! labelCellBottom(btex \footnotesize 2 etex, (0,0), z2); ! labelCellBottom(btex \footnotesize 3 etex, (1,0), z2); ! labelCellBottom(btex \footnotesize 4 etex, (2,0), z2); labelCellLeft(btex \footnotesize 0 etex, (0,0), z2); labelCellLeft(btex \footnotesize 1 etex, (0,1), z2); labelCellLeft(btex \footnotesize 2 etex, (0,2), z2); %% Label the grids. labelGrid(btex $b(I,J)+b(I+1,J-1)$ etex, nuCells, z0); --- 164,189 ---- %% Label the indices. % Label b(I,J) grid indices. ! labelCellBottom(btex \footnotesize 0 etex, (0,0), z1); ! labelCellBottom(btex \footnotesize 1 etex, (1,0), z1); ! labelCellBottom(btex \footnotesize 2 etex, (2,0), z1); ! labelCellLeft(btex \footnotesize 0 etex, (0,0), z1); ! labelCellLeft(btex \footnotesize 1 etex, (0,1), z1); ! labelCellLeft(btex \footnotesize 2 etex, (0,2), z1); % Label b(I+1,J-1) grid indices. ! labelCellBottom(btex \footnotesize 0 etex, (0,0), z2); ! labelCellBottom(btex \footnotesize 1 etex, (1,0), z2); ! labelCellBottom(btex \footnotesize 2 etex, (2,0), z2); labelCellLeft(btex \footnotesize 0 etex, (0,0), z2); labelCellLeft(btex \footnotesize 1 etex, (0,1), z2); labelCellLeft(btex \footnotesize 2 etex, (0,2), z2); + % Label b(I,J)+b(I+1,J-1) grid indices. + labelCellBottom(btex \footnotesize 0 etex, (0,0), z0); + labelCellBottom(btex \footnotesize 1 etex, (1,0), z0); + labelCellBottom(btex \footnotesize 2 etex, (2,0), z0); + labelCellLeft(btex \footnotesize 0 etex, (0,0), z0); + labelCellLeft(btex \footnotesize 1 etex, (0,1), z0); + labelCellLeft(btex \footnotesize 2 etex, (0,2), z0); %% Label the grids. labelGrid(btex $b(I,J)+b(I+1,J-1)$ etex, nuCells, z0); Index: introduction.mp =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/introduction.mp,v retrieving revision 1.2 diff -c -p -r1.2 introduction.mp *** introduction.mp 2002/01/04 17:42:43 1.2 --- introduction.mp 2002/01/25 02:53:47 *************** etex *** 18,23 **** --- 18,26 ---- %% Relationship between science, computational science, and Pooma. beginfig(101) + %% FIXME: Ensure the arrow labels are the same distance above the arrows. + %% FIXME: Ensure the boxes all have the same height. + %% FIXME: Ensure the arrowheads do not collide. numeric unit; unit = 0.8cm; numeric horizSpace; horizSpace = 8unit; numeric vertSpace; vertSpace = unit; Index: macros.ltx =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/macros.ltx,v retrieving revision 1.1 diff -c -p -r1.1 macros.ltx *** macros.ltx 2001/12/11 20:36:13 1.1 --- macros.ltx 2002/01/25 02:53:47 *************** *** 6,11 **** --- 6,34 ---- %% Consistency between these macros and the DocBook/Jade output is desired. + % Mathematical Notation + \newcommand{\dimension}{\ensuremath{d}}% + % Produce a representation for a fixed number of dimensions. + % Requires no parameters. + \newcommand{\naturalNus}{\ensuremath{\boldsymbol{N}}}% + % Produce a representation for discrete space. + % Requires no parameters. + \newcommand{\maps}{\ensuremath{\rightarrow}}% + % Produce a representation for a map. + % Requires no parameters. + \newcommand{\real}{\ensuremath{\boldsymbol{R}}}% + % Produce a representation for continuous space. + % Requires no parameters. + + % Other Notation + \newcommand{\pooma}{POOMA}% + % Produce "Pooma." + % Requires no parameters. + + % Programming Notation + \newcommand{\statement}[1]{\texttt{#1}}% + % Produce a C++ (or other programming language) statement or fragment. + % Requires: 1. the statement. \newcommand{\type}[1]{\texttt{#1}}% % Produce a C++ (or other programming language) type. % Requires: 1. the type's name. Index: makefile =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/makefile,v retrieving revision 1.1 diff -c -p -r1.1 makefile *** makefile 2001/12/04 00:07:00 1.1 --- makefile 2002/01/25 02:53:47 *************** INDEXOPTIONS= -t 'Index' -i 'index' -g *** 23,30 **** CXXFLAGS= -g -Wall -pedantic -W -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wcast-align -Wconversion -Wnested-externs -Wundef -Winline -static ! all: outline.ps %.all: %.ps %.pdf %.html chmod 644 $*.ps $*.pdf mv $*.ps $*.pdf $* --- 23,34 ---- CXXFLAGS= -g -Wall -pedantic -W -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wcast-align -Wconversion -Wnested-externs -Wundef -Winline -static ! all: manual.ps + manual.dvi: manual.xml introduction.xml template.xml tutorial.xml \ + concepts.xml arrays.xml data-parallel.xml glossary.xml \ + bibliography.xml + %.all: %.ps %.pdf %.html chmod 644 $*.ps $*.pdf mv $*.ps $*.pdf $* *************** all: outline.ps *** 41,54 **** %.pdf.ltx: %.ltx sed -e 's/^%\\usepackage{times}/\\usepackage{times}/' $< > $@ ! %.pdf: %.pdf.ps ! ps2pdf $< $@ # This rule assumes index creation. %.dvi: %.xml genindex.sgm ! jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) -V html-index $(XML) $< ! perl collateindex.pl $(INDEXOPTIONS) -o genindex.sgm HTML.index ! jade -D$(JADEDIR) -t tex -d $(PRINTDOCBOOKDSL) $(XML) $< && jadetex $*.tex && jadetex $*.tex && jadetex $*.tex genindex.sgm: perl collateindex.pl $(INDEXOPTIONS) -N -o $@ --- 45,59 ---- %.pdf.ltx: %.ltx sed -e 's/^%\\usepackage{times}/\\usepackage{times}/' $< > $@ ! %.pdf: %.pdf.ltx ! pdflatex $< ! mv $@.pdf $@ # This rule assumes index creation. %.dvi: %.xml genindex.sgm ! jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) -V html-index $(XML) $< && \ ! perl collateindex.pl $(INDEXOPTIONS) -o genindex.sgm HTML.index && \ ! jade -D$(JADEDIR) -t tex -d $(PRINTDOCBOOKDSL) -V tex-backend $(XML) $< && jadetex $*.tex && jadetex $*.tex && jadetex $*.tex genindex.sgm: perl collateindex.pl $(INDEXOPTIONS) -N -o $@ *************** mproof-%.ps: %.mp *** 66,69 **** detex $< > $@ clean: ! rm -f *.dvi *.aux *.log *.toc *.bak *.blg *.bbl *.glo *.idx *.lof *.lot *.htm *.mpx mpxerr.tex HTML.index outline.tex --- 71,74 ---- detex $< > $@ clean: ! rm -f *.dvi *.aux *.log *.toc *.bak *.blg *.bbl *.glo *.idx *.lof *.lot *.htm *.mpx mpxerr.tex HTML.index manual.tex genindex.sgm From oldham at mail.codesourcery.com Fri Jan 25 03:31:18 2002 From: oldham at mail.codesourcery.com (Jeffrey) Date: Thu, 24 Jan 2002 19:31:18 -0800 Subject: Manual: Move Program Annotation Files Message-ID: <20020124193118.A575@vaio.codesourcery.com> This patch deals with patches to convert executable code into annotated programs suitable for DocBook. The files are 1) moved 2) revised to varying extents. 2002-Jan-24 Jeffrey D. Oldham * Doof2d-Array-distributed-annotated.patch: Move this file to examples/Doof2d/. * Doof2d-Array-element-annotated.patch: Likewise. * Doof2d-Array-parallel-annotated.patch: Likewise. * Doof2d-Array-stencil-annotated.patch: Likewise. * Doof2d-C-element-annotated.patch: Likewise. * Doof2d-Field-distributed-annotated.patch: Likewise. * Doof2d-Field-parallel-annotated.patch: Likewise. * Makefile: Likewise. * initialize-finalize-annotated.patch: Likewise. * pairs-templated-annotated.patch: Likewise. * pairs-untemplated-annotated.patch: Likewise. * examples/Doof2d-Array-distributed-annotated.patch: Likewise. * examples/Doof2d-Array-element-annotated.patch: Likewise. * examples/Doof2d-Array-parallel-annotated.patch: Likewise. * examples/Doof2d-Array-stencil-annotated.patch: Likewise. * examples/Doof2d-C-element-annotated.patch: Likewise. * examples/Doof2d-Field-distributed-annotated.patch: Likewise. * examples/Doof2d-Field-parallel-annotated.patch: Likewise. * examples/Makefile: Likewise. * examples/initialize-finalize-annotated.patch: Likewise. * examples/pairs-templated-annotated.patch: Likewise. * examples/pairs-untemplated-annotated.patch: Likewise. * examples/Doof2d/Doof2d-Array-distributed-annotated.patch: Most recent version of this file. Also moved here. * examples/Doof2d/Doof2d-Array-element-annotated.patch: Likewise. * examples/Doof2d/Doof2d-Array-parallel-annotated.patch: Likewise. * examples/Doof2d/Doof2d-Array-stencil-annotated.patch: Likewise. * examples/Doof2d/Doof2d-C-element-annotated.patch: Likewise. * examples/Doof2d/Doof2d-Field-distributed-annotated.patch: Likewise. * examples/Doof2d/Doof2d-Field-parallel-annotated.patch: Likewise. * examples/Sequential/array-copy-annotated.patch: Likewise. * examples/Sequential/array-size-annotated.patch: Likewise. * examples/Sequential/dynamicarray-annotated.patch: Likewise. * examples/Sequential/initialize-finalize-annotated.patch: Likewise. * examples/Templates/pairs-templated-annotated.patch: Likewise. Applied to mainline. Approved by no one. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Doof2d-Array-distributed-annotated.patch =================================================================== RCS file: Doof2d-Array-distributed-annotated.patch diff -N Doof2d-Array-distributed-annotated.patch *** /tmp/cvsQs5Bce Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,184 **** - *** Doof2d-Array-distributed.cpp Wed Dec 5 14:04:36 2001 - --- Doof2d-Array-distributed-annotated.cpp Wed Dec 5 14:07:56 2001 - *************** - *** 1,3 **** - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - *************** - *** 14,18 **** - // (i,j). The "C" template parameter permits use of this stencil - // operator with both Arrays and Fields. - ! template - inline - typename C::Element_t - --- 16,20 ---- - // (i,j). The "C" template parameter permits use of this stencil - // operator with both Arrays and Fields. - ! template <class C> - inline - typename C::Element_t - *************** - *** 42,46 **** - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - --- 44,48 ---- - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - *************** - *** 48,52 **** - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; - return EXIT_FAILURE; - } - --- 50,54 ---- - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output &openopen; argv[0] &openopen; ": number-of-processors number-of-averagings number-of-values" &openopen; std::endl; - return EXIT_FAILURE; - } - *************** - *** 55,63 **** - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 57,65 ---- - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 65,69 **** - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - --- 67,71 ---- - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - *************** - *** 71,80 **** - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the distributed arrays. - --- 73,82 ---- - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the distributed arrays. - *************** - *** 83,98 **** - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire array domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // The template parameters indicate 2 dimensions and a 'double' - // element type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Array<2, double, MultiPatch > > a(layout); - ! Array<2, double, MultiPatch > > b(layout); - - // Set up the initial conditions. - --- 85,100 ---- - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire array domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // The template parameters indicate 2 dimensions and a 'double' - // element type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > a(layout); - ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > b(layout); - - // Set up the initial conditions. - *************** - *** 104,112 **** - - // Create the stencil performing the computation. - ! Stencil stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - --- 106,114 ---- - - // Create the stencil performing the computation. - ! Stencil<DoofNinePt> stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - *************** - *** 117,121 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 119,123 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The arrays are automatically deallocated. - *************** - *** 125,126 **** - --- 127,129 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: Doof2d-Array-element-annotated.patch =================================================================== RCS file: Doof2d-Array-element-annotated.patch diff -N Doof2d-Array-element-annotated.patch *** /tmp/cvsW8TBRh Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,143 **** - *** Doof2d-Array-element.cpp Tue Dec 4 12:02:10 2001 - --- Doof2d-Array-element-annotated.cpp Tue Dec 4 12:24:25 2001 - *************** - *** 1,5 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - ! #include "Pooma/Arrays.h" // has Pooma's Array - - // Doof2d: Pooma Arrays, element-wise implementation - --- 1,6 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - ! #include "Pooma/Arrays.h" // has Pooma's Array - - // Doof2d: Pooma Arrays, element-wise implementation - *************** - *** 7,17 **** - int main(int argc, char *argv[]) - { - ! // Prepare the Pooma library for execution. - Pooma::initialize(argc,argv); - - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 8,18 ---- - int main(int argc, char *argv[]) - { - ! // Prepare the Pooma library for execution. - Pooma::initialize(argc,argv); - - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,37 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - ! // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - for (int j = 1; j < n-1; j++) - for (int i = 1; i < n-1; i++) - --- 20,38 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - ! // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - for (int j = 1; j < n-1; j++) - for (int i = 1; i < n-1; i++) - *************** - *** 43,51 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - ! a(i,j) = weight * - (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + - b(i ,j+1) + b(i ,j ) + b(i ,j-1) + - --- 44,52 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - ! a(i,j) = weight * - (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + - b(i ,j+1) + b(i ,j ) + b(i ,j-1) + - *************** - *** 53,58 **** - - // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b(i,j) = weight * - (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + - --- 54,59 ---- - - // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b(i,j) = weight * - (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + - *************** - *** 62,71 **** - - // Print out the final central value. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - ! // The arrays are automatically deallocated. - - ! // Tell the Pooma library execution has finished. - Pooma::finalize(); - return EXIT_SUCCESS; - } - --- 63,74 ---- - - // Print out the final central value. - ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - ! // The arrays are automatically deallocated. - - ! // Tell the Pooma library execution has finished. - Pooma::finalize(); - return EXIT_SUCCESS; - } - + --- 0 ---- Index: Doof2d-Array-parallel-annotated.patch =================================================================== RCS file: Doof2d-Array-parallel-annotated.patch diff -N Doof2d-Array-parallel-annotated.patch *** /tmp/cvs0nlUsn Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,116 **** - *** Doof2d-Array-parallel.cpp Tue Dec 4 11:49:43 2001 - --- Doof2d-Array-parallel-annotated.cpp Tue Dec 4 12:24:36 2001 - *************** - *** 1,4 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - *************** - *** 12,17 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 13,18 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,43 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - // All grid values should be zero except for the central value. - a = b = 0.0; - ! // Ensure all data-parallel computation finishes before accessing a value. - Pooma::blockAndEvaluate(); - b(n/2,n/2) = 1000.0; - --- 20,44 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - // All grid values should be zero except for the central value. - a = b = 0.0; - ! // Ensure all data-parallel computation finishes before accessing a value. - Pooma::blockAndEvaluate(); - b(n/2,n/2) = 1000.0; - *************** - *** 47,52 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - --- 48,53 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - *************** - *** 63,67 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 64,68 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The arrays are automatically deallocated. - *************** - *** 71,72 **** - --- 72,74 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: Doof2d-Array-stencil-annotated.patch =================================================================== RCS file: Doof2d-Array-stencil-annotated.patch diff -N Doof2d-Array-stencil-annotated.patch *** /tmp/cvsERegQs Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,152 **** - *** Doof2d-Array-stencil.cpp Tue Dec 4 11:49:39 2001 - --- Doof2d-Array-stencil-annotated.cpp Tue Dec 4 12:26:46 2001 - *************** - *** 1,9 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - // Doof2d: Pooma Arrays, stencil implementation - - ! // Define the stencil class performing the computation. - class DoofNinePt - { - --- 1,10 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - // Doof2d: Pooma Arrays, stencil implementation - - ! // Define the stencil class performing the computation. - class DoofNinePt - { - *************** - *** 14,19 **** - // This stencil operator is applied to each interior domain position - // (i,j). The "C" template parameter permits use of this stencil - ! // operator with both Arrays and Fields. - ! template - inline - typename C::Element_t - --- 15,20 ---- - // This stencil operator is applied to each interior domain position - // (i,j). The "C" template parameter permits use of this stencil - ! // operator with both Arrays and Fields. - ! template <class C> - inline - typename C::Element_t - *************** - *** 26,30 **** - } - - ! inline int lowerExtent(int) const { return 1; } - inline int upperExtent(int) const { return 1; } - - --- 27,31 ---- - } - - ! inline int lowerExtent(int) const { return 1; } - inline int upperExtent(int) const { return 1; } - - *************** - *** 42,47 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 43,48 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 49,68 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - --- 50,69 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - *************** - *** 73,82 **** - b(n/2,n/2) = 1000.0; - - ! // Create the stencil performing the computation. - ! Stencil stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - --- 74,83 ---- - b(n/2,n/2) = 1000.0; - - ! // Create the stencil performing the computation. - ! Stencil<DoofNinePt> stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - *************** - *** 87,91 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 88,92 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The arrays are automatically deallocated. - *************** - *** 95,96 **** - --- 96,98 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: Doof2d-C-element-annotated.patch =================================================================== RCS file: Doof2d-C-element-annotated.patch diff -N Doof2d-C-element-annotated.patch *** /tmp/cvsgKf9Vx Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,150 **** - *** Doof2d-C-element.cpp Tue Nov 27 08:36:38 2001 - --- Doof2d-C-element-annotated.cpp Tue Nov 27 12:08:03 2001 - *************** - *** 1,4 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - - // Doof2d: C-like, element-wise implementation - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - - // Doof2d: C-like, element-wise implementation - *************** - *** 6,30 **** - int main() - { - ! // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - ! // Use two-dimensional grids of values. - double **a; - double **b; - - // Ask the user for the number n of elements along one dimension of - ! // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - ! // Allocate the arrays. - typedef double* doublePtr; - a = new doublePtr[n]; - b = new doublePtr[n]; - ! for (int i = 0; i < n; i++) { - a[i] = new double[n]; - b[i] = new double[n]; - --- 7,31 ---- - int main() - { - ! // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - ! // Use two-dimensional grids of values. - double **a; - double **b; - - // Ask the user for the number n of elements along one dimension of - ! // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - ! // Allocate the arrays. - typedef double* doublePtr; - a = new doublePtr[n]; - b = new doublePtr[n]; - ! for (int i = 0; i < n; i++) { - a[i] = new double[n]; - b[i] = new double[n]; - *************** - *** 32,49 **** - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - ! for (int j = 0; j < n; j++) - ! for (int i = 0; i < n; i++) - a[i][j] = b[i][j] = 0.0; - b[n/2][n/2] = 1000.0; - - ! // In the average, weight elements with this value. - const double weight = 1.0/9.0; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - a[i][j] = weight * - (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + - --- 33,50 ---- - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - ! for (int j = 0; j < n; j++) - ! for (int i = 0; i < n; i++) - a[i][j] = b[i][j] = 0.0; - b[n/2][n/2] = 1000.0; - - ! // In the average, weight elements with this value. - const double weight = 1.0/9.0; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - a[i][j] = weight * - (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + - *************** - *** 51,57 **** - b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); - - ! // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b[i][j] = weight * - (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + - --- 52,58 ---- - b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); - - ! // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b[i][j] = weight * - (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + - *************** - *** 60,68 **** - } - - ! // Print out the final central value. - ! std::cout << (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) << std::endl; - - ! // Deallocate the arrays. - ! for (int i = 0; i < n; i++) { - delete [] a[i]; - delete [] b[i]; - --- 61,69 ---- - } - - ! // Print out the final central value. - ! std::cout &openopen; (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) &openopen; std::endl; - - ! // Deallocate the arrays. - ! for (int i = 0; i < n; i++) { - delete [] a[i]; - delete [] b[i]; - *************** - *** 73,74 **** - --- 74,76 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: Doof2d-Field-distributed-annotated.patch =================================================================== RCS file: Doof2d-Field-distributed-annotated.patch diff -N Doof2d-Field-distributed-annotated.patch *** /tmp/cvsg1eoJC Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,176 **** - *** Doof2d-Field-distributed.cpp Wed Dec 5 14:05:10 2001 - --- Doof2d-Field-distributed-annotated.cpp Wed Dec 5 14:41:24 2001 - *************** - *** 1,3 **** - ! #include // has EXIT_SUCCESS - #include "Pooma/Fields.h" // has Pooma's Field - - --- 1,4 ---- - ! - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Fields.h" // has Pooma's Field - - *************** - *** 12,16 **** - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - --- 13,17 ---- - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - *************** - *** 18,22 **** - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; - return EXIT_FAILURE; - } - --- 19,23 ---- - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output &openopen; argv[0] &openopen; ": number-of-processors number-of-averagings number-of-values" &openopen; std::endl; - return EXIT_FAILURE; - } - *************** - *** 25,33 **** - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 26,34 ---- - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 35,39 **** - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - --- 36,40 ---- - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - *************** - *** 41,50 **** - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Partition the fields' domains uniformly, i.e., each patch has the - --- 42,51 ---- - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Partition the fields' domains uniformly, i.e., each patch has the - *************** - *** 52,74 **** - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire field domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // The template parameters indicate a mesh and a 'double' - // element type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Field, double, MultiPatch > > a(cell, layout, mesh); - ! Field, double, MultiPatch > > b(cell, layout, mesh); - - // Set up the initial conditions. - --- 53,75 ---- - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire field domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // The template parameters indicate a mesh and a 'double' - // element type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, - ! Remote<Brick> > > a(cell, layout, mesh); - ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, - ! Remote<Brick> > > b(cell, layout, mesh); - - // Set up the initial conditions. - *************** - *** 83,87 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - a(I,J) = weight * - --- 84,88 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - a(I,J) = weight * - *************** - *** 99,103 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The fields are automatically deallocated. - --- 100,104 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The fields are automatically deallocated. - *************** - *** 107,108 **** - --- 108,110 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: Doof2d-Field-parallel-annotated.patch =================================================================== RCS file: Doof2d-Field-parallel-annotated.patch diff -N Doof2d-Field-parallel-annotated.patch *** /tmp/cvsq9uXsJ Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,120 **** - *** Doof2d-Field-parallel.cpp Tue Dec 4 10:01:28 2001 - --- Doof2d-Field-parallel-annotated.cpp Tue Dec 4 11:04:26 2001 - *************** - *** 1,5 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - ! #include "Pooma/Fields.h" // has Pooma's Field - - // Doof2d: Pooma Fields, data-parallel implementation - --- 1,6 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - ! #include "Pooma/Fields.h" // has Pooma's Field - - // Doof2d: Pooma Fields, data-parallel implementation - *************** - *** 12,17 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 13,18 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,44 **** - // the grid. - long n; - ! std::cout << "Please enter the field size: "; - ! std::cin >> n; - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! DomainLayout<2> layout(vertDomain); - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // Create the fields. - // The template parameters indicate a mesh, a 'double' element - ! // type, and ordinary 'Brick' storage. - ! Field, double, Brick> a(cell, layout, mesh); - ! Field, double, Brick> b(cell, layout, mesh); - - // Set up the initial conditions. - --- 20,45 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the field size: "; - ! std::cin &closeclose; n; - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! DomainLayout<2> layout(vertDomain); - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // Create the fields. - // The template parameters indicate a mesh, a 'double' element - ! // type, and ordinary 'Brick' storage. - ! Field<UniformRectilinearMesh<2>, double, Brick> a(cell, layout, mesh); - ! Field<UniformRectilinearMesh<2>, double, Brick> b(cell, layout, mesh); - - // Set up the initial conditions. - *************** - *** 51,56 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - --- 52,57 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - *************** - *** 67,71 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The fields are automatically deallocated. - --- 68,72 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The fields are automatically deallocated. - *************** - *** 75,76 **** - --- 76,78 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: Makefile =================================================================== RCS file: Makefile diff -N Makefile *** /tmp/cvsgROIRP Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,13 **** - ### Oldham, Jeffrey D. - ### 2001Nov27 - ### Pooma - ### - ### Produce Annotated Source Code - - all: Doof2d-C-element-annotated.cpp Doof2d-Array-element-annotated.cpp \ - Doof2d-Array-parallel-annotated.cpp Doof2d-Array-stencil-annotated.cpp \ - Doof2d-Array-distributed-annotated.cpp \ - Doof2d-Field-parallel-annotated.cpp Doof2d-Field-distributed-annotated.cpp - - %-annotated.cpp: %-annotated.patch %.cpp - patch -o $@ < $< --- 0 ---- Index: initialize-finalize-annotated.patch =================================================================== RCS file: initialize-finalize-annotated.patch diff -N initialize-finalize-annotated.patch *** /tmp/cvs6U9YaW Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,14 **** - *** initialize-finalize.cpp Sat Dec 15 15:35:57 2001 - --- initialize-finalize-annotated.cpp Sun Dec 16 14:24:43 2001 - *************** - *** 1,2 **** - --- 1,3 ---- - + - #include "Pooma/Pooma.h" - - *************** - *** 10,11 **** - --- 11,13 ---- - return 0; - } - + --- 0 ---- Index: pairs-templated-annotated.patch =================================================================== RCS file: pairs-templated-annotated.patch diff -N pairs-templated-annotated.patch *** /tmp/cvsucf6o2 Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,37 **** - *** pairs-templated.cpp Wed Dec 26 14:01:38 2001 - --- pairs-templated-annotated.cpp Wed Dec 26 14:12:51 2001 - *************** - *** 1,15 **** - ! // Declare a template class storing a pair of values with the same type. - ! template - struct pair { - ! pair(const int& left, const int& right) - : left_(left), right_(right) {} - - ! T left_; - T right_; - }; - - ! // Use a class storing a pair of integers. - ! pair pair1; - - // Use a class storing a pair of doubles; - ! pair pair2; - --- 1,17 ---- - ! - ! // Declare a template class storing a pair of values with the same type. - ! template <typename T> - struct pair { - ! pair(const T& left, const T& right) // - : left_(left), right_(right) {} - - ! T left_; // - T right_; - }; - - ! // Use a class storing a pair of integers. - ! pair<int> pair1; - - // Use a class storing a pair of doubles; - ! pair<double> pair2; - ! --- 0 ---- Index: pairs-untemplated-annotated.patch =================================================================== RCS file: pairs-untemplated-annotated.patch diff -N pairs-untemplated-annotated.patch *** /tmp/cvsqR3av8 Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,35 **** - *** pairs-untemplated.cpp Wed Dec 26 13:48:10 2001 - --- pairs-untemplated-annotated.cpp Wed Dec 26 14:02:58 2001 - *************** - *** 1,5 **** - // Declare a class storing a pair of integers. - struct pairOfInts { - ! pairOfInts(const int& left, const int& right) - : left_(left), right_(right) {} - - --- 1,6 ---- - + - // Declare a class storing a pair of integers. - struct pairOfInts { - ! pairOfInts(const int& left, const int& right) - : left_(left), right_(right) {} - - *************** - *** 10,14 **** - // Declare a class storing a pair of doubles. - struct pairOfDoubles { - ! pairOfDoubles(const double& left, const double& right) - : left_(left), right_(right) {} - - --- 11,15 ---- - // Declare a class storing a pair of doubles. - struct pairOfDoubles { - ! pairOfDoubles(const double& left, const double& right) - : left_(left), right_(right) {} - - *************** - *** 16,17 **** - --- 17,19 ---- - double right_; - }; - + --- 0 ---- Index: examples/Doof2d-Array-distributed-annotated.patch =================================================================== RCS file: Doof2d-Array-distributed-annotated.patch diff -N Doof2d-Array-distributed-annotated.patch *** /tmp/cvsSYg3pe Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,184 **** - *** Doof2d-Array-distributed.cpp Wed Dec 5 14:04:36 2001 - --- Doof2d-Array-distributed-annotated.cpp Wed Dec 5 14:07:56 2001 - *************** - *** 1,3 **** - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - *************** - *** 14,18 **** - // (i,j). The "C" template parameter permits use of this stencil - // operator with both Arrays and Fields. - ! template - inline - typename C::Element_t - --- 16,20 ---- - // (i,j). The "C" template parameter permits use of this stencil - // operator with both Arrays and Fields. - ! template <class C> - inline - typename C::Element_t - *************** - *** 42,46 **** - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - --- 44,48 ---- - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - *************** - *** 48,52 **** - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; - return EXIT_FAILURE; - } - --- 50,54 ---- - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output &openopen; argv[0] &openopen; ": number-of-processors number-of-averagings number-of-values" &openopen; std::endl; - return EXIT_FAILURE; - } - *************** - *** 55,63 **** - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 57,65 ---- - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 65,69 **** - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - --- 67,71 ---- - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - *************** - *** 71,80 **** - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the distributed arrays. - --- 73,82 ---- - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the distributed arrays. - *************** - *** 83,98 **** - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire array domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // The template parameters indicate 2 dimensions and a 'double' - // element type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Array<2, double, MultiPatch > > a(layout); - ! Array<2, double, MultiPatch > > b(layout); - - // Set up the initial conditions. - --- 85,100 ---- - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire array domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // The template parameters indicate 2 dimensions and a 'double' - // element type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > a(layout); - ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > b(layout); - - // Set up the initial conditions. - *************** - *** 104,112 **** - - // Create the stencil performing the computation. - ! Stencil stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - --- 106,114 ---- - - // Create the stencil performing the computation. - ! Stencil<DoofNinePt> stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - *************** - *** 117,121 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 119,123 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The arrays are automatically deallocated. - *************** - *** 125,126 **** - --- 127,129 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Doof2d-Array-element-annotated.patch =================================================================== RCS file: Doof2d-Array-element-annotated.patch diff -N Doof2d-Array-element-annotated.patch *** /tmp/cvs0NfShm Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,143 **** - *** Doof2d-Array-element.cpp Tue Dec 4 12:02:10 2001 - --- Doof2d-Array-element-annotated.cpp Tue Dec 4 12:24:25 2001 - *************** - *** 1,5 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - ! #include "Pooma/Arrays.h" // has Pooma's Array - - // Doof2d: Pooma Arrays, element-wise implementation - --- 1,6 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - ! #include "Pooma/Arrays.h" // has Pooma's Array - - // Doof2d: Pooma Arrays, element-wise implementation - *************** - *** 7,17 **** - int main(int argc, char *argv[]) - { - ! // Prepare the Pooma library for execution. - Pooma::initialize(argc,argv); - - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 8,18 ---- - int main(int argc, char *argv[]) - { - ! // Prepare the Pooma library for execution. - Pooma::initialize(argc,argv); - - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,37 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - ! // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - for (int j = 1; j < n-1; j++) - for (int i = 1; i < n-1; i++) - --- 20,38 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - ! // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - for (int j = 1; j < n-1; j++) - for (int i = 1; i < n-1; i++) - *************** - *** 43,51 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - ! a(i,j) = weight * - (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + - b(i ,j+1) + b(i ,j ) + b(i ,j-1) + - --- 44,52 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - ! a(i,j) = weight * - (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + - b(i ,j+1) + b(i ,j ) + b(i ,j-1) + - *************** - *** 53,58 **** - - // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b(i,j) = weight * - (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + - --- 54,59 ---- - - // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b(i,j) = weight * - (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + - *************** - *** 62,71 **** - - // Print out the final central value. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - ! // The arrays are automatically deallocated. - - ! // Tell the Pooma library execution has finished. - Pooma::finalize(); - return EXIT_SUCCESS; - } - --- 63,74 ---- - - // Print out the final central value. - ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - ! // The arrays are automatically deallocated. - - ! // Tell the Pooma library execution has finished. - Pooma::finalize(); - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Doof2d-Array-parallel-annotated.patch =================================================================== RCS file: Doof2d-Array-parallel-annotated.patch diff -N Doof2d-Array-parallel-annotated.patch *** /tmp/cvsaOFKTt Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,116 **** - *** Doof2d-Array-parallel.cpp Tue Dec 4 11:49:43 2001 - --- Doof2d-Array-parallel-annotated.cpp Tue Dec 4 12:24:36 2001 - *************** - *** 1,4 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - *************** - *** 12,17 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 13,18 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,43 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - // All grid values should be zero except for the central value. - a = b = 0.0; - ! // Ensure all data-parallel computation finishes before accessing a value. - Pooma::blockAndEvaluate(); - b(n/2,n/2) = 1000.0; - --- 20,44 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - // All grid values should be zero except for the central value. - a = b = 0.0; - ! // Ensure all data-parallel computation finishes before accessing a value. - Pooma::blockAndEvaluate(); - b(n/2,n/2) = 1000.0; - *************** - *** 47,52 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - --- 48,53 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - *************** - *** 63,67 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 64,68 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The arrays are automatically deallocated. - *************** - *** 71,72 **** - --- 72,74 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Doof2d-Array-stencil-annotated.patch =================================================================== RCS file: Doof2d-Array-stencil-annotated.patch diff -N Doof2d-Array-stencil-annotated.patch *** /tmp/cvs4b053A Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,152 **** - *** Doof2d-Array-stencil.cpp Tue Dec 4 11:49:39 2001 - --- Doof2d-Array-stencil-annotated.cpp Tue Dec 4 12:26:46 2001 - *************** - *** 1,9 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - // Doof2d: Pooma Arrays, stencil implementation - - ! // Define the stencil class performing the computation. - class DoofNinePt - { - --- 1,10 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has Pooma's Array - - // Doof2d: Pooma Arrays, stencil implementation - - ! // Define the stencil class performing the computation. - class DoofNinePt - { - *************** - *** 14,19 **** - // This stencil operator is applied to each interior domain position - // (i,j). The "C" template parameter permits use of this stencil - ! // operator with both Arrays and Fields. - ! template - inline - typename C::Element_t - --- 15,20 ---- - // This stencil operator is applied to each interior domain position - // (i,j). The "C" template parameter permits use of this stencil - ! // operator with both Arrays and Fields. - ! template <class C> - inline - typename C::Element_t - *************** - *** 26,30 **** - } - - ! inline int lowerExtent(int) const { return 1; } - inline int upperExtent(int) const { return 1; } - - --- 27,31 ---- - } - - ! inline int lowerExtent(int) const { return 1; } - inline int upperExtent(int) const { return 1; } - - *************** - *** 42,47 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 43,48 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 49,68 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - --- 50,69 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the arrays. - // The template parameters indicate 2 dimensions, a 'double' element - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - *************** - *** 73,82 **** - b(n/2,n/2) = 1000.0; - - ! // Create the stencil performing the computation. - ! Stencil stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - --- 74,83 ---- - b(n/2,n/2) = 1000.0; - - ! // Create the stencil performing the computation. - ! Stencil<DoofNinePt> stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - *************** - *** 87,91 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 88,92 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The arrays are automatically deallocated. - *************** - *** 95,96 **** - --- 96,98 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Doof2d-C-element-annotated.patch =================================================================== RCS file: Doof2d-C-element-annotated.patch diff -N Doof2d-C-element-annotated.patch *** /tmp/cvsCww7hK Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,150 **** - *** Doof2d-C-element.cpp Tue Nov 27 08:36:38 2001 - --- Doof2d-C-element-annotated.cpp Tue Nov 27 12:08:03 2001 - *************** - *** 1,4 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - - // Doof2d: C-like, element-wise implementation - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - - // Doof2d: C-like, element-wise implementation - *************** - *** 6,30 **** - int main() - { - ! // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - ! // Use two-dimensional grids of values. - double **a; - double **b; - - // Ask the user for the number n of elements along one dimension of - ! // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - ! // Allocate the arrays. - typedef double* doublePtr; - a = new doublePtr[n]; - b = new doublePtr[n]; - ! for (int i = 0; i < n; i++) { - a[i] = new double[n]; - b[i] = new double[n]; - --- 7,31 ---- - int main() - { - ! // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - ! // Use two-dimensional grids of values. - double **a; - double **b; - - // Ask the user for the number n of elements along one dimension of - ! // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - ! // Allocate the arrays. - typedef double* doublePtr; - a = new doublePtr[n]; - b = new doublePtr[n]; - ! for (int i = 0; i < n; i++) { - a[i] = new double[n]; - b[i] = new double[n]; - *************** - *** 32,49 **** - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - ! for (int j = 0; j < n; j++) - ! for (int i = 0; i < n; i++) - a[i][j] = b[i][j] = 0.0; - b[n/2][n/2] = 1000.0; - - ! // In the average, weight elements with this value. - const double weight = 1.0/9.0; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - a[i][j] = weight * - (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + - --- 33,50 ---- - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - ! for (int j = 0; j < n; j++) - ! for (int i = 0; i < n; i++) - a[i][j] = b[i][j] = 0.0; - b[n/2][n/2] = 1000.0; - - ! // In the average, weight elements with this value. - const double weight = 1.0/9.0; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - a[i][j] = weight * - (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + - *************** - *** 51,57 **** - b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); - - ! // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b[i][j] = weight * - (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + - --- 52,58 ---- - b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); - - ! // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b[i][j] = weight * - (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + - *************** - *** 60,68 **** - } - - ! // Print out the final central value. - ! std::cout << (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) << std::endl; - - ! // Deallocate the arrays. - ! for (int i = 0; i < n; i++) { - delete [] a[i]; - delete [] b[i]; - --- 61,69 ---- - } - - ! // Print out the final central value. - ! std::cout &openopen; (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) &openopen; std::endl; - - ! // Deallocate the arrays. - ! for (int i = 0; i < n; i++) { - delete [] a[i]; - delete [] b[i]; - *************** - *** 73,74 **** - --- 74,76 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Doof2d-Field-distributed-annotated.patch =================================================================== RCS file: Doof2d-Field-distributed-annotated.patch diff -N Doof2d-Field-distributed-annotated.patch *** /tmp/cvswwII7S Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,176 **** - *** Doof2d-Field-distributed.cpp Wed Dec 5 14:05:10 2001 - --- Doof2d-Field-distributed-annotated.cpp Wed Dec 5 14:41:24 2001 - *************** - *** 1,3 **** - ! #include // has EXIT_SUCCESS - #include "Pooma/Fields.h" // has Pooma's Field - - --- 1,4 ---- - ! - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Fields.h" // has Pooma's Field - - *************** - *** 12,16 **** - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - --- 13,17 ---- - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - *************** - *** 18,22 **** - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; - return EXIT_FAILURE; - } - --- 19,23 ---- - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output &openopen; argv[0] &openopen; ": number-of-processors number-of-averagings number-of-values" &openopen; std::endl; - return EXIT_FAILURE; - } - *************** - *** 25,33 **** - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 26,34 ---- - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 35,39 **** - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - --- 36,40 ---- - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - *************** - *** 41,50 **** - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Partition the fields' domains uniformly, i.e., each patch has the - --- 42,51 ---- - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Partition the fields' domains uniformly, i.e., each patch has the - *************** - *** 52,74 **** - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire field domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // The template parameters indicate a mesh and a 'double' - // element type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Field, double, MultiPatch > > a(cell, layout, mesh); - ! Field, double, MultiPatch > > b(cell, layout, mesh); - - // Set up the initial conditions. - --- 53,75 ---- - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire field domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // The template parameters indicate a mesh and a 'double' - // element type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, - ! Remote<Brick> > > a(cell, layout, mesh); - ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, - ! Remote<Brick> > > b(cell, layout, mesh); - - // Set up the initial conditions. - *************** - *** 83,87 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - a(I,J) = weight * - --- 84,88 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - a(I,J) = weight * - *************** - *** 99,103 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The fields are automatically deallocated. - --- 100,104 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The fields are automatically deallocated. - *************** - *** 107,108 **** - --- 108,110 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Doof2d-Field-parallel-annotated.patch =================================================================== RCS file: Doof2d-Field-parallel-annotated.patch diff -N Doof2d-Field-parallel-annotated.patch *** /tmp/cvsOaLly1 Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,120 **** - *** Doof2d-Field-parallel.cpp Tue Dec 4 10:01:28 2001 - --- Doof2d-Field-parallel-annotated.cpp Tue Dec 4 11:04:26 2001 - *************** - *** 1,5 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - ! #include "Pooma/Fields.h" // has Pooma's Field - - // Doof2d: Pooma Fields, data-parallel implementation - --- 1,6 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - ! #include "Pooma/Fields.h" // has Pooma's Field - - // Doof2d: Pooma Fields, data-parallel implementation - *************** - *** 12,17 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 13,18 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,44 **** - // the grid. - long n; - ! std::cout << "Please enter the field size: "; - ! std::cin >> n; - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! DomainLayout<2> layout(vertDomain); - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // Create the fields. - // The template parameters indicate a mesh, a 'double' element - ! // type, and ordinary 'Brick' storage. - ! Field, double, Brick> a(cell, layout, mesh); - ! Field, double, Brick> b(cell, layout, mesh); - - // Set up the initial conditions. - --- 20,45 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the field size: "; - ! std::cin &closeclose; n; - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! DomainLayout<2> layout(vertDomain); - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // Create the fields. - // The template parameters indicate a mesh, a 'double' element - ! // type, and ordinary 'Brick' storage. - ! Field<UniformRectilinearMesh<2>, double, Brick> a(cell, layout, mesh); - ! Field<UniformRectilinearMesh<2>, double, Brick> b(cell, layout, mesh); - - // Set up the initial conditions. - *************** - *** 51,56 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - --- 52,57 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - *************** - *** 67,71 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The fields are automatically deallocated. - --- 68,72 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The fields are automatically deallocated. - *************** - *** 75,76 **** - --- 76,78 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Makefile =================================================================== RCS file: Makefile diff -N Makefile *** /tmp/cvsca9QN9 Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,13 **** - ### Oldham, Jeffrey D. - ### 2001Nov27 - ### Pooma - ### - ### Produce Annotated Source Code - - all: Doof2d-C-element-annotated.cpp Doof2d-Array-element-annotated.cpp \ - Doof2d-Array-parallel-annotated.cpp Doof2d-Array-stencil-annotated.cpp \ - Doof2d-Array-distributed-annotated.cpp \ - Doof2d-Field-parallel-annotated.cpp Doof2d-Field-distributed-annotated.cpp - - %-annotated.cpp: %-annotated.patch %.cpp - patch -o $@ < $< --- 0 ---- Index: examples/initialize-finalize-annotated.patch =================================================================== RCS file: initialize-finalize-annotated.patch diff -N initialize-finalize-annotated.patch *** /tmp/cvsQZFDjk Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,14 **** - *** initialize-finalize.cpp Sat Dec 15 15:35:57 2001 - --- initialize-finalize-annotated.cpp Sun Dec 16 14:24:43 2001 - *************** - *** 1,2 **** - --- 1,3 ---- - + - #include "Pooma/Pooma.h" - - *************** - *** 10,11 **** - --- 11,13 ---- - return 0; - } - + --- 0 ---- Index: examples/pairs-templated-annotated.patch =================================================================== RCS file: pairs-templated-annotated.patch diff -N pairs-templated-annotated.patch *** /tmp/cvsWpEoKu Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,37 **** - *** pairs-templated.cpp Wed Dec 26 14:01:38 2001 - --- pairs-templated-annotated.cpp Wed Dec 26 14:12:51 2001 - *************** - *** 1,15 **** - ! // Declare a template class storing a pair of values with the same type. - ! template - struct pair { - ! pair(const int& left, const int& right) - : left_(left), right_(right) {} - - ! T left_; - T right_; - }; - - ! // Use a class storing a pair of integers. - ! pair pair1; - - // Use a class storing a pair of doubles; - ! pair pair2; - --- 1,17 ---- - ! - ! // Declare a template class storing a pair of values with the same type. - ! template <typename T> - struct pair { - ! pair(const T& left, const T& right) // - : left_(left), right_(right) {} - - ! T left_; // - T right_; - }; - - ! // Use a class storing a pair of integers. - ! pair<int> pair1; - - // Use a class storing a pair of doubles; - ! pair<double> pair2; - ! --- 0 ---- Index: examples/pairs-untemplated-annotated.patch =================================================================== RCS file: pairs-untemplated-annotated.patch diff -N pairs-untemplated-annotated.patch *** /tmp/cvse4E61E Thu Jan 24 20:22:23 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,35 **** - *** pairs-untemplated.cpp Wed Dec 26 13:48:10 2001 - --- pairs-untemplated-annotated.cpp Wed Dec 26 14:02:58 2001 - *************** - *** 1,5 **** - // Declare a class storing a pair of integers. - struct pairOfInts { - ! pairOfInts(const int& left, const int& right) - : left_(left), right_(right) {} - - --- 1,6 ---- - + - // Declare a class storing a pair of integers. - struct pairOfInts { - ! pairOfInts(const int& left, const int& right) - : left_(left), right_(right) {} - - *************** - *** 10,14 **** - // Declare a class storing a pair of doubles. - struct pairOfDoubles { - ! pairOfDoubles(const double& left, const double& right) - : left_(left), right_(right) {} - - --- 11,15 ---- - // Declare a class storing a pair of doubles. - struct pairOfDoubles { - ! pairOfDoubles(const double& left, const double& right) - : left_(left), right_(right) {} - - *************** - *** 16,17 **** - --- 17,19 ---- - double right_; - }; - + --- 0 ---- Index: examples/Doof2d/Doof2d-Array-distributed-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Doof2d-Array-distributed-annotated.patch,v retrieving revision 1.4 diff -c -p -r1.4 Doof2d-Array-distributed-annotated.patch *** examples/Doof2d/Doof2d-Array-distributed-annotated.patch 2002/01/04 18:00:02 1.4 --- examples/Doof2d/Doof2d-Array-distributed-annotated.patch 2002/01/25 03:22:23 *************** *** 3,15 **** *************** *** 1,3 **** ! #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has Pooma's Array --- 1,5 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has Pooma's Array *************** *** 14,18 **** --- 3,15 ---- *************** *** 1,3 **** ! #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations --- 1,5 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations *************** *** 14,18 **** *************** *** 117,124 **** ! GuardLayers<2>(0)); // external ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); ! // The template parameters indicate 2 dimensions and a 'double' ! // element type. MultiPatch indicates multiple computation patches, // i.e., distributed computation. The UniformTag indicates the ! // patches should have the same size. Each patch has Brick type. ! Array<2, double, MultiPatch > > a(layout); --- 117,124 ---- ! GuardLayers<2>(0)); // external ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); ! // The Array template parameters indicate 2 dimensions and a 'double' ! // value type. MultiPatch indicates multiple computation patches, // i.e., distributed computation. The UniformTag indicates the ! // patches should have the same size. Each patch has Brick type. ! Array<2, double, MultiPatch > > a(layout); *************** *** 134,141 **** ! GuardLayers<2>(0)); // external ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); ! // The template parameters indicate 2 dimensions and a 'double' ! // element type. MultiPatch indicates multiple computation patches, // i.e., distributed computation. The UniformTag indicates the ! // patches should have the same size. Each patch has Brick type. ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > a(layout); --- 134,141 ---- ! GuardLayers<2>(0)); // external ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); ! // The Array template parameters indicate 2 dimensions and a 'double' ! // value type. MultiPatch indicates multiple computation patches, // i.e., distributed computation. The UniformTag indicates the ! // patches should have the same size. Each patch has Brick type. ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > a(layout); Index: examples/Doof2d/Doof2d-Array-element-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Doof2d-Array-element-annotated.patch,v retrieving revision 1.4 diff -c -p -r1.4 Doof2d-Array-element-annotated.patch *** examples/Doof2d/Doof2d-Array-element-annotated.patch 2002/01/04 18:00:02 1.4 --- examples/Doof2d/Doof2d-Array-element-annotated.patch 2002/01/25 03:22:23 *************** *** 1,24 **** *** Doof2d-Array-element.cpp Tue Dec 4 12:02:10 2001 ! --- Doof2d-Array-element-annotated.cpp Tue Dec 4 12:24:25 2001 *************** *** 1,5 **** ! #include // has std::cout, ... ! #include // has EXIT_SUCCESS ! ! #include "Pooma/Arrays.h" // has Pooma's Array ! // Doof2d: Pooma Arrays, element-wise implementation --- 1,6 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! ! #include "Pooma/Arrays.h" // has Pooma's Array ! // Doof2d: Pooma Arrays, element-wise implementation *************** *** 7,17 **** int main(int argc, char *argv[]) { ! ! // Prepare the Pooma library for execution. Pooma::initialize(argc,argv); // Ask the user for the number of averagings. --- 1,24 ---- *** Doof2d-Array-element.cpp Tue Dec 4 12:02:10 2001 ! --- Doof2d-Array-element-annotated.cpp Wed Jan 23 16:35:29 2002 *************** *** 1,5 **** ! #include // has std::cout, ... ! #include // has EXIT_SUCCESS ! ! #include "Pooma/Arrays.h" // has POOMA's Array declarations ! // Doof2d: POOMA Arrays, element-wise implementation --- 1,6 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! ! #include "Pooma/Arrays.h" // has POOMA's Array declarations ! // Doof2d: POOMA Arrays, element-wise implementation *************** *** 7,17 **** int main(int argc, char *argv[]) { ! ! // Prepare the POOMA library for execution. Pooma::initialize(argc,argv); // Ask the user for the number of averagings. *************** *** 30,36 **** --- 8,18 ---- int main(int argc, char *argv[]) { ! ! // Prepare the Pooma library for execution. Pooma::initialize(argc,argv); // Ask the user for the number of averagings. --- 30,36 ---- --- 8,18 ---- int main(int argc, char *argv[]) { ! ! // Prepare the POOMA library for execution. Pooma::initialize(argc,argv); // Ask the user for the number of averagings. *************** *** 51,57 **** ! Interval<2> vertDomain(N, N); ! // Create the arrays. ! // The template parameters indicate 2 dimensions, a 'double' element // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); --- 51,57 ---- ! Interval<2> vertDomain(N, N); ! // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); *************** *** 71,77 **** ! Interval<2> vertDomain(N, N); ! // Create the arrays. ! // The template parameters indicate 2 dimensions, a 'double' element // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); --- 71,77 ---- ! Interval<2> vertDomain(N, N); ! // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); *************** *** 124,130 **** ! // The arrays are automatically deallocated. ! ! // Tell the Pooma library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } --- 124,130 ---- ! // The arrays are automatically deallocated. ! ! // Tell the POOMA library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } *************** *** 136,142 **** ! // The arrays are automatically deallocated. ! ! // Tell the Pooma library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } --- 136,142 ---- ! // The arrays are automatically deallocated. ! ! // Tell the POOMA library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } Index: examples/Doof2d/Doof2d-Array-parallel-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Doof2d-Array-parallel-annotated.patch,v retrieving revision 1.4 diff -c -p -r1.4 Doof2d-Array-parallel-annotated.patch *** examples/Doof2d/Doof2d-Array-parallel-annotated.patch 2002/01/04 18:00:02 1.4 --- examples/Doof2d/Doof2d-Array-parallel-annotated.patch 2002/01/25 03:22:23 *************** *** 1,16 **** *** Doof2d-Array-parallel.cpp Tue Dec 4 11:49:43 2001 ! --- Doof2d-Array-parallel-annotated.cpp Tue Dec 4 12:24:36 2001 *************** *** 1,4 **** ! #include // has std::cout, ... ! #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has Pooma's Array --- 1,5 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has Pooma's Array *************** *** 12,17 **** --- 1,16 ---- *** Doof2d-Array-parallel.cpp Tue Dec 4 11:49:43 2001 ! --- Doof2d-Array-parallel-annotated.cpp Wed Jan 23 16:35:54 2002 *************** *** 1,4 **** ! #include // has std::cout, ... ! #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations --- 1,5 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations *************** *** 12,17 **** *************** *** 43,49 **** ! Interval<1> J(1,n-2); // Create the arrays. ! // The template parameters indicate 2 dimensions, a 'double' element // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); --- 43,49 ---- ! Interval<1> J(1,n-2); // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); *************** *** 69,75 **** ! Interval<1> J(1,n-2); // Create the arrays. ! // The template parameters indicate 2 dimensions, a 'double' element // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); --- 69,75 ---- ! Interval<1> J(1,n-2); // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); Index: examples/Doof2d/Doof2d-Array-stencil-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Doof2d-Array-stencil-annotated.patch,v retrieving revision 1.4 diff -c -p -r1.4 Doof2d-Array-stencil-annotated.patch *** examples/Doof2d/Doof2d-Array-stencil-annotated.patch 2002/01/04 18:00:02 1.4 --- examples/Doof2d/Doof2d-Array-stencil-annotated.patch 2002/01/25 03:22:23 *************** *** 1,12 **** *** Doof2d-Array-stencil.cpp Tue Dec 4 11:49:39 2001 ! --- Doof2d-Array-stencil-annotated.cpp Tue Dec 4 12:26:46 2001 *************** *** 1,9 **** ! #include // has std::cout, ... ! #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has Pooma's Array ! // Doof2d: Pooma Arrays, stencil implementation ! // Define the stencil class performing the computation. class DoofNinePt --- 1,12 ---- *** Doof2d-Array-stencil.cpp Tue Dec 4 11:49:39 2001 ! --- Doof2d-Array-stencil-annotated.cpp Wed Jan 23 16:36:15 2002 *************** *** 1,9 **** ! #include // has std::cout, ... ! #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations ! // Doof2d: POOMA Arrays, stencil implementation ! // Define the stencil class performing the computation. class DoofNinePt *************** *** 15,23 **** ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has Pooma's Array ! // Doof2d: Pooma Arrays, stencil implementation ! // Define the stencil class performing the computation. class DoofNinePt --- 15,23 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations ! // Doof2d: POOMA Arrays, stencil implementation ! // Define the stencil class performing the computation. class DoofNinePt *************** *** 81,87 **** ! Interval<2> interiorDomain(I,I); // Create the arrays. ! // The template parameters indicate 2 dimensions, a 'double' element // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); --- 81,87 ---- ! Interval<2> interiorDomain(I,I); // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); *************** *** 102,108 **** ! Interval<2> interiorDomain(I,I); // Create the arrays. ! // The template parameters indicate 2 dimensions, a 'double' element // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); --- 102,108 ---- ! Interval<2> interiorDomain(I,I); // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); Index: examples/Doof2d/Doof2d-C-element-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Doof2d-C-element-annotated.patch,v retrieving revision 1.4 diff -c -p -r1.4 Doof2d-C-element-annotated.patch *** examples/Doof2d/Doof2d-C-element-annotated.patch 2002/01/04 18:00:02 1.4 --- examples/Doof2d/Doof2d-C-element-annotated.patch 2002/01/25 03:22:23 *************** *** 1,5 **** ! *** Doof2d-C-element.cpp Tue Nov 27 08:36:38 2001 ! --- Doof2d-C-element-annotated.cpp Tue Nov 27 12:08:03 2001 *************** *** 1,4 **** ! #include // has std::cout, ... --- 1,5 ---- ! *** Doof2d-C-element.cpp Tue Dec 4 09:59:18 2001 ! --- Doof2d-C-element-annotated.cpp Wed Jan 23 16:34:20 2002 *************** *** 1,4 **** ! #include // has std::cout, ... *************** *** 26,32 **** double **a; double **b; ! // Ask the user for the number n of elements along one dimension of ! // the grid. long n; ! std::cout << "Please enter the array size: "; --- 26,32 ---- double **a; double **b; ! // Ask the user for the number n of values along one dimension of ! // the grid. long n; ! std::cout << "Please enter the array size: "; *************** *** 52,58 **** double **a; double **b; ! // Ask the user for the number n of elements along one dimension of ! // the grid. long n; ! std::cout &openopen; "Please enter the array size: "; --- 52,58 ---- double **a; double **b; ! // Ask the user for the number n of values along one dimension of ! // the grid. long n; ! std::cout &openopen; "Please enter the array size: "; Index: examples/Doof2d/Doof2d-Field-distributed-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Doof2d-Field-distributed-annotated.patch,v retrieving revision 1.3 diff -c -p -r1.3 Doof2d-Field-distributed-annotated.patch *** examples/Doof2d/Doof2d-Field-distributed-annotated.patch 2002/01/04 18:00:02 1.3 --- examples/Doof2d/Doof2d-Field-distributed-annotated.patch 2002/01/25 03:22:23 *************** *** 1,14 **** *** Doof2d-Field-distributed.cpp Wed Dec 5 14:05:10 2001 ! --- Doof2d-Field-distributed-annotated.cpp Wed Dec 5 14:41:24 2001 *************** *** 1,3 **** ! #include // has EXIT_SUCCESS ! #include "Pooma/Fields.h" // has Pooma's Field --- 1,4 ---- ! ! #include <stdlib.h> // has EXIT_SUCCESS ! #include "Pooma/Fields.h" // has Pooma's Field *************** *** 12,16 **** --- 1,14 ---- *** Doof2d-Field-distributed.cpp Wed Dec 5 14:05:10 2001 ! --- Doof2d-Field-distributed-annotated.cpp Wed Jan 23 16:36:34 2002 *************** *** 1,3 **** ! #include // has EXIT_SUCCESS ! #include "Pooma/Fields.h" // has POOMA's Field declarations --- 1,4 ---- ! ! #include <stdlib.h> // has EXIT_SUCCESS ! #include "Pooma/Fields.h" // has POOMA's Field declarations *************** *** 12,16 **** *************** *** 108,115 **** ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); ! // The template parameters indicate a mesh and a 'double' ! // element type. MultiPatch indicates multiple computation patches, // i.e., distributed computation. The UniformTag indicates the ! // patches should have the same size. Each patch has Brick type. ! Field, double, MultiPatch mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); ! // The Field template parameters indicate a mesh and a 'double' ! // value type. MultiPatch indicates multiple computation patches, // i.e., distributed computation. The UniformTag indicates the ! // patches should have the same size. Each patch has Brick type. ! Field, double, MultiPatch ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, --- 132,139 ---- ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); ! // The Field template parameters indicate a mesh and a 'double' ! // value type. MultiPatch indicates multiple computation patches, // i.e., distributed computation. The UniformTag indicates the ! // patches should have the same size. Each patch has Brick type. ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, Index: examples/Doof2d/Doof2d-Field-parallel-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Doof2d-Field-parallel-annotated.patch,v retrieving revision 1.3 diff -c -p -r1.3 Doof2d-Field-parallel-annotated.patch *** examples/Doof2d/Doof2d-Field-parallel-annotated.patch 2002/01/04 18:00:02 1.3 --- examples/Doof2d/Doof2d-Field-parallel-annotated.patch 2002/01/25 03:22:23 *************** *** 1,19 **** ! *** Doof2d-Field-parallel.cpp Tue Dec 4 10:01:28 2001 ! --- Doof2d-Field-parallel-annotated.cpp Tue Dec 4 11:04:26 2001 *************** *** 1,5 **** ! #include // has std::cout, ... ! #include // has EXIT_SUCCESS ! ! #include "Pooma/Fields.h" // has Pooma's Field ! // Doof2d: Pooma Fields, data-parallel implementation --- 1,6 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! ! #include "Pooma/Fields.h" // has Pooma's Field ! // Doof2d: Pooma Fields, data-parallel implementation *************** *** 12,17 **** // Ask the user for the number of averagings. --- 1,19 ---- ! *** Doof2d-Field-parallel.cpp Tue Dec 4 11:47:58 2001 ! --- Doof2d-Field-parallel-annotated.cpp Wed Jan 23 16:37:19 2002 *************** *** 1,5 **** ! #include // has std::cout, ... ! #include // has EXIT_SUCCESS ! ! #include "Pooma/Fields.h" // has POOMA's Field declarations ! // Doof2d: POOMA Fields, data-parallel implementation --- 1,6 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! ! #include "Pooma/Fields.h" // has POOMA's Field declarations ! // Doof2d: POOMA Fields, data-parallel implementation *************** *** 12,17 **** // Ask the user for the number of averagings. *************** *** 51,57 **** ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); // Create the fields. ! // The template parameters indicate a mesh, a 'double' element ! // type, and ordinary 'Brick' storage. ! Field, double, Brick> a(cell, layout, mesh); ! Field, double, Brick> b(cell, layout, mesh); --- 51,57 ---- ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); // Create the fields. ! // The Field template parameters indicate a mesh, a 'double' value ! // type, and ordinary 'Brick' storage. ! Field, double, Brick> a(cell, layout, mesh); ! Field, double, Brick> b(cell, layout, mesh); *************** *** 78,98 **** ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); // Create the fields. ! // The template parameters indicate a mesh, a 'double' element ! // type, and ordinary 'Brick' storage. ! Field<UniformRectilinearMesh<2>, double, Brick> a(cell, layout, mesh); ! Field<UniformRectilinearMesh<2>, double, Brick> b(cell, layout, mesh); // Set up the initial conditions. *************** ! *** 51,56 **** // Perform the simulation. ! for (int k = 0; k < nuIterations; ++k) { ! // Read from b. Write to a. a(I,J) = weight * (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + ! --- 52,57 ---- // Perform the simulation. ! for (int k = 0; k < nuIterations; ++k) { --- 78,98 ---- ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); // Create the fields. ! // The Field template parameters indicate a mesh, a 'double' value ! // type, and ordinary 'Brick' storage. ! Field<UniformRectilinearMesh<2>, double, Brick> a(cell, layout, mesh); ! Field<UniformRectilinearMesh<2>, double, Brick> b(cell, layout, mesh); // Set up the initial conditions. *************** ! *** 53,58 **** // Perform the simulation. ! for (int k = 0; k < nuIterations; ++k) { ! // Read from b. Write to a. a(I,J) = weight * (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + ! --- 54,59 ---- // Perform the simulation. ! for (int k = 0; k < nuIterations; ++k) { *************** *** 100,120 **** a(I,J) = weight * (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + *************** ! *** 67,71 **** // Print out the final central value. Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; // The fields are automatically deallocated. ! --- 68,72 ---- // Print out the final central value. Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; // The fields are automatically deallocated. *************** ! *** 75,76 **** ! --- 76,78 ---- return EXIT_SUCCESS; } + --- 100,120 ---- a(I,J) = weight * (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + *************** ! *** 69,73 **** // Print out the final central value. Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; // The fields are automatically deallocated. ! --- 70,74 ---- // Print out the final central value. Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; // The fields are automatically deallocated. *************** ! *** 77,78 **** ! --- 78,80 ---- return EXIT_SUCCESS; } + Index: examples/Sequential/array-copy-annotated.patch =================================================================== RCS file: array-copy-annotated.patch diff -N array-copy-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- array-copy-annotated.patch Thu Jan 24 20:22:23 2002 *************** *** 0 **** --- 1,77 ---- + *** array-copy.cpp Thu Jan 24 11:12:23 2002 + --- array-copy-annotated.cpp Thu Jan 24 11:12:49 2002 + *************** + *** 1,8 **** + #include "Pooma/Pooma.h" + #include "Pooma/Arrays.h" + ! #include + + // Changes the Array value at index (0,0). + ! void changeValue(Array<2,int,Brick>& z) + { z(0,0) = 6; } + + --- 1,9 ---- + + + #include "Pooma/Pooma.h" + #include "Pooma/Arrays.h" + ! #include <iostream> + + // Changes the Array value at index (0,0). + ! void changeValue(Array<2,int,Brick>& z) + { z(0,0) = 6; } + + *************** + *** 11,17 **** + Pooma::initialize(argc,argv); + + ! Array<2,int,Brick> a(3,4, ModelElement(4)); + ! std::cout << "Initial value:\n"; + ! std::cout << "a: " << a(0,0) << std::endl; + + // Array copies share the same underlying values. + --- 12,18 ---- + Pooma::initialize(argc,argv); + + ! Array<2,int,Brick> a(3,4, ModelElement<int>(4)); + ! std::cout &openopen; "Initial value:\n"; + ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; + + // Array copies share the same underlying values. + *************** + *** 19,35 **** + // Explicit initialization uses reference semantics so changing the + // copy's value at (0,0) also changes the original's value. + ! Array<2,int,Brick> b(a); + b(0,0) = 5; + ! std::cout << "After explicit initialization.\n"; + ! std::cout << "a: " << a(0,0) << std::endl; + ! std::cout << "b: " << b(0,0) << std::endl; + + // Initialization of function arguments also uses reference semantics. + ! std::cout << "After function call:\n"; + changeValue(a); + ! std::cout << "a: " << a(0,0) << std::endl; + ! std::cout << "b: " << b(0,0) << std::endl; + + Pooma::finalize(); + return 0; + } + --- 20,37 ---- + // Explicit initialization uses reference semantics so changing the + // copy's value at (0,0) also changes the original's value. + ! Array<2,int,Brick> b(a); + b(0,0) = 5; + ! std::cout &openopen; "After explicit initialization.\n"; + ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; + ! std::cout &openopen; "b: " &openopen; b(0,0) &openopen; std::endl; + + // Initialization of function arguments also uses reference semantics. + ! std::cout &openopen; "After function call:\n"; + changeValue(a); + ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; + ! std::cout &openopen; "b: " &openopen; b(0,0) &openopen; std::endl; + + Pooma::finalize(); + return 0; + } + + Index: examples/Sequential/array-size-annotated.patch =================================================================== RCS file: array-size-annotated.patch diff -N array-size-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- array-size-annotated.patch Thu Jan 24 20:22:23 2002 *************** *** 0 **** --- 1,67 ---- + *** array-size.cpp Tue Jan 15 12:59:40 2002 + --- array-size-annotated.cpp Tue Jan 15 13:30:07 2002 + *************** + *** 1,5 **** + #include "Pooma/Pooma.h" + #include "Pooma/Arrays.h" + ! #include + + // Print an Array's Size + --- 1,6 ---- + + + #include "Pooma/Pooma.h" + #include "Pooma/Arrays.h" + ! #include <iostream> + + // Print an Array's Size + *************** + *** 10,22 **** + // member functions. + + ! template + inline + ! long computeArraySize(const Array& a) + { + ! const Loc fs = a.firsts(); + ! const Loc ls = a.lasts(); + ! const Loc lens = a.lengths(); + long size = 1; + ! for (int d = 0; d < Dim; ++d) { + size *= (ls[d] - fs[d] + 1).first(); + // Check that lengths() and our computed lengths agree. + --- 11,23 ---- + // member functions. + + ! template <int Dim, typename Type, typename EngineTag> + inline + ! long computeArraySize(const Array<Dim,Type,EngineTag>& a) + { + ! const Loc<Dim> fs = a.firsts(); + ! const Loc<Dim> ls = a.lasts(); + ! const Loc<Dim> lens = a.lengths(); + long size = 1; + ! for (int d = 0; d < Dim; ++d) { + size *= (ls[d] - fs[d] + 1).first(); + // Check that lengths() and our computed lengths agree. + *************** + *** 30,38 **** + Pooma::initialize(argc,argv); + + ! Array<3,int,Brick> a(3,4,5, ModelElement(4)); + PAssert(computeArraySize(a) == a.size()); + ! std::cout << "The array's size is " << a.size() << ".\n"; + + Pooma::finalize(); + return 0; + } + --- 31,40 ---- + Pooma::initialize(argc,argv); + + ! Array<3,int,Brick> a(3,4,5, ModelElement<int>(4)); + PAssert(computeArraySize(a) == a.size()); + ! std::cout &openopen; "The array's size is " &openopen; a.size() &openopen; ".\n"; + + Pooma::finalize(); + return 0; + } + + Index: examples/Sequential/dynamicarray-annotated.patch =================================================================== RCS file: dynamicarray-annotated.patch diff -N dynamicarray-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- dynamicarray-annotated.patch Thu Jan 24 20:22:23 2002 *************** *** 0 **** --- 1,80 ---- + *** dynamicarray.cpp Mon Jan 21 17:29:38 2002 + --- dynamicarray-annotated.cpp Tue Jan 22 07:06:15 2002 + *************** + *** 1,5 **** + #include "Pooma/Pooma.h" + ! #include "Pooma/DynamicArrays.h" + ! #include + + // Demonstrate using DynamicArrays. + --- 1,6 ---- + + + #include "Pooma/Pooma.h" + ! #include "Pooma/DynamicArrays.h" + ! #include <iostream> + + // Demonstrate using DynamicArrays. + *************** + *** 9,38 **** + Pooma::initialize(argc,argv); + + ! // Create a DynamicArray with one element. + ! DynamicArray<> d0(1); + ! DynamicArray d01(1); + ! DynamicArray d02(1); + + ! // Add five more elements. + d0.create(5); + // Store values in the array. + ! for (int i = d0.domain().first(); i <= d0.domain().last(); ++i) + ! d0(i) = i; + + ! // Delete every other element. + ! d0.destroy(Range<1>(d0.domain().first(),d0.domain().last(),2), BackFill()); + + // Print the resulting array. + ! std::cout << d0 << std::endl; + + // Use the iterator form of 'destroy.' + ! DynamicArray<> d1(6); + for (int i = d1.domain().first(); i <= d1.domain().last(); ++i) + d1(i) = i; + ! int killList[] = { 0, 2, 4 }; + d1.destroy(killList, killList+3); + ! std::cout << d1 << std::endl; + + Pooma::finalize(); + return 0; + } + --- 10,40 ---- + Pooma::initialize(argc,argv); + + ! // Create a DynamicArray with one element. + ! DynamicArray<> d0(1); + ! DynamicArray<double> d01(1); + ! DynamicArray<double, Dynamic> d02(1); + + ! // Add five more elements. + d0.create(5); + // Store values in the array. + ! for (int i = d0.domain().first(); i <= d0.domain().last(); ++i) + ! d0(i) = i; + + ! // Delete every other element. + ! d0.destroy(Range<1>(d0.domain().first(),d0.domain().last(),2), BackFill()); + + // Print the resulting array. + ! std::cout &openopen; d0 &openopen; std::endl; + + // Use the iterator form of 'destroy.' + ! DynamicArray<> d1(6); + for (int i = d1.domain().first(); i <= d1.domain().last(); ++i) + d1(i) = i; + ! int killList[] = { 0, 2, 4 }; + d1.destroy(killList, killList+3); + ! std::cout &openopen; d1 &openopen; std::endl; + + Pooma::finalize(); + return 0; + } + + Index: examples/Sequential/initialize-finalize-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/initialize-finalize-annotated.patch,v retrieving revision 1.1 diff -c -p -r1.1 initialize-finalize-annotated.patch *** examples/Sequential/initialize-finalize-annotated.patch 2002/01/04 18:00:02 1.1 --- examples/Sequential/initialize-finalize-annotated.patch 2002/01/25 03:22:23 *************** *** 1,14 **** ! *** initialize-finalize.cpp Sat Dec 15 15:35:57 2001 ! --- initialize-finalize-annotated.cpp Sun Dec 16 14:24:43 2001 *************** ! *** 1,2 **** ! --- 1,3 ---- + #include "Pooma/Pooma.h" *************** ! *** 10,11 **** ! --- 11,13 ---- return 0; } + --- 1,20 ---- ! *** initialize-finalize.cpp Thu Jan 24 11:14:13 2002 ! --- initialize-finalize-annotated.cpp Thu Jan 24 11:14:17 2002 *************** ! *** 1,4 **** ! #include "Pooma/Pooma.h" ! ! #include ! ! int main(int argc, char *argv[]) ! --- 1,5 ---- + #include "Pooma/Pooma.h" + ! #include <iostream> + int main(int argc, char *argv[]) *************** ! *** 11,12 **** ! --- 12,14 ---- return 0; } + Index: examples/Templates/pairs-templated-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/pairs-templated-annotated.patch,v retrieving revision 1.1 diff -c -p -r1.1 pairs-templated-annotated.patch *** examples/Templates/pairs-templated-annotated.patch 2002/01/04 18:00:02 1.1 --- examples/Templates/pairs-templated-annotated.patch 2002/01/25 03:22:23 *************** *** 1,8 **** ! *** pairs-templated.cpp Wed Dec 26 14:01:38 2001 ! --- pairs-templated-annotated.cpp Wed Dec 26 14:12:51 2001 *************** *** 1,15 **** ! ! // Declare a template class storing a pair of values with the same type. ! template struct pair { ! pair(const int& left, const int& right) --- 1,8 ---- ! *** pairs-templated.cpp Mon Jan 7 16:11:56 2002 ! --- pairs-templated-annotated.cpp Wed Jan 23 12:33:13 2002 *************** *** 1,15 **** ! // Declare a template class storing a pair of values with the same type. ! template struct pair { ! pair(const int& left, const int& right) *************** *** 12,26 **** T right_; }; ! ! // Use a class storing a pair of integers. ! pair pair1; ! // Use a class storing a pair of doubles; ! pair pair2; --- 1,17 ---- ! ! ! ! // Declare a template class storing a pair of values with the same type. ! ! template <typename T> struct pair { ! pair(const T& left, const T& right) // : left_(left), right_(right) {} --- 12,26 ---- T right_; }; ! ! // Define a class storing a pair of integers. ! pair pair1; ! ! // Define a class storing a pair of doubles; ! pair pair2; --- 1,17 ---- ! + ! // Declare a template class storing a pair of values with the same type. ! ! template <typename T> // struct pair { ! pair(const T& left, const T& right) // : left_(left), right_(right) {} *************** *** 32,37 **** ! // Use a class storing a pair of integers. ! pair<int> pair1; ! // Use a class storing a pair of doubles; ! pair<double> pair2; ! --- 32,37 ---- ! // Use a class storing a pair of integers. ! pair<int> pair1; ! ! // Use a class storing a pair of doubles; ! pair<double> pair2; ! From oldham at mail.codesourcery.com Fri Jan 25 03:48:27 2002 From: oldham at mail.codesourcery.com (Jeffrey) Date: Thu, 24 Jan 2002 19:48:27 -0800 Subject: Manual: Illustrative Programs Message-ID: <20020124194827.A732@vaio.codesourcery.com> This file hopefully saves all the POOMA programs illustrated in the POOMA manual. 2002-Jan-24 Jeffrey D. Oldham * Doof2d/Doof2d-Array-distributed.cpp: Minor comment changes. s/element/value/g. s/Pooma/POOMA/ in comment. * Doof2d/Doof2d-Array-element.cpp: Likewise. * Doof2d/Doof2d-Array-parallel.cpp: Likewise. * Doof2d/Doof2d-Array-stencil.cpp: Likewise. * Doof2d/Doof2d-C-element.cpp: Likewise. * Doof2d/Doof2d-Field-distributed.cpp: Likewise. * Doof2d/Doof2d-Field-parallel.cpp: Likewise. * Sequential/array-copy.cpp: New file indicating Array copy reference semantics. * Sequential/array-size.cpp: New file illustrating use of Array member functions. * Sequential/data-parallel.cpp: New file illustrating use of data parallel expressions. * Sequential/dynamicarray.cpp: New file illustrating changing domains. * Sequential/initialize-finalize.cpp: New file illustrating simplest POOMA program. * Sequential/makefile: New file. * Templates/pairs-templated.cpp: New file demonstrating templated class. * Templates/pairs-untemplated.cpp: New file with untemplated classes. Applied to mainline. Approved by me. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Doof2d/Doof2d-Array-distributed.cpp =================================================================== RCS file: /home/pooma/Repository/r2/examples/Manual/Doof2d/Doof2d-Array-distributed.cpp,v retrieving revision 1.2 diff -c -p -r1.2 Doof2d-Array-distributed.cpp *** Doof2d/Doof2d-Array-distributed.cpp 2001/12/11 19:22:32 1.2 --- Doof2d/Doof2d-Array-distributed.cpp 2002/01/25 03:36:10 *************** *** 1,7 **** #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has Pooma's Array ! // Doof2d: Pooma Arrays, stencil, multiple processor implementation // Define the stencil class performing the computation. class DoofNinePt --- 1,7 ---- #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations ! // Doof2d: POOMA Arrays, stencil, multiple processor implementation // Define the stencil class performing the computation. class DoofNinePt *************** private: *** 35,41 **** int main(int argc, char *argv[]) { ! // Prepare the Pooma library for execution. Pooma::initialize(argc,argv); // Since multiple copies of this program may simultaneously run, we --- 35,41 ---- int main(int argc, char *argv[]) { ! // Prepare the POOMA library for execution. Pooma::initialize(argc,argv); // Since multiple copies of this program may simultaneously run, we *************** int main(int argc, char *argv[]) *** 61,67 **** nuAveragings = strtol(argv[2], &tail, 0); nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Ask the user for the number n of elements along one dimension of // the grid. long n; n = strtol(argv[3], &tail, 0); --- 61,67 ---- nuAveragings = strtol(argv[2], &tail, 0); nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Ask the user for the number n of values along one dimension of // the grid. long n; n = strtol(argv[3], &tail, 0); *************** int main(int argc, char *argv[]) *** 88,95 **** GuardLayers<2>(0)); // external UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); ! // The template parameters indicate 2 dimensions and a 'double' ! // element type. MultiPatch indicates multiple computation patches, // i.e., distributed computation. The UniformTag indicates the // patches should have the same size. Each patch has Brick type. Array<2, double, MultiPatch > > a(layout); --- 88,95 ---- GuardLayers<2>(0)); // external UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); ! // The Array template parameters indicate 2 dimensions and a 'double' ! // value type. MultiPatch indicates multiple computation patches, // i.e., distributed computation. The UniformTag indicates the // patches should have the same size. Each patch has Brick type. Array<2, double, MultiPatch > > a(layout); *************** int main(int argc, char *argv[]) *** 120,126 **** // The arrays are automatically deallocated. ! // Tell the Pooma library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } --- 120,126 ---- // The arrays are automatically deallocated. ! // Tell the POOMA library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } Index: Doof2d/Doof2d-Array-element.cpp =================================================================== RCS file: /home/pooma/Repository/r2/examples/Manual/Doof2d/Doof2d-Array-element.cpp,v retrieving revision 1.2 diff -c -p -r1.2 Doof2d-Array-element.cpp *** Doof2d/Doof2d-Array-element.cpp 2001/12/11 19:22:32 1.2 --- Doof2d/Doof2d-Array-element.cpp 2002/01/25 03:36:10 *************** *** 1,12 **** #include // has std::cout, ... #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has Pooma's Array ! // Doof2d: Pooma Arrays, element-wise implementation int main(int argc, char *argv[]) { ! // Prepare the Pooma library for execution. Pooma::initialize(argc,argv); // Ask the user for the number of averagings. --- 1,12 ---- #include // has std::cout, ... #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations ! // Doof2d: POOMA Arrays, element-wise implementation int main(int argc, char *argv[]) { ! // Prepare the POOMA library for execution. Pooma::initialize(argc,argv); // Ask the user for the number of averagings. *************** int main(int argc, char *argv[]) *** 15,21 **** std::cin >> nuAveragings; nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Ask the user for the number n of elements along one dimension of // the grid. long n; std::cout << "Please enter the array size: "; --- 15,21 ---- std::cin >> nuAveragings; nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Ask the user for the number n of values along one dimension of // the grid. long n; std::cout << "Please enter the array size: "; *************** int main(int argc, char *argv[]) *** 26,32 **** Interval<2> vertDomain(N, N); // Create the arrays. ! // The template parameters indicate 2 dimensions, a 'double' element // type, and ordinary 'Brick' storage. Array<2, double, Brick> a(vertDomain); Array<2, double, Brick> b(vertDomain); --- 26,32 ---- Interval<2> vertDomain(N, N); // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. Array<2, double, Brick> a(vertDomain); Array<2, double, Brick> b(vertDomain); *************** int main(int argc, char *argv[]) *** 65,71 **** // The arrays are automatically deallocated. ! // Tell the Pooma library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } --- 65,71 ---- // The arrays are automatically deallocated. ! // Tell the POOMA library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } Index: Doof2d/Doof2d-Array-parallel.cpp =================================================================== RCS file: /home/pooma/Repository/r2/examples/Manual/Doof2d/Doof2d-Array-parallel.cpp,v retrieving revision 1.2 diff -c -p -r1.2 Doof2d-Array-parallel.cpp *** Doof2d/Doof2d-Array-parallel.cpp 2001/12/11 19:22:32 1.2 --- Doof2d/Doof2d-Array-parallel.cpp 2002/01/25 03:36:10 *************** *** 1,12 **** #include // has std::cout, ... #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has Pooma's Array ! // Doof2d: Pooma Arrays, data-parallel implementation int main(int argc, char *argv[]) { ! // Prepare the Pooma library for execution. Pooma::initialize(argc,argv); // Ask the user for the number of averagings. --- 1,12 ---- #include // has std::cout, ... #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations ! // Doof2d: POOMA Arrays, data-parallel implementation int main(int argc, char *argv[]) { ! // Prepare the POOMA library for execution. Pooma::initialize(argc,argv); // Ask the user for the number of averagings. *************** int main(int argc, char *argv[]) *** 15,21 **** std::cin >> nuAveragings; nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Ask the user for the number n of elements along one dimension of // the grid. long n; std::cout << "Please enter the array size: "; --- 15,21 ---- std::cin >> nuAveragings; nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Ask the user for the number n of values along one dimension of // the grid. long n; std::cout << "Please enter the array size: "; *************** int main(int argc, char *argv[]) *** 30,36 **** Interval<1> J(1,n-2); // Create the arrays. ! // The template parameters indicate 2 dimensions, a 'double' element // type, and ordinary 'Brick' storage. Array<2, double, Brick> a(vertDomain); Array<2, double, Brick> b(vertDomain); --- 30,36 ---- Interval<1> J(1,n-2); // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. Array<2, double, Brick> a(vertDomain); Array<2, double, Brick> b(vertDomain); *************** int main(int argc, char *argv[]) *** 66,72 **** // The arrays are automatically deallocated. ! // Tell the Pooma library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } --- 66,72 ---- // The arrays are automatically deallocated. ! // Tell the POOMA library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } Index: Doof2d/Doof2d-Array-stencil.cpp =================================================================== RCS file: /home/pooma/Repository/r2/examples/Manual/Doof2d/Doof2d-Array-stencil.cpp,v retrieving revision 1.2 diff -c -p -r1.2 Doof2d-Array-stencil.cpp *** Doof2d/Doof2d-Array-stencil.cpp 2001/12/11 19:22:32 1.2 --- Doof2d/Doof2d-Array-stencil.cpp 2002/01/25 03:36:10 *************** *** 1,8 **** #include // has std::cout, ... #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has Pooma's Array ! // Doof2d: Pooma Arrays, stencil implementation // Define the stencil class performing the computation. class DoofNinePt --- 1,8 ---- #include // has std::cout, ... #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations ! // Doof2d: POOMA Arrays, stencil implementation // Define the stencil class performing the computation. class DoofNinePt *************** private: *** 36,42 **** int main(int argc, char *argv[]) { ! // Prepare the Pooma library for execution. Pooma::initialize(argc,argv); // Ask the user for the number of averagings. --- 36,42 ---- int main(int argc, char *argv[]) { ! // Prepare the POOMA library for execution. Pooma::initialize(argc,argv); // Ask the user for the number of averagings. *************** int main(int argc, char *argv[]) *** 45,51 **** std::cin >> nuAveragings; nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Ask the user for the number n of elements along one dimension of // the grid. long n; std::cout << "Please enter the array size: "; --- 45,51 ---- std::cin >> nuAveragings; nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Ask the user for the number n of values along one dimension of // the grid. long n; std::cout << "Please enter the array size: "; *************** int main(int argc, char *argv[]) *** 60,66 **** Interval<2> interiorDomain(I,I); // Create the arrays. ! // The template parameters indicate 2 dimensions, a 'double' element // type, and ordinary 'Brick' storage. Array<2, double, Brick> a(vertDomain); Array<2, double, Brick> b(vertDomain); --- 60,66 ---- Interval<2> interiorDomain(I,I); // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. Array<2, double, Brick> a(vertDomain); Array<2, double, Brick> b(vertDomain); *************** int main(int argc, char *argv[]) *** 90,96 **** // The arrays are automatically deallocated. ! // Tell the Pooma library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } --- 90,96 ---- // The arrays are automatically deallocated. ! // Tell the POOMA library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } Index: Doof2d/Doof2d-C-element.cpp =================================================================== RCS file: /home/pooma/Repository/r2/examples/Manual/Doof2d/Doof2d-C-element.cpp,v retrieving revision 1.2 diff -c -p -r1.2 Doof2d-C-element.cpp *** Doof2d/Doof2d-C-element.cpp 2001/12/11 19:22:32 1.2 --- Doof2d/Doof2d-C-element.cpp 2002/01/25 03:36:10 *************** int main() *** 15,21 **** double **a; double **b; ! // Ask the user for the number n of elements along one dimension of // the grid. long n; std::cout << "Please enter the array size: "; --- 15,21 ---- double **a; double **b; ! // Ask the user for the number n of values along one dimension of // the grid. long n; std::cout << "Please enter the array size: "; Index: Doof2d/Doof2d-Field-distributed.cpp =================================================================== RCS file: /home/pooma/Repository/r2/examples/Manual/Doof2d/Doof2d-Field-distributed.cpp,v retrieving revision 1.2 diff -c -p -r1.2 Doof2d-Field-distributed.cpp *** Doof2d/Doof2d-Field-distributed.cpp 2001/12/11 19:22:32 1.2 --- Doof2d/Doof2d-Field-distributed.cpp 2002/01/25 03:36:10 *************** *** 1,11 **** #include // has EXIT_SUCCESS ! #include "Pooma/Fields.h" // has Pooma's Field ! // Doof2d: Pooma Fields, data-parallel, multiple processor implementation int main(int argc, char *argv[]) { ! // Prepare the Pooma library for execution. Pooma::initialize(argc,argv); // Since multiple copies of this program may simultaneously run, we --- 1,11 ---- #include // has EXIT_SUCCESS ! #include "Pooma/Fields.h" // has POOMA's Field declarations ! // Doof2d: POOMA Fields, data-parallel, multiple processor implementation int main(int argc, char *argv[]) { ! // Prepare the POOMA library for execution. Pooma::initialize(argc,argv); // Since multiple copies of this program may simultaneously run, we *************** int main(int argc, char *argv[]) *** 31,37 **** nuAveragings = strtol(argv[2], &tail, 0); nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Ask the user for the number n of elements along one dimension of // the grid. long n; n = strtol(argv[3], &tail, 0); --- 31,37 ---- nuAveragings = strtol(argv[2], &tail, 0); nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Ask the user for the number n of values along one dimension of // the grid. long n; n = strtol(argv[3], &tail, 0); *************** int main(int argc, char *argv[]) *** 62,69 **** UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); ! // The template parameters indicate a mesh and a 'double' ! // element type. MultiPatch indicates multiple computation patches, // i.e., distributed computation. The UniformTag indicates the // patches should have the same size. Each patch has Brick type. Field, double, MultiPatch mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); ! // The Field template parameters indicate a mesh and a 'double' ! // value type. MultiPatch indicates multiple computation patches, // i.e., distributed computation. The UniformTag indicates the // patches should have the same size. Each patch has Brick type. Field, double, MultiPatch // has std::cout, ... #include // has EXIT_SUCCESS ! #include "Pooma/Fields.h" // has Pooma's Field ! // Doof2d: Pooma Fields, data-parallel implementation int main(int argc, char *argv[]) { ! // Prepare the Pooma library for execution. Pooma::initialize(argc,argv); // Ask the user for the number of averagings. --- 1,12 ---- #include // has std::cout, ... #include // has EXIT_SUCCESS ! #include "Pooma/Fields.h" // has POOMA's Field declarations ! // Doof2d: POOMA Fields, data-parallel implementation int main(int argc, char *argv[]) { ! // Prepare the POOMA library for execution. Pooma::initialize(argc,argv); // Ask the user for the number of averagings. *************** int main(int argc, char *argv[]) *** 15,21 **** std::cin >> nuAveragings; nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Ask the user for the number n of elements along one dimension of // the grid. long n; std::cout << "Please enter the field size: "; --- 15,21 ---- std::cin >> nuAveragings; nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Ask the user for the number n of values along one dimension of // the grid. long n; std::cout << "Please enter the field size: "; *************** int main(int argc, char *argv[]) *** 36,42 **** Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); // Create the fields. ! // The template parameters indicate a mesh, a 'double' element // type, and ordinary 'Brick' storage. Field, double, Brick> a(cell, layout, mesh); Field, double, Brick> b(cell, layout, mesh); --- 36,42 ---- Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); // Create the fields. ! // The Field template parameters indicate a mesh, a 'double' value // type, and ordinary 'Brick' storage. Field, double, Brick> a(cell, layout, mesh); Field, double, Brick> b(cell, layout, mesh); *************** int main(int argc, char *argv[]) *** 72,78 **** // The fields are automatically deallocated. ! // Tell the Pooma library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } --- 72,78 ---- // The fields are automatically deallocated. ! // Tell the POOMA library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } Index: Sequential/array-copy.cpp =================================================================== RCS file: array-copy.cpp diff -N array-copy.cpp *** /dev/null Fri Mar 23 21:37:44 2001 --- array-copy.cpp Thu Jan 24 20:36:10 2002 *************** *** 0 **** --- 1,35 ---- + #include "Pooma/Pooma.h" + #include "Pooma/Arrays.h" + #include + + // Changes the Array value at index (0,0). + void changeValue(Array<2,int,Brick>& z) + { z(0,0) = 6; } + + int main(int argc, char *argv[]) + { + Pooma::initialize(argc,argv); + + Array<2,int,Brick> a(3,4, ModelElement(4)); + std::cout << "Initial value:\n"; + std::cout << "a: " << a(0,0) << std::endl; + + // Array copies share the same underlying values. + + // Explicit initialization uses reference semantics so changing the + // copy's value at (0,0) also changes the original's value. + Array<2,int,Brick> b(a); + b(0,0) = 5; + std::cout << "After explicit initialization.\n"; + std::cout << "a: " << a(0,0) << std::endl; + std::cout << "b: " << b(0,0) << std::endl; + + // Initialization of function arguments also uses reference semantics. + std::cout << "After function call:\n"; + changeValue(a); + std::cout << "a: " << a(0,0) << std::endl; + std::cout << "b: " << b(0,0) << std::endl; + + Pooma::finalize(); + return 0; + } Index: Sequential/array-size.cpp =================================================================== RCS file: array-size.cpp diff -N array-size.cpp *** /dev/null Fri Mar 23 21:37:44 2001 --- array-size.cpp Thu Jan 24 20:36:10 2002 *************** *** 0 **** --- 1,38 ---- + #include "Pooma/Pooma.h" + #include "Pooma/Arrays.h" + #include + + // Print an Array's Size + + // This program illustrates using the Array member functions. + // computeArraySize's computation is redundant because Array's size() + // function computes the same value, but it illustrates using Array + // member functions. + + template + inline + long computeArraySize(const Array& a) + { + const Loc fs = a.firsts(); + const Loc ls = a.lasts(); + const Loc lens = a.lengths(); + long size = 1; + for (int d = 0; d < Dim; ++d) { + size *= lens[d].first(); + // Check that lengths() and our computed lengths agree. + PAssert((ls[d] - fs[d] + 1).first() == a.length(d)); + } + return size; + } + + int main(int argc, char *argv[]) + { + Pooma::initialize(argc,argv); + + Array<3,int,Brick> a(3,4,5, ModelElement(4)); + PAssert(computeArraySize(a) == a.size()); + std::cout << "The array's size is " << a.size() << ".\n"; + + Pooma::finalize(); + return 0; + } Index: Sequential/data-parallel.cpp =================================================================== RCS file: data-parallel.cpp diff -N data-parallel.cpp *** /dev/null Fri Mar 23 21:37:44 2001 --- data-parallel.cpp Thu Jan 24 20:36:10 2002 *************** *** 0 **** --- 1,17 ---- + // Illustrate data-parallel expressions. + + #include "Pooma/Arrays.h" + + int main(int argc, char *argv[]) + { + Pooma::initialize(argc,argv); + + Array<1, double, Brick> A(Interval<1>(0,2)); + Array<1, double, Brick> B(Interval<1>(1,3)); + A = 1.0; + B = 2.0; + std::cout << A-B << std::endl; + + Pooma::finalize(); + return 0; + } Index: Sequential/dynamicarray.cpp =================================================================== RCS file: dynamicarray.cpp diff -N dynamicarray.cpp *** /dev/null Fri Mar 23 21:37:44 2001 --- dynamicarray.cpp Thu Jan 24 20:36:10 2002 *************** *** 0 **** --- 1,38 ---- + #include "Pooma/Pooma.h" + #include "Pooma/DynamicArrays.h" + #include + + // Demonstrate using DynamicArrays. + + int main(int argc, char *argv[]) + { + Pooma::initialize(argc,argv); + + // Create a DynamicArray with one element. + DynamicArray<> d0(1); + DynamicArray d01(1); + DynamicArray d02(1); + + // Add five more elements. + d0.create(5); + // Store values in the array. + for (int i = d0.domain().first(); i <= d0.domain().last(); ++i) + d0(i) = i; + + // Delete every other element. + d0.destroy(Range<1>(d0.domain().first(),d0.domain().last(),2), BackFill()); + + // Print the resulting array. + std::cout << d0 << std::endl; + + // Use the iterator form of 'destroy.' + DynamicArray<> d1(6); + for (int i = d1.domain().first(); i <= d1.domain().last(); ++i) + d1(i) = i; + int killList[] = { 0, 2, 4 }; + d1.destroy(killList, killList+3); + std::cout << d1 << std::endl; + + Pooma::finalize(); + return 0; + } Index: Sequential/initialize-finalize.cpp =================================================================== RCS file: initialize-finalize.cpp diff -N initialize-finalize.cpp *** /dev/null Fri Mar 23 21:37:44 2001 --- initialize-finalize.cpp Thu Jan 24 20:36:10 2002 *************** *** 0 **** --- 1,12 ---- + #include "Pooma/Pooma.h" + #include + + int main(int argc, char *argv[]) + { + // Prepare the Pooma library for execution. + Pooma::initialize(argc,argv); + + // Tell the Pooma library execution has finished. + Pooma::finalize(); + return 0; + } Index: Sequential/makefile =================================================================== RCS file: makefile diff -N makefile *** /dev/null Fri Mar 23 21:37:44 2001 --- makefile Thu Jan 24 20:36:10 2002 *************** *** 0 **** --- 1,80 ---- + # Generated by mm.pl: Mon Mar 9 13:58:39 MST 1998 + # ACL:license + # ---------------------------------------------------------------------- + # This software and ancillary information (herein called "SOFTWARE") + # called POOMA (Parallel Object-Oriented Methods and Applications) is + # made available under the terms described here. The SOFTWARE has been + # approved for release with associated LA-CC Number LA-CC-98-65. + # + # Unless otherwise indicated, this SOFTWARE has been authored by an + # employee or employees of the University of California, operator of the + # Los Alamos National Laboratory under Contract No. W-7405-ENG-36 with + # the U.S. Department of Energy. The U.S. Government has rights to use, + # reproduce, and distribute this SOFTWARE. The public may copy, distribute, + # prepare derivative works and publicly display this SOFTWARE without + # charge, provided that this Notice and any statement of authorship are + # reproduced on all copies. Neither the Government nor the University + # makes any warranty, express or implied, or assumes any liability or + # responsibility for the use of this SOFTWARE. + # + # If SOFTWARE is modified to produce derivative works, such modified + # SOFTWARE should be clearly marked, so as not to confuse it with the + # version available from LANL. + # + # For more information about POOMA, send e-mail to pooma at acl.lanl.gov, + # or visit the POOMA web page at http://www.acl.lanl.gov/pooma/. + # ---------------------------------------------------------------------- + # ACL:license + + # This file is user-editable + + PROJECT_ROOT = $(shell cd ../../..; pwd) + include $(PROJECT_ROOT)/config/head.mk + + PASS=APP + + default:: array-copy array-size data-parallel dynamicarray initialize-finalize + + .PHONY: array-copy + + array-copy:: $(ODIR)/array-copy + + $(ODIR)/array-copy: $(ODIR)/array-copy.o + $(LinkToSuite) + + .PHONY: array-size + + array-size:: $(ODIR)/array-size + + $(ODIR)/array-size: $(ODIR)/array-size.o + $(LinkToSuite) + + .PHONY: data-parallel + + data-parallel:: $(ODIR)/data-parallel + + $(ODIR)/data-parallel: $(ODIR)/data-parallel.o + $(LinkToSuite) + + .PHONY: dynamicarray + + dynamicarray:: $(ODIR)/dynamicarray + + $(ODIR)/dynamicarray: $(ODIR)/dynamicarray.o + $(LinkToSuite) + + .PHONY: initialize-finalize + + initialize-finalize:: $(ODIR)/initialize-finalize + + $(ODIR)/initialize-finalize: $(ODIR)/initialize-finalize.o + $(LinkToSuite) + + include $(SHARED_ROOT)/tail.mk + + # ACL:rcsinfo + # ---------------------------------------------------------------------- + # $RCSfile: makefile,v $ $Author: oldham $ + # $Revision: 1.1 $ $Date: 2001/12/04 00:07:00 $ + # ---------------------------------------------------------------------- + # ACL:rcsinfo Index: Templates/pairs-templated.cpp =================================================================== RCS file: pairs-templated.cpp diff -N pairs-templated.cpp *** /dev/null Fri Mar 23 21:37:44 2001 --- pairs-templated.cpp Thu Jan 24 20:36:10 2002 *************** *** 0 **** --- 1,15 ---- + // Declare a template class storing a pair of values with the same type. + template + struct pair { + pair(const int& left, const int& right) + : left_(left), right_(right) {} + + T left_; + T right_; + }; + + // Use a class storing a pair of integers. + pair pair1; + + // Use a class storing a pair of doubles; + pair pair2; Index: Templates/pairs-untemplated.cpp =================================================================== RCS file: pairs-untemplated.cpp diff -N pairs-untemplated.cpp *** /dev/null Fri Mar 23 21:37:44 2001 --- pairs-untemplated.cpp Thu Jan 24 20:36:10 2002 *************** *** 0 **** --- 1,17 ---- + // Declare a class storing a pair of integers. + struct pairOfInts { + pairOfInts(const int& left, const int& right) + : left_(left), right_(right) {} + + int left_; + int right_; + }; + + // Declare a class storing a pair of doubles. + struct pairOfDoubles { + pairOfDoubles(const double& left, const double& right) + : left_(left), right_(right) {} + + double left_; + double right_; + }; From oldham at mail.codesourcery.com Tue Jan 29 17:59:47 2002 From: oldham at mail.codesourcery.com (Jeffrey) Date: Tue, 29 Jan 2002 09:59:47 -0800 Subject: Patch: Fix Typos in Comments Message-ID: <20020129095947.A21227@vaio.codesourcery.com> 2002-Jan-29 Jeffrey D. Oldham * Domain/Grid.h: Fix typos in comments. Change "bidirectional iterator" to "forward iterator" in comment to reflect code. * Domain/IndirectionList.h: Likewise. * Domain/Interval.h: Likewise. * Domain/Loc.h: Likewise. * Domain/Range.h: Likewise. * Domain/Region.h: Likewise. * Domain/tests/grid.cpp: End comment with a period. * Engine/BrickBase.h (BrickBase::first): s/direction/dimension/ in comment. (BrickBase::strides_m): Likewise. (BrickViewBase::first): Likewise. * Engine/DynamicEngine.h (Engine<1,T,Dynamic>::destroy): Remove incorrect space in comment. (Engine<1,T,Dynamic>::performDestroy): Remove incorrect apostrophe in comment. * Engine/RemoteDynamicEngine.h: End comment with a period. * Engine/Stencil.h: Remove non-existent 'ArrayStencil' from comment. * Field/DiffOps/FieldStencil.h: Fix spacing in comment. * Field/tests/TestBasicRelations.cpp: Fix spacing. * PETE/Combiners.h: Fix typos in comments. * PETE/TypeComputations.h: Fix typo in comment. * Tiny/VectorTensor.h: Likewise. * Utilities/DataBlockPtr.h (DataBlockController): Fix spelling mistake in comment. Applied to mainline Approved by Stephen Smith Not tested. Only comments (and one whitespace change) so no testing. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Domain/Grid.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/Grid.h,v retrieving revision 1.13 diff -c -p -r1.13 Grid.h *** Domain/Grid.h 2002/01/14 16:48:21 1.13 --- Domain/Grid.h 2002/01/25 03:50:52 *************** *** 84,90 **** // in the constructor for Grid; it acts like a Loc<1> object // in that context. The domain arguments for the Grid // constructors are combined together to form a single domain object with ! // a dimension equal to the sum of the arguments dimensions; for example, // if you try to create a Grid<3> from a Loc<2> and an Interval<1>, e.g. // Grid<3> a(Loc<2>(1,2), Interval<1>(3,5)); // the Loc<2> and Interval arguments are combined into a (2+1=3) dimensional --- 84,90 ---- // in the constructor for Grid; it acts like a Loc<1> object // in that context. The domain arguments for the Grid // constructors are combined together to form a single domain object with ! // a dimension equal to the sum of the argument's dimensions; for example, // if you try to create a Grid<3> from a Loc<2> and an Interval<1>, e.g. // Grid<3> a(Loc<2>(1,2), Interval<1>(3,5)); // the Loc<2> and Interval arguments are combined into a (2+1=3) dimensional *************** *** 116,122 **** // Grid interface: // ------------------- // long size() - return the 'volume' of the domain, which is the product ! // of the lenghts of the N 1D Grids // bool empty() - return if any of the Grid<1> objects have length == 0 // Grid<1> operator[](int N) - return the Nth Grid<1> in a // multidimensional Grid. For Grid<1> objects, this just --- 116,122 ---- // Grid interface: // ------------------- // long size() - return the 'volume' of the domain, which is the product ! // of the lengths of the N 1D Grids // bool empty() - return if any of the Grid<1> objects have length == 0 // Grid<1> operator[](int N) - return the Nth Grid<1> in a // multidimensional Grid. For Grid<1> objects, this just *************** *** 124,130 **** // comparison operators: <, >, !=, ==, <=, >= : compare a Grid to // another domain object. The compared domains must have the same // number of dimensions. ! // arithmetic accumulation operators +=, -=, *=, /= : add or substract in a // given domain. The added domain must have the same number of // dimensions, or a dimension of 1 (in which case, the same value // is used for all dimensions), and be known to be single-valued (which --- 124,130 ---- // comparison operators: <, >, !=, ==, <=, >= : compare a Grid to // another domain object. The compared domains must have the same // number of dimensions. ! // arithmetic accumulation operators +=, -=, *=, /= : add or subtract in a // given domain. The added domain must have the same number of // dimensions, or a dimension of 1 (in which case, the same value // is used for all dimensions), and be known to be single-valued (which *************** *** 134,140 **** // the length (and size) the same. += and -= shift the beginning // endpoints by the given values, also leaving the length and size the // same. Negation of a Grid negates the endpoints and stride. ! // binary arithmethic operators +, -, *, / : for + and -, adding a Grid // to another Loc or int returns a new Grid. For * and /, scaling // by a Loc or int also returns a Grid object, since the stride may // change. --- 134,140 ---- // the length (and size) the same. += and -= shift the beginning // endpoints by the given values, also leaving the length and size the // same. Negation of a Grid negates the endpoints and stride. ! // binary arithmetic operators +, -, *, / : for + and -, adding a Grid // to another Loc or int returns a new Grid. For * and /, scaling // by a Loc or int also returns a Grid object, since the stride may // change. *************** *** 152,159 **** // int first() - the beginning endpoint. // int last() - the ending endpoint. // int min(), int max() - min or max of the endpoints. ! // Interval<1>::iterator begin() and end() - return iterators for the 1D ! // domain. These act like (at least) bidirectional iterators. // // For the special case of Grid<1>, there is a specialization given // after the general case that has different constructors. --- 152,159 ---- // int first() - the beginning endpoint. // int last() - the ending endpoint. // int min(), int max() - min or max of the endpoints. ! // Grid<1>::iterator begin() and end() - return iterators for the 1D ! // domain. These act like (at least) forward iterators. // // For the special case of Grid<1>, there is a specialization given // after the general case that has different constructors. Index: Domain/IndirectionList.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/IndirectionList.h,v retrieving revision 1.16 diff -c -p -r1.16 IndirectionList.h *** Domain/IndirectionList.h 2001/04/13 02:12:59 1.16 --- Domain/IndirectionList.h 2002/01/25 03:50:52 *************** *** 85,91 **** // IndirectionList interface: // ------------------- // long size() - return the 'volume' of the domain, which is the product ! // of the lenghts of the N 1D IndirectionLists // bool empty() - return if any of the IndirectionList objects have // length == 0 // IndirectionList operator[](int N) - return the Nth IndirectionList --- 85,91 ---- // IndirectionList interface: // ------------------- // long size() - return the 'volume' of the domain, which is the product ! // of the lengths of the N 1D IndirectionLists // bool empty() - return if any of the IndirectionList objects have // length == 0 // IndirectionList operator[](int N) - return the Nth IndirectionList *************** *** 94,100 **** // comparison operators: <, >, !=, ==, <=, >= : compare a IndirectionList // to another domain object. The compared domains must have the same // number of dimensions. ! // arithmetic accumulation operators +=, -=, *=, /= : add or substract in a // given domain. The added domain must have the same number of // dimensions, or a dimension of 1 (in which case, the same value // is used for all dimensions), and be known to be single-valued (which --- 94,100 ---- // comparison operators: <, >, !=, ==, <=, >= : compare a IndirectionList // to another domain object. The compared domains must have the same // number of dimensions. ! // arithmetic accumulation operators +=, -=, *=, /= : add or subtract in a // given domain. The added domain must have the same number of // dimensions, or a dimension of 1 (in which case, the same value // is used for all dimensions), and be known to be single-valued (which *************** *** 120,126 **** // int last() - the ending endpoint. // int min(), int max() - min or max of the endpoints. // IndirectionList::iterator begin() and end() - return iterators for ! // the 1D domain. These act like (at least) bidirectional iterators. // //----------------------------------------------------------------------------- --- 120,126 ---- // int last() - the ending endpoint. // int min(), int max() - min or max of the endpoints. // IndirectionList::iterator begin() and end() - return iterators for ! // the 1D domain. These act like (at least) forward iterators. // //----------------------------------------------------------------------------- Index: Domain/Interval.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/Interval.h,v retrieving revision 1.19 diff -c -p -r1.19 Interval.h *** Domain/Interval.h 2002/01/14 16:48:21 1.19 --- Domain/Interval.h 2002/01/25 03:50:52 *************** *** 78,84 **** // in the constructor for Interval; it acts like a Loc<1> object // in that context. The domain arguments for the Interval // constructors are combined together to form a single domain object with ! // a dimension equal to the sum of the arguments dimensions; for example, // if you try to create an Interval<3> from a Loc<2> and an Interval<1>, e.g. // Interval<3> a(Loc<2>(1,2), Interval<1>(3,5)); // the Loc<2> and Interval arguments are combined into a (2+1=3) dimensional --- 78,84 ---- // in the constructor for Interval; it acts like a Loc<1> object // in that context. The domain arguments for the Interval // constructors are combined together to form a single domain object with ! // a dimension equal to the sum of the arguments' dimensions; for example, // if you try to create an Interval<3> from a Loc<2> and an Interval<1>, e.g. // Interval<3> a(Loc<2>(1,2), Interval<1>(3,5)); // the Loc<2> and Interval arguments are combined into a (2+1=3) dimensional *************** *** 104,110 **** // Interval interface: // ---------------------- // long size() - return the 'volume' of the domain, which is the product ! // of the lenghts of the N 1D Intervals // bool empty() - return if any of the Interval<1> objects have length == 0 // Interval<1> operator[](int N) - return the Nth Interval<1> in a // multidimensional Interval. For Interval<1> objects, this just --- 104,110 ---- // Interval interface: // ---------------------- // long size() - return the 'volume' of the domain, which is the product ! // of the lengths of the N 1D Intervals // bool empty() - return if any of the Interval<1> objects have length == 0 // Interval<1> operator[](int N) - return the Nth Interval<1> in a // multidimensional Interval. For Interval<1> objects, this just *************** *** 112,118 **** // comparison operators: <, >, !=, ==, <=, >= : compare an Interval to // another domain object. The compared domains must have the same // number of dimensions. ! // arithmetic accumulation operators +=, -= : add or substract in a // given domain. The added domain must have the same number of // dimensions, or a dimension of 1 (in which case, the same value // is used for all dimensions), and be known to be single-valued (which --- 112,118 ---- // comparison operators: <, >, !=, ==, <=, >= : compare an Interval to // another domain object. The compared domains must have the same // number of dimensions. ! // arithmetic accumulation operators +=, -= : add or subtract in a // given domain. The added domain must have the same number of // dimensions, or a dimension of 1 (in which case, the same value // is used for all dimensions), and be known to be single-valued (which *************** *** 120,126 **** // allowed, since these operators would change the stride and that is // not allowed for Interval (it has a hard-coded stride of 1). // The negation operator (operator-) is also NOT allowed for Interval. ! // binary arithmethic operators +, -, *, / : for + and -, adding an Interval // to another Loc or int returns a new Interval. For * and /, scaling // by a Loc or int returns a Range object, since the stride may // change. --- 120,126 ---- // allowed, since these operators would change the stride and that is // not allowed for Interval (it has a hard-coded stride of 1). // The negation operator (operator-) is also NOT allowed for Interval. ! // binary arithmetic operators +, -, *, / : for + and -, adding an Interval // to another Loc or int returns a new Interval. For * and /, scaling // by a Loc or int returns a Range object, since the stride may // change. *************** *** 135,141 **** // int last() - the ending endpoint. // int min(), int max() - min or max of the endpoints. // Interval<1>::iterator begin() and end() - return iterators for the 1D ! // domain. These act like (at least) bidirectional iterators. // // Interval inherits much of its activity from Domain>. // --- 135,141 ---- // int last() - the ending endpoint. // int min(), int max() - min or max of the endpoints. // Interval<1>::iterator begin() and end() - return iterators for the 1D ! // domain. These act like (at least) forward iterators. // // Interval inherits much of its activity from Domain>. // Index: Domain/Loc.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/Loc.h,v retrieving revision 1.25 diff -c -p -r1.25 Loc.h *** Domain/Loc.h 2002/01/14 16:48:21 1.25 --- Domain/Loc.h 2002/01/25 03:50:52 *************** *** 113,119 **** // dimensions, or a dimension of 1 (in which case, the same value // is used for all dimensions), and be known to be single-valued (which // is true for Loc and int's). ! // binary arithmethic operators +, -, *, / : for + and -, adding a Loc // to another Loc or int returns a new Loc object. For * and /, scaling // by a Loc or int returns a Range object, since the stride may // change. --- 113,119 ---- // dimensions, or a dimension of 1 (in which case, the same value // is used for all dimensions), and be known to be single-valued (which // is true for Loc and int's). ! // binary arithmetic operators +, -, *, / : for + and -, adding a Loc // to another Loc or int returns a new Loc object. For * and /, scaling // by a Loc or int returns a Range object, since the stride may // change. *************** *** 129,135 **** // int last() - the ending endpoint, for Loc<1> just the point itself. // int min(), int max() - min or max of the endpoints. // Loc<1>::iterator begin() and end() - return iterators for the 1D domain. ! // These act like (at least) bidirectional iterators. // // Loc inherits much of its activity from Domain,Dim>. // Domain is a base class that uses the template argument as a traits class --- 129,135 ---- // int last() - the ending endpoint, for Loc<1> just the point itself. // int min(), int max() - min or max of the endpoints. // Loc<1>::iterator begin() and end() - return iterators for the 1D domain. ! // These act like (at least) forward iterators. // // Loc inherits much of its activity from Domain,Dim>. // Domain is a base class that uses the template argument as a traits class Index: Domain/Range.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/Range.h,v retrieving revision 1.20 diff -c -p -r1.20 Range.h *** Domain/Range.h 2002/01/14 16:48:21 1.20 --- Domain/Range.h 2002/01/25 03:50:52 *************** void fillRangeScalar(Range &r, cons *** 111,117 **** // Range interface: // ------------------- // long size() - return the 'volume' of the domain, which is the product ! // of the lenghts of the N 1D Ranges // bool empty() - return if any of the Range<1> objects have length == 0 // Range<1> operator[](int N) - return the Nth Range<1> in a // multidimensional Range. For Range<1> objects, this just --- 111,117 ---- // Range interface: // ------------------- // long size() - return the 'volume' of the domain, which is the product ! // of the lengths of the N 1D Ranges // bool empty() - return if any of the Range<1> objects have length == 0 // Range<1> operator[](int N) - return the Nth Range<1> in a // multidimensional Range. For Range<1> objects, this just *************** void fillRangeScalar(Range &r, cons *** 119,125 **** // comparison operators: <, >, !=, ==, <=, >= : compare a Range to // another domain object. The compared domains must have the same // number of dimensions. ! // arithmetic accumulation operators +=, -=, *=, /= : add or substract in a // given domain. The added domain must have the same number of // dimensions, or a dimension of 1 (in which case, the same value // is used for all dimensions), and be known to be single-valued (which --- 119,125 ---- // comparison operators: <, >, !=, ==, <=, >= : compare a Range to // another domain object. The compared domains must have the same // number of dimensions. ! // arithmetic accumulation operators +=, -=, *=, /= : add or subtract in a // given domain. The added domain must have the same number of // dimensions, or a dimension of 1 (in which case, the same value // is used for all dimensions), and be known to be single-valued (which *************** void fillRangeScalar(Range &r, cons *** 129,135 **** // the length (and size) the same. += and -= shift the beginning // endpoints by the given values, also leaving the length and size the // same. Negation of a Range negates the endpoints and stride. ! // binary arithmethic operators +, -, *, / : for + and -, adding a Range // to another Loc or int returns a new Range. For * and /, scaling // by a Loc or int also returns a Range object, since the stride may // change. --- 129,135 ---- // the length (and size) the same. += and -= shift the beginning // endpoints by the given values, also leaving the length and size the // same. Negation of a Range negates the endpoints and stride. ! // binary arithmetic operators +, -, *, / : for + and -, adding a Range // to another Loc or int returns a new Range. For * and /, scaling // by a Loc or int also returns a Range object, since the stride may // change. *************** void fillRangeScalar(Range &r, cons *** 147,154 **** // int first() - the beginning endpoint. // int last() - the ending endpoint. // int min(), int max() - min or max of the endpoints. ! // Interval<1>::iterator begin() and end() - return iterators for the 1D ! // domain. These act like (at least) bidirectional iterators. // // For the special case of Range<1>, there is a specialization given // after the general case that has different constructors. --- 147,154 ---- // int first() - the beginning endpoint. // int last() - the ending endpoint. // int min(), int max() - min or max of the endpoints. ! // Range<1>::iterator begin() and end() - return iterators for the 1D ! // domain. These act like (at least) forward iterators. // // For the special case of Range<1>, there is a specialization given // after the general case that has different constructors. Index: Domain/Region.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/Region.h,v retrieving revision 1.23 diff -c -p -r1.23 Region.h *** Domain/Region.h 2001/04/13 02:12:59 1.23 --- Domain/Region.h 2002/01/25 03:50:52 *************** *** 78,84 **** // // You can construct a Region object using other domain objects. // The constructors accept up to 7 domain objects of various types. ! // Domain types are, for example, Loc, Region, Interval. an int, double, or // float may also be used // in the constructor for Region; it acts like a Loc<1> object // in that context. The domain arguments for the Region --- 78,84 ---- // // You can construct a Region object using other domain objects. // The constructors accept up to 7 domain objects of various types. ! // Domain types are, for example, Loc, Region, Interval. An int, double, or // float may also be used // in the constructor for Region; it acts like a Loc<1> object // in that context. The domain arguments for the Region *************** *** 117,123 **** // Region interface: // ------------------- // T size() - return the 'volume' of the domain, which is the product ! // of the lenghts of the N 1D Regions // bool empty() - always false here // Region<1,T> operator[](int N) - return the Nth Region<1,T> in a // multidimensional Region. For Region<1,T> objects, this just --- 117,123 ---- // Region interface: // ------------------- // T size() - return the 'volume' of the domain, which is the product ! // of the lengths of the N 1D Regions // bool empty() - always false here // Region<1,T> operator[](int N) - return the Nth Region<1,T> in a // multidimensional Region. For Region<1,T> objects, this just *************** *** 125,131 **** // comparison operators: <, >, !=, ==, <=, >= : compare a Region to // another domain object. The compared domains must have the same // number of dimensions. ! // arithmetic accumulation operators +=, -=, *=, /= : add or substract in a // given domain. The added domain must have the same number of // dimensions, or a dimension of 1 (in which case, the same value // is used for all dimensions), and be known to be single-valued (which --- 125,131 ---- // comparison operators: <, >, !=, ==, <=, >= : compare a Region to // another domain object. The compared domains must have the same // number of dimensions. ! // arithmetic accumulation operators +=, -=, *=, /= : add or subtract in a // given domain. The added domain must have the same number of // dimensions, or a dimension of 1 (in which case, the same value // is used for all dimensions), and be known to be single-valued (which *************** *** 135,141 **** // the length (and size) the same. += and -= shift the beginning // endpoints by the given values, also leaving the length and size the // same. Negation of a Region negates the endpoints and stride. ! // binary arithmethic operators +, -, *, / : for + and -, adding a Region // to another Loc or int returns a new Region. For * and /, scaling // by a Loc or int also returns a Region object, since the stride may // change. --- 135,141 ---- // the length (and size) the same. += and -= shift the beginning // endpoints by the given values, also leaving the length and size the // same. Negation of a Region negates the endpoints and stride. ! // binary arithmetic operators +, -, *, / : for + and -, adding a Region // to another Loc or int returns a new Region. For * and /, scaling // by a Loc or int also returns a Region object, since the stride may // change. *************** *** 147,162 **** // all the methods for Region are also available for Region<1,T>. Plus: // T length() - number of elements (including endpoints) of the domain. // Really, this should be either 1 or infinity, but it defined here ! // somewhat differently, as just the distance betweent the endpoints. So // a length of zero really means this just refers to one point, not that ! // this is empty. A Region cannot be empty, it must refer to SOME point(s) // T first() - the beginning endpoint. // T last() - the ending endpoint. // T stride() - here, the same as the length() // T min(), T max() - min or max of the endpoints. // bool empty() - always false for a Region // Region<1,T>::iterator begin() and end() - return iterators for the 1D ! // domain. These act like (at least) bidirectional iterators. // // For the special case of Region<1,T>, there is a specialization given // after the general case that has different constructors. --- 147,162 ---- // all the methods for Region are also available for Region<1,T>. Plus: // T length() - number of elements (including endpoints) of the domain. // Really, this should be either 1 or infinity, but it defined here ! // somewhat differently, as just the distance between the endpoints. So // a length of zero really means this just refers to one point, not that ! // this is empty. A Region cannot be empty, it must refer to SOME point(s). // T first() - the beginning endpoint. // T last() - the ending endpoint. // T stride() - here, the same as the length() // T min(), T max() - min or max of the endpoints. // bool empty() - always false for a Region // Region<1,T>::iterator begin() and end() - return iterators for the 1D ! // domain. These act like (at least) forward iterators. // // For the special case of Region<1,T>, there is a specialization given // after the general case that has different constructors. Index: Domain/tests/grid.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/tests/grid.cpp,v retrieving revision 1.5 diff -c -p -r1.5 grid.cpp *** Domain/tests/grid.cpp 2000/03/07 13:16:42 1.5 --- Domain/tests/grid.cpp 2002/01/25 03:50:53 *************** int main(int argc, char *argv[]) { *** 60,66 **** tester.out() << "Created Range = " << range << std::endl; ! // Construct a 1D Grid from the IndirectionList, and from the range Grid<1> g1(list); Grid<1> g2(range); --- 60,66 ---- tester.out() << "Created Range = " << range << std::endl; ! // Construct a 1D Grid from the IndirectionList and from the range. Grid<1> g1(list); Grid<1> g2(range); Index: Engine/BrickBase.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/BrickBase.h,v retrieving revision 1.13 diff -c -p -r1.13 BrickBase.h *** Engine/BrickBase.h 2001/10/24 15:39:42 1.13 --- Engine/BrickBase.h 2002/01/25 03:50:53 *************** public: *** 173,179 **** inline const int *originalStrides() const { return &ostrides_m[0]; } ! // Return the first index value for the specified direction. int first(int i) const; --- 173,179 ---- inline const int *originalStrides() const { return &ostrides_m[0]; } ! // Return the first index value for the specified dimension. int first(int i) const; *************** protected: *** 315,321 **** Layout_t layout_m; ! // Strides through actual data block when stepping in different directions. // We keep two copies - strides_m is used by the offset calculations. // If we are compressible, then when compressed, these will all be // set to zero. --- 315,321 ---- Layout_t layout_m; ! // Strides through actual data block when stepping in different dimensions. // We keep two copies - strides_m is used by the offset calculations. // If we are compressible, then when compressed, these will all be // set to zero. *************** public: *** 538,544 **** inline const int *originalStrides() const { return &ostrides_m[0]; } ! // Return the first index value for the specified direction. // (Always zero since views are zero-based). inline int first(int) const { return 0; } --- 538,544 ---- inline const int *originalStrides() const { return &ostrides_m[0]; } ! // Return the first index value for the specified dimension. // (Always zero since views are zero-based). inline int first(int) const { return 0; } *************** protected: *** 663,669 **** Domain_t domain_m; ! // Strides through actual data block when stepping in each direction. // We keep two copies - strides_m is used by the offset calculations. // If we are compressible, then when compressed, these will all be // set to zero. --- 663,669 ---- Domain_t domain_m; ! // Strides through actual data block when stepping in each dimension. // We keep two copies - strides_m is used by the offset calculations. // If we are compressible, then when compressed, these will all be // set to zero. Index: Engine/DynamicEngine.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/DynamicEngine.h,v retrieving revision 1.16 diff -c -p -r1.16 DynamicEngine.h *** Engine/DynamicEngine.h 2001/04/09 21:34:27 1.16 --- Engine/DynamicEngine.h 2002/01/25 03:50:53 *************** public: *** 275,281 **** void destroy(const Dom &killList); // Same, but with iterators into some container holding the ! // points of the domain. These must be random-access iterators ( a // requirement of the underlying delete algorithm). template --- 275,281 ---- void destroy(const Dom &killList); // Same, but with iterators into some container holding the ! // points of the domain. These must be random-access iterators (a // requirement of the underlying delete algorithm). template *************** private: *** 359,365 **** // versions that take iterators into the killList. This allows one // to use many more data structures for holding the kill list. ! // If offsetFlag is true (delete default's it to false), the domain // is interpreted as a list of offsets rather than a subset of // the engine's domain. --- 359,365 ---- // versions that take iterators into the killList. This allows one // to use many more data structures for holding the kill list. ! // If offsetFlag is true (delete defaults it to false), the domain // is interpreted as a list of offsets rather than a subset of // the engine's domain. Index: Engine/RemoteDynamicEngine.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/RemoteDynamicEngine.h,v retrieving revision 1.16 diff -c -p -r1.16 RemoteDynamicEngine.h *** Engine/RemoteDynamicEngine.h 2001/05/16 21:21:06 1.16 --- Engine/RemoteDynamicEngine.h 2002/01/25 03:50:54 *************** *** 40,46 **** // // Engine<1, T, Remote > // - A wrapper engine that remotifies an Engine<1, T, Dynamic>. ! // The remote version belongs to a particular context // //----------------------------------------------------------------------------- --- 40,46 ---- // // Engine<1, T, Remote > // - A wrapper engine that remotifies an Engine<1, T, Dynamic>. ! // The remote version belongs to a particular context. // //----------------------------------------------------------------------------- Index: Engine/Stencil.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/Stencil.h,v retrieving revision 1.44 diff -c -p -r1.44 Stencil.h *** Engine/Stencil.h 2001/09/14 22:37:56 1.44 --- Engine/Stencil.h 2002/01/25 03:50:54 *************** *** 30,37 **** // Classes: // Stencil - Base class for defining stencils // StencilEngine - An tag for an engine for representing a stencil - // ArrayStencil - contains utility functions for building stencils - // on arrays // View1 - Specialization for Stencil // Engine - Specialization for StencilEngine // NewEngine - Specialization for StencilEngine --- 30,35 ---- Index: Field/DiffOps/FieldStencil.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Field/DiffOps/FieldStencil.h,v retrieving revision 1.1 diff -c -p -r1.1 FieldStencil.h *** Field/DiffOps/FieldStencil.h 2001/08/30 01:15:09 1.1 --- Field/DiffOps/FieldStencil.h 2002/01/25 03:50:54 *************** struct LeafFunctor& v1 , const V *** 297,303 **** // // Full Description: // ! // Subroutine for taking outper product between two vectors, yielding a tensor. // Takes the outer product of vector of type V1 and vector of type V2 // // The chain of operations is: --- 297,303 ---- // // Full Description: // ! // Subroutine for taking outer product between two vectors, yielding a tensor. // Takes the outer product of vector of type V1 and vector of type V2 // // The chain of operations is: Index: Utilities/DataBlockPtr.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Utilities/DataBlockPtr.h,v retrieving revision 1.20 diff -c -p -r1.20 DataBlockPtr.h *** Utilities/DataBlockPtr.h 2001/05/04 15:41:29 1.20 --- Utilities/DataBlockPtr.h 2002/01/25 03:50:55 *************** public: *** 190,196 **** // Ordinarily, this will NOT be used. However, if one // wants to have a RefCountedBlockPtr where T1 itself // is or contains a RefCountedBlockPtr, then this ! // may occaisionally be used. When it IS used, a DEEP // copy is required. The RefCounted base class's copy // constructor properly sets the count of the new // class to zero. --- 190,196 ---- // Ordinarily, this will NOT be used. However, if one // wants to have a RefCountedBlockPtr where T1 itself // is or contains a RefCountedBlockPtr, then this ! // may occasionally be used. When it IS used, a DEEP // copy is required. The RefCounted base class's copy // constructor properly sets the count of the new // class to zero. From oldham at mail.codesourcery.com Tue Jan 29 21:49:48 2002 From: oldham at mail.codesourcery.com (Jeffrey) Date: Tue, 29 Jan 2002 13:49:48 -0800 Subject: Manual Patch: More Wordsmithing and Formatting Message-ID: <20020129134948.A22638@vaio.codesourcery.com> 2002-Jan-29 Jeffrey D. Oldham These changes to the POOMA manual continue the process of working toward delivery. Most of the changes involve wordsmithing and formatting of the PostScript version. * arrays.xml: Fix formatting. Minor wording changes. * concepts.xml: Likewise. * data-parallel.xml: Change section title. Fix formatting of verbatim sections. * introduction.xml: Change use of the word "free." Other minor wording and formatting changes. * manual.xml: Update download page entity. Add acknowledgements. Fix use of the word "Unix." Fix some formatting, particularly verbatim environments. * template.xml: Be consist in use of "programming time." Minor formatting and wordsmithing. * tutorial.xml: Replace use of "Unix." Fix formatting. Applied to mainline Approved by me. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: arrays.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/arrays.xml,v retrieving revision 1.4 diff -c -p -r1.4 arrays.xml *** arrays.xml 2002/01/25 02:28:25 1.4 --- arrays.xml 2002/01/29 18:11:18 *************** *** 239,248 **** Declaring &domain;s Since &domain;s are mainly used to declare container ! domains, we focus on declaring &domain;s. We subsequently ! describe a few &domain; operations but most, including arithmetic ! operations with &domain;s, are described in . All &domain; declarations require a dimension template parameter &dim;. This positive integer --- 239,248 ---- Declaring &domain;s Since &domain;s are mainly used to declare container ! domains, we focus on declaring &domain;s, deferring most ! discussion of their use. We subsequently describe a few &domain; ! operations but most, including arithmetic operations with ! &domain;s, are described in . All &domain; declarations require a dimension template parameter &dim;. This positive integer *************** Grid<1> g(list); *** 1099,1109 **** &array; values need not just be stored values, as &c; arrays ! have. They can also be computed by its engine. We defer ! discussion of computing values to the next chapter discussing ! engines (). To avoid being verbose ! in this chapter, when we discuss stored values, the values might ! instead be computed. Declaring an &array; requires four arguments: the domain's dimensionality, the type of values stored or computed, a --- 1099,1110 ---- &array; values need not just be stored values, as &c; arrays ! have. The values can also be computed dynamically by the engine ! associated with the &array;. We defer discussion of computing ! values to the next chapter discussing engines (). Therefore, when we mention the ! values stored in an &array;, we implicitly mean the ! values stored in or computed by the &array;. Declaring an &array; requires four arguments: the domain's dimensionality, the type of values stored or computed, a *************** Array<2,bool> c(2,3, ModelElement& *** 1395,1401 **** seven &double;s all equaling π, use const double pi = 4.0*atan(1.0); ! Array<1,double,CompressibleBrick> d(7, ModelElement<double>(pi));. We use a &compressiblebrick; &engine;, rather than a &brick; &engine;, so all seven values will be stored in one location rather than in seven separate locations when they are all the --- 1396,1403 ---- seven &double;s all equaling π, use const double pi = 4.0*atan(1.0); ! Array<1,double,CompressibleBrick> ! d(7, ModelElement<double>(pi));. We use a &compressiblebrick; &engine;, rather than a &brick; &engine;, so all seven values will be stored in one location rather than in seven separate locations when they are all the *************** Array<1,double,CompressibleBrick> *** 1420,1426 **** // Create an Array and its domain. Array<2,float,Brick> a(Interval<1>(2,7), Interval<1>(-2,4)); ! // Create an Array without a domain and then specify its domain. Array<2,float,Brick> b(); b.initialize(Interval<1>(2,7), Interval<1>(-2,4));. Invoking initialize on an --- 1422,1429 ---- // Create an Array and its domain. Array<2,float,Brick> a(Interval<1>(2,7), Interval<1>(-2,4)); ! // Create an Array without a domain and then specify ! // its domain. Array<2,float,Brick> b(); b.initialize(Interval<1>(2,7), Interval<1>(-2,4));. Invoking initialize on an *************** std::cout &openopen; a.read(2,-2) &openo *** 1623,1629 **** a's values are the same as b at the time of assignment only. Subsequent changes to a's values do not change b's ! values or vice versa. The &array; class has internal type definitions and constants useful for both compile-time and run-time computations. --- 1626,1637 ---- a's values are the same as b at the time of assignment only. Subsequent changes to a's values do not change b's ! values or vice versa. Assignment is more expensive than creating ! a reference. Creating a reference requires creating a very small ! object and incrementing a reference-counted pointer. An ! assignment requires storage for both the left-hand side and ! right-hand side operands and traversing all of the right-hand ! side's data. The &array; class has internal type definitions and constants useful for both compile-time and run-time computations. Index: concepts.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/concepts.xml,v retrieving revision 1.9 diff -c -p -r1.9 concepts.xml *** concepts.xml 2002/01/25 02:28:26 1.9 --- concepts.xml 2002/01/29 18:11:19 *************** *** 52,60 **** Container ! Computation Modes ! Computation Environment --- 52,65 ---- + + + Computation + + Container ! Computation Modes ! Environment *************** *** 377,384 **** are several different types of domains. An interval consists of all integral points between two endpoints. It is ! frequently represented using mathematical interval notation [a,b] ! even though it contains only the integral points, e.g., a, a+1, a+2, …, b. The concept is generalized to multiple dimensions by forming direct products of intervals, i.e., all the integral tuples in an &n;-dimensional space. For example, the --- 382,389 ---- are several different types of domains. An interval consists of all integral points between two endpoints. It is ! frequently represented using mathematical interval notation [a,b]; ! it contains only the integral points, e.g., a, a+1, a+2, …, b. The concept is generalized to multiple dimensions by forming direct products of intervals, i.e., all the integral tuples in an &n;-dimensional space. For example, the *************** *** 501,511 **** involves explicitly accessing a container's values. A data-parallel computation operates on larger subsets of a container's values. Stencil-based computations express a computation as repeatedly ! applying a local computation to each element of an array. A ! relation among containers establishes a dependency among them so the ! values of one container are updated whenever any other's values ! change. A program may use any or all of these styles, which are ! described below. Element-wise --- 506,516 ---- involves explicitly accessing a container's values. A data-parallel computation operates on larger subsets of a container's values. Stencil-based computations express a computation as repeatedly ! applying a local computation to each element of an array. ! Relation-based computations use relations on containers to establish ! dependencies among them so the values of one container are updated ! whenever any other's values change. A program may use any or all of ! these styles, which are described below. Element-wise *************** *** 528,536 **** data-parallel expressions frequently eliminates the need for writing explicit loops. ! A stencil ! computes a container's value using neighboring data values. Each stencil consists of a specification of which neighboring values to read and a function using those values. For example, an averaging stencil may access all its adjacent neighbors, averaging them. In --- 533,541 ---- data-parallel expressions frequently eliminates the need for writing explicit loops. ! Stencil-based computation uses stencils ! to compute containers' values using neighboring data values. Each stencil consists of a specification of which neighboring values to read and a function using those values. For example, an averaging stencil may access all its adjacent neighbors, averaging them. In *************** *** 540,548 **** differential equations, image processing, and geometric modeling. ! A relation ! is a dependence among containers such the dependent container's values are updated when its values are needed and any of its related containers' values have changed. A relation is specified by a dependent container, independent containers, and a function --- 545,553 ---- differential equations, image processing, and geometric modeling. ! Relation-based computation uses relations ! to create dependences among containers such the dependent container's values are updated when its values are needed and any of its related containers' values have changed. A relation is specified by a dependent container, independent containers, and a function Index: data-parallel.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/data-parallel.xml,v retrieving revision 1.3 diff -c -p -r1.3 data-parallel.xml *** data-parallel.xml 2002/01/25 02:28:26 1.3 --- data-parallel.xml 2002/01/29 18:11:20 *************** *** 57,63 ****

! Their Use &pooma; containers can be used in data-parallel expressions and statements. The basic guidelines are simple: --- 57,63 ----

! Using Data-Parallel Expressions &pooma; containers can be used in data-parallel expressions and statements. The basic guidelines are simple: *************** std::cout &openopen; A &openopen; std::e *** 969,981 **** For example, the overloaded unary minus operator yields a tree node representing -A, having a unary-minus function object, and having type ! Expression<UnaryNode<OpMinus,Ar&closeclose;. ! The binary nodes continue the construction process yielding a parse tree object for the entire right-hand side and having type ! Expression<BinaryNode<OpAdd, UnaryNode<OpMinus, ! Ar>, ! BinaryNode<OpMultiply<Scalar<int>,Ar&closecloseclose;. ! Evaluating the left-hand side yields an object representing A.

--- 969,983 ---- For example, the overloaded unary minus operator yields a tree node representing -A, having a unary-minus function object, and having type ! ! Expression<UnaryNode<OpMinus,Ar&closeclose; ! The binary nodes continue the construction process yielding a parse tree object for the entire right-hand side and having type ! ! Expression<BinaryNode<OpAdd, ! UnaryNode<OpMinus, Ar>, ! BinaryNode<OpMultiply<Scalar<int>,Ar&closecloseclose; ! Evaluating the left-hand side yields an object representing A.

*************** struct CreateLeaf<Array<Dim, T, En *** 1122,1128 **** template<int D1,class T1,class E1> inline typename MakeReturn<UnaryNode<OpUnaryMinus, ! typename CreateLeaf<Array<D1,T1,E1> >::Leaf_t> >::Expression_t operator-(const Array<D1,T1,E1> & l) { typedef UnaryNode<OpUnaryMinus, --- 1124,1131 ---- template<int D1,class T1,class E1> inline typename MakeReturn<UnaryNode<OpUnaryMinus, ! typename CreateLeaf<Array<D1,T1,E1&closeclose;::Leaf_t&closeclose;:: ! Expression_t operator-(const Array<D1,T1,E1> & l) { typedef UnaryNode<OpUnaryMinus, *************** operator-(const Array<D1,T1,E1> &a *** 1133,1140 **** Tree_t specifies the node's unique type. Constructing the object first involves creating a leaf containing the &array; reference through the call to ! CreateLeaf<Array<D1,T1,E1> ! >::make. The call to MakeReturn<Tree_t>::make permits programmers to store trees in different formats. The &pooma; implementation stores them as Expressions. The --- 1136,1144 ---- Tree_t specifies the node's unique type. Constructing the object first involves creating a leaf containing the &array; reference through the call to ! ! CreateLeaf<Array<D1,T1,E1> >::make ! The call to MakeReturn<Tree_t>::make permits programmers to store trees in different formats. The &pooma; implementation stores them as Expressions. The *************** for (int i = a's domain[0].first(); i < *** 1199,1205 **** performs a compile-time post-order parse-tree traversal. Its general form is ! forEach(const Expression& e, const LeafTag& f, const CombineTag& c). That is, it traverses the nodes of the Expression object e. At leaves, it applies the operation specified by --- 1203,1210 ---- performs a compile-time post-order parse-tree traversal. Its general form is ! forEach(const Expression& e, const LeafTag& f, ! const CombineTag& c). That is, it traverses the nodes of the Expression object e. At leaves, it applies the operation specified by *************** struct ForEach<UnaryNode<Op, A> *** 1232,1238 **** const CTag &c) { return Combine1<TypeA_t, Op, CTag>:: ! combine(ForEach<A, FTag, CTag>::apply(expr.child(), f, c), c); } }; Since this structure is specialized for --- 1237,1244 ---- const CTag &c) { return Combine1<TypeA_t, Op, CTag>:: ! combine(ForEach<A, FTag, CTag>:: ! apply(expr.child(), f, c), c); } }; Since this structure is specialized for Index: introduction.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/introduction.xml,v retrieving revision 1.4 diff -c -p -r1.4 introduction.xml *** introduction.xml 2002/01/24 05:11:21 1.4 --- introduction.xml 2002/01/29 18:11:21 *************** *** 33,40 **** Using these high-level abstractions, the same code runs on a sequential, parallel, and distributed computers. It runs almost as fast as carefully crafted machine-specific hand-written programs. ! The &toolkit; is freely available, open-source software compatible ! with any modern &cc; compiler.

--- 33,40 ---- Using these high-level abstractions, the same code runs on a sequential, parallel, and distributed computers. It runs almost as fast as carefully crafted machine-specific hand-written programs. ! The &toolkit; is open-source software, available for no cost, and ! compatible with any modern &cc; compiler.

*************** *** 79,85 **** The same &pooma; programs run on sequential, distributed, and parallel computers. No change in source code is required. Two or ! three lines specify how each container's domain should be distributed among available processors. Using these directives and run-time information about the computer's configuration, the &toolkit; automatically distributes pieces of the container domains, --- 79,85 ---- The same &pooma; programs run on sequential, distributed, and parallel computers. No change in source code is required. Two or ! three lines specify how each container's data should be distributed among available processors. Using these directives and run-time information about the computer's configuration, the &toolkit; automatically distributes pieces of the container domains, *************** *** 283,289 **** inner-loop evaluation ! &pooma; uses &pete; technology to ensure inner loops involving &pooma;'s object-oriented containers run as quickly as hand-coded loops. &pete; (the Portable Expression Template --- 283,289 ---- inner-loop evaluation ! &pooma; uses the &pete; Library to ensure inner loops involving &pooma;'s object-oriented containers run as quickly as hand-coded loops. &pete; (the Portable Expression Template *************** A += -B + 2 * C; *** 303,317 **** converted, at compile time, to a loop directly evaluating each component of the result without computing intermediate values. For example, the code corresponding to the statement above is ! ! vector<double>::iterator iterA = A.begin(); ! vector<int>::const_iterator iterB = B.begin(); ! vector<double>::const_iterator iterC = C.begin(); ! while (iterA != A.end()) { ! *iterA += -*iterB + 2 * *iterC; ! ++iterA; ++iterB; ++iterC; ! } ! Furthermore, since the code is available at compile time, not run time, it can be further optimized, e.g., moving any loop-invariant code out of the loop. --- 303,317 ---- converted, at compile time, to a loop directly evaluating each component of the result without computing intermediate values. For example, the code corresponding to the statement above is ! ! vector<double>::iterator iterA = A.begin(); ! vector<int>::const_iterator iterB = B.begin(); ! vector<double>::const_iterator iterC = C.begin(); ! while (iterA != A.end()) { ! *iterA += -*iterB + 2 * *iterC; ! ++iterA; ++iterB; ++iterC; ! } ! Furthermore, since the code is available at compile time, not run time, it can be further optimized, e.g., moving any loop-invariant code out of the loop. *************** A += -B + 2 * C; *** 330,340 **** as part of the U.S. government's science-based Stockpile Stewardship ! Program Stockpile Stewardship Program ! to simulate nuclear weapons. Other applications include a matrix solver, an accelerator code simulating the dynamics of high-intensity charged particle beams in linear accelerators, and a Monte Carlo --- 330,340 ---- as part of the U.S. government's science-based Stockpile Stewardship ! Program. Stockpile Stewardship Program ! Other applications include a matrix solver, an accelerator code simulating the dynamics of high-intensity charged particle beams in linear accelerators, and a Monte Carlo *************** A += -B + 2 * C; *** 400,406 ****

! &pooma; is Free, Open-Source Software open-source software --- 400,406 ----

! &pooma; is Open-Source Software open-source software *************** A += -B + 2 * C; *** 416,426 **** available, any programmer may add it. Any programmer can extend it to solve problems in previously unsupported domains. Companies using the &toolkit; can read the source code to ensure it has no ! security holes. It may be downloaded for free and used for perpetuity. There are no annual licenses and no on-going costs. By keeping their own copies, companies are guaranteed the software will never disappear. In summary, the ! &poomatoolkit; is free, low-risk software.

--- 416,426 ---- available, any programmer may add it. Any programmer can extend it to solve problems in previously unsupported domains. Companies using the &toolkit; can read the source code to ensure it has no ! security holes. It may be downloaded at no cost and used for perpetuity. There are no annual licenses and no on-going costs. By keeping their own copies, companies are guaranteed the software will never disappear. In summary, the ! &poomatoolkit; is low-risk software.

Acknowledgements ! Mark Mitchell, Stephen Smith

--- 352,397 ----

Acknowledgements + ]]> ! ! Acknowledgements ! ]]> ! ! This &book; would not have been completed without the help ! and encouragement of a lot of people and organizations. Los Alamos ! National Laboratory funded the writing of this manual and the ! development of the &poomatoolkit;. John Reynders conceived, ! advocated, and headed &pooma; development in its early days, and ! Scott Haney continued the leadership. Susan Atlas, Subhankar ! Banerjee, Timothy Cleland, Julian Cummings, James Crotinger, David ! Forslund, Salman Habib, Scott Haney, Paul Hinker, William Humphrey, ! Steve Karmesin, Graham Mark, Jeffrey D. Oldham, Ji Qiang, John ! Reynders, Robert Ryne, Stephen Smith, M. Srikant, Marydell ! Tholburn, and Timothy Williams all helped develop &pooma;. Rod ! Oldehoeft and Jeff Brown of Los Alamos National Laboratory ! supported CodeSourcery's and Proximation's work, including the ! development of this manual. John Hall, Don Marshall, Jean ! Marshall, and the rest of the BLANCA team at Los Alamos worked ! closely with the developers and provided valuable suggestions for ! improvements. ! ! I am grateful to James Crotinger, Mark Mitchell, and Stephen ! Smith who answered my many questions during the writing of this ! &book;. ! ! ! ! Jeffrey D. Oldham, 2002 January ! ! ! ! ! ]]> ! ! *************** UNFINISHED *** 3728,3734 **** ADD: Write this section, including extensive instructions ! for Unix, MS Windows, and MacOS. List the configuration options. Be sure to describe configuring for parallel execution. ]]> --- 3766,3772 ---- ADD: Write this section, including extensive instructions ! for Unix-like, MS Windows, and MacOS. List the configuration options. Be sure to describe configuring for parallel execution. ]]> *************** UNFINISHED *** 3751,3758 **** example, the &author; uses this library on a two-processor computer running &linux;. The library, available at http://www.engelschall.com/sw/mm/, ! is available for free and has been successfully tested on a ! variety of Unix platforms. We describe how to download and install the &mm; library. --- 3789,3796 ---- example, the &author; uses this library on a two-processor computer running &linux;. The library, available at http://www.engelschall.com/sw/mm/, ! is available at no cost and has been successfully tested on a ! variety of Unix-like platforms. We describe how to download and install the &mm; library. *************** UNFINISHED *** 3777,3784 **** specifying the &dashdash;help option. Since the &author; prefers to keep all &pooma;-related code in his poomasubdirectory, he ! uses ./configure ! &dashdash;prefix=${HOME}/pooma/mm-1.1.3. Create the library by issuing the --- 3815,3824 ---- specifying the &dashdash;help option. Since the &author; prefers to keep all &pooma;-related code in his poomasubdirectory, he ! uses ! ! ./configure &dashdash;prefix=${HOME}/pooma/mm-1.1.3 ! Create the library by issuing the *************** UNFINISHED *** 3825,3836 **** (FIXME: xref linkend="mpi99", ) ]]> ! or the &mm; ! Shared Memory Library. &mpi; works on a wide variety of platforms ! and has achieved widespread usage. &mm; works under Unix on any ! computer with shared memory. Both libraries are available for ! free. The instructions below work for whichever library you ! choose. We describe how to download and install &cheetah;. --- 3865,3875 ---- (FIXME: xref linkend="mpi99", ) ]]> ! or the &mm; Shared Memory Library. &mpi; works on a wide variety ! of platforms and has achieved widespread usage. &mm; works under ! Unix-like operating systems on any computer with shared memory. Both libraries are ! available at no cost. The instructions below work for whichever ! library you choose. We describe how to download and install &cheetah;. *************** UNFINISHED *** 3967,3974 **** Set the &cheetah; directory environment variable CHEETAHDIR to the directory containing the installed &cheetah; library. For ! example, declare -x ! CHEETAHDIR=${HOME}/pooma/cheetah-1.0 specifies the installation directory used in the previous section. If using the csh shell, use setenv CHEETAHDIR ${HOME}/pooma/cheetah-1.0. --- 4006,4015 ---- Set the &cheetah; directory environment variable CHEETAHDIR to the directory containing the installed &cheetah; library. For ! example, ! ! declare -x CHEETAHDIR=${HOME}/pooma/cheetah-1.0 ! specifies the installation directory used in the previous section. If using the csh shell, use setenv CHEETAHDIR ${HOME}/pooma/cheetah-1.0. Index: template.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/template.xml,v retrieving revision 1.2 diff -c -p -r1.2 template.xml *** template.xml 2002/01/24 05:11:21 1.2 --- template.xml 2002/01/29 18:11:25 *************** *** 104,111 **** values. All computation not involving run-time input or output can ! occur at program time, compile time, or run time, whichever is ! more convenient. At program time, a programmer can perform computations by hand rather than writing code to compute it. &cc; templates are Turing-complete so they can compute anything computable. Unfortunately, syntax for compile-time computation is --- 104,111 ---- values. All computation not involving run-time input or output can ! occur at programming time, compile time, or run time, whichever is ! more convenient. At programming time, a programmer can perform computations by hand rather than writing code to compute it. &cc; templates are Turing-complete so they can compute anything computable. Unfortunately, syntax for compile-time computation is *************** *** 257,265 **** function application ! A template class is analogous to a ! function. The analogy between compile-time and run-time ! programming constructs can be extended. lists these correspondences. For example, at run time, values consist of things such as integers, floating point numbers, --- 257,265 ---- function application ! A template class is analogous to a function; it is a function from ! types and constants to classes. The analogy between compile-time ! and run-time programming constructs can be extended. lists these correspondences. For example, at run time, values consist of things such as integers, floating point numbers, *************** struct usuallySimpleClass<false> { *** 770,778 **** creates a file containing the intermediate code. Unfortunately, ! reading and understanding the code is frequently difficult. ! Perhaps future &cc; compilers will support easy inspection of ! optimized code. Each category of values supports a distinct set of operations. For example, the run-time category of --- 770,776 ---- creates a file containing the intermediate code. Unfortunately, ! reading and understanding the code is frequently difficult. Each category of values supports a distinct set of operations. For example, the run-time category of *************** struct ExpressionTraits<BinaryNode< *** 834,840 **** { typedef typename ExpressionTraits<Left>::Type_t Left_t; typedef typename ExpressionTraits<Right>::Type_t Right_t; ! typedef typename CombineExpressionTraits<Left_t, Right_t>::Type_t Type_t; }; consists of a class definition and internal type definitions. This traits class contains three values, all types --- 832,839 ---- { typedef typename ExpressionTraits<Left>::Type_t Left_t; typedef typename ExpressionTraits<Right>::Type_t Right_t; ! typedef typename ! CombineExpressionTraits<Left_t, Right_t>::Type_t Type_t; }; consists of a class definition and internal type definitions. This traits class contains three values, all types *************** class F { *** 1027,1035 **** + operator is overloaded to add two &array;s, which require template parameters to specify: ! template <int D1,class T1,class E1,int D2,class T2,class E2> // complicated return type omitted ! operator+(const Array<D1,T1,E1> & l,const Array<D2,T2,E2> & r); Without using function templates, it would not be possible to write expressions such as a1 + a2. Member functions can also be templated. This --- 1026,1036 ---- + operator is overloaded to add two &array;s, which require template parameters to specify: ! template <int D1,class T1,class E1, ! int D2,class T2,class E2> // complicated return type omitted ! operator+(const Array<D1,T1,E1> & l, ! const Array<D2,T2,E2> & r); Without using function templates, it would not be possible to write expressions such as a1 + a2. Member functions can also be templated. This *************** template<class T> *** 1080,1086 **** struct CreateLeaf { typedef Scalar<T> Leaf_t; ! inline static Leaf_t make(const T& a) { return Scalar<T>(a); } }; Thus, CreateLeaf<T>::make is a function with --- 1081,1088 ---- struct CreateLeaf { typedef Scalar<T> Leaf_t; ! inline static Leaf_t make(const T& a) ! { return Scalar<T>(a); } }; Thus, CreateLeaf<T>::make is a function with Index: tutorial.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/tutorial.xml,v retrieving revision 1.7 diff -c -p -r1.7 tutorial.xml *** tutorial.xml 2002/01/24 05:11:21 1.7 --- tutorial.xml 2002/01/29 18:11:25 *************** *** 114,125 **** ]]> In this section, we describe how to obtain, build, and ! install the &poomatoolkit;. We focus on installing under the ! Unix operating system. . ]]> --- 114,125 ---- ]]> In this section, we describe how to obtain, build, and ! install the &poomatoolkit;. We focus on installing under a ! Unix-like operating system. . ]]> *************** *** 141,147 **** class="libraryfile">LINUXgcc.conf supports compiling under a &linux; operating system with &gcc;, while SGI64KCC.conf supports compiling ! under a 64-bit SGI Unix operating system with &kcc;. Next, configure the source code: ./configure &dashdash;arch LINUXgcc &dashdash;opt &dashdash;suite --- 141,147 ---- class="libraryfile">LINUXgcc.conf supports compiling under a &linux; operating system with &gcc;, while SGI64KCC.conf supports compiling ! under a 64-bit SGI Irix operating system with &kcc;. Next, configure the source code: ./configure &dashdash;arch LINUXgcc &dashdash;opt &dashdash;suite *************** *** 715,721 **** ! the &pooma; distributed computation model The &pooma; distributed computation model creates a layout --- 715,723 ---- ! The &pooma; distributed computation model has three ! pieces: partitioning domain, computer configuration, and ! layout. The &pooma; distributed computation model creates a layout *************** *** 793,801 **** template parameter is Remote. Its Brick template parameter specifies the &engine; for a particular patch on a particular context. Most distributed programs use ! MultiPatch<UniformTag, Remote<Brick> > or ! MultiPatch<UniformTag, Remote<CompressibleBrick> ! > &engine;s. The computations for a distributed implementation are exactly the same as for a sequential implementation. The &poomatoolkit; and --- 795,806 ---- template parameter is Remote. Its Brick template parameter specifies the &engine; for a particular patch on a particular context. Most distributed programs use ! ! MultiPatch<UniformTag, Remote<Brick&closeclose; ! or ! ! MultiPatch<UniformTag, Remote<CompressibleBrick&closeclose; ! or &engine;s. The computations for a distributed implementation are exactly the same as for a sequential implementation. The &poomatoolkit; and From oldham at codesourcery.com Wed Jan 30 23:13:24 2002 From: oldham at codesourcery.com (Jeffrey D . Oldham) Date: Wed, 30 Jan 2002 15:13:24 -0800 Subject: Manual: Today's Patch Message-ID: <20020130151324.A25694@vaio.codesourcery.com> The POOMA manual must be delivered tomorrow. The formatting changes continue, but the volume decreases. 2002-Jan-30 Jeffrey D. Oldham * Makefile: Clean to convert from a general Makefile to one for creating the POOMA manual. * arrays.xml: Revise tags to ones that are implemented by DocBook. * concepts.xml: Revise figures to support PostScript and HTML/PDF. * data-parallel.xml: Likewise. * introduction.xml: Likewise. * manual.xml: Remove FIXME comment. * template.xml: Shorten section titles. Reformat type. * tutorial.xml: Revise figures to support PostScript and HTML/PDF. Applied to mainline Approved by Jeff Brown. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Makefile =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/Makefile,v retrieving revision 1.2 diff -c -p -r1.2 Makefile *** Makefile 2002/01/25 02:28:25 1.2 --- Makefile 2002/01/30 22:59:22 *************** *** 1,74 **** ### Oldham, Jeffrey D. ! ### 1997 Dec 26 ! ### misc ### ! ### LaTeX -> PostScript/PDF/WWW ! ### XML -> TeX/DVI/PS/PDF - # Definitions for PostScript and WWW Creation TEX= latex - WWWHOMEDIR= /u/oldham/www - LATEX2HTML= latex2html - BASICLATEX2HTMLOPTIONS= -info "" -no_footnode -no_math -html_version 3.2,math - #LATEX2HTMLOPTIONS= -local_icons -split +1 $(BASICLATEX2HTMLOPTIONS) - LATEX2HTMLOPTIONS= -no_navigation -split 0 $(BASICLATEX2HTMLOPTIONS) - MPOST= mpost # Definitions for Jade. JADEDIR= /usr/lib/sgml/stylesheets/docbook ! PRINTDOCBOOKDSL= print/docbook.dsl ! HTMLDOCBOOKDSL= html/docbook.dsl XML= dtds/decls/xml.dcl INDEXOPTIONS= -t 'Index' -i 'index' -g -p ! CXXFLAGS= -g -Wall -pedantic -W -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wcast-align -Wconversion -Wnested-externs -Wundef -Winline -static ! all: manual.ps ! manual.dvi: manual.xml introduction.xml template.xml tutorial.xml \ ! concepts.xml arrays.xml data-parallel.xml glossary.xml \ ! bibliography.xml ! %.all: %.ps %.pdf %.html ! chmod 644 $*.ps $*.pdf ! mv $*.ps $*.pdf $* ! ! %.dvi: %.ltx ! $(TEX) $< ! # bibtex $* ! # $(TEX) $< ! $(TEX) $< ! ! %.ps: %.dvi ! dvips -t letter $< -o ! ! %.pdf.ltx: %.ltx ! sed -e 's/^%\\usepackage{times}/\\usepackage{times}/' $< > $@ ! ! %.pdf: %.pdf.ltx ! pdflatex $< ! mv $@.pdf $@ ! # This rule assumes index creation. ! %.dvi: %.xml genindex.sgm ! jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) -V html-index $(XML) $< && \ ! perl collateindex.pl $(INDEXOPTIONS) -o genindex.sgm HTML.index && \ ! jade -D$(JADEDIR) -t tex -d $(PRINTDOCBOOKDSL) -V tex-backend $(XML) $< && jadetex $*.tex && jadetex $*.tex && jadetex $*.tex genindex.sgm: perl collateindex.pl $(INDEXOPTIONS) -N -o $@ ! %.html: %.xml jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) $(XML) $< ! %.pdf: %.xml ! jade -D$(JADEDIR) -t tex -d $(PRINTDOCBOOKDSL) $(XML) $< && pdfjadetex $*.tex && pdfjadetex $*.tex ! ! mproof-%.ps: %.mp ! declare -x TEX=latex && $(MPOST) $< && tex mproof.tex $*.[0-9]* && dvips mproof.dvi -o $@ ! %.txt: %.ltx ! detex $< > $@ clean: ! rm -f *.dvi *.aux *.log *.toc *.bak *.blg *.bbl *.glo *.idx *.lof *.lot *.htm *.mpx mpxerr.tex HTML.index manual.tex genindex.sgm --- 1,54 ---- ### Oldham, Jeffrey D. ! ### 2002Jan29 ! ### POOMA ### ! ### POOMA Manual Creation TEX= latex # Definitions for Jade. JADEDIR= /usr/lib/sgml/stylesheets/docbook ! PRINTDOCBOOKDSL= print.dsl # print/docbook.dsl ! HTMLDOCBOOKDSL= html.dsl # html/docbook.dsl XML= dtds/decls/xml.dcl INDEXOPTIONS= -t 'Index' -i 'index' -g -p ! XMLSOURCES= manual.xml introduction.xml template.xml tutorial.xml \ ! concepts.xml arrays.xml data-parallel.xml glossary.xml \ ! bibliography.xml ! ## HERE How do I include dependences on programs? ! all: manual.ps manual.pdf manual.html ! manual.dvi manual.pdf manual.html: $(XMLSOURCES) figures ! figures: ! $(MAKE) -C figures genindex.sgm: perl collateindex.pl $(INDEXOPTIONS) -N -o $@ ! %.html: %.xml html.dsl jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) $(XML) $< ! # This rule assumes index creation. ! %.dvi: %.xml genindex.sgm print.dsl ! jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) -V html-index $(XML) $< ! perl collateindex.pl $(INDEXOPTIONS) -o genindex.sgm HTML.index ! jade -D$(JADEDIR) -t tex -d $(PRINTDOCBOOKDSL) -V tex-backend -V use-eps $(XML) $< ! jadetex $*.tex ! jadetex $*.tex ! jadetex $*.tex ! # This rule assumes index creation. ! %.pdf: %.xml genindex.sgm print.dsl ! jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) -V html-index $(XML) $< ! perl collateindex.pl $(INDEXOPTIONS) -o genindex.sgm HTML.index ! jade -D$(JADEDIR) -t tex -d $(PRINTDOCBOOKDSL) $(XML) $< ! pdfjadetex $*.tex ! pdfjadetex $*.tex ! pdfjadetex $*.tex clean: ! rm -f *.dvi *.aux *.log *.toc *.bak *.blg *.bbl *.glo *.idx *.lof *.lot *.htm *.html *.mpx mpxerr.tex HTML.index manual.tex genindex.sgm pooma-html.manifest Index: arrays.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/arrays.xml,v retrieving revision 1.5 diff -c -p -r1.5 arrays.xml *** arrays.xml 2002/01/29 21:45:42 1.5 --- arrays.xml 2002/01/30 22:59:23 *************** std::cout &openopen; a.read(2,-2) &openo *** 1644,1651 **** domain index to a particular processor and memory used to compute the associated value. The two internal enumerations ! dimensions and ! rank both record the &array;'s dimension. The two internal enumerations ! dimensions and ! rank both record the &array;'s dimension.

+ + + concepts involved in declaring containers *************** *** 355,360 **** --- 358,366 ---- + + + &array;s and &field;s map from indices to values. Index: data-parallel.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/data-parallel.xml,v retrieving revision 1.4 diff -c -p -r1.4 data-parallel.xml *** data-parallel.xml 2002/01/29 21:45:42 1.4 --- data-parallel.xml 2002/01/30 22:59:25 *************** Array<2, double, Brick> A(I,I), B(J,H); *** 123,128 **** --- 123,131 ---- + + + Adding two arrays with different domains adds values with the same indices. *************** Expression<BinaryNode<OpAdd, *** 985,990 **** --- 988,996 ---- + + + A parse tree for the statement is produced. Index: introduction.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/introduction.xml,v retrieving revision 1.5 diff -c -p -r1.5 introduction.xml *** introduction.xml 2002/01/29 21:45:42 1.5 --- introduction.xml 2002/01/30 22:59:26 *************** *** 126,131 **** --- 126,134 ---- + + + &pooma; helps translate algorithms into programs. Index: manual.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/manual.xml,v retrieving revision 1.11 diff -c -p -r1.11 manual.xml *** manual.xml 2002/01/29 21:45:42 1.11 --- manual.xml 2002/01/30 22:59:29 *************** *** 1,6 **** - Correspondences Between Run-Time and Compile-Time ! Programming Constructs --- 281,287 ---- orient="port" pgwide="0" id="template_programming-template_use-correspondence_table"> Correspondences Between Run-Time and Compile-Time ! Constructs *************** typedef typename Engine_t::Domain_t Doma *** 524,530 **** orient="port" pgwide="0" id="template_programming-pooma_implementation-correspondence_table"> More Correspondences Between Run-Time and Compile-Time ! Programming Constructs --- 524,530 ---- orient="port" pgwide="0" id="template_programming-pooma_implementation-correspondence_table"> More Correspondences Between Run-Time and Compile-Time ! Constructs *************** struct CreateLeaf<Expression<T&clo *** 943,949 **** matches the condition is executed. If no case label matches the condition, the default code, if present, is used. In template programming, instantiating a template, e.g., ! CreateLeaf<Expression<int&closeclose; serves as the condition. The set of template parameters for the indicated template class, e.g., CreateLeaf, are analogous to the case labels, and each has an associated definition. In our --- 943,951 ---- matches the condition is executed. If no case label matches the condition, the default code, if present, is used. In template programming, instantiating a template, e.g., ! ! CreateLeaf<Expression<int&closeclose; ! serves as the condition. The set of template parameters for the indicated template class, e.g., CreateLeaf, are analogous to the case labels, and each has an associated definition. In our Index: tutorial.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/tutorial.xml,v retrieving revision 1.8 diff -c -p -r1.8 tutorial.xml *** tutorial.xml 2002/01/29 21:45:42 1.8 --- tutorial.xml 2002/01/30 22:59:31 *************** *** 69,74 **** --- 69,77 ---- + + + The Initial &doof2d; Configuration *************** *** 77,82 **** --- 80,88 ---- + + + After the First Averaging *************** *** 85,90 **** --- 91,99 ---- + + + After the Second Averaging *************** *** 484,489 **** --- 493,501 ---- + + + Adding two arrays is supported. *************** *** 580,585 **** --- 592,600 ---- + + + Apply a stencil to position (1,3) of an &array;. *************** *** 713,718 **** --- 728,736 ---- + + + The &pooma; distributed computation model has three From oldham at codesourcery.com Wed Jan 30 23:43:15 2002 From: oldham at codesourcery.com (Jeffrey D . Oldham) Date: Wed, 30 Jan 2002 15:43:15 -0800 Subject: Manual Patch: Figure Code Message-ID: <20020130154315.A25949@vaio.codesourcery.com> 2002-Jan-30 Jeffrey D. Oldham This patch moves most, hopefully all, of the manual's figure creation code into the CVS tree. Including the PNG files, used for the HTML and PDF versions of the manual, is not strictly necessary since they can be created. However, converting the EPS files created MetaPost to PNG uses the non-standard peps program so I include them in the tree. The MetaPost source files were modified to include fonts in the initial comments. * concepts-101.png: New illustration. * concepts-111.png: Likewise. * concepts.mp: Minor tweaking. Include fonts in comments. * data-parallel-101.png: New illustration. * data-parallel-212.png: Likewise. * data-parallel.mp: Minor tweaking. Include fonts in comments. * distributed-101.png: New illustration. * distributed.mp: Minor tweaking. Include fonts in comments. Fix labelling of context box. * doof2d-201.png: New illustration. * doof2d-202.png: Likewise. * doof2d-203.png: Likewise. * doof2d-210.png: Likewise. * doof2d-211.png: Likewise. * doof2d.mp: Minor tweaking. Include fonts in comments. Modify to avoid kerning problems. Avoid math font problem by omitting '$...$'. * introduction-101.png: New illustration. * introduction.mp: Minor tweaking. Include fonts in comments. * macros.ltx: Avoid macros to avoid kerning problems. Applied to mainline. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: concepts-101.png =================================================================== RCS file: concepts-101.png diff -N concepts-101.png Binary files /dev/null and concepts-101.png differ Index: concepts-111.png =================================================================== RCS file: concepts-111.png diff -N concepts-111.png Binary files /dev/null and concepts-111.png differ Index: concepts.mp =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/concepts.mp,v retrieving revision 1.3 diff -c -p -r1.3 concepts.mp *** concepts.mp 2001/12/14 04:18:13 1.3 --- concepts.mp 2002/01/30 23:17:45 *************** *** 6,23 **** %% Assumes TEX=latex. input boxes; verbatimtex ! \documentclass[10pt]{article} \input{macros.ltx} \begin{document} etex %% Container Declaration Concepts and Dependences beginfig(111) ! numeric unit; unit = 0.9cm; numeric horizSpace; horizSpace = unit; numeric vertSpace; vertSpace = unit; --- 6,27 ---- %% Assumes TEX=latex. + %% Ensure fonts are included in the output. + prologues := 2; % >= 2 for PostScript + input boxes; verbatimtex ! \documentclass[12pt]{article} \input{macros.ltx} + \usepackage{times} \begin{document} etex %% Container Declaration Concepts and Dependences beginfig(111) ! numeric unit; unit = 0.5cm; numeric horizSpace; horizSpace = unit; numeric vertSpace; vertSpace = unit; Index: data-parallel-101.png =================================================================== RCS file: data-parallel-101.png diff -N data-parallel-101.png Binary files /dev/null and data-parallel-101.png differ Index: data-parallel-212.png =================================================================== RCS file: data-parallel-212.png diff -N data-parallel-212.png Binary files /dev/null and data-parallel-212.png differ Index: data-parallel.mp =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/data-parallel.mp,v retrieving revision 1.1 diff -c -p -r1.1 data-parallel.mp *** data-parallel.mp 2002/01/04 17:42:43 1.1 --- data-parallel.mp 2002/01/30 23:17:45 *************** *** 6,18 **** %% Assumes TEX=latex. input boxes; input box-macros; input grid-macros; verbatimtex ! \documentclass[10pt]{article} \input{macros.ltx} \begin{document} etex --- 6,22 ---- %% Assumes TEX=latex. + %% Ensure fonts are included in the output. + prologues := 2; % >= 2 for PostScript + input boxes; input box-macros; input grid-macros; verbatimtex ! \documentclass[12pt]{article} \input{macros.ltx} + \usepackage{times} \begin{document} etex Index: distributed-101.png =================================================================== RCS file: distributed-101.png diff -N distributed-101.png Binary files /dev/null and distributed-101.png differ Index: distributed.mp =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/distributed.mp,v retrieving revision 1.2 diff -c -p -r1.2 distributed.mp *** distributed.mp 2001/12/11 20:36:13 1.2 --- distributed.mp 2002/01/30 23:17:47 *************** *** 6,16 **** %% Assumes TEX=latex. input boxes; verbatimtex ! \documentclass[10pt]{article} \input{macros.ltx} \begin{document} etex --- 6,20 ---- %% Assumes TEX=latex. + %% Ensure fonts are included in the output. + prologues := 2; % >= 2 for PostScript + input boxes; verbatimtex ! \documentclass[12pt]{article} \input{macros.ltx} + \usepackage{times} \begin{document} etex *************** beginfig(101) *** 174,181 **** drawboxed(c[t]); endfor label.top(btex contexts etex, c[1].n); - label.bot(btex \begin{tabular}{c} Each context has memory and\\ processors to execute a program. \end{tabular} etex, c[1].s); drawboxed(configurationBoundary); label.top(btex Computer Configuration etex, configurationBoundary.n); %% Draw the Computer Computation structures. --- 178,188 ---- drawboxed(c[t]); endfor label.top(btex contexts etex, c[1].n); drawboxed(configurationBoundary); + picture foo; + foo = thelabel.bot(btex \begin{tabular}{c} Each context has memory and\\ processors to execute a program. \end{tabular} etex, c[1].s); + unfill bbox foo; + draw foo; label.top(btex Computer Configuration etex, configurationBoundary.n); %% Draw the Computer Computation structures. Index: doof2d-201.png =================================================================== RCS file: doof2d-201.png diff -N doof2d-201.png Binary files /dev/null and doof2d-201.png differ Index: doof2d-202.png =================================================================== RCS file: doof2d-202.png diff -N doof2d-202.png Binary files /dev/null and doof2d-202.png differ Index: doof2d-203.png =================================================================== RCS file: doof2d-203.png diff -N doof2d-203.png Binary files /dev/null and doof2d-203.png differ Index: doof2d-210.png =================================================================== RCS file: doof2d-210.png diff -N doof2d-210.png Binary files /dev/null and doof2d-210.png differ Index: doof2d-211.png =================================================================== RCS file: doof2d-211.png diff -N doof2d-211.png Binary files /dev/null and doof2d-211.png differ Index: doof2d.mp =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/doof2d.mp,v retrieving revision 1.4 diff -c -p -r1.4 doof2d.mp *** doof2d.mp 2002/01/25 02:58:25 1.4 --- doof2d.mp 2002/01/30 23:17:47 *************** *** 6,17 **** %% Assumes TEX=latex. verbatimtex ! \documentclass[10pt]{article} \input{macros.ltx} \begin{document} etex input grid-macros; %% Global Declarations --- 6,23 ---- %% Assumes TEX=latex. + %% Ensure fonts are included in the output. + prologues := 2; % >= 2 for PostScript + verbatimtex ! \documentclass[12pt]{article} ! \usepackage{times} \input{macros.ltx} \begin{document} + etex + input grid-macros; %% Global Declarations *************** beginfig(201) *** 37,43 **** endfor % Label the grid. ! labelGrid(btex Array \varname{b}: Initial Configuration etex, nuCells, origin); endfig; --- 43,49 ---- endfor % Label the grid. ! labelGrid(btex Array \varname{b}: Initial Con\avoidfi guration etex, nuCells, origin); endfig; *************** beginfig(202) *** 66,72 **** endfor % Label the grid. ! labelGrid(btex Array \varname{a}: After the first averaging etex, nuCells, origin); endfig; --- 72,78 ---- endfor % Label the grid. ! labelGrid(btex Array \varname{a}: After the \avoidfi rst averaging etex, nuCells, origin); endfig; *************** beginfig(210) *** 186,194 **** labelCellLeft(btex \footnotesize 2 etex, (0,2), z0); %% Label the grids. ! labelGrid(btex $b(I,J)+b(I+1,J-1)$ etex, nuCells, z0); ! labelGrid(btex $b(I,J)$ etex, nuCells, z1); ! labelGrid(btex $b(I+1,J-1)$ etex, nuCells, z2); endfig; --- 192,203 ---- labelCellLeft(btex \footnotesize 2 etex, (0,2), z0); %% Label the grids. ! %% Avoid mpost problem. labelGrid(btex $b(I,J)+b(I+1,J-1)$ etex, nuCells, z0); ! %% Avoid mpost problem. labelGrid(btex $b(I,J)$ etex, nuCells, z1); ! %% Avoid mpost problem. labelGrid(btex $b(I+1,J-1)$ etex, nuCells, z2); ! labelGrid(btex b(I,J)+b(I+1,J-1) etex, nuCells, z0); ! labelGrid(btex b(I,J) etex, nuCells, z1); ! labelGrid(btex b(I+1,J-1) etex, nuCells, z2); endfig; Index: introduction-101.png =================================================================== RCS file: introduction-101.png diff -N introduction-101.png Binary files /dev/null and introduction-101.png differ Index: introduction.mp =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/introduction.mp,v retrieving revision 1.3 diff -c -p -r1.3 introduction.mp *** introduction.mp 2002/01/25 02:58:25 1.3 --- introduction.mp 2002/01/30 23:17:47 *************** *** 6,18 **** %% Assumes TEX=latex. input boxes; input box-macros; verbatimtex ! \documentclass[10pt]{article} \usepackage{amsmath} \input{macros.ltx} \begin{document} etex --- 6,22 ---- %% Assumes TEX=latex. + %% Ensure fonts are included in the output. + prologues := 2; % >= 2 for PostScript + input boxes; input box-macros; verbatimtex ! \documentclass[12pt]{article} \usepackage{amsmath} \input{macros.ltx} + \usepackage{times} \begin{document} etex Index: macros.ltx =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/macros.ltx,v retrieving revision 1.2 diff -c -p -r1.2 macros.ltx *** macros.ltx 2002/01/25 02:58:25 1.2 --- macros.ltx 2002/01/30 23:17:47 *************** *** 35,37 **** --- 35,43 ---- \newcommand{\varname}[1]{\texttt{#1}}% % Produce a C++ (or other programming language) variable. % Requires: 1. the variable's name. + + % Avoid dvitomp Errors. + \newcommand{\avoidfi}{f\mbox{}i}% + % Avoid a problem with dvitomp and ligatures. + \newcommand{\avoidFi}{F\mbox{}i}% + % Avoid a problem with dvitomp and ligatures. From oldham at codesourcery.com Wed Jan 30 23:54:45 2002 From: oldham at codesourcery.com (Jeffrey D . Oldham) Date: Wed, 30 Jan 2002 15:54:45 -0800 Subject: Manual Patch: Use Standard DocBook Tags Message-ID: <20020130155445.A26013@vaio.codesourcery.com> 2002-Jan-30 Jeffrey D. Oldham Before this change, the POOMA manual used non-standard tags to describe programming language features: , , , . Since these are not standard, we replace them with , losing information. :( * arrays.xml: Replace , , , and with . * concepts.xml: Likewise. * data-parallel.xml: Likewise. * glossary.xml: Likewise. * introduction.xml: Likewise. * manual.xml: Likewise. * template.xml: Likewise. * tutorial.xml: Likewise. Applied to mainline. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: arrays.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/arrays.xml,v retrieving revision 1.6 diff -c -p -r1.6 arrays.xml *** arrays.xml 2002/01/30 23:09:06 1.6 --- arrays.xml 2002/01/30 23:47:30 *************** *** 79,85 **** objects so they can be used more easily than built-in &cc; arrays. For example, &array;s can be used as operands and in assignment statements. The statement ! a = a + b; adds corresponding values of &array;s a and b, assigning the sums to the &array; a. The statement treats each array as an object, rather than requiring the use of --- 79,85 ---- objects so they can be used more easily than built-in &cc; arrays. For example, &array;s can be used as operands and in assignment statements. The statement ! a = a + b; adds corresponding values of &array;s a and b, assigning the sums to the &array; a. The statement treats each array as an object, rather than requiring the use of *************** *** 87,94 **** statements such as this are further discussed in . &array;s also handle their own memory allocation and deallocation. For example, the &array; ! declaration Array<2, double, Brick> ! a(vertDomain) creates an &array; a, allocating whatever memory it needs. When a goes out of scope, it and its memory are automatically deallocated. Automatic memory allocation --- 87,94 ---- statements such as this are further discussed in . &array;s also handle their own memory allocation and deallocation. For example, the &array; ! declaration Array<2, double, Brick> ! a(vertDomain) creates an &array; a, allocating whatever memory it needs. When a goes out of scope, it and its memory are automatically deallocated. Automatic memory allocation *************** *** 96,102 **** Individual &array; values can be accessed using parentheses, not square brackets, as for &cc; arrays. For example, ! a(3,4) yields the value at position (3,4) of a's two-dimensional domain. --- 96,102 ---- Individual &array; values can be accessed using parentheses, not square brackets, as for &cc; arrays. For example, ! a(3,4) yields the value at position (3,4) of a's two-dimensional domain. *************** *** 179,188 **** All the &domain; categories listed above except &grid; can be represented using domain triplet notation. Since the triplet [7:7:1] represents {7}, or more simply 7, it can also ! represent the one-dimensional Loc<1>(7). Multidimensional &loc;s are similarly represented. For example, [0:0:1,10:10:1,2:2:1] represents ! Loc<3>(0,10,2), but it is frequently abbreviated as [0,10,2]. An &interval; [a,b] has unit stride: [a:b:1], while a ⦥ has specific stride s, e.g., [a:b:s]. --- 179,188 ---- All the &domain; categories listed above except &grid; can be represented using domain triplet notation. Since the triplet [7:7:1] represents {7}, or more simply 7, it can also ! represent the one-dimensional Loc<1>(7). Multidimensional &loc;s are similarly represented. For example, [0:0:1,10:10:1,2:2:1] represents ! Loc<3>(0,10,2), but it is frequently abbreviated as [0,10,2]. An &interval; [a,b] has unit stride: [a:b:1], while a ⦥ has specific stride s, e.g., [a:b:s]. *************** *** 192,199 **** &interval; is the direct product of two one-dimensional &interval;s, it can be specified using two one-dimensional &interval;s. For example, ! Interval<2>(Interval<1>(2,3), ! Interval<1>(4,5)) creates a [2:3:1,4:5:1] &domain;. The resulting dimensionality equals the sum of the components' dimensions. For example, a four-dimension &loc; can be specified using three- and one-dimension &loc;s or using four --- 192,199 ---- &interval; is the direct product of two one-dimensional &interval;s, it can be specified using two one-dimensional &interval;s. For example, ! Interval<2>(Interval<1>(2,3), ! Interval<1>(4,5)) creates a [2:3:1,4:5:1] &domain;. The resulting dimensionality equals the sum of the components' dimensions. For example, a four-dimension &loc; can be specified using three- and one-dimension &loc;s or using four *************** *** 206,217 **** different types. A &loc; object can be constructed from other &loc; objects and integers. &interval;s, ⦥s, and &grid;s can be constructed using any of these types, &loc;s, and integers. ! For example, Interval<3> a(Loc<2>(1,2), ! Interval<1>(3,5)) uses a two-dimensional &loc; and a one-dimensional &interval; to create a [1:1:1,2:2:1,3:5:1] &domain;. During creation of a &domain;, the type of each object is changed to the &domain;'s type. In the example, ! Loc<2>(1,2) is first converted to an &interval;. &domain;s can participate in some arithmetic and comparison --- 206,217 ---- different types. A &loc; object can be constructed from other &loc; objects and integers. &interval;s, ⦥s, and &grid;s can be constructed using any of these types, &loc;s, and integers. ! For example, Interval<3> a(Loc<2>(1,2), ! Interval<1>(3,5)) uses a two-dimensional &loc; and a one-dimensional &interval; to create a [1:1:1,2:2:1,3:5:1] &domain;. During creation of a &domain;, the type of each object is changed to the &domain;'s type. In the example, ! Loc<2>(1,2) is first converted to an &interval;. &domain;s can participate in some arithmetic and comparison *************** *** 293,317 **** ! Loc<1>() indicates zero. ! Loc<1>(const Pooma::NoInit& no) creates an uninitialized &locone;, to be assigned a value later. ! Loc<1>(const &domaintemplate;1& t1) creates a &locone; with the integer converted from t1. ! Loc<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates a &locone; with the integer converted from t1. t2 must equal t1. ! Loc<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates a &locone; with the integer converted from t1. t2 must equal t1, and t3 is --- 293,317 ---- ! Loc<1>() indicates zero. ! Loc<1>(const Pooma::NoInit& no) creates an uninitialized &locone;, to be assigned a value later. ! Loc<1>(const &domaintemplate;1& t1) creates a &locone; with the integer converted from t1. ! Loc<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates a &locone; with the integer converted from t1. t2 must equal t1. ! Loc<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates a &locone; with the integer converted from t1. t2 must equal t1, and t3 is *************** *** 360,405 **** ! Loc<&dim;>() indicates zero. ! Loc<&dim;>(const Pooma::NoInit& no) creates an uninitialized &loc;, to be assigned a value later. ! Loc<&dim;>(const &domaintemplate;1& t1) creates a &loc; using the given &domain; object. ! Loc<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates a &loc; using the given &domain; objects. ! Loc<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates a &loc; using the given &domain; objects. ! Loc<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) creates a &loc; using the given &domain; objects. ! Loc<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5) creates a &loc; using the given &domain; objects. ! Loc<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6) creates a &loc; using the given &domain; objects. ! Loc<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) creates a &loc; using the given &domain; objects. --- 360,405 ---- ! Loc<&dim;>() indicates zero. ! Loc<&dim;>(const Pooma::NoInit& no) creates an uninitialized &loc;, to be assigned a value later. ! Loc<&dim;>(const &domaintemplate;1& t1) creates a &loc; using the given &domain; object. ! Loc<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates a &loc; using the given &domain; objects. ! Loc<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates a &loc; using the given &domain; objects. ! Loc<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) creates a &loc; using the given &domain; objects. ! Loc<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5) creates a &loc; using the given &domain; objects. ! Loc<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6) creates a &loc; using the given &domain; objects. ! Loc<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) creates a &loc; using the given &domain; objects. *************** *** 418,425 **** to a multidimensional &domain; object that itself can be converted into a &loc;. The total dimensionality of all the arguments' types should be at most &dim;. For example, ! Loc<5>(Range<1>(2,2,2), Loc<2>(2,3), ! Interval<1>(4,4)) creates a five-dimensional &loc; [2,2,3,4,1] using a one-dimensional ⦥, a two-dimensional &loc;, and a one-dimensional &interval;. The final fifth dimension has an unspecified value, in this case 1. The --- 418,425 ---- to a multidimensional &domain; object that itself can be converted into a &loc;. The total dimensionality of all the arguments' types should be at most &dim;. For example, ! Loc<5>(Range<1>(2,2,2), Loc<2>(2,3), ! Interval<1>(4,4)) creates a five-dimensional &loc; [2,2,3,4,1] using a one-dimensional ⦥, a two-dimensional &loc;, and a one-dimensional &interval;. The final fifth dimension has an unspecified value, in this case 1. The *************** *** 466,489 **** ! Interval<1>() creates an empty, uninitialized interval. ! Interval<1>(const Pooma::NoInit& no) creates an uninitialized &intervalone;, to be assigned a value later. ! Interval<1>(const &domaintemplate;1& t1) creates an &intervalone;. See the text for an explanation. ! Interval<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates an &intervalone; with the integers converted from t1 and t2. ! Interval<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates an &intervalone; with the integers converted from t1 and t2. t3 must equal 1. --- 466,489 ---- ! Interval<1>() creates an empty, uninitialized interval. ! Interval<1>(const Pooma::NoInit& no) creates an uninitialized &intervalone;, to be assigned a value later. ! Interval<1>(const &domaintemplate;1& t1) creates an &intervalone;. See the text for an explanation. ! Interval<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates an &intervalone; with the integers converted from t1 and t2. ! Interval<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates an &intervalone; with the integers converted from t1 and t2. t3 must equal 1. *************** *** 532,577 **** ! Interval<&dim;>() creates an empty, uninitialized &interval;, to be assigned a value later. ! Interval<&dim;>(const Pooma::NoInit& no) creates an empty, uninitialized &interval;, to be assigned a value later. ! Interval<&dim;>(const &domaintemplate;1& t1) creates an &interval; using the given &domain; object. ! Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates an &interval; using the given &domain; objects. ! Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates an &interval; using the given &domain; objects. ! Interval<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) creates an &interval; using the given &domain; objects. ! Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5) creates an &interval; using the given &domain; objects. ! Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6) creates an &interval; using the given &domain; objects. ! Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) creates an &interval; using the given &domain; objects. --- 532,577 ---- ! Interval<&dim;>() creates an empty, uninitialized &interval;, to be assigned a value later. ! Interval<&dim;>(const Pooma::NoInit& no) creates an empty, uninitialized &interval;, to be assigned a value later. ! Interval<&dim;>(const &domaintemplate;1& t1) creates an &interval; using the given &domain; object. ! Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates an &interval; using the given &domain; objects. ! Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates an &interval; using the given &domain; objects. ! Interval<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) creates an &interval; using the given &domain; objects. ! Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5) creates an &interval; using the given &domain; objects. ! Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6) creates an &interval; using the given &domain; objects. ! Interval<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) creates an &interval; using the given &domain; objects. *************** *** 637,661 **** ! Range<1>() creates an empty, uninitialized range. ! Range<1>(const Pooma::NoInit& no) creates an uninitialized &rangeone;, to be assigned a value later. ! Range<1>(const &domaintemplate;1& t1) creates a &rangeone;. See the text for an explanation. ! Range<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates a &rangeone; with an interval specified by the integers converted from t1 and t2. ! Range<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates a &rangeone; by converting the arguments to integers i1, i2, and i3 and then making a range [i1:i2:i3]. --- 637,661 ---- ! Range<1>() creates an empty, uninitialized range. ! Range<1>(const Pooma::NoInit& no) creates an uninitialized &rangeone;, to be assigned a value later. ! Range<1>(const &domaintemplate;1& t1) creates a &rangeone;. See the text for an explanation. ! Range<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates a &rangeone; with an interval specified by the integers converted from t1 and t2. ! Range<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates a &rangeone; by converting the arguments to integers i1, i2, and i3 and then making a range [i1:i2:i3]. *************** *** 702,747 **** ! Range<&dim;>() creates an empty, uninitialized ⦥, to be assigned a value later. ! Range<&dim;>(const Pooma::NoInit& no) creates an empty, uninitialized ⦥, to be assigned a value later. ! Range<&dim;>(const &domaintemplate;1& t1) creates a ⦥ using the given &domain; object. ! Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates a ⦥ using the given &domain; objects. ! Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates a ⦥ using the given &domain; objects. ! Range<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) creates a ⦥ using the given &domain; objects. ! Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5) creates a ⦥ using the given &domain; objects. ! Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6) creates a ⦥ using the given &domain; objects. ! Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) creates a ⦥ using the given &domain; objects. --- 702,747 ---- ! Range<&dim;>() creates an empty, uninitialized ⦥, to be assigned a value later. ! Range<&dim;>(const Pooma::NoInit& no) creates an empty, uninitialized ⦥, to be assigned a value later. ! Range<&dim;>(const &domaintemplate;1& t1) creates a ⦥ using the given &domain; object. ! Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates a ⦥ using the given &domain; objects. ! Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates a ⦥ using the given &domain; objects. ! Range<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) creates a ⦥ using the given &domain; objects. ! Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5) creates a ⦥ using the given &domain; objects. ! Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6) creates a ⦥ using the given &domain; objects. ! Range<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) creates a ⦥ using the given &domain; objects. *************** *** 811,831 **** ! Grid<1>() creates an empty, uninitialized grid. ! Grid<1>(const &domaintemplate;1& t1) creates a &gridone;. See the text for an explanation. ! Grid<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates a &gridone; from the interval specified by the integers converted from t1 and t2. ! Grid<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates a &gridone; from the domain triplet specified by the integers converted from t1, t2, and t3. --- 811,831 ---- ! Grid<1>() creates an empty, uninitialized grid. ! Grid<1>(const &domaintemplate;1& t1) creates a &gridone;. See the text for an explanation. ! Grid<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates a &gridone; from the interval specified by the integers converted from t1 and t2. ! Grid<1>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates a &gridone; from the domain triplet specified by the integers converted from t1, t2, and t3. *************** Grid<1> g(list); *** 889,930 **** ! Grid<&dim;>() creates an empty, uninitialized &grid;, to be assigned a value later. ! Grid<&dim;>(const &domaintemplate;1& t1) creates a &grid; using the given &domain; object. ! Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates a &grid; using the given &domain; objects. ! Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates a &grid; using the given &domain; objects. ! Grid<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) creates a &grid; using the given &domain; objects. ! Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5) creates a &grid; using the given &domain; objects. ! Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6) creates a &grid; using the given &domain; objects. ! Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) creates a &grid; using the given &domain; objects. --- 889,930 ---- ! Grid<&dim;>() creates an empty, uninitialized &grid;, to be assigned a value later. ! Grid<&dim;>(const &domaintemplate;1& t1) creates a &grid; using the given &domain; object. ! Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2) creates a &grid; using the given &domain; objects. ! Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3) creates a &grid; using the given &domain; objects. ! Grid<&dim;>(const &domaintemplate;1& t1, const ! &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4) creates a &grid; using the given &domain; objects. ! Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5) creates a &grid; using the given &domain; objects. ! Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6) creates a &grid; using the given &domain; objects. ! Grid<&dim;>(const &domaintemplate;1& t1, const &domaintemplate;2& t2, const &domaintemplate;3& t3, const &domaintemplate;4& t4, const &domaintemplate;5& ! t5, const &domaintemplate;6& t6, const &domaintemplate;7& t7) creates a &grid; using the given &domain; objects. *************** Grid<1> g(list); *** 995,1009 **** Multidimensional &domain; Accessors ! long size() returns the total number of indices. ! bool empty() returns &true; if and only if the &domain; has no indices. ! D<1> operator[](int dimension) returns the one-dimensional &domain; for the specified dimension. The return type is a one-dimensional version of the &domain;. --- 995,1009 ---- Multidimensional &domain; Accessors ! long size() returns the total number of indices. ! bool empty() returns &true; if and only if the &domain; has no indices. ! D<1> operator[](int dimension) returns the one-dimensional &domain; for the specified dimension. The return type is a one-dimensional version of the &domain;. *************** Grid<1> g(list); *** 1012,1043 **** One-dimensional &domain; Accessors ! long length() returns the number of indices. ! int first() returns the beginning of the domain. ! int last() returns the ending of the domain. ! int min() returns the minimum index in the domain. ! int max() returns the maximum index in the domain. ! D<1>::iterator begin() returns a forward iterator pointing to the beginning domain index. ! D<1>::iterator end() returns a forward iterator pointing to the ending domain index. --- 1012,1043 ---- One-dimensional &domain; Accessors ! long length() returns the number of indices. ! int first() returns the beginning of the domain. ! int last() returns the ending of the domain. ! int min() returns the minimum index in the domain. ! int max() returns the maximum index in the domain. ! D<1>::iterator begin() returns a forward iterator pointing to the beginning domain index. ! D<1>::iterator end() returns a forward iterator pointing to the ending domain index. *************** Grid<1> g(list); *** 1049,1087 **** linkend="arrays-domains-use-table">. Functions applicable to both one-dimensional and multidimensional &domain;s are listed before functions that only applicable to one-dimensional ! &domain;s. The size member function yields the total number of indices in a given &domain;. If and ! only if this number is zero, empty will yield &true;. A multidimensional domain<&dim;> is the direct product of &dim; ! one-dimensional &domain;s. The operator[](int ! dimension) operator extracts the one-dimensional &domain; corresponding to its parameter. For example, the three one-dimensional Range<1> &domain;s can be extracted from a Range<3> object r using ! r[0], r[1], and ! r[2].&domain; accessors applicable only to one-dimensional &domain;s are listed in the second half of . The ! length member function, analogous to the ! multidimensional size function, returns the number of indices in the &domain;. The ! first and last member functions return the domain's beginning and ending ! indices. The begin and ! end member functions return forward iterators pointing to these respective locations. They have type D<1>::iterator, where D abbreviates the &domain;'s type, e.g., &interval; or &grid;. The min and ! max member functions return the minimum and maximum indices in the &domain; object, respectively. For &locone; and &intervalone;, these yield the same values as ! first and last, but &rangeone; and &gridone; can have their numerically largest index at the beginning of their &domain;s. --- 1049,1087 ---- linkend="arrays-domains-use-table">. Functions applicable to both one-dimensional and multidimensional &domain;s are listed before functions that only applicable to one-dimensional ! &domain;s. The size member function yields the total number of indices in a given &domain;. If and ! only if this number is zero, empty will yield &true;. A multidimensional domain<&dim;> is the direct product of &dim; ! one-dimensional &domain;s. The operator[](int ! dimension) operator extracts the one-dimensional &domain; corresponding to its parameter. For example, the three one-dimensional Range<1> &domain;s can be extracted from a Range<3> object r using ! r[0], r[1], and ! r[2].&domain; accessors applicable only to one-dimensional &domain;s are listed in the second half of . The ! length member function, analogous to the ! multidimensional size function, returns the number of indices in the &domain;. The ! first and last member functions return the domain's beginning and ending ! indices. The begin and ! end member functions return forward iterators pointing to these respective locations. They have type D<1>::iterator, where D abbreviates the &domain;'s type, e.g., &interval; or &grid;. The min and ! max member functions return the minimum and maximum indices in the &domain; object, respectively. For &locone; and &intervalone;, these yield the same values as ! first and last, but &rangeone; and &gridone; can have their numerically largest index at the beginning of their &domain;s. *************** Grid<1> g(list); *** 1204,1210 **** …, DT7. The first constructor, with no domain arguments, creates an empty, uninitialized &array; for which a domain must be specified before it is used. Specify the ! array's domain using its initialize function. The next seven constructors combine their domain arguments to compute the resulting &array;'s domain. These are combined in the same way that multidimensional &interval;s are --- 1204,1210 ---- …, DT7. The first constructor, with no domain arguments, creates an empty, uninitialized &array; for which a domain must be specified before it is used. Specify the ! array's domain using its initialize function. The next seven constructors combine their domain arguments to compute the resulting &array;'s domain. These are combined in the same way that multidimensional &interval;s are *************** Grid<1> g(list); *** 1259,1358 **** ! Array<&dim;,T,E>() creates an empty, uninitialized &array; which must be ! initialize()d before use. ! Array<&dim;,T,E>(const DT1& t1) creates an &array; using the given &domain; object or integer. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2) creates an &array; using the given &domain; objects and integers. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3) creates an &array; using the given &domain; objects and integers. ! Array<&dim;,T,E>(const DT1& t1, const ! DT2& t2, const DT3& t3, const DT4& t4) creates an &array; using the given &domain; objects and integers. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& ! t5) creates an &array; using the given &domain; objects and integers. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& ! t5, const DT6& t6) creates an &array; using the given &domain; objects and integers. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& ! t5, const DT6& t6, const DT7& t7) creates an &array; using the given &domain; objects and integers. ! Array<&dim;,T,E>(const DT1& t1, ! const ModelElement<T>& model) creates an &array; using the given &domain; object or integer and then initializes all entries using model. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, ! const ModelElement<T>& model) creates an &array; using the given &domain; objects and integers and then initializes all entries using model. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, ! const ModelElement<T>& model) creates an &array; using the given &domain; objects and integers and then initializes all entries using model. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, ! const ModelElement<T>& model) creates an &array; using the given &domain; objects and integers and then initializes all entries using model. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, ! const ModelElement<T>& model) creates an &array; using the given &domain; objects and integers and then initializes all entries using model. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, const DT6& t6, ! const ModelElement<T>& model) creates an &array; using the given &domain; objects and integers and then initializes all entries using model. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, const DT6& t6, const DT7& t7, ! const ModelElement<T>& model) creates an &array; using the given &domain; objects and integers and then initializes all entries using model. --- 1259,1358 ---- ! Array<&dim;,T,E>() creates an empty, uninitialized &array; which must be ! initialize()d before use. ! Array<&dim;,T,E>(const DT1& t1) creates an &array; using the given &domain; object or integer. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2) creates an &array; using the given &domain; objects and integers. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3) creates an &array; using the given &domain; objects and integers. ! Array<&dim;,T,E>(const DT1& t1, const ! DT2& t2, const DT3& t3, const DT4& t4) creates an &array; using the given &domain; objects and integers. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& ! t5) creates an &array; using the given &domain; objects and integers. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& ! t5, const DT6& t6) creates an &array; using the given &domain; objects and integers. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& ! t5, const DT6& t6, const DT7& t7) creates an &array; using the given &domain; objects and integers. ! Array<&dim;,T,E>(const DT1& t1, ! const ModelElement<T>& model) creates an &array; using the given &domain; object or integer and then initializes all entries using model. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, ! const ModelElement<T>& model) creates an &array; using the given &domain; objects and integers and then initializes all entries using model. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, ! const ModelElement<T>& model) creates an &array; using the given &domain; objects and integers and then initializes all entries using model. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, ! const ModelElement<T>& model) creates an &array; using the given &domain; objects and integers and then initializes all entries using model. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, ! const ModelElement<T>& model) creates an &array; using the given &domain; objects and integers and then initializes all entries using model. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, const DT6& t6, ! const ModelElement<T>& model) creates an &array; using the given &domain; objects and integers and then initializes all entries using model. ! Array<&dim;,T,E>(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, const DT6& t6, const DT7& t7, ! const ModelElement<T>& model) creates an &array; using the given &domain; objects and integers and then initializes all entries using model. *************** Array<3> b(2,3,1); *** 1389,1395 **** Array<2,bool> c(2,3); To specify a default &array; value of &true;, use ! ModelElement<bool>(true): Array<2,bool> c(2,3, ModelElement<bool>(true));. To create a one-dimensional &array; containing --- 1389,1395 ---- Array<2,bool> c(2,3); To specify a default &array; value of &true;, use ! ModelElement<bool>(true): Array<2,bool> c(2,3, ModelElement<bool>(true));. To create a one-dimensional &array; containing *************** Array<1,double,CompressibleBrick> *** 1407,1416 **** constructor, must have a specified domain before it can be used. For example, one must use the parameter-less &array; constructor when creating an array of &array;s using ! new so their domains must be specified. (It would probably be better to create an &array; of &array;s since memory allocation and deallocation would automatically be ! handled.) &array;'s initialize functions accept the same set of domain object specifications and model elements that the &array; constructors do, creating the specified domain. See new so their domains must be specified. (It would probably be better to create an &array; of &array;s since memory allocation and deallocation would automatically be ! handled.) &array;'s initialize functions accept the same set of domain object specifications and model elements that the &array; constructors do, creating the specified domain. See a(Interval<1>(2,7), *** 1426,1432 **** // its domain. Array<2,float,Brick> b(); b.initialize(Interval<1>(2,7), Interval<1>(-2,4));. ! Invoking initialize on an &array; with an existing domain yields unspecified behavior. All &array; values may be lost and memory may be leaked. --- 1426,1432 ---- // its domain. Array<2,float,Brick> b(); b.initialize(Interval<1>(2,7), Interval<1>(-2,4));. ! Invoking initialize on an &array; with an existing domain yields unspecified behavior. All &array; values may be lost and memory may be leaked. *************** b.initialize(Interval<1>(2,7), Interval< *** 1437,1448 **** ! An &array;'s initialize member functions sets its domain and should be invoked only for an array created without a domain. It returns nothing. ! initialize declaration result --- 1437,1448 ---- ! An &array;'s initialize member functions sets its domain and should be invoked only for an array created without a domain. It returns nothing. ! initialize declaration result *************** b.initialize(Interval<1>(2,7), Interval< *** 1457,1546 **** ! initialize(const DT1& t1) creates the &array;'s domain using the given &domain; object or integer. ! initialize(const DT1& t1, const DT2& t2) creates the &array;'s domain using the given &domain; objects and integers. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3) creates the &array;'s domain using the given &domain; objects and integers. ! initialize(const DT1& t1, const ! DT2& t2, const DT3& t3, const DT4& t4) creates the &array;'s domain using the given &domain; objects and integers. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& ! t5) creates the &array;'s domain using the given &domain; objects and integers. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& ! t5, const DT6& t6) creates the &array;'s domain using the given &domain; objects and integers. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& ! t5, const DT6& t6, const DT7& t7) creates the &array;'s domain using the given &domain; objects and integers. ! initialize(const DT1& t1, ! const ModelElement<T>& model) creates the &array;'s domain using the given &domain; object or integer and then initializes all entries using model. ! initialize(const DT1& t1, const DT2& t2, ! const ModelElement<T>& model) creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, ! const ModelElement<T>& model) creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, ! const ModelElement<T>& model) creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, ! const ModelElement<T>& model) creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, const DT6& t6, ! const ModelElement<T>& model) creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, const DT6& t6, const DT7& t7, ! const ModelElement<T>& model) creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. --- 1457,1546 ---- ! initialize(const DT1& t1) creates the &array;'s domain using the given &domain; object or integer. ! initialize(const DT1& t1, const DT2& t2) creates the &array;'s domain using the given &domain; objects and integers. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3) creates the &array;'s domain using the given &domain; objects and integers. ! initialize(const DT1& t1, const ! DT2& t2, const DT3& t3, const DT4& t4) creates the &array;'s domain using the given &domain; objects and integers. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& ! t5) creates the &array;'s domain using the given &domain; objects and integers. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& ! t5, const DT6& t6) creates the &array;'s domain using the given &domain; objects and integers. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& ! t5, const DT6& t6, const DT7& t7) creates the &array;'s domain using the given &domain; objects and integers. ! initialize(const DT1& t1, ! const ModelElement<T>& model) creates the &array;'s domain using the given &domain; object or integer and then initializes all entries using model. ! initialize(const DT1& t1, const DT2& t2, ! const ModelElement<T>& model) creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, ! const ModelElement<T>& model) creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, ! const ModelElement<T>& model) creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, ! const ModelElement<T>& model) creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, const DT6& t6, ! const ModelElement<T>& model) creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. ! initialize(const DT1& t1, const DT2& t2, const DT3& t3, const DT4& t4, const DT5& t5, const DT6& t6, const DT7& t7, ! const ModelElement<T>& model) creates the &array;'s domain using the given &domain; objects and integers and then initializes all entries using model. *************** std::cout &openopen; a(2,-2) &openopen; *** 1583,1593 **** numbers.For read-only access to a value, use the ! read member function, which takes the same index notation as its nameless read-write counterpart: std::cout &openopen; a.read(2,-2) &openopen; std::endl; ! Using read sometimes permits the optimizer to produce faster executing code.Copying &array;s requires little execution time because --- 1583,1593 ---- numbers.For read-only access to a value, use the ! read member function, which takes the same index notation as its nameless read-write counterpart: std::cout &openopen; a.read(2,-2) &openopen; std::endl; ! Using read sometimes permits the optimizer to produce faster executing code.Copying &array;s requires little execution time because *************** std::cout &openopen; a.read(2,-2) &openo *** 1622,1628 **** Destruction is similarly inexpensive.Array assignment does not have reference semantics. Thus, ! the assignment a = b ensures that all of a's values are the same as b at the time of assignment only. Subsequent changes to a's values do not change b's --- 1622,1628 ---- Destruction is similarly inexpensive.Array assignment does not have reference semantics. Thus, ! the assignment a = b ensures that all of a's values are the same as b at the time of assignment only. Subsequent changes to a's values do not change b's *************** std::cout &openopen; a.read(2,-2) &openo *** 1637,1645 **** constants useful for both compile-time and run-time computations. See . These may be accessed using the &array;'s type and the scope ! resolution operator (::). The table begins with a list of internal type definitions, e.g., ! Array<&dim;,T,E>::This_t. A layout maps a domain index to a particular processor and memory used to compute the associated value. The last two functions return the --- 1708,1727 ---- returning the &array;'s domain, which has type Array<&dim;,T,E>::Domain_t (abbreviated Domain_t in the table). The next seven functions ! query the domain. first, ! last, and length return the first index, last index, and number of indices for the specified dimension. The domain's dimensions are numbered 0, 1, …, ! Array<&dim;,T,E>::dimensions-1. If these values are needed for all dimensions, use ! firsts, lasts, ! and lengths. The returned Loc<&dim;>s have &dim; entries, one for each ! dimension. size returns the total number of indices in the entire domain. This is the product of all the ! dimensions' lengths. The ! layout member function returns the &array;'s layout, which specifies the mapping of indices to processors and memory. The last two functions return the *************** std::cout &openopen; a.read(2,-2) &openo *** 1742,1807 **** Internal type definitions, e.g., Domain_t, are listed here without the class type prefix ! Array<&dim;,T,E>::. ! Domain_t domain() returns the &array;'s domain. ! Domain_t physicalDomain() returns the &array;'s domain. ! Domain_t totalDomain() returns the &array;'s domain. ! int first(int dim) returns the first index value for the specified dimension. ! int last(int dim) returns the last index value for the specified dimension. ! int length(int dim) returns the number of indices (including endpoints) for the specified dimension. ! Loc<Dim> firsts() returns the first index values for all the dimensions. ! Loc<Dim> lasts() returns the last index values for all the specified dimensions. ! Loc<Dim> lengths() returns the numbers of indices (including endpoints) for all the specified dimensions. ! long size() returns the total number of indices in the domain. ! Layout_t layout() returns the &array;'s layout. ! Engine_t engine() returns the &array;'s engine. ! const Engine_t engine() returns the &array;'s engine. --- 1742,1807 ---- Internal type definitions, e.g., Domain_t, are listed here without the class type prefix ! Array<&dim;,T,E>::. ! Domain_t domain() returns the &array;'s domain. ! Domain_t physicalDomain() returns the &array;'s domain. ! Domain_t totalDomain() returns the &array;'s domain. ! int first(int dim) returns the first index value for the specified dimension. ! int last(int dim) returns the last index value for the specified dimension. ! int length(int dim) returns the number of indices (including endpoints) for the specified dimension. ! Loc<Dim> firsts() returns the first index values for all the dimensions. ! Loc<Dim> lasts() returns the last index values for all the specified dimensions. ! Loc<Dim> lengths() returns the numbers of indices (including endpoints) for all the specified dimensions. ! long size() returns the total number of indices in the domain. ! Layout_t layout() returns the &array;'s layout. ! Engine_t engine() returns the &array;'s engine. ! const Engine_t engine() returns the &array;'s engine. *************** std::cout &openopen; a.read(2,-2) &openo *** 1811,1819 **** We illustrate using &array; member functions in . The program computes the total number of &array;'s indices, comparing the ! result with invoking its size method. Since the &array;'s name is a, ! a.size() returns its size. The computeArraySize function also computes the &array;'s size. This templated function uses its three template parameters to accept any &array;, regardless of its dimension, --- 1811,1819 ---- We illustrate using &array; member functions in . The program computes the total number of &array;'s indices, comparing the ! result with invoking its size method. Since the &array;'s name is a, ! a.size() returns its size. The computeArraySize function also computes the &array;'s size. This templated function uses its three template parameters to accept any &array;, regardless of its dimension, *************** std::cout &openopen; a.read(2,-2) &openo *** 1823,1832 **** illustrates using member functions. The domain's size is the product of the length of each dimension. Since the lengths are stored in the Loc<&dim> ! lens, lens[d] is a Loc<1>, for which its ! first member function extracts the ! length. The length &array; member function is used in the PAssert. --- 1823,1832 ---- illustrates using member functions. The domain's size is the product of the length of each dimension. Since the lengths are stored in the Loc<&dim> ! lens, lens[d] is a Loc<1>, for which its ! first member function extracts the ! length. The length &array; member function is used in the PAssert. *************** std::cout &openopen; a.read(2,-2) &openo *** 1844,1853 **** functions' names. These functions return &loc;s. ! lens[d] returns a Loc<1> for dimension d's length. Invoking ! Loc<1> first method yields its value. --- 1844,1853 ---- functions' names. These functions return &loc;s. ! lens[d] returns a Loc<1> for dimension d's length. Invoking ! Loc<1> first method yields its value. *************** std::cout &openopen; a.read(2,-2) &openo *** 1855,1861 **** using member functions. ! The size is invoked by prepending the &array;'s name followed by a period. This assertion is unnecessary, but the computeArraySize function further --- 1855,1861 ---- using member functions. ! The size is invoked by prepending the &array;'s name followed by a period. This assertion is unnecessary, but the computeArraySize function further *************** std::cout &openopen; a.read(2,-2) &openo *** 1890,1905 **** &dynamic; &engine; is analogous to a one-dimensional &brick; &engine; supporting a dynamically-resizable domain. It is also usually the default value for this tag. For example, ! DynamicArray<> d0(1);, ! DynamicArray<double> d1(1);, and ! DynamicArray<double, Dynamic> d2(1); all declare the same &dynamicarray;s explicitly storing one &double; value. A &dynamicarray; automatically allocates its initial memory and deallocates its final memory, just as an &array; does. ! The create and ! destroy member functions permit changing a &dynamicarray;'s domain. lists these member functions but omits functions exclusively used in distributed --- 1890,1905 ---- &dynamic; &engine; is analogous to a one-dimensional &brick; &engine; supporting a dynamically-resizable domain. It is also usually the default value for this tag. For example, ! DynamicArray<> d0(1);, ! DynamicArray<double> d1(1);, and ! DynamicArray<double, Dynamic> d2(1); all declare the same &dynamicarray;s explicitly storing one &double; value. A &dynamicarray; automatically allocates its initial memory and deallocates its final memory, just as an &array; does. ! The create and ! destroy member functions permit changing a &dynamicarray;'s domain. lists these member functions but omits functions exclusively used in distributed *************** std::cout &openopen; a.read(2,-2) &openo *** 1927,1945 **** ! void create(int num) extend the current domain by the requested number of elements. ! void destroy(const Dom& killList) remove the values specified by the indices in the given &domain; argument. The Backfill method moves values from the end of the domain to replace the deleted values. ! void destroy(Iter killBegin, Iter killEnd) remove the values specified by the indices in the container range [begin,end) specified by the random-access iterators. The Backfill method moves values --- 1927,1945 ---- ! void create(int num) extend the current domain by the requested number of elements. ! void destroy(const Dom& killList) remove the values specified by the indices in the given &domain; argument. The Backfill method moves values from the end of the domain to replace the deleted values. ! void destroy(Iter killBegin, Iter killEnd) remove the values specified by the indices in the container range [begin,end) specified by the random-access iterators. The Backfill method moves values *************** std::cout &openopen; a.read(2,-2) &openo *** 1947,1954 **** values. ! void destroy(const Dom& killList, const ! DeleteMethod& method) remove the values specified by the indices in the given &domain; argument. Deleted values can be replaced by --- 1947,1954 ---- values. ! void destroy(const Dom& killList, const ! DeleteMethod& method) remove the values specified by the indices in the given &domain; argument. Deleted values can be replaced by *************** std::cout &openopen; a.read(2,-2) &openo *** 1958,1965 **** ordering. ! void destroy(Iter killBegin, Iter killEnd, ! const DeleteMethod& method) remove the values specified by the indices in the container range [begin,end) specified by the random-access iterators. Deleted values can be replaced by --- 1958,1965 ---- ordering. ! void destroy(Iter killBegin, Iter killEnd, ! const DeleteMethod& method) remove the values specified by the indices in the container range [begin,end) specified by the random-access iterators. Deleted values can be replaced by *************** std::cout &openopen; a.read(2,-2) &openo *** 1972,1985 ****

! The destroy member function deletes the specified indices. The indices may be specified using either a &domain; object (Interval<1>, Range<1>, or IndirectionList) or by random-access iterators pointing into a container. For example, every other value from a ten-value array d might be removed using ! Range<1>(0,9,2). Alternatively, int killList[] = {0, 2, 4, 6, 8}; d.destroy(killList, killList+5); --- 1972,1985 ---- ! The destroy member function deletes the specified indices. The indices may be specified using either a &domain; object (Interval<1>, Range<1>, or IndirectionList) or by random-access iterators pointing into a container. For example, every other value from a ten-value array d might be removed using ! Range<1>(0,9,2). Alternatively, int killList[] = {0, 2, 4, 6, 8}; d.destroy(killList, killList+5); *************** d.destroy(killList, killList+5); *** 2002,2012 **** 0 1 2 3 ! destroy using BackFill: 3 1 2 ! destroy using ShiftUp: 1 2 3 --- 2002,2012 ---- 0 1 2 3 ! destroy using BackFill: 3 1 2 ! destroy using ShiftUp: 1 2 3 *************** d.destroy(killList, killList+5); *** 2025,2032 **** original indices of 0 1 2 3. Removing 2 yields 0 1 3 because 3 is moved into 2's position. Removing 0 yields 3 1 because 3 is again moved. Use an object with the desired type to indicate which fill ! method is desired, i.e., BackFill() or ! ShiftUp(). We illustrate &dynamicarray; resizing in . &dynamicarray;s --- 2025,2032 ---- original indices of 0 1 2 3. Removing 2 yields 0 1 3 because 3 is moved into 2's position. Removing 0 yields 3 1 because 3 is again moved. Use an object with the desired type to indicate which fill ! method is desired, i.e., BackFill() or ! ShiftUp(). We illustrate &dynamicarray; resizing in . &dynamicarray;s *************** d.destroy(killList, killList+5); *** 2037,2055 **** be one-dimensional. The three arrays, each having one &double; value, are equivalent. (The &poomatoolkit; can be configured to support different default template values.) Invoking ! d0's create with an argument of five increases its domain size from one to six. The additional indices are added to the end of the domain so the value at index 0 is not changed. To illustrate which indices are removed and which indices are reordered, the program first sets all values equal to their indices. This illustrates that &dynamicarray; values are accessed the same way as &array; values. ! For example, d0(i) accesses the ith value. The ! destroy member function removes every other index from the array because the one-dimensional ⦥ specifies the domain's entire interval with a stride of 2. ! The BackFill function call creates a BackFill object indicating the BackFill method should be used. We illustrate the steps of this method: d0's create with an argument of five increases its domain size from one to six. The additional indices are added to the end of the domain so the value at index 0 is not changed. To illustrate which indices are removed and which indices are reordered, the program first sets all values equal to their indices. This illustrates that &dynamicarray; values are accessed the same way as &array; values. ! For example, d0(i) accesses the ith value. The ! destroy member function removes every other index from the array because the one-dimensional ⦥ specifies the domain's entire interval with a stride of 2. ! The BackFill function call creates a BackFill object indicating the BackFill method should be used. We illustrate the steps of this method: destroy. Since this &dynamicarray;'s indices are specified using ∫s, the killList explicitly lists the indices to ! remove. The destroy call uses pointers to the beginning and end of the killList array to specify which of its indices to use. Since no replacement method is specified, the default BackFill method is --- 2081,2090 ---- originally at 5 is again moved into 2's position. Finally, index 0 is replaced by index 3. The rest of the program repeats the computation, using the random-access iterator version ! of destroy. Since this &dynamicarray;'s indices are specified using ∫s, the killList explicitly lists the indices to ! remove. The destroy call uses pointers to the beginning and end of the killList array to specify which of its indices to use. Since no replacement method is specified, the default BackFill method is *************** d.destroy(killList, killList+5); *** 2104,2110 **** &dynamicarray;s, storing one &double; value. ! This create member function call adds five indices to the end of the domain. --- 2104,2110 ---- &dynamicarray;s, storing one &double; value. ! This create member function call adds five indices to the end of the domain. *************** d.destroy(killList, killList+5); *** 2113,2124 **** The ⦥ object specifies that every other index ! should be removed. The BackFill() object is unnecessary since it is the default replacement method. ! This destroy call is equivalent to the previous one but uses iterators. --- 2113,2124 ---- The ⦥ object specifies that every other index ! should be removed. The BackFill() object is unnecessary since it is the default replacement method. ! This destroy call is equivalent to the previous one but uses iterators. Index: concepts.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/concepts.xml,v retrieving revision 1.11 diff -c -p -r1.11 concepts.xml *** concepts.xml 2002/01/30 23:09:06 1.11 --- concepts.xml 2002/01/30 23:47:30 *************** *** 251,258 **** versa. While users sometimes explicitly create views, they are perhaps more frequently created as temporaries in expressions. For example, if A is an &array; and ! I is a domain, A(I) - ! A(I-1) uses two views to form the difference between adjacent values. --- 251,258 ---- versa. While users sometimes explicitly create views, they are perhaps more frequently created as temporaries in expressions. For example, if A is an &array; and ! I is a domain, A(I) - ! A(I-1) uses two views to form the difference between adjacent values. *************** *** 523,530 **** computation accesses individual container values through explicit notation. For example, values in a two-dimensional container &container; might be referenced as ! &container(3,4) or ! &container(i,j+1). This is the usual notation for non-object-oriented languages such as &c;. &container(3,4) or ! &container(i,j+1). This is the usual notation for non-object-oriented languages such as &c;. , ! a(I,J) represents the subset of &array; a's values having coordinates in the domain specified by the direct product of one-dimensional &interval;s I and J. Using --- 532,538 ---- computation uses expressions to access subsets of a container's values. For example, in , ! a(I,J) represents the subset of &array; a's values having coordinates in the domain specified by the direct product of one-dimensional &interval;s I and J. Using Index: data-parallel.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/data-parallel.xml,v retrieving revision 1.5 diff -c -p -r1.5 data-parallel.xml *** data-parallel.xml 2002/01/30 23:09:06 1.5 --- data-parallel.xml 2002/01/30 23:47:31 *************** *** 83,94 **** The data-parallel operators operate element-wise on containers' values. For example, if A is a one-dimensional array, ! -A is a one-dimensional array with the same size such that the value at the ith position equals -A(i). If A and B are two-dimensional &array;s on the same domain, ! A+B is an array on the same domain with values equaling the sum of corresponding values in A and B. --- 83,94 ---- The data-parallel operators operate element-wise on containers' values. For example, if A is a one-dimensional array, ! -A is a one-dimensional array with the same size such that the value at the ith position equals -A(i). If A and B are two-dimensional &array;s on the same domain, ! A+B is an array on the same domain with values equaling the sum of corresponding values in A and B. *************** *** 103,110 **** with a one-dimensional interval [0,3]. Its first and last entries equal A's first and last entries, while its middle two entries are the sums ! A(1)+B(1) and ! A(2)+B(2). We assume zero is the default value for the type of values stored in B. A more complicated example of adding two &array;s with different domains is illustrated in A's first and last entries, while its middle two entries are the sums ! A(1)+B(1) and ! A(2)+B(2). We assume zero is the default value for the type of values stored in B. A more complicated example of adding two &array;s with different domains is illustrated in A(I,I), B(J,H); *** 143,155 **** their domains' extent differ, as indicated by the solid lines in the figure. The sum has domain equal to the left operand's domain. Values with the same indices are added. For example, ! A(2,2) and B(2,2) are added. B's domain does not include index ! (1,1) so, when adding A(1,1) and ! B(1,1), the default value for B's value type is used. Usually this ! is 0. Thus, A(1,1) + B(1,1) equals ! 9 + 0. Operations with both &array;s and scalar values are supported. Conceptually, a scalar value can be thought of as an --- 143,155 ---- their domains' extent differ, as indicated by the solid lines in the figure. The sum has domain equal to the left operand's domain. Values with the same indices are added. For example, ! A(2,2) and B(2,2) are added. B's domain does not include index ! (1,1) so, when adding A(1,1) and ! B(1,1), the default value for B's value type is used. Usually this ! is 0. Thus, A(1,1) + B(1,1) equals ! 9 + 0. Operations with both &array;s and scalar values are supported. Conceptually, a scalar value can be thought of as an *************** Array<2, double, Brick> A(I,I), B(J,H); *** 158,171 **** Array<1, double, Brick> D(Interval<1>(7,10)); D += 2*D + 7; ! 2*D obeys the guidelines ! because the scalar 2 can be thought of as an array with the same domain as D. It has the ! same value 2 everywhere. Likewise the ! conceptual domain for the scalar 7 is the ! same as 2*D's domain. Thus, ! 2*D(i) + 7 is added to ! D(i) wherever index i is in D's domain. In practice, the &toolkit; does not first convert scalar values to arrays but instead uses them directly in expressions. --- 158,171 ---- Array<1, double, Brick> D(Interval<1>(7,10)); D += 2*D + 7; ! 2*D obeys the guidelines ! because the scalar 2 can be thought of as an array with the same domain as D. It has the ! same value 2 everywhere. Likewise the ! conceptual domain for the scalar 7 is the ! same as 2*D's domain. Thus, ! 2*D(i) + 7 is added to ! D(i) wherever index i is in D's domain. In practice, the &toolkit; does not first convert scalar values to arrays but instead uses them directly in expressions. *************** Array<2, double, Brick> A(I,I), B(H,J), *** 201,215 **** Array<1, double, Brick> A(Interval<1>(0,1)); Array<1, double, Brick> B(Interval<1>(1,2)); A = B; ! A(0) is assigned ! B(1) and A(1) is ! assigned B(2). Assigning a scalar value to an &array; also is supported, but assigning an &array; to a scalar is not. A scalar value is conformable to any domain because, conceptually it can be viewed as an &array; with any desired domain and having the same value ! everywhere. Thus, the assignment B = 3 ensures every value in B equals 3. Even though a scalar value is conformable to any &array;, it is not an l-value so it cannot appear on the left-hand side of an --- 201,215 ---- Array<1, double, Brick> A(Interval<1>(0,1)); Array<1, double, Brick> B(Interval<1>(1,2)); A = B; ! A(0) is assigned ! B(1) and A(1) is ! assigned B(2). Assigning a scalar value to an &array; also is supported, but assigning an &array; to a scalar is not. A scalar value is conformable to any domain because, conceptually it can be viewed as an &array; with any desired domain and having the same value ! everywhere. Thus, the assignment B = 3 ensures every value in B equals 3. Even though a scalar value is conformable to any &array;, it is not an l-value so it cannot appear on the left-hand side of an *************** A = B; *** 217,225 **** Data-parallel expressions can involve typical mathematical functions and output operations. For example, ! sin(A) yields an &array; with values equal to the sine of each of &array; A's values. ! dot(A,B) has values equaling the dot product of corresponding values in &array;s A and B. The contents of an entire &array; can be easily printed to standard output. For example, the program --- 217,225 ---- Data-parallel expressions can involve typical mathematical functions and output operations. For example, ! sin(A) yields an &array; with values equal to the sine of each of &array; A's values. ! dot(A,B) has values equaling the dot product of corresponding values in &array;s A and B. The contents of an entire &array; can be easily printed to standard output. For example, the program *************** std::cout &openopen; A-B &openopen; std: *** 234,240 **** (000:002:001) = 1 -1 -1. The initial (000:002:001) indicates the &array;'s domain ranges from 0 to 2 with a stride of 1. The ! three values in A-B follow. The following four tables list the data-parallel operators that operate on &array;s. . The initial (000:002:001) indicates the &array;'s domain ranges from 0 to 2 with a stride of 1. The ! three values in A-B follow. The following four tables list the data-parallel operators that operate on &array;s. ! can take an Array<bool>, Array<int>, Array<long>, or ! any other value type to which ! can be applied. The result is an Array<bool>. Each binary operator also returns an &array;. When specifying two &array;s or an &array; and a scalar value, a full set of operators is supported. When specifying an &array; and a &tensor;, &matrix;, or &vector;, a more limited set of operators is ! supported. For example, == can take two &array;s, an &array; and a scalar value, or a scalar value and an &array;. If given two &array;s, corresponding values are used. If an argument is a scalar value, its same value is the used with ! each &array; value. The + supports the same set of parameters but also supports adding an &array; and a &tensor;, an &array; and a &matrix;, an &array; and a &vector;, a &tensor; and an &array;, a &matrix; and an &array;, and a &vector; --- 242,261 ---- &cc; operators that can be applied to &array;s and also scalar values if appropriate. Each unary operator takes an &array; parameter and returns an &array;. The types of the two &array;s ! need not be the same. For example, ! can take an Array<bool>, Array<int>, Array<long>, or ! any other value type to which ! can be applied. The result is an Array<bool>. Each binary operator also returns an &array;. When specifying two &array;s or an &array; and a scalar value, a full set of operators is supported. When specifying an &array; and a &tensor;, &matrix;, or &vector;, a more limited set of operators is ! supported. For example, == can take two &array;s, an &array; and a scalar value, or a scalar value and an &array;. If given two &array;s, corresponding values are used. If an argument is a scalar value, its same value is the used with ! each &array; value. The + supports the same set of parameters but also supports adding an &array; and a &tensor;, an &array; and a &matrix;, an &array; and a &vector;, a &tensor; and an &array;, a &matrix; and an &array;, and a &vector; *************** std::cout &openopen; A-B &openopen; std: *** 277,297 **** unary operators ! +, -, ~, ! binary operators with at least one &array; and at most one scalar value ! +, -, *, /, %, &, |, ^, <, <=, >=, >, ==, !=, &&, ||, &openopen;, &closeclose; binary operators with at least one &array; and at most one &tensor;, &matrix;, or &vector; ! +, -, ! *, /, ! %, &, ! |, ^, ! ==, != --- 277,297 ---- unary operators ! +, -, ~, ! binary operators with at least one &array; and at most one scalar value ! +, -, *, /, %, &, |, ^, <, <=, >=, >, ==, !=, &&, ||, &openopen;, &closeclose; binary operators with at least one &array; and at most one &tensor;, &matrix;, or &vector; ! +, -, ! *, /, ! %, &, ! |, ^, ! ==, != *************** std::cout &openopen; A-B &openopen; std: *** 361,445 **** Trigonometric and Hyperbolic Functions ! #include <math.h> ! Array<T> cos (const Array<T>& A) Returns the cosines of the &array;'s values. ! Array<T> sin (const Array<T>& A) Returns the sines of the &array;'s values. ! Array<T> tan (const Array<T>& A) Returns the tangents of the &array;'s values. ! Array<T> acos (const Array<T1>& A) Returns the arc cosines of the &array;'s values. ! Array<T> asin (const Array<T1>& A) Returns the arc sines of the &array;'s values. ! Array<T> atan (const Array<T1>& A) Returns the arc tangents of the &array;'s values. ! Array<T> atan2 (const Array<T1>& A, const Array<T2>& B) Computes the arc tangents of the values from the division of elements in B by the elements in A. The resulting values are the signed angles in the range -π to π, inclusive. ! Array<T> atan2 (const Array<T1>& A, const T2& r) Computes the arc tangents of the values from the division of r by the elements in A. The resulting values are the signed angles in the range -π to π, inclusive. ! Array<T> atan2 (const T1& l, const Array<T2>& B) Computes the arc tangents of the values from the division of elements in B by l. The resulting values are the signed angles in the range -π to π, inclusive. ! Array<T> cosh (const Array<T>& A) Returns the hyperbolic cosines of the &array;'s values. ! Array<T> sinh (const Array<T>& A) Returns the hyperbolic sines of the &array;'s values. ! Array<T> tanh (const Array<T>& A) Returns the hyperbolic tangents of the &array;'s values. Absolute Value, Rounding, and Modulus Functions ! #include <math.h> ! Array<T> fabs (const Array<T1>& A) Returns the absolute values of the floating point numbers in the &array;. ! Array<T> ceil (const Array<T1>& A) For each of the &array;'s values, return the integer larger than or equal to it (as a floating point number). ! Array<T> floor (const Array<T1>& A) For each of the &array;'s values, return the integer smaller than or equal to it (as a floating point number). ! Array<T> fmod (const Array<T1>& A, const Array<T2>& B) Computes the floating-point modulus (remainder) of A's values with the corresponding value in B. The results have the same signs --- 361,445 ---- Trigonometric and Hyperbolic Functions ! #include <math.h> ! Array<T> cos (const Array<T>& A) Returns the cosines of the &array;'s values. ! Array<T> sin (const Array<T>& A) Returns the sines of the &array;'s values. ! Array<T> tan (const Array<T>& A) Returns the tangents of the &array;'s values. ! Array<T> acos (const Array<T1>& A) Returns the arc cosines of the &array;'s values. ! Array<T> asin (const Array<T1>& A) Returns the arc sines of the &array;'s values. ! Array<T> atan (const Array<T1>& A) Returns the arc tangents of the &array;'s values. ! Array<T> atan2 (const Array<T1>& A, const Array<T2>& B) Computes the arc tangents of the values from the division of elements in B by the elements in A. The resulting values are the signed angles in the range -π to π, inclusive. ! Array<T> atan2 (const Array<T1>& A, const T2& r) Computes the arc tangents of the values from the division of r by the elements in A. The resulting values are the signed angles in the range -π to π, inclusive. ! Array<T> atan2 (const T1& l, const Array<T2>& B) Computes the arc tangents of the values from the division of elements in B by l. The resulting values are the signed angles in the range -π to π, inclusive. ! Array<T> cosh (const Array<T>& A) Returns the hyperbolic cosines of the &array;'s values. ! Array<T> sinh (const Array<T>& A) Returns the hyperbolic sines of the &array;'s values. ! Array<T> tanh (const Array<T>& A) Returns the hyperbolic tangents of the &array;'s values. Absolute Value, Rounding, and Modulus Functions ! #include <math.h> ! Array<T> fabs (const Array<T1>& A) Returns the absolute values of the floating point numbers in the &array;. ! Array<T> ceil (const Array<T1>& A) For each of the &array;'s values, return the integer larger than or equal to it (as a floating point number). ! Array<T> floor (const Array<T1>& A) For each of the &array;'s values, return the integer smaller than or equal to it (as a floating point number). ! Array<T> fmod (const Array<T1>& A, const Array<T2>& B) Computes the floating-point modulus (remainder) of A's values with the corresponding value in B. The results have the same signs *************** std::cout &openopen; A-B &openopen; std: *** 447,460 **** absolute values of B. ! Array<T> fmod (const Array<T1>& A, const T2& r) Computes the floating-point modulus (remainder) of A's values with r. The results have the same signs as A and absolute values less than the absolute value of r. ! Array<T> fmod (const T1& l, const Array<T2>& B) Computes the floating-point modulus (remainder) of l with the values in B. The results have the same signs --- 447,460 ---- absolute values of B. ! Array<T> fmod (const Array<T1>& A, const T2& r) Computes the floating-point modulus (remainder) of A's values with r. The results have the same signs as A and absolute values less than the absolute value of r. ! Array<T> fmod (const T1& l, const Array<T2>& B) Computes the floating-point modulus (remainder) of l with the values in B. The results have the same signs *************** std::cout &openopen; A-B &openopen; std: *** 463,618 **** Powers, Exponentiation, and Logarithmic Functions ! #include <math.h> ! Array<T> PETE_identity (const Array<T>& A) Returns the &array;. That is, it applies the identity operation. ! Array<T> sqrt (const Array<T>& A) Returns the square roots of the &array;'s values. ! Array<T> pow (const Array<T1>& A, const Array<T2>& B) Raises A's values by the corresponding power in B. ! Array<T> pow (const Array<T1>& A, const T2& r) Raises A's values by the power r. ! Array<T> pow (const T1& l, const Array<T2>& B) Raises l by the powers in B. ! Array<T> pow2 (const Array<T>& A) Returns the squares of A's values. ! Array<T> pow3 (const Array<T>& A) Returns the cubes of A's values. ! Array<T> pow4 (const Array<T>& A) Returns the fourth powers of A's values. ! Array<T> ldexp (const Array<T1>& A, const Array<int>& B) Multiplies A's values by two raised to the corresponding value in B. ! Array<T> ldexp (const Array<T1>& A, int r) Multiplies A's values by two raised to the rth power. ! Array<T> ldexp (const T1& l, const Array<int>& B) Multiplies l by two raised to the values in B. ! Array<T> exp (const Array<T>& A) Returns the exponentiations of the &array;'s values. ! Array<T> log (const Array<T>& A) Returns the natural logarithms of the &array;'s values. ! Array<T> log10 (const Array<T>& A) Returns the base-10 logarithms of the &array;'s values. Functions Involving Complex Numbers ! #include <complex> ! Array<T> real (const Array<complex<T&closeclose;& A) Returns the real parts of A's complex numbers. ! Array<T> imag (const Array<complex<T&closeclose;& A) Returns the imaginary parts of A's complex numbers. ! Array<T> abs (const Array<complex<T&closeclose;& A) Returns the absolute values (magnitudes) of A's complex numbers. ! Array<T> abs (const Array<T>& A) Returns the absolute values of A's values. ! Array<T> arg (const Array<complex<T&closeclose;& A) Returns the angle representations (in radians) of the polar representations of A's complex numbers. ! Array<T> norm (const Array<complex<T&closeclose;& A) Returns the squared absolute values of A's complex numbers. ! Array<complex<T&closeclose; conj (const Array<complex<T&closeclose;& A) Returns the complex conjugates of A's complex numbers. ! Array<complex<T&closeclose; polar (const Array<T1>& A, const Array<T2>& B) Returns the complex numbers created from polar coordinates (magnitudes and phase angles) in corresponding &array;s. ! Array<complex<T&closeclose; polar (const T1& l, const Array<T2>& A) Returns the complex numbers created from polar coordinates with magnitude l and phase angles in the &array;. ! Array<complex<T&closeclose; polar (const Array<T1>& A, const T2& r) Returns the complex numbers created from polar coordinates with magnitudes in the &array; and phase angle r. Functions Involving Matrices and Tensors ! #include "Pooma/Tiny.h" ! T trace (const Array<T>& A) Returns the sum of the A's diagonal entries, viewed as a matrix. ! T det (const Array<T>& A) Returns the determinant of A, viewed as a matrix. ! Array<T> transpose (const Array<T>& A) Returns the transpose of A, viewed as a matrix. ! Array<T> symmetrize (const Array<T>& A) Returns the tensors of A with the requested output symmetry. ! Array<T> dot (const Array<T1>& A, const Array<T2>& B) Returns the dot products of values in the two &array;s. Value type T equals the type of the dot operating on T1 and T2. ! Array<T> dot (const Array<T1>& A, const T2& r) Returns the dot products of values in the &array; with r. Value type T equals the type of the --- 463,618 ---- Powers, Exponentiation, and Logarithmic Functions ! #include <math.h> ! Array<T> PETE_identity (const Array<T>& A) Returns the &array;. That is, it applies the identity operation. ! Array<T> sqrt (const Array<T>& A) Returns the square roots of the &array;'s values. ! Array<T> pow (const Array<T1>& A, const Array<T2>& B) Raises A's values by the corresponding power in B. ! Array<T> pow (const Array<T1>& A, const T2& r) Raises A's values by the power r. ! Array<T> pow (const T1& l, const Array<T2>& B) Raises l by the powers in B. ! Array<T> pow2 (const Array<T>& A) Returns the squares of A's values. ! Array<T> pow3 (const Array<T>& A) Returns the cubes of A's values. ! Array<T> pow4 (const Array<T>& A) Returns the fourth powers of A's values. ! Array<T> ldexp (const Array<T1>& A, const Array<int>& B) Multiplies A's values by two raised to the corresponding value in B. ! Array<T> ldexp (const Array<T1>& A, int r) Multiplies A's values by two raised to the rth power. ! Array<T> ldexp (const T1& l, const Array<int>& B) Multiplies l by two raised to the values in B. ! Array<T> exp (const Array<T>& A) Returns the exponentiations of the &array;'s values. ! Array<T> log (const Array<T>& A) Returns the natural logarithms of the &array;'s values. ! Array<T> log10 (const Array<T>& A) Returns the base-10 logarithms of the &array;'s values. Functions Involving Complex Numbers ! #include <complex> ! Array<T> real (const Array<complex<T&closeclose;& A) Returns the real parts of A's complex numbers. ! Array<T> imag (const Array<complex<T&closeclose;& A) Returns the imaginary parts of A's complex numbers. ! Array<T> abs (const Array<complex<T&closeclose;& A) Returns the absolute values (magnitudes) of A's complex numbers. ! Array<T> abs (const Array<T>& A) Returns the absolute values of A's values. ! Array<T> arg (const Array<complex<T&closeclose;& A) Returns the angle representations (in radians) of the polar representations of A's complex numbers. ! Array<T> norm (const Array<complex<T&closeclose;& A) Returns the squared absolute values of A's complex numbers. ! Array<complex<T&closeclose; conj (const Array<complex<T&closeclose;& A) Returns the complex conjugates of A's complex numbers. ! Array<complex<T&closeclose; polar (const Array<T1>& A, const Array<T2>& B) Returns the complex numbers created from polar coordinates (magnitudes and phase angles) in corresponding &array;s. ! Array<complex<T&closeclose; polar (const T1& l, const Array<T2>& A) Returns the complex numbers created from polar coordinates with magnitude l and phase angles in the &array;. ! Array<complex<T&closeclose; polar (const Array<T1>& A, const T2& r) Returns the complex numbers created from polar coordinates with magnitudes in the &array; and phase angle r. Functions Involving Matrices and Tensors ! #include "Pooma/Tiny.h" ! T trace (const Array<T>& A) Returns the sum of the A's diagonal entries, viewed as a matrix. ! T det (const Array<T>& A) Returns the determinant of A, viewed as a matrix. ! Array<T> transpose (const Array<T>& A) Returns the transpose of A, viewed as a matrix. ! Array<T> symmetrize (const Array<T>& A) Returns the tensors of A with the requested output symmetry. ! Array<T> dot (const Array<T1>& A, const Array<T2>& B) Returns the dot products of values in the two &array;s. Value type T equals the type of the dot operating on T1 and T2. ! Array<T> dot (const Array<T1>& A, const T2& r) Returns the dot products of values in the &array; with r. Value type T equals the type of the *************** std::cout &openopen; A-B &openopen; std: *** 620,633 **** and T2. ! Array<T> dot (const T1& l, const Array<T2>& A) Returns the dot products of l with values in the &array;. Value type T equals the type of the dot operating on T1 and T2. ! Array<Tensor<T&closeclose; outerProduct (const Array<T1>& A, const Array<T2>& B) Returns tensors created by computing the outer product of corresponding vectors in the two &array;s. Value type T equals the type of the product of --- 620,633 ---- and T2. ! Array<T> dot (const T1& l, const Array<T2>& A) Returns the dot products of l with values in the &array;. Value type T equals the type of the dot operating on T1 and T2. ! Array<Tensor<T&closeclose; outerProduct (const Array<T1>& A, const Array<T2>& B) Returns tensors created by computing the outer product of corresponding vectors in the two &array;s. Value type T equals the type of the product of *************** std::cout &openopen; A-B &openopen; std: *** 635,641 **** must have the same length. ! Array<Tensor<T&closeclose; outerProduct (const T1& l, const Array<T2>& A) Returns tensors created by computing the outer product of l with the vectors in the &array;. Value type T equals the type of the product of --- 635,641 ---- must have the same length. ! Array<Tensor<T&closeclose; outerProduct (const T1& l, const Array<T2>& A) Returns tensors created by computing the outer product of l with the vectors in the &array;. Value type T equals the type of the product of *************** std::cout &openopen; A-B &openopen; std: *** 643,649 **** must have the same length. ! Array<Tensor<T&closeclose; outerProduct (const Array<T1>& A, const T2& r) Returns tensors created by computing the outer product of vectors in the &array; with r. Value type T equals the type of the product of --- 643,649 ---- must have the same length. ! Array<Tensor<T&closeclose; outerProduct (const Array<T1>& A, const T2& r) Returns tensors created by computing the outer product of vectors in the &array; with r. Value type T equals the type of the product of *************** std::cout &openopen; A-B &openopen; std: *** 651,658 **** must have the same length. ! TinyMatrix<T> outerProductAsTinyMatrix (const Array<T1>& A, const ! Array<T2>& B) Returns matrices created by computing the outer product of corresponding vectors in the two &array;s. Value type T equals the type of the product of --- 651,658 ---- must have the same length. ! TinyMatrix<T> outerProductAsTinyMatrix (const Array<T1>& A, const ! Array<T2>& B) Returns matrices created by computing the outer product of corresponding vectors in the two &array;s. Value type T equals the type of the product of *************** std::cout &openopen; A-B &openopen; std: *** 660,667 **** the same length. ! TinyMatrix<T> outerProductAsTinyMatrix (const T1& l, const ! Array<T2>& A) Returns matrices created by computing the outer product of l with the vectors in the &array;. Value type T equals the type of the product of --- 660,667 ---- the same length. ! TinyMatrix<T> outerProductAsTinyMatrix (const T1& l, const ! Array<T2>& A) Returns matrices created by computing the outer product of l with the vectors in the &array;. Value type T equals the type of the product of *************** std::cout &openopen; A-B &openopen; std: *** 669,676 **** have the same length. ! TinyMatrix<T> outerProductAsTinyMatrix (const ! Array<T1>& A, const T2& r) Returns matrices created by computing the outer product of the vectors in the &array; with r. Value --- 669,676 ---- have the same length. ! TinyMatrix<T> outerProductAsTinyMatrix (const ! Array<T1>& A, const T2& r) Returns matrices created by computing the outer product of the vectors in the &array; with r. Value *************** std::cout &openopen; A-B &openopen; std: *** 687,694 **** max and min functions supplement named comparison functions. For example, LT and LE compute the ! same thing as the < and ! <= operators. --- 687,694 ---- max and min functions supplement named comparison functions. For example, LT and LE compute the ! same thing as the < and ! <= operators.

*************** std::cout &openopen; A-B &openopen; std: *** 703,826 **** ! Array<T> max (const Array<T1>& A, const Array<T2>& B) Returns the maximum of corresponding &array; values. ! Array<T> max (const T1& l, const Array<T2>& A) Returns the maximums of l with the &array;'s values. ! Array<T> max (const Array<T1>& A, const T2& r) Returns the maximums of the &array;'s values with r. ! Array<T> min (const Array<T1>& A, const Array<T2>& B) Returns the minimum of corresponding &array; values. ! Array<T> min (const T1& l, const Array<T2>& A) Returns the minimums of l with the &array;'s values. ! Array<T> min (const Array<T1>& A, const T2& r) Returns the minimums of the &array;'s values with r. ! Array<bool> LT (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the less-than ! operator < to compare corresponding &array; values in A and B. ! Array<bool> LT (const T1& r, const Array<T2>& A) Returns booleans from using the less-than ! operator < to compare l with the &array;'s values. ! Array<bool> LT (const Array<T1>& A, const T2& r) Returns booleans from using the less-than ! operator < to compare the &array;'s values with r. ! Array<bool> LE (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the less-than-or-equal ! operator <= to compare &array; values in A and B. ! Array<bool> LE (const T1& l, const Array<T2>& A) Returns booleans from using the less-than-or-equal ! operator <= to compare l with the &array;'s values. ! Array<bool> LE (const Array<T1>& A, const T2& r) Returns booleans from using the less-than-or-equal ! operator <= to compare the &array;'s values with r. ! Array<bool> GE (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the greater-than-or-equal ! operator >= to compare &array; values in A and B. ! Array<bool> GE (const T1& l, const Array<T2>& A) Returns booleans from using the greater-than-or-equal ! operator >= to compare l with the &array;'s values. ! Array<bool> GE (const Array<T1>& A, const T2& r) Returns booleans from using the greater-than-or-equal ! operator >= to compare the &array;'s values with r. ! Array<bool> GT (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the greater-than ! operator > to compare &array; values in A and B. ! Array<bool> GT (const T1& l, const Array<T2>& A) Returns booleans from using the greater-than ! operator > to compare l with the &array;'s values. ! Array<bool> GT (const Array<T1>& A, const T2& r) Returns booleans from using the greater-than ! operator > to compare the &array;'s values with r. ! Array<bool> EQ (const Array<T1>& A, const Array<T2>& B) Returns booleans from determining whether corresponding &array; values in A and B are equal. ! Array<bool> EQ (const T1& l, const Array<T2>& A) Returns booleans from determining whether l equals the &array;'s values. ! Array<bool> EQ (const Array<T1>& A, const T2& r) Returns booleans from determining whether the &array;'s values equal r. ! Array<bool> NE (const Array<T1>& A, const Array<T2>& B) Returns booleans from determining whether corresponding &array; values in A and B are not equal. ! Array<bool> NE (const T1& l, const Array<T2>& A) Returns booleans from determining whether l does not equal the &array;'s values. ! Array<bool> NE (const Array<T1>& A, const T2& r) Returns booleans from determining whether the &array;'s values are not equal to r. --- 703,826 ---- ! Array<T> max (const Array<T1>& A, const Array<T2>& B) Returns the maximum of corresponding &array; values. ! Array<T> max (const T1& l, const Array<T2>& A) Returns the maximums of l with the &array;'s values. ! Array<T> max (const Array<T1>& A, const T2& r) Returns the maximums of the &array;'s values with r. ! Array<T> min (const Array<T1>& A, const Array<T2>& B) Returns the minimum of corresponding &array; values. ! Array<T> min (const T1& l, const Array<T2>& A) Returns the minimums of l with the &array;'s values. ! Array<T> min (const Array<T1>& A, const T2& r) Returns the minimums of the &array;'s values with r. ! Array<bool> LT (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the less-than ! operator < to compare corresponding &array; values in A and B. ! Array<bool> LT (const T1& r, const Array<T2>& A) Returns booleans from using the less-than ! operator < to compare l with the &array;'s values. ! Array<bool> LT (const Array<T1>& A, const T2& r) Returns booleans from using the less-than ! operator < to compare the &array;'s values with r. ! Array<bool> LE (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the less-than-or-equal ! operator <= to compare &array; values in A and B. ! Array<bool> LE (const T1& l, const Array<T2>& A) Returns booleans from using the less-than-or-equal ! operator <= to compare l with the &array;'s values. ! Array<bool> LE (const Array<T1>& A, const T2& r) Returns booleans from using the less-than-or-equal ! operator <= to compare the &array;'s values with r. ! Array<bool> GE (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the greater-than-or-equal ! operator >= to compare &array; values in A and B. ! Array<bool> GE (const T1& l, const Array<T2>& A) Returns booleans from using the greater-than-or-equal ! operator >= to compare l with the &array;'s values. ! Array<bool> GE (const Array<T1>& A, const T2& r) Returns booleans from using the greater-than-or-equal ! operator >= to compare the &array;'s values with r. ! Array<bool> GT (const Array<T1>& A, const Array<T2>& B) Returns booleans from using the greater-than ! operator > to compare &array; values in A and B. ! Array<bool> GT (const T1& l, const Array<T2>& A) Returns booleans from using the greater-than ! operator > to compare l with the &array;'s values. ! Array<bool> GT (const Array<T1>& A, const T2& r) Returns booleans from using the greater-than ! operator > to compare the &array;'s values with r. ! Array<bool> EQ (const Array<T1>& A, const Array<T2>& B) Returns booleans from determining whether corresponding &array; values in A and B are equal. ! Array<bool> EQ (const T1& l, const Array<T2>& A) Returns booleans from determining whether l equals the &array;'s values. ! Array<bool> EQ (const Array<T1>& A, const T2& r) Returns booleans from determining whether the &array;'s values equal r. ! Array<bool> NE (const Array<T1>& A, const Array<T2>& B) Returns booleans from determining whether corresponding &array; values in A and B are not equal. ! Array<bool> NE (const T1& l, const Array<T2>& A) Returns booleans from determining whether l does not equal the &array;'s values. ! Array<bool> NE (const Array<T1>& A, const T2& r) Returns booleans from determining whether the &array;'s values are not equal to r. *************** std::cout &openopen; A-B &openopen; std: *** 834,840 **** two functions. peteCast casts all values in an &array; to the type specified by its first parameter. The where function generalizes the trinary ! ?: operator. Using its first &array; argument as boolean values, it returns an &array; of just two values: t and f. --- 834,840 ---- two functions. peteCast casts all values in an &array; to the type specified by its first parameter. The where function generalizes the trinary ! ?: operator. Using its first &array; argument as boolean values, it returns an &array; of just two values: t and f. *************** std::cout &openopen; A-B &openopen; std: *** 851,862 **** ! Array<T> peteCast (const T1&, const Array<T>& A) Returns the casting of the &array;'s values to type T1. ! Array<T> where (const Array<T1>& A, const T2& t, const T3& f) ! Generalizes the ?: operator, returning an &array; of t and f values depending on whether A's values are true or false, --- 851,862 ---- ! Array<T> peteCast (const T1&, const Array<T>& A) Returns the casting of the &array;'s values to type T1. ! Array<T> where (const Array<T1>& A, const T2& t, const T3& f) ! Generalizes the ?: operator, returning an &array; of t and f values depending on whether A's values are true or false, *************** B = 2.0; *** 926,932 **** A += -A + 2*B; std::cout &openopen; A &openopen; std::endl; Our goal is to transform the data-parallel ! statement A += -A + 2*B into a single loop, preferably without using intermediary containers. To simplify notation, let Ar abbreviate the type Array<1, double, Brick>. --- 926,932 ---- A += -A + 2*B; std::cout &openopen; A &openopen; std::endl; Our goal is to transform the data-parallel ! statement A += -A + 2*B into a single loop, preferably without using intermediary containers. To simplify notation, let Ar abbreviate the type Array<1, double, Brick>. *************** std::cout &openopen; A &openopen; std::e *** 934,945 **** Using overloaded arithmetic operators would require using intermediate containers to evaluate the statement. For example, the sum's left operand -A ! would be computed by the overloaded unary operator Ar ! operator-(const Ar&), which would produce an ! intermediate &array;. Ar operator*(double, ! const Ar&) would produce another intermediate ! &array; holding 2*B. Yet another intermediate container would hold their sum, all before performing the assignment. Thus, three intermediate containers would be created and destroyed. Below, we show these are --- 934,945 ---- Using overloaded arithmetic operators would require using intermediate containers to evaluate the statement. For example, the sum's left operand -A ! would be computed by the overloaded unary operator Ar ! operator-(const Ar&), which would produce an ! intermediate &array;. Ar operator*(double, ! const Ar&) would produce another intermediate ! &array; holding 2*B. Yet another intermediate container would hold their sum, all before performing the assignment. Thus, three intermediate containers would be created and destroyed. Below, we show these are *************** std::cout &openopen; A &openopen; std::e *** 965,976 **** intermediate loops or temporary values are needed. Before explaining the implementation, let us illustrate ! using our example statement A += -A + 2*B. Evaluating the right-hand side creates a parse tree similar to the one in . For example, the overloaded unary minus operator yields a tree ! node representing -A, having a unary-minus function object, and having type Expression<UnaryNode<OpMinus,Ar&closeclose; --- 965,976 ---- intermediate loops or temporary values are needed. Before explaining the implementation, let us illustrate ! using our example statement A += -A + 2*B. Evaluating the right-hand side creates a parse tree similar to the one in . For example, the overloaded unary minus operator yields a tree ! node representing -A, having a unary-minus function object, and having type Expression<UnaryNode<OpMinus,Ar&closeclose; *************** Expression<BinaryNode<OpAdd, *** 984,990 **** representing A.

! Annotated Parse Tree for <statement>-A + 2*B</statement> --- 984,990 ---- representing A.

! Annotated Parse Tree for <literal>-A + 2*B</literal> *************** Expression<BinaryNode<OpAdd, *** 996,1009 **** A parse tree for the statement is produced. ! Finally, the assignment operator += calls the evaluate function corresponding to the left-hand side's type. At compile time, it produces the code for the computation. Since this templated function is --- 996,1009 ---- A parse tree for the statement is produced. ! Finally, the assignment operator += calls the evaluate function corresponding to the left-hand side's type. At compile time, it produces the code for the computation. Since this templated function is *************** Expression<BinaryNode<OpAdd, *** 1033,1039 **** the three things it must store: ! Op the type of the node's operation. For example, the OpAdd type represents adding two operands --- 1033,1039 ---- the three things it must store: ! Op the type of the node's operation. For example, the OpAdd type represents adding two operands *************** Expression<BinaryNode<OpAdd, *** 1041,1053 **** ! Left the type of the left child. ! Right the type of the right child. --- 1041,1053 ---- ! Left the type of the left child. ! Right the type of the right child. *************** struct CreateLeaf *** 1096,1102 **** }; The Scalar class stores the scalar value. The CreateLeaf's Leaf_t type ! indicates its type. The static make function is invoked by an overloaded operator function when creating its children. --- 1096,1102 ---- }; The Scalar class stores the scalar value. The CreateLeaf's Leaf_t type ! indicates its type. The staticmake function is invoked by an overloaded operator function when creating its children. *************** CreateLeaf<Array<D1,T1,E1> > *** 1149,1155 **** programmers to store trees in different formats. The &pooma; implementation stores them as Expressions. The function's return type is similar to the ! return statement except it extracts the type from Expression's internal Expression_t type. --- 1149,1155 ---- programmers to store trees in different formats. The &pooma; implementation stores them as Expressions. The function's return type is similar to the ! return statement except it extracts the type from Expression's internal Expression_t type. *************** classes *** 1171,1178 **** Inside the &array; class definition, each such operator just invokes the assign function with a corresponding function object. For example, ! operator+= invokes assign(*this, ! rhs, OpAddAssign()). rhs is the parse tree object for the right-hand side. Calling this function invokes evaluate, which begins the evaluation. --- 1171,1178 ---- Inside the &array; class definition, each such operator just invokes the assign function with a corresponding function object. For example, ! operator+= invokes assign(*this, ! rhs, OpAddAssign()). rhs is the parse tree object for the right-hand side. Calling this function invokes evaluate, which begins the evaluation. *************** for (int i = a's domain[0].first(); i < *** 1204,1210 **** assignment operation, and rhs is the right-hand side's parse tree. ! Evaluating rhs.read(i) inlines into a call to the forEach function. This function performs a compile-time post-order parse-tree traversal. Its general form is --- 1204,1210 ---- assignment operation, and rhs is the right-hand side's parse tree. ! Evaluating rhs.read(i) inlines into a call to the forEach function. This function performs a compile-time post-order parse-tree traversal. Its general form is *************** struct ForEach<UnaryNode<Op, A> *** 1249,1255 **** }; Since this structure is specialized for UnaryNodes, the first parameter of its ! static apply function is a UnaryNode. After recursively calling its child, it invokes the combination function indicated by the Combine1 traits class. In our example, the --- 1249,1255 ---- }; Since this structure is specialized for UnaryNodes, the first parameter of its ! static apply function is a UnaryNode. After recursively calling its child, it invokes the combination function indicated by the Combine1 traits class. In our example, the Index: glossary.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/glossary.xml,v retrieving revision 1.9 diff -c -p -r1.9 glossary.xml *** glossary.xml 2002/01/25 02:28:26 1.9 --- glossary.xml 2002/01/30 23:47:32 *************** *** 227,233 **** describes an expression involving a (non-singleton) subset of a container's values. For example, ! sin(&container;) is an expression indicating that the sin is applied to each value in container &container;. element wise --- 227,233 ---- describes an expression involving a (non-singleton) subset of a container's values. For example, ! sin(&container;) is an expression indicating that the sin is applied to each value in container &container;. element wise *************** *** 305,311 **** element wise describes accesses to individual values within a container. ! For example, &container(-4,3) represents one particular value in the container &container;. data parallel relation --- 305,311 ---- element wise describes accesses to individual values within a container. ! For example, &container(-4,3) represents one particular value in the container &container;. data parallel relation *************** *** 413,419 **** object that can behave as a function. The object can store values that the function uses. If its function is called ! operator(), the object can be invoked as a function. --- 413,419 ---- object that can behave as a function. The object can store values that the function uses. If its function is called ! operator(), the object can be invoked as a function. *************** guard layer *** 602,608 **** function defining a function invoked using a &cc; operator. For example, the operator+ function defines the ! result of using the +. --- 602,608 ---- function defining a function invoked using a &cc; operator. For example, the operator+ function defines the ! result of using the +. *************** guard layer *** 814,822 **** template instantiation applying a template class to template parameter arguments to create a ! type. For example, foo<double,3> ! instantiates template <typename T, int n> class ! foo with the type &double; and the constant integer 3. Template instantiation is analogous to applying a function to function arguments.template --- 814,822 ---- template instantiation applying a template class to template parameter arguments to create a ! type. For example, foo<double,3> ! instantiates template <typename T, int n> class ! foo with the type &double; and the constant integer 3. Template instantiation is analogous to applying a function to function arguments.template Index: introduction.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/introduction.xml,v retrieving revision 1.6 diff -c -p -r1.6 introduction.xml *** introduction.xml 2002/01/30 23:09:06 1.6 --- introduction.xml 2002/01/30 23:47:32 *************** A += -B + 2 * C; *** 298,305 **** where A and C are vector<double>s and B is a vector<int>. &naivecap; evaluation might introduce ! intermediaries for -B, ! 2*C, and their sum. The presence of these intermediaries in inner loops can measurably slow performance. To produce a loop without intermediaries, &pete; stores each expression as a parse tree. Using its templates, the parse tree is --- 298,305 ---- where A and C are vector<double>s and B is a vector<int>. &naivecap; evaluation might introduce ! intermediaries for -B, ! 2*C, and their sum. The presence of these intermediaries in inner loops can measurably slow performance. To produce a loop without intermediaries, &pete; stores each expression as a parse tree. Using its templates, the parse tree is Index: manual.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/manual.xml,v retrieving revision 1.12 diff -c -p -r1.12 manual.xml *** manual.xml 2002/01/30 23:09:06 1.12 --- manual.xml 2002/01/30 23:47:35 *************** *** 108,114 **** Engine"> ! false"> Field"> --- 108,114 ---- Engine"> ! false"> Field"> *************** *** 157,163 **** Tensor"> ! true"> Vector"> --- 157,163 ---- Tensor"> ! true"> Vector"> *************** *** 446,454 **** and accessor functions returning individual elements. The &pooma; &engine; class and its specializations implement the engine concept. Given an index within the domain, an &engine;'s ! operator() function returns the associated value, which can be used or changed. Its ! read member function returns the same value but permitting only use, not modification. The acceptable indices are determined by each &engine;. Most accept indices specified using ∫ and Loc<&dim;> --- 446,454 ---- and accessor functions returning individual elements. The &pooma; &engine; class and its specializations implement the engine concept. Given an index within the domain, an &engine;'s ! operator() function returns the associated value, which can be used or changed. Its ! read member function returns the same value but permitting only use, not modification. The acceptable indices are determined by each &engine;. Most accept indices specified using ∫ and Loc<&dim;> *************** *** 499,505 **** Thus, copying an &engine; or a container requires little execution time. If an &engine; has the same data as another &engine; but it needs its own data to modify, the ! makeOwnCopy member function creates such a copy.&engine;s are rarely explicitly declared. Instead a --- 499,505 ---- Thus, copying an &engine; or a container requires little execution time. If an &engine; has the same data as another &engine; but it needs its own data to modify, the ! makeOwnCopy member function creates such a copy.&engine;s are rarely explicitly declared. Instead a *************** *** 517,524 **** &brick; &engine; tag indicates a &brick; &engine; should be used. Some &engine;s, such as CompFwd, are rarely declared even using &engine; tags. Instead the &array;'s ! comp and ! readComp member functions return views of containers using CompFwd &engine;s. --- 517,524 ---- &brick; &engine; tag indicates a &brick; &engine; should be used. Some &engine;s, such as CompFwd, are rarely declared even using &engine; tags. Instead the &array;'s ! comp and ! readComp member functions return views of containers using CompFwd &engine;s. *************** *** 569,575 **** CompFwdextracts specified components of an engine's vectors, tensors, arrays, etc.; usually created using the ! comp container function. ConstantFunction --- 569,575 ---- CompFwd extracts specified components of an engine's vectors, tensors, arrays, etc.; usually created using the ! comp container function. ConstantFunction *************** *** 644,652 **** value, not every value. Using less storage space may also permit more useful values to be stored in cache, improving cache performance. Reading a value in a compressed &engine; using the ! read member function is as fast as reading a value in a &brick; &engine;, but writing a value always ! requires executing an additional if conditional. Thus, if an &engine; infrequently has multiple different values during its life time, a &compressiblebrick; &engine; may be faster than a &brick; &engine;. If an &engine; is --- 644,652 ---- value, not every value. Using less storage space may also permit more useful values to be stored in cache, improving cache performance. Reading a value in a compressed &engine; using the ! read member function is as fast as reading a value in a &brick; &engine;, but writing a value always ! requires executing an additional if conditional. Thus, if an &engine; infrequently has multiple different values during its life time, a &compressiblebrick; &engine; may be faster than a &brick; &engine;. If an &engine; is *************** *** 664,683 **** distributed computing. Both &brick; and &compressiblebrick; &engine;s have ! read and ! operator() member functions taking ∫ and &loc; parameters. The parameters should match the &array;'s dimensionality. For example, if &array; a has dimensionality 3, a.read(int, int, int) and a(int, int, int) should be used. The former returns a value that cannot be modified, while the latter ! can be changed. Using the read member function can lead to faster code. Alternatively, an index can be specified using a &loc;. For example, ! a.read(Loc<3>(1,-2,5)) and ! a(Loc<3>(1,-2,5)) are equivalent to ! a.read(1,-2,5)) and ! a(1,-2,5). The &dynamic; &engine; supports changing domain sizes while a program is executing. It is basically a one-dimensional --- 664,683 ---- distributed computing. Both &brick; and &compressiblebrick; &engine;s have ! read and ! operator() member functions taking ∫ and &loc; parameters. The parameters should match the &array;'s dimensionality. For example, if &array; a has dimensionality 3, a.read(int, int, int) and a(int, int, int) should be used. The former returns a value that cannot be modified, while the latter ! can be changed. Using the read member function can lead to faster code. Alternatively, an index can be specified using a &loc;. For example, ! a.read(Loc<3>(1,-2,5)) and ! a(Loc<3>(1,-2,5)) are equivalent to ! a.read(1,-2,5)) and ! a(1,-2,5). The &dynamic; &engine; supports changing domain sizes while a program is executing. It is basically a one-dimensional *************** *** 685,695 **** order of stored values to change. Thus, it supports the same interface as &brick; except that all member functions are restricted to their one-dimensional versions. For example, ! read and ! operator() take Loc<1> or one ∫ parameter. In addition, the one-dimensional domain ! can be dynamically resized using create ! and destroy. read and ! operator() take Loc<1> or one ∫ parameter. In addition, the one-dimensional domain ! can be dynamically resized using create ! and destroy. The last statement creates ten views. For example, ! a(I,J) creates a view of a using the smaller domain specified by I and J. This omits the outermost rows of columns of a. The views of b illustrate the use of views in ! data-parallel statements. b(I-1,J-1) has a subset shifted up one row and left one column compared with ! b(I,J). ]]> Be sure to list the various arithmetic operations on domains --- 809,822 ---- b(I-1,J+1) + b(I-1,J ) + b(I-1,J-1)); The last statement creates ten views. For example, ! a(I,J) creates a view of a using the smaller domain specified by I and J. This omits the outermost rows of columns of a. The views of b illustrate the use of views in ! data-parallel statements. b(I-1,J-1) has a subset shifted up one row and left one column compared with ! b(I,J). ]]> Be sure to list the various arithmetic operations on domains *************** UNFINISHED *** 1601,1607 **** where A, B and C are &array;s and foo is a function taking an &array; as an argument. The expression ! A*B+C will only be evaluated by the expression engine as needed by foo. --- 1601,1607 ---- where A, B and C are &array;s and foo is a function taking an &array; as an argument. The expression ! A*B+C will only be evaluated by the expression engine as needed by foo. *************** UNFINISHED *** 1718,1724 **** incorrect. To help diagnose if calls to Pooma::blockAndEvaluate are missing, invoke a &pooma; executable with the ! &dashdash;pooma-blocking-expressions option. This automatically causes Pooma::blockAndEvaluate to be called after each statement. Doing so ensures program correctness, but it --- 1718,1724 ---- incorrect. To help diagnose if calls to Pooma::blockAndEvaluate are missing, invoke a &pooma; executable with the ! &dashdash;pooma-blocking-expressions option. This automatically causes Pooma::blockAndEvaluate to be called after each statement. Doing so ensures program correctness, but it *************** UNFINISHED *** 1728,1741 **** important than execution speed. If using ! &dashdash;pooma-blocking-expressions changes a program's output, it is missing one or more calls to Pooma::blockAndEvaluate. To narrow the region with a missing call, surround the region in question with ! calls to Pooma::blockingExpressions(true) ! and Pooma::blockingExpressions(false), but do not use the ! &dashdash;pooma-blocking-expressions option. Within the region, Pooma::blockAndEvaluate will be invoked after each statement. Repeatedly reducing the region's size should reveal where calls are missing. --- 1728,1741 ---- important than execution speed. If using ! &dashdash;pooma-blocking-expressions changes a program's output, it is missing one or more calls to Pooma::blockAndEvaluate. To narrow the region with a missing call, surround the region in question with ! calls to Pooma::blockingExpressions(true) ! and Pooma::blockingExpressions(false), but do not use the ! &dashdash;pooma-blocking-expressions option. Within the region, Pooma::blockAndEvaluate will be invoked after each statement. Repeatedly reducing the region's size should reveal where calls are missing. *************** UNFINISHED *** 1767,1773 **** class="libraryfile">.cmpl.cpp, .mk, .conf. Should we also explain use ! of inline even when necessary and the template model, e.g., including .cpp files. --- 1767,1773 ---- class="libraryfile">.cmpl.cpp, .mk, .conf. Should we also explain use ! of inline even when necessary and the template model, e.g., including .cpp files. *************** UNFINISHED *** 2090,2096 **** ! Array --- 2090,2096 ---- ! Array *************** UNFINISHED *** 2100,2106 **** ! Array const Engine_t& engine --- 2100,2106 ---- ! Array const Engine_t& engine *************** UNFINISHED *** 2114,2120 **** ! Array const Engine<Dim2, T2, EngineTag2>& --- 2114,2120 ---- ! Array const Engine<Dim2, T2, EngineTag2>& *************** UNFINISHED *** 2162,2168 **** ! Element_t read --- 2162,2168 ---- ! Element_t read *************** UNFINISHED *** 2171,2177 **** ! Element_t read const Sub1& s1 --- 2171,2177 ---- ! Element_t read const Sub1& s1 *************** UNFINISHED *** 2189,2195 **** ! Element_t operator() const Sub1& s1 --- 2189,2195 ---- ! Element_t operator() const Sub1& s1 *************** UNFINISHED *** 2200,2207 **** ! How does this differ from read(const ! Sub1& s1, const Sub2& s2)? ADD ALL reads and --- 2200,2207 ---- ! How does this differ from read(const ! Sub1& s1, const Sub2& s2)? ADD ALL reads and *************** UNFINISHED *** 2218,2231 **** When an array stores elements having components, e.g., an array of vectors, tensors, or arrays, the ! comp returns an array consisting of the specified components. The original and component array share the same engine so changing the values in one affects values in the other. For example, if &n; × &n; array a consists of three-dimensional real-valued vectors, ! a.comp(1) returns a &n; × &n; real-valued array of all the middle vector components. Assigning to the component array will also modify the middle components of the vectors in a. --- 2218,2231 ---- When an array stores elements having components, e.g., an array of vectors, tensors, or arrays, the ! comp returns an array consisting of the specified components. The original and component array share the same engine so changing the values in one affects values in the other. For example, if &n; × &n; array a consists of three-dimensional real-valued vectors, ! a.comp(1) returns a &n; × &n; real-valued array of all the middle vector components. Assigning to the component array will also modify the middle components of the vectors in a. *************** UNFINISHED *** 2245,2251 **** ! UNKNOWN compute this comp const int& --- 2245,2251 ---- ! UNKNOWN compute this comp const int& *************** UNFINISHED *** 2256,2262 **** unknown: See line 1989. ! ADD ALL comps. --- 2256,2262 ---- unknown: See line 1989. ! ADD ALL comps. *************** UNFINISHED *** 2281,2287 **** ! int first int d --- 2281,2287 ---- ! int first int d *************** UNFINISHED *** 2292,2298 **** ADD ALL other accessor methods, including ! engine. --- 2292,2298 ---- ADD ALL other accessor methods, including ! engine. *************** UNFINISHED *** 2327,2333 **** ! void makeOwnCopy --- 2327,2333 ---- ! void makeOwnCopy *************** UNFINISHED *** 2346,2353 **** Implementation Details As a container, an &array;'s implementation is quite ! simple. Its privatedata consists of ! an engine, and it has no private functions.

Implementation DetailsAs a container, an &array;'s implementation is quite ! simple. Its privatedata consists of ! an engine, and it has no private functions.

*** 2406,2413 **** Implementation DetailsDynamicArray has no ! protected or ! private members. --- 2406,2413 ---- Implementation DetailsDynamicArray has no ! protected or ! private members. *************** UNFINISHED *** 2456,2462 **** In &pooma;, expressions may contain entire &array;s. That is, &array;s are first-class objects with respect to expressions. For example, given &array;s a and ! b, the expression a + b is equivalent to an array containing the element-wise sum of the two arrays. --- 2456,2462 ---- In &pooma;, expressions may contain entire &array;s. That is, &array;s are first-class objects with respect to expressions. For example, given &array;s a and ! b, the expression a + b is equivalent to an array containing the element-wise sum of the two arrays. *************** UNFINISHED *** 2696,2702 **** Element AccessADD: a table ala &array;. Be sure to include ! all. --- 2696,2702 ---- Element AccessADD: a table ala &array;. Be sure to include ! all. *************** UNFINISHED *** 2718,2726 **** See src/Field/Field.h's ! operator[], ! subField, …, ! material. --- 2718,2726 ---- See src/Field/Field.h's ! operator[], ! subField, …, ! material. *************** UNFINISHED *** 2728,2737 **** Supporting RelationsADD: a table with the member functions including ! addRelation, ! removeRelations, ! applyRelations, and ! setDirty. --- 2728,2737 ---- Supporting RelationsADD: a table with the member functions including ! addRelation, ! removeRelations, ! applyRelations, and ! setDirty. *************** UNFINISHED *** 2747,2753 **** Utility MethodsADD: a table including ! makeOwnCopy. --- 2747,2753 ---- Utility MethodsADD: a table including ! makeOwnCopy. *************** UNFINISHED *** 2767,2773 **** Be sure to relate to &array; views. Note only three dimensions are supported. ! Be sure to describe f[i]. Does this refer to a particular material or a particular value within a cell? I do not remember. See SubFieldView in src/Field/Field.h. --- 2767,2773 ---- Be sure to relate to &array; views. Note only three dimensions are supported. ! Be sure to describe f[i]. Does this refer to a particular material or a particular value within a cell? I do not remember. See SubFieldView in src/Field/Field.h. *************** UNFINISHED *** 3180,3187 ****

Element Access ! ADD: a table with read and ! operator().

--- 3180,3187 ----

Element Access ! ADD: a table with read and ! operator().

*************** UNFINISHED *** 3204,3213 **** Utility MethodsADD: a table including ! makeOwnCopy. ! QUESTION: What are dataObject, ! isShared, and related methods? --- 3204,3213 ---- Utility MethodsADD: a table including ! makeOwnCopy. ! QUESTION: What are dataObject, ! isShared, and related methods? *************** UNFINISHED *** 3226,3232 **** ADD: description of what a brick means. ADD: whatever specializations the class has, e.g., ! offset.QUESTION: What does DoubleSliceHelper do? --- 3226,3232 ---- ADD: description of what a brick means. ADD: whatever specializations the class has, e.g., ! offset.QUESTION: What does DoubleSliceHelper do? *************** UNFINISHED *** 3375,3381 **** created by Pooma::initialize, storing run-time configurable values found in argv. Default options are found in ! Options::usage.See src/Utilities/Options.h and --- 3375,3381 ---- created by Pooma::initialize, storing run-time configurable values found in argv. Default options are found in ! Options::usage.See src/Utilities/Options.h and *************** UNFINISHED *** 3593,3599 **** class="headerfile">src/Utilities/DerefIterator.h: DerefIterator<T> and ConstDerefIterator<T> automatically ! dereference themselves to maintain const correctness. --- 3593,3599 ---- class="headerfile">src/Utilities/DerefIterator.h: DerefIterator<T> and ConstDerefIterator<T> automatically ! dereference themselves to maintain const correctness. *************** UNFINISHED *** 3896,3902 **** modification. However, if you are using &mm;, ensure shmem_default_dir specifies its location. For example, the &author; modified the value to ! "/home/oldham/pooma/mm-1.1.3". Prepare to compile the source code by configuring it --- 3896,3902 ---- modification. However, if you are using &mm;, ensure shmem_default_dir specifies its location. For example, the &author; modified the value to ! "/home/oldham/pooma/mm-1.1.3". Prepare to compile the source code by configuring it Index: template.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/template.xml,v retrieving revision 1.4 diff -c -p -r1.4 template.xml *** template.xml 2002/01/30 23:09:06 1.4 --- template.xml 2002/01/30 23:47:36 *************** *** 95,101 **** its dimension, the type of its values, and its &engine; type. To use this, a programmer specifies values for the template parameters: ! Array<2,double,Brick> specifies a dimension of 2, a value type of &double;, and the &brick; &engine; type. At compile time, the compiler creates a type definition by substituting the values for the template --- 95,101 ---- its dimension, the type of its values, and its &engine; type. To use this, a programmer specifies values for the template parameters: ! Array<2,double,Brick> specifies a dimension of 2, a value type of &double;, and the &brick; &engine; type. At compile time, the compiler creates a type definition by substituting the values for the template *************** *** 195,201 **** these concrete types with a template parameter T. We precede, not follow, the class definition ! with template <typename T>. The constructor's parameters' types are changed to T, as are the data members' types. --- 195,201 ---- these concrete types with a template parameter T. We precede, not follow, the class definition ! with template <typename T>. The constructor's parameters' types are changed to T, as are the data members' types. *************** *** 223,236 **** arearefs="template_programming-template_use-templated_pair_program-use"> To use a templated class, specify the template parameter's argument after the class's name and surrounded by ! angle brackets (<>). To use a template class definition, template arguments follow the class name surrounded by angle ! brackets (<>). For example, pair<int> instantiates --- 223,236 ---- arearefs="template_programming-template_use-templated_pair_program-use"> To use a templated class, specify the template parameter's argument after the class's name and surrounded by ! angle brackets (<>). To use a template class definition, template arguments follow the class name surrounded by angle ! brackets (<>). For example, pair<int> instantiates *************** *** 242,249 **** creates a definition for pair<int> by copying pair's template definition and substituting ∫ for each occurrence of T. The copy ! omits the template parameter declaration template ! <typename T> at the beginning of its definition. The result is a definition exactly the same as pairOfInts. --- 242,249 ---- creates a definition for pair<int> by copying pair's template definition and substituting ∫ for each occurrence of T. The copy ! omits the template parameter declaration template ! <typename T> at the beginning of its definition. The result is a definition exactly the same as pairOfInts. *************** *** 273,279 **** compile-time operations use these types. For both run-time and compile-time programming, &cc; defines default sets of values that all conforming compilers must support. For example, ! 3 and 6.022e+23 are run-time values that any &cc; compiler must accept. It must also accept the ∫, &bool;, and int* types. --- 273,279 ---- compile-time operations use these types. For both run-time and compile-time programming, &cc; defines default sets of values that all conforming compilers must support. For example, ! 3 and 6.022e+23 are run-time values that any &cc; compiler must accept. It must also accept the ∫, &bool;, and int* types. *************** maxOut(0, 3); *** 422,450 **** with the templated class in . Note the notation for the template class parameters. ! template <typename T> precedes the class definition. The keyword ! typename ! typename indicates the template parameter is a type. T is the template parameter's name. (We could have used any other identifier such as pairElementType or foo.) ! Note that using class ! class is equivalent to ! using typename so template ! <class T> is equivalent to template ! <typename T>. While declaring a template class requires prefix notation, using a templated class requires postfix notation. The class's name precedes angle brackets (<>) surrounding specific values, i.e., types, for its parameters. As we showed above, ! pair<int> instantiates template --- 422,450 ---- with the templated class in . Note the notation for the template class parameters. ! template <typename T> precedes the class definition. The keyword ! typename ! typename indicates the template parameter is a type. T is the template parameter's name. (We could have used any other identifier such as pairElementType or foo.) ! Note that using class ! class is equivalent to ! using typename so template ! <class T> is equivalent to template ! <typename T>. While declaring a template class requires prefix notation, using a templated class requires postfix notation. The class's name precedes angle brackets (<>) surrounding specific values, i.e., types, for its parameters. As we showed above, ! pair<int> instantiates template *************** maxOut(0, 3); *** 471,479 **** domain: typedef typename Engine_t::Domain_t Domain_t; ! This typedef, ! typedef type, definition. --- 471,479 ---- domain: typedef typename Engine_t::Domain_t Domain_t; ! This typedef, ! typedef type, definition. *************** typedef typename Engine_t::Domain_t Doma *** 483,491 **** i.e., type definition, defines the type Domain_t as equivalent to Engine_t::Domain_t. The ! :: operator ! :: operator selects the Domain_t nested type from inside the Engine_t type. This illustrates how to access --- 483,491 ---- i.e., type definition, defines the type Domain_t as equivalent to Engine_t::Domain_t. The ! :: operator ! :: operator selects the Domain_t nested type from inside the Engine_t type. This illustrates how to access *************** typedef typename Engine_t::Domain_t Doma *** 544,557 **** operations on values ! Integral values support +, ! -, >, ! ==, …. String values support ! [], ==, …. Types may be declared and used. Constant integral and ! enumeration values can be combined using +, ! -, >, ! ==, …. There are no permitted operations on code. --- 544,557 ---- operations on values ! Integral values support +, ! -, >, ! ==, …. String values support ! [], ==, …. Types may be declared and used. Constant integral and ! enumeration values can be combined using +, ! -, >, ! ==, …. There are no permitted operations on code. *************** typedef typename Engine_t::Domain_t Doma *** 572,586 **** extracting values from collections An object's named values are extracted using the ! . operator. ! . operator A class's nested types and classes are extracted using ! the :: operator. ! :: operator --- 572,586 ---- extracting values from collections An object's named values are extracted using the ! . operator. ! . operator A class's nested types and classes are extracted using ! the :: operator. ! :: operator *************** typedef typename Engine_t::Domain_t Doma *** 590,596 **** control flow to choose among operations ! if, while, goto, … template class specializations with pattern matching --- 590,596 ---- control flow to choose among operations ! if, while, goto, … template class specializations with pattern matching *************** typedef typename Engine_t::Domain_t Doma *** 609,615 **** The only compile-time values described in the previous section were types, but any compile-time constant can also be used. ! Integral literals, const variables, and other constructs can be used, but the main use is enumerations. An enumeration --- 609,615 ---- The only compile-time values described in the previous section were types, but any compile-time constant can also be used. ! Integral literals, const variables, and other constructs can be used, but the main use is enumerations. An enumeration *************** struct usuallySimpleClass { *** 741,747 **** should be true only if the constructor must perform some very complicated, time-expensive computation. When instantiated with &false;, the compiler substitutes this value into the template ! class definition. Since the if statement's conditional is false, the compiler optimizer can eliminate the statement, yielding internal code similar to --- 741,747 ---- should be true only if the constructor must perform some very complicated, time-expensive computation. When instantiated with &false;, the compiler substitutes this value into the template ! class definition. Since the if statement's conditional is false, the compiler optimizer can eliminate the statement, yielding internal code similar to *************** struct usuallySimpleClass<false> { *** 774,791 **** Each category of values supports a distinct set of operations. For example, the run-time category of ! integer values supports combination using + ! and - and comparison using ! > and ==. At run time, the category of strings can be compared using ! == and characters can be extracted using ! subscripts with the [] operator. Compile-time operations are more limited. Types may be declared and used. The ! sizeof operator yields the number of bytes to represent an object of the specified type. Enumerations, ! constant integers, sizeof expressions, and simple arithmetic and comparison operators such as ! + and == can form constant expressions that can be used at compile time. These values can initialize enumerations and integer constants and be used as template arguments. At compile time, pointers and --- 774,791 ---- Each category of values supports a distinct set of operations. For example, the run-time category of ! integer values supports combination using + ! and - and comparison using ! > and ==. At run time, the category of strings can be compared using ! == and characters can be extracted using ! subscripts with the [] operator. Compile-time operations are more limited. Types may be declared and used. The ! sizeof operator yields the number of bytes to represent an object of the specified type. Enumerations, ! constant integers, sizeof expressions, and simple arithmetic and comparison operators such as ! + and == can form constant expressions that can be used at compile time. These values can initialize enumerations and integer constants and be used as template arguments. At compile time, pointers and *************** struct usuallySimpleClass<false> { *** 809,822 **** can store multiple values, each having its own name. For example, a pair<int> object p stores two ∫s named ! left_ and ! right_. The . operator ! . operator extracts a named member from an object: ! p.left_. At compile time, a class can store multiple values, each having its own name. These are sometimes called traits --- 809,822 ---- can store multiple values, each having its own name. For example, a pair<int> object p stores two ∫s named ! left_ and ! right_. The . operator ! . operator extracts a named member from an object: ! p.left_. At compile time, a class can store multiple values, each having its own name. These are sometimes called traits *************** struct ExpressionTraits<BinaryNode< *** 848,863 **** ! :: operator ! The example also illustrates using the :: operator to extract a member of a traits class. The type ExpressionTraits<Left> contains an internal type definition of Type_t. Using the ! :: operator extracts it: ! ExpressionTraits<Left>::Type_t. Enumerations and other values can also be extracted. For example, ! Array<2, int, Brick>::dimensions yields the dimension of the array's domain. --- 848,863 ---- ! :: operator ! The example also illustrates using the :: operator to extract a member of a traits class. The type ExpressionTraits<Left> contains an internal type definition of Type_t. Using the ! :: operator extracts it: ! ExpressionTraits<Left>::Type_t. Enumerations and other values can also be extracted. For example, ! Array<2, int, Brick>::dimensions yields the dimension of the array's domain. *************** struct ExpressionTraits<BinaryNode< *** 869,877 **** control flow Control flow determines which code is used. At run time, ! control-flow statements such as if, ! while, and ! goto determine which statements to execute. Template programming uses two mechanisms: template class specializations and pattern matching. These are similar to control flow in functional programming languages. A control flow Control flow determines which code is used. At run time, ! control-flow statements such as if, ! while, and ! goto determine which statements to execute. Template programming uses two mechanisms: template class specializations and pattern matching. These are similar to control flow in functional programming languages. A Expression<int>. Control flow using template specializations and pattern ! matching is similar to switch statements. ! switch ! A switch statement has a condition and one or more pairs of case labels and associated code. The code associated with the the case label whose value matches the condition is executed. If no case label matches the --- 932,943 ---- Expression<int>. Control flow using template specializations and pattern ! matching is similar to switch statements. ! switch ! A switch statement has a condition and one or more pairs of case labels and associated code. The code associated with the the case label whose value matches the condition is executed. If no case label matches the *************** CreateLeaf<Expression<int&closeclo *** 949,959 **** the condition. The set of template parameters for the indicated template class, e.g., CreateLeaf, are analogous to the case labels, and each has an associated definition. In our ! example, the set of template parameters are <class ! T> and <Expression<class ! T&closeclose;. The best match, if any, indicates the matching code that will be used. In our example, ! the <class T> parameter serves as the default label since it matches any arguments. If no set of template parameters match (which is impossible for our example) or if more than one set are best matches, the code is --- 949,959 ---- the condition. The set of template parameters for the indicated template class, e.g., CreateLeaf, are analogous to the case labels, and each has an associated definition. In our ! example, the set of template parameters are <class ! T> and <Expression<class ! T&closeclose;. The best match, if any, indicates the matching code that will be used. In our example, ! the <class T> parameter serves as the default label since it matches any arguments. If no set of template parameters match (which is impossible for our example) or if more than one set are best matches, the code is *************** class F { *** 1012,1018 **** Both the templated class and the templated function take the same template arguments, but the class uses a static member function. Thus, the notation to invoke it is slightly more ! verbose: F<T>::f(t). --- 1012,1018 ---- Both the templated class and the templated function take the same template arguments, but the class uses a static member function. Thus, the notation to invoke it is slightly more ! verbose: F<T>::f(t). *************** class F { *** 1025,1031 **** The advantage of a function template is that it can be overloaded, particularly operator functions. For example, the ! + operator is overloaded to add two &array;s, which require template parameters to specify: template <int D1,class T1,class E1, --- 1025,1031 ---- The advantage of a function template is that it can be overloaded, particularly operator functions. For example, the ! + operator is overloaded to add two &array;s, which require template parameters to specify: template <int D1,class T1,class E1, *************** template <int D1,class T1,class E1, *** 1034,1041 **** operator+(const Array<D1,T1,E1> & l, const Array<D2,T2,E2> & r); Without using function templates, it would not be ! possible to write expressions such as a1 + ! a2. Member functions can also be templated. This permits, for example, overloading of assignment operators defined within templated classes. --- 1034,1041 ---- operator+(const Array<D1,T1,E1> & l, const Array<D2,T2,E2> & r); Without using function templates, it would not be ! possible to write expressions such as a1 + ! a2. Member functions can also be templated. This permits, for example, overloading of assignment operators defined within templated classes. Index: tutorial.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/tutorial.xml,v retrieving revision 1.9 diff -c -p -r1.9 tutorial.xml *** tutorial.xml 2002/01/30 23:09:06 1.9 --- tutorial.xml 2002/01/30 23:47:37 *************** *** 215,221 **** value is assigned the average of its corresponding value in b and the latter's neighbors. Values in the two-dimensional grids are accessed using two sets of brackets, e.g., ! a[i][j]. After assigning values to a, a second averaging reads values in a, writing values in b. --- 215,221 ---- value is assigned the average of its corresponding value in b and the latter's neighbors. Values in the two-dimensional grids are accessed using two sets of brackets, e.g., ! a[i][j]. After assigning values to a, a second averaging reads values in a, writing values in b. *************** *** 250,256 **** Initially, all grid values are zero except for the one nonzero value at the center of the second array. Array positions are indicated using two brackets, e.g., ! a[i][j]. A better implementation might initialize only the outermost values of the a array. --- 250,256 ---- Initially, all grid values are zero except for the one nonzero value at the center of the second array. Array positions are indicated using two brackets, e.g., ! a[i][j]. A better implementation might initialize only the outermost values of the a array. *************** *** 335,342 **** its value type, and how the values will be stored or computed. The &brick; &engine; type indicates values will be directly stored. It is responsible for allocating and deallocating ! storage so new and ! delete statements are not necessary. The vertDomain specifies the array index domain. --- 335,342 ---- its value type, and how the values will be stored or computed. The &brick; &engine; type indicates values will be directly stored. It is responsible for allocating and deallocating ! storage so new and ! delete statements are not necessary. The vertDomain specifies the array index domain. *************** *** 345,351 **** same scalar value. The second statement illustrates assigning one &array; value. Indices, separated by commas, are surrounded by parentheses rather than surrounded by ! square brackets ([]). &array; element access uses parentheses, rather than --- 345,351 ---- same scalar value. The second statement illustrates assigning one &array; value. Indices, separated by commas, are surrounded by parentheses rather than surrounded by ! square brackets ([]). &array; element access uses parentheses, rather than *************** *** 394,413 **** &array;s support both element-wise access and scalar assignment. Element-wise access uses parentheses, not square ! brackets. For example, b(n/2,n/2) ! specifies the central element. The scalar assignment b ! = 0.0 assigns the same 0.0 value to all array elements. This is possible because the array knows the extent of its domain. We illustrate these data-parallel statements in the next section. Any program using the &poomatoolkit; must initialize the &toolkit;'s data structures using ! Pooma::initialize(argc,argv). This extracts &pooma;-specific command-line options from the program's command-line arguments and initializes the interprocessor communication and other data structures. When finished, ! Pooma::finalize() ensures all computation and communication has finished and the data structures are destructed. --- 394,413 ---- &array;s support both element-wise access and scalar assignment. Element-wise access uses parentheses, not square ! brackets. For example, b(n/2,n/2) ! specifies the central element. The scalar assignment b ! = 0.0 assigns the same 0.0 value to all array elements. This is possible because the array knows the extent of its domain. We illustrate these data-parallel statements in the next section. Any program using the &poomatoolkit; must initialize the &toolkit;'s data structures using ! Pooma::initialize(argc,argv). This extracts &pooma;-specific command-line options from the program's command-line arguments and initializes the interprocessor communication and other data structures. When finished, ! Pooma::finalize() ensures all computation and communication has finished and the data structures are destructed. *************** *** 443,449 **** Data-parallel expressions replace nested loops and array ! element accesses. For example, a(I,J) represents the subset of the a array having a domain equal to the Cartesian product of I and J. Intervals can shifted by an additive --- 443,449 ---- Data-parallel expressions replace nested loops and array ! element accesses. For example, a(I,J) represents the subset of the a array having a domain equal to the Cartesian product of I and J. Intervals can shifted by an additive *************** *** 454,483 **** Data-parallel expressions use containers and domain objects to indicate a set of parallel expressions. For example, in the program ! listed above, a(I,J) specifies the subset of a array omitting the outermost elements. The array's vertDomain domain consists of the Cartesian product of {0, 1, 2, …, n-1} with itself, while I and J each specify {1, 2, ! …, n-2}. Thus, a(I,J) is the subset with a domain of the Cartesian product of {1, 2, …, n-2} with itself. It is called a view of an array. It is itself an &array;, with a domain and supporting element access, but its storage is the same as a's. Changing a value ! in a(I,J) also changes the same value in a. Changing a value in the latter also changes the former if the value is not one of a's outermost elements. The expression ! b(I+1,J+1) indicates the subset of b with a domain consisting of the Cartesian product of {2, 3, …, n-1}, i.e., the same domain as ! a(I,J) but shifted up one unit and to the right one unit. Only an &interval;'s value, not its name, is important so all uses of J in this program could be replaced by I without changing the semantics. ! The statement assigning to a(I,J) illustrates that &array;s may participate in expressions. Each addend is a view of an array, which is itself an array. The views' indices are zero-based so their sum can be formed by adding --- 454,483 ---- Data-parallel expressions use containers and domain objects to indicate a set of parallel expressions. For example, in the program ! listed above, a(I,J) specifies the subset of a array omitting the outermost elements. The array's vertDomain domain consists of the Cartesian product of {0, 1, 2, …, n-1} with itself, while I and J each specify {1, 2, ! …, n-2}. Thus, a(I,J) is the subset with a domain of the Cartesian product of {1, 2, …, n-2} with itself. It is called a view of an array. It is itself an &array;, with a domain and supporting element access, but its storage is the same as a's. Changing a value ! in a(I,J) also changes the same value in a. Changing a value in the latter also changes the former if the value is not one of a's outermost elements. The expression ! b(I+1,J+1) indicates the subset of b with a domain consisting of the Cartesian product of {2, 3, …, n-1}, i.e., the same domain as ! a(I,J) but shifted up one unit and to the right one unit. Only an &interval;'s value, not its name, is important so all uses of J in this program could be replaced by I without changing the semantics. ! The statement assigning to a(I,J) illustrates that &array;s may participate in expressions. Each addend is a view of an array, which is itself an array. The views' indices are zero-based so their sum can be formed by adding *************** *** 581,587 **** Applying the stencil's function call operator() yields the computed value. To compute multiple &array; values, apply a stencil to the array and a domain object: ! stencil(b, interiorDomain). This applies the stencil to each position in the domain. The user must ensure that applying the stencil does not access nonexistent &array; values. --- 581,587 ---- Applying the stencil's function call operator() yields the computed value. To compute multiple &array; values, apply a stencil to the array and a domain object: ! stencil(b, interiorDomain). This applies the stencil to each position in the domain. The user must ensure that applying the stencil does not access nonexistent &array; values. *************** *** 611,632 **** To create a stencil object, apply the &stencil; type to a function object class. For example, ! Stencil<DoofNinePt> stencil declares the stencil object. The function object class must define a function call operator() with a container parameter and index parameters. The number of index parameters, indicating the stencil's center, must equal the container's dimension. For example, DoofNinePt defines ! operator()(const C& c, int i, int j). We templated the container type C although this is not strictly necessary. The two index parameters i and j ensure the stencil works with two-dimensional containers. The ! lowerExtent function indicates how far to the left (or below) the stencil extends beyond its center. Its parameter indicates a particular dimension. Index parameters i and j are in dimension 0 ! and 1. upperExtent serves an analogous purpose. The &poomatoolkit; uses these functions when distributing computation among various processors, but it does not use these functions to ensure nonexistent &array; values are not --- 611,632 ---- To create a stencil object, apply the &stencil; type to a function object class. For example, ! Stencil<DoofNinePt> stencil declares the stencil object. The function object class must define a function call operator() with a container parameter and index parameters. The number of index parameters, indicating the stencil's center, must equal the container's dimension. For example, DoofNinePt defines ! operator()(const C& c, int i, int j). We templated the container type C although this is not strictly necessary. The two index parameters i and j ensure the stencil works with two-dimensional containers. The ! lowerExtent function indicates how far to the left (or below) the stencil extends beyond its center. Its parameter indicates a particular dimension. Index parameters i and j are in dimension 0 ! and 1. upperExtent serves an analogous purpose. The &poomatoolkit; uses these functions when distributing computation among various processors, but it does not use these functions to ensure nonexistent &array; values are not From oldham at codesourcery.com Thu Jan 31 21:23:24 2002 From: oldham at codesourcery.com (Jeffrey D . Oldham) Date: Thu, 31 Jan 2002 13:23:24 -0800 Subject: Manual Patch: Formatting Changes Message-ID: <20020131132324.A29384@vaio.codesourcery.com> 2002-Jan-31 Jeffrey D. Oldham This patch continues the formatting to prepare the manual for delivery. No substantive semantic changes were made. * Makefile: Generalize to support any top-level name. Fix mistakes in PostScript and PDF rules. * arrays.xml: Reformat and reword to avoid bad line breaks and incursions into the right margin. * data-parallel.xml: Reformat to avoid bad line breaks and incursions into the right margin. * html.dsl: New file controlling conversion of DocBook into HTML. * jadetex.cfg: New file controlling jadetex, which converts TeX to PostScript and PDF. The changes support better line breaking for URLs and pathnames. * manual.xml: Renamed pooma.xml. * pooma.xml: New file moved from manual.xml. * print.dsl: New file controlling conversion of DocBook into PostScript and PDF. * template.xml: Fix parameter type. * tutorial.xml: Reformat and reword to avoid bad line breaks and incursions into the right margin. Applied to mainline. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Makefile =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/Makefile,v retrieving revision 1.3 diff -c -p -r1.3 Makefile *** Makefile 2002/01/30 23:09:06 1.3 --- Makefile 2002/01/31 21:10:37 *************** HTMLDOCBOOKDSL= html.dsl # html/docbook *** 13,27 **** XML= dtds/decls/xml.dcl INDEXOPTIONS= -t 'Index' -i 'index' -g -p ! XMLSOURCES= manual.xml introduction.xml template.xml tutorial.xml \ concepts.xml arrays.xml data-parallel.xml glossary.xml \ bibliography.xml ## HERE How do I include dependences on programs? ! all: manual.ps manual.pdf manual.html ! manual.dvi manual.pdf manual.html: $(XMLSOURCES) figures figures: $(MAKE) -C figures --- 13,28 ---- XML= dtds/decls/xml.dcl INDEXOPTIONS= -t 'Index' -i 'index' -g -p ! MANUALNAME= pooma ! XMLSOURCES= $(MANUALNAME).xml introduction.xml template.xml tutorial.xml \ concepts.xml arrays.xml data-parallel.xml glossary.xml \ bibliography.xml ## HERE How do I include dependences on programs? ! all: $(MANUALNAME).ps $(MANUALNAME).pdf $(MANUALNAME).html ! $(MANUALNAME).dvi $(MANUALNAME).pdf $(MANUALNAME).html: $(XMLSOURCES) figures figures: $(MAKE) -C figures *************** genindex.sgm: *** 33,54 **** jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) $(XML) $< # This rule assumes index creation. ! %.dvi: %.xml genindex.sgm print.dsl jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) -V html-index $(XML) $< perl collateindex.pl $(INDEXOPTIONS) -o genindex.sgm HTML.index jade -D$(JADEDIR) -t tex -d $(PRINTDOCBOOKDSL) -V tex-backend -V use-eps $(XML) $< ! jadetex $*.tex ! jadetex $*.tex ! jadetex $*.tex # This rule assumes index creation. ! %.pdf: %.xml genindex.sgm print.dsl jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) -V html-index $(XML) $< perl collateindex.pl $(INDEXOPTIONS) -o genindex.sgm HTML.index jade -D$(JADEDIR) -t tex -d $(PRINTDOCBOOKDSL) $(XML) $< ! pdfjadetex $*.tex ! pdfjadetex $*.tex ! pdfjadetex $*.tex clean: ! rm -f *.dvi *.aux *.log *.toc *.bak *.blg *.bbl *.glo *.idx *.lof *.lot *.htm *.html *.mpx mpxerr.tex HTML.index manual.tex genindex.sgm pooma-html.manifest --- 34,58 ---- jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) $(XML) $< # This rule assumes index creation. ! $(MANUALNAME).dvi: $(XMLSOURCES) genindex.sgm print.dsl jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) -V html-index $(XML) $< perl collateindex.pl $(INDEXOPTIONS) -o genindex.sgm HTML.index jade -D$(JADEDIR) -t tex -d $(PRINTDOCBOOKDSL) -V tex-backend -V use-eps $(XML) $< ! jadetex $(MANUALNAME).tex ! jadetex $(MANUALNAME).tex ! jadetex $(MANUALNAME).tex + %.ps: %.dvi + dvips -t letter $< -o + # This rule assumes index creation. ! $(MANUALNAME).pdf: $(XMLSOURCES) genindex.sgm print.dsl jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) -V html-index $(XML) $< perl collateindex.pl $(INDEXOPTIONS) -o genindex.sgm HTML.index jade -D$(JADEDIR) -t tex -d $(PRINTDOCBOOKDSL) $(XML) $< ! pdfjadetex $(MANUALNAME).tex ! pdfjadetex $(MANUALNAME).tex ! pdfjadetex $(MANUALNAME).tex clean: ! rm -f *.dvi *.aux *.log *.toc *.bak *.blg *.bbl *.glo *.idx *.lof *.lot *.htm *.html *.mpx mpxerr.tex HTML.index $(MANUALNAME).tex genindex.sgm pooma-html.manifest Index: arrays.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/arrays.xml,v retrieving revision 1.7 diff -c -p -r1.7 arrays.xml *** arrays.xml 2002/01/30 23:51:45 1.7 --- arrays.xml 2002/01/31 21:10:38 *************** *** 156,162 **** interval [2,9]. Its indices are ordered pairs such as (0,2), (0,3), (1,2), (1,9), and (3,7). ! Many domains can be represented using domain triplets. A domain triplet [begin:end:stride] --- 156,163 ---- interval [2,9]. Its indices are ordered pairs such as (0,2), (0,3), (1,2), (1,9), and (3,7). ! Many domains can be represented using domain triplets. That ! is, a domain triplet [begin:end:stride] *************** Array<1,double,CompressibleBrick> *** 1420,1431 **** domains: // Create an Array and its domain. ! Array<2,float,Brick> a(Interval<1>(2,7), Interval<1>(-2,4)); // Create an Array without a domain and then specify // its domain. ! Array<2,float,Brick> b(); ! b.initialize(Interval<1>(2,7), Interval<1>(-2,4));. Invoking initialize on an &array; with an existing domain yields unspecified behavior. All &array; values may be lost and memory may be leaked. --- 1421,1433 ---- domains: // Create an Array and its domain. ! Array<2,float,Brick> a(Interval<1>(2,7), ! Interval<1>(-2,4)); // Create an Array without a domain and then specify // its domain. ! Array<2,float,Brick> b(); ! b.initialize(Interval<1>(2,7), Interval<1>(-2,4));. Invoking initialize on an &array; with an existing domain yields unspecified behavior. All &array; values may be lost and memory may be leaked. *************** object or integer. *** 1570,1576 **** following code prints the initial value at index (2,-2) and increments its value, printing the new value: ! Array<2,int,Brick> a(Interval<1>(0,3), Interval<1>(-2,4), ModelElement<int>(4)); std::cout &openopen; a(2,-2) &openopen; std::endl; ++a(2,-2); --- 1572,1579 ---- following code prints the initial value at index (2,-2) and increments its value, printing the new value: ! Array<2,int,Brick> a(Interval<1>(0,3), ! Interval<1>(-2,4), ModelElement<int>(4)); std::cout &openopen; a(2,-2) &openopen; std::endl; ++a(2,-2); Index: data-parallel.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/data-parallel.xml,v retrieving revision 1.6 diff -c -p -r1.6 data-parallel.xml *** data-parallel.xml 2002/01/30 23:51:45 1.6 --- data-parallel.xml 2002/01/31 21:10:40 *************** Expression<UnaryNode<OpMinus,Ar&cl *** 977,985 **** The binary nodes continue the construction process yielding a parse tree object for the entire right-hand side and having type ! Expression<BinaryNode<OpAdd, ! UnaryNode<OpMinus, Ar>, ! BinaryNode<OpMultiply<Scalar<int>,Ar&closecloseclose; Evaluating the left-hand side yields an object representing A. --- 977,986 ---- The binary nodes continue the construction process yielding a parse tree object for the entire right-hand side and having type ! Expression< ! BinaryNode<OpAdd, ! UnaryNode<OpMinus, Ar>, ! BinaryNode<OpMultiply<Scalar<int>,Ar&closecloseclose; Evaluating the left-hand side yields an object representing A. *************** forEach(const Expression& e, const L *** 1218,1224 **** nodes, it combines the results using the CombineTag operator c. It inlines into a call to ! ForEach<Expression, LeafTag, CombineTag>::apply(e, f, c). The apply function continues the traversal through the tree. For our example, LeafTag equals EvalLeaf<1>, and --- 1219,1225 ---- nodes, it combines the results using the CombineTag operator c. It inlines into a call to ! ForEach<Expression, LeafTag, CombineTag>::apply(e, f, c) The apply function continues the traversal through the tree. For our example, LeafTag equals EvalLeaf<1>, and *************** ForEach<Expression, LeafTag, CombineT *** 1236,1246 **** template<class Op, class A, class FTag, class CTag> struct ForEach<UnaryNode<Op, A>, FTag, CTag> { ! typedef typename ForEach<A, FTag, CTag>::Type_t TypeA_t; ! typedef typename Combine1<TypeA_t, Op, CTag>::Type_t Type_t; inline static ! Type_t apply(const UnaryNode<Op, A> &expr, const FTag &f, ! const CTag &c) { return Combine1<TypeA_t, Op, CTag>:: combine(ForEach<A, FTag, CTag>:: --- 1237,1248 ---- template<class Op, class A, class FTag, class CTag> struct ForEach<UnaryNode<Op, A>, FTag, CTag> { ! typedef typename ForEach<A,FTag,CTag>::Type_t TypeA_t; ! typedef typename ! Combine1<TypeA_t,Op,CTag>::Type_t Type_t; inline static ! Type_t apply(const UnaryNode<Op,A>&expr,const FTag&f, ! const CTag& c) { return Combine1<TypeA_t, Op, CTag>:: combine(ForEach<A, FTag, CTag>:: *************** struct ForEach<UnaryNode<Op, A> *** 1264,1272 **** template<class Expr, class FTag, class CTag> struct ForEach { ! typedef typename LeafFunctor<Expr, FTag>::Type_t Type_t; inline static ! Type_t apply(const Expr &expr, const FTag &f, const CTag &) { return LeafFunctor<Expr, FTag>::apply(expr, f); } --- 1266,1275 ---- template<class Expr, class FTag, class CTag> struct ForEach { ! typedef typename ! LeafFunctor<Expr, FTag>::Type_t Type_t; inline static ! Type_t apply(const Expr&expr,const FTag&f,const CTag&) { return LeafFunctor<Expr, FTag>::apply(expr, f); } *************** struct ForEach *** 1286,1292 **** int end = A.domain[0].first() + A.domain[0].length(); for (int i = A.domain[0].first(); i < end; ++i) ! A.engine(i) += -A.engine.read(i) + 2 * B.engine.read(i); The loop iterates through A's domain, using &array;'s engines to obtain values and assigning values. Notice there is no use of the run-time parse tree so the --- 1289,1295 ---- int end = A.domain[0].first() + A.domain[0].length(); for (int i = A.domain[0].first(); i < end; ++i) ! A.engine(i) += -A.engine.read(i)+2*B.engine.read(i); The loop iterates through A's domain, using &array;'s engines to obtain values and assigning values. Notice there is no use of the run-time parse tree so the Index: html.dsl =================================================================== RCS file: html.dsl diff -N html.dsl *** /dev/null Fri Mar 23 21:37:44 2001 --- html.dsl Thu Jan 31 14:10:40 2002 *************** *** 0 **** --- 1,82 ---- + + + + ]> + + + + + + + + ;; $Id: plain.dsl,v 1.2 2000/09/28 12:50:20 ndw Exp $ + ;; + ;; This file is part of the Modular DocBook Stylesheet distribution. + ;; See ../README or http://www.berkshire.net/~norm/dsssl/ + ;; + ;; Example of a customization layer on top of the modular docbook style + ;; sheet. Definitions inserted in this file take precedence over + ;; definitions in the 'use'd stylesheet(s). + + ;; Use the extension .html for output files. + (define %html-ext% ".html") + + ;; The main file is named index. + (define %root-filename% "pooma") + + ;; Number chapters and sections. + (define %chapter-autolabel% #t) + (define %section-autolabel% #t) + + ;; Don't place the first section of each chapter in the same chunk as + ;; the chapter head. + (define (chunk-skip-first-element-list) (list)) + + ;; Write a manifest of created files to pooma-html.manifest. + (define html-manifest #t) + (define html-manifest-filename "pooma-html.manifest") + + ;; Use element ids to generate chunk filenames + (define %use-id-as-filename% #t) + + ;; Support block elements inside para. + (define %fix-para-wrappers% #t) + + ;; Avoid a hack to force 'correct' vertical spacing. + (define %spacing-para% #f) + + ;; Prevent verbatim text from being displayed at a different size. + (define %verbatim-size-factor% 1.1) + + ;; Change the default presentation for various tags. + ; Use mono-space font for computer items. + (element command ($mono-seq$)) + (element envar ($mono-seq$)) + (element errorname ($mono-seq$)) + (element errortype ($mono-seq$)) + (element keywordname ($mono-seq$)) ; new tag aded by Oldham + (element methodname ($mono-seq$)) ; new tag aded by Oldham + (element operator ($mono-seq$)) ; new tag aded by Oldham + (element statement ($mono-seq$)) ; new tag aded by Oldham + (element symbol ($mono-seq$)) + (element token ($mono-seq$)) + (element type ($mono-seq$)) + + ; Center figures. + (element mediaobject + (make element gi: "DIV" + attributes: (list (list "CLASS" (gi)) (list "ALIGN" "center")) + (make element gi: "P" + ($mediaobject$)))) + + + + + + + Index: jadetex.cfg =================================================================== RCS file: jadetex.cfg diff -N jadetex.cfg *** /dev/null Fri Mar 23 21:37:44 2001 --- jadetex.cfg Thu Jan 31 14:10:41 2002 *************** *** 0 **** --- 1,6 ---- + %% Support better hyphenation for URLs and paths. + %% Idea taken from http://cyberelk.net/tim/docbook/selfdocbook/jadetex.cfg.htm + \usepackage{url} + \tolerance=2000 + \hypersetup{colorlinks=false} + \hyphenation{block-And-Eval-u-ate} Index: manual.xml =================================================================== RCS file: manual.xml diff -N manual.xml *** /tmp/cvsWATf4H Thu Jan 31 14:10:46 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,4220 **** - - - - - - - - - - - - - - - - - - - - - - - - - - C"> - - - C++"> - - - Cheetah" > - - - - - - - - - - Doof2d" > - - Fortran"> - - - - - Make"> - - MM"> - - MPI"> - - - - PDToolkit"> - - PETE"> - - POOMA"> - - POOMA &toolkitcap;"> - - Purify"> - - Smarts"> - - - STL"> - - Tau"> - - - - - - - - - Array"> - - Benchmark"> - - bool"> - - Brick"> - - char"> - - complex"> - - CompressibleBrick"> - - DistributedTag"> - - Domain"> - - - - double"> - - Dynamic"> - - DynamicArray"> - - Engine"> - - false"> - - - Field"> - - float"> - - Grid"> - - Grid<1>"> - - IndirectionList"> - - IndirectionList<int>"> - - Inform"> - - int"> - - Interval"> - - Interval<1>"> - - Layout"> - - LeafFunctor"> - - Loc"> - - Loc<1>"> - - TinyMatrix"> - - MultiPatch"> - - Options"> - - Range"> - - Range<1>"> - - Remote"> - - ReplicatedTag"> - - Stencil"> - - Tensor"> - - true"> - - - Vector"> - - - - - - - - - - - d"> - - - - g++"> - - KCC"> - - Linux"> - - - - - http://pooma.codesourcery.com/pooma/download'> - - - http://www.codesourcery.com/pooma/pooma/'> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ]> - - - - &pooma; - A &cc; &toolkitcap; for High-Performance Parallel Scientific Computing - JeffreyD.Oldham - - CodeSourcery, LLC - - - 2002CodeSourcery, LLC () - Los Alamos National Laboratory - - - All rights reserved. This document may not be redistributed in any form without the express permission of the author. - - - - 1.00 - 2002 Jan 23 - jdo - First publication. - - - - - - - - - Preface - - FINISH: Describe the target audience for &pooma; programs and - for this manual: &cc; programmers writing scientific code, possibly - parallel execution. - - Assume familiarity with &cc; template programming and the - standard template library. FIXME: Remove this index - entry.Oldham, - Jeffrey D. - -

- Notation - - UNFINISHED -

- - -

- How to Read This &bookcap; - - FINISH: Write this section in a style similar to Lamport's - LaTeX section 1.2. FINISH: Fix the book title and the section - number. -

- - -

- Obtaining &pooma; and Sample Programs - - Available for free from what WWW site? Include what portions - of LICENSE? Be sure to - include CVS instructions as well. - - Which additional packages are necessary and when? - -

- - -

- Using and Modifying &pooma; - - &pooma; is available under open source license. It can be - used and modified by anyone, anywhere. Can it be sold? Include - LICENSE. - - QUESTION: How do developers contribute code? - -

- - -

- Acknowledgements - ]]> - - - Acknowledgements - ]]> - - This &book; would not have been completed without the help - and encouragement of a lot of people and organizations. Los Alamos - National Laboratory funded the writing of this manual and the - development of the &poomatoolkit;. John Reynders conceived, - advocated, and headed &pooma; development in its early days, and - Scott Haney continued the leadership. Susan Atlas, Subhankar - Banerjee, Timothy Cleland, Julian Cummings, James Crotinger, David - Forslund, Salman Habib, Scott Haney, Paul Hinker, William Humphrey, - Steve Karmesin, Graham Mark, Jeffrey D. Oldham, Ji Qiang, John - Reynders, Robert Ryne, Stephen Smith, M. Srikant, Marydell - Tholburn, and Timothy Williams all helped develop &pooma;. Rod - Oldehoeft and Jeff Brown of Los Alamos National Laboratory - supported CodeSourcery's and Proximation's work, including the - development of this manual. John Hall, Don Marshall, Jean - Marshall, and the rest of the BLANCA team at Los Alamos worked - closely with the developers and provided valuable suggestions for - improvements. - - I am grateful to James Crotinger, Mark Mitchell, and Stephen - Smith who answered my many questions during the writing of this - &book;. - - - - Jeffrey D. Oldham, 2002 January - - - - - ]]> - - - - - ]]> - - - - Programming with &pooma; - - - ]]> - - &introductory-chapter; - - &template-chapter; - - &tutorial-chapter; - - &concepts-chapter; - - &arrays-chapter; - - - - Engines - - Each container has one or more &engine;s to store or compute - its values. As we mentioned in , a container's role is - high-level, supporting access to groups of values, and an engine's - role is low-level, storing or computing values and supporting - access to individual values. This separation permits optimizing - space and computation requirements. - - We begin this chapter by introducing the concept of an engine - and how it is used. Then, we describe the various &engine;s that - &pooma; provides, separating them into engines that store values - and engines that compute values. - - - - -

- The Concept - - An engine performs the low-level value storage, computation, - and element-wise access for a container. An engine has a domain - and accessor functions returning individual elements. The &pooma; - &engine; class and its specializations implement the engine - concept. Given an index within the domain, an &engine;'s - operator() function returns the - associated value, which can be used or changed. Its - read member function returns the same - value but permitting only use, not modification. The acceptable - indices are determined by each &engine;. Most accept indices - specified using ∫ and Loc<&dim;> - parameters, but an &engine; might accept string or floating-point - parameters. An &engine;'s layout specifies maps its domain - indices to the processors and memory used to store and compute the - associated values. - - Since an engine's main role is to return the individual - values associated with specific domain indices, any implementation - performing this task is an engine. &pooma; &engine;s fall into - three categories: - - - &engine;s that store values. - - - &engine;s that compute their values using other &engine;s' - values. - - - &engine;s that support distributed computation. - - - For example, the &brick; &engine; explicitly stores all its - values, while the &compressiblebrick; engine adds the feature of - reducing its storage requirements if all these values are - identical. A UserFunction &engine; yields values by - applying a function - object to each value returned by another &engine;. A - CompFwd &engine; projects components from another - &engine;. For example, CompFwd will use the second - components of each &vector; in an &array; to form its own &array;. - Since each container has at least one &engine;, we can also - describe the latter category as containers that compute their - values using other containers' values. A &multipatch; &engine; - distributes its domain among various processors and memory spaces, - each responsible for computing values associated with a portion, - or patch, of the domain. The &remote; &engine; also supports - distributed computation. - - Just as multiple containers can use the same engine, - multiple &engine;s can use the same underlying data. As we - mentioned in , &engine;s - have reference - semantics. A copy of an &engine; has a - reference-counted pointer to the &engine;'s data (if any exists). - Thus, copying an &engine; or a container requires little execution - time. If an &engine; has the same data as another &engine; but it - needs its own data to modify, the - makeOwnCopy member function creates such - a copy. - - &engine;s are rarely explicitly declared. Instead a - container is declared using an &engine; tag, and the container - creates the specified &engine; to deal with its values. For - example, a &brick; &engine; is explicitly declared as - Engine<&dim;,T,Brick>, but they are more - frequently created by containers, e.g., - Array<&dim;,T,Brick>. An &engine;'s first two - template parameters specify the domain's dimensionality and the - value type, as described in . Unlike container - declarations, the third template parameter, the &engine; tag, - specifies which &engine; specialization to use. For example, the - &brick; &engine; tag indicates a &brick; &engine; should be used. - Some &engine;s, such as CompFwd, are rarely declared - even using &engine; tags. Instead the &array;'s - comp and - readComp member functions return views of - containers using CompFwd &engine;s. -

- - -

- Types of &engine;s - - In this section, we describe the different types of - &engine;s and illustrate their creation, when appropriate. First, - we describe &engine;s that explicitly store values and then - &engine;s that compute values. See . - -

- Types of &engine;s - - - - - &engine; tag - description - - - - - &engine;s That Store - - - &brick; - explicitly stores all values; similar to &c; arrays. - - - &compressiblebrick; - stores all values, reducing storage requirements when - all values are identical. - - - &dynamic; - is a one-dimensional &brick; with dynamically - resizable domain. This should be used with &dynamicarray;, - not &array;. - - - &engine;s That Compute - - - CompFwd - extracts specified components of an engine's vectors, - tensors, arrays, etc.; usually created using the - comp container function. - - - ConstantFunction - makes a scalar value behave like a container. - - - IndexFunction<FunctionObject> - makes the FunctionObject's function of - indices behave like a container. - - - ExpressionTag<Expr> - evaluates an expression tree; usually created by - data-parallel expressions. - - - Stencil<Function, Expression> - applies a stencil computation (Function) - to its input (Expression) which is usually a - container; usually created by applying a Stencil - object to a container. A stencil computation can use - multiple neighboring input values. - - - UserFunctionEngine<Function, - Expression> - applies the given function (or function - object) to its input (Expression) - which is usually a container; usually created by applying a - UserFunction object to a container. The - function implements a one-to-one mapping from its input to - values. - - - &engine;s for Distributed Computation - - - MultiPatch<LayoutTag,EngineTag> - runs a separate EngineTag &engine; on - each context (patch) specified by the given layout. This is - the usual &engine; for distributed computation. - - - Remote<EngineTag> - runs the &engine; specified by EngineTag - on a specified context. - - - Remote<Dynamic> - runs a Dynamic one-dimensional, resizable - &engine; on a specified context. This is a specialization of - Remote. - - - -

- - - &brick; - &engine;s explicitly store values just like &c; - arrays. &compressiblebrick; &engine;s optimize their storage - requirements when all values are identical. Many &array;s use one - of these two &engine;s. &brick;s are the default &engine;s for - &array; and &field; containers because they explicitly store each - value. This explicit storage can require a large amount of space, - particularly if all these values are the same. If all a - compressible brick &engine;'s values are identical, the &engine; - stores that one value rather than many, many copies of the same - value. These engines can both save time as well as space. - Initializing a compressible engine requires setting only one - value, not every value. Using less storage space may also permit - more useful values to be stored in cache, improving cache - performance. Reading a value in a compressed &engine; using the - read member function is as fast as - reading a value in a &brick; &engine;, but writing a value always - requires executing an additional if - conditional. Thus, if an &engine; infrequently has multiple - different values during its life time, a &compressiblebrick; - &engine; may be faster than a &brick; &engine;. If an &engine; is - created and its values are mostly read, not written, a - &compressiblebrick; &engine; may also be faster. Otherwise, a - &brick; &engine; may be preferable. Timing the same program using - the two different &engine; types will reveal which is faster for a - particular situation. In distributed computing, many &engine;s - may have few nonzero values so &compressiblebrick; &engine;s may - be preferable. For distributed computing, a container's domain is - partitioned into regions each computed by a separate processor and - &engine;. If the computation is concentrated in sections of the - domain, many &engine;s may have few, if any, nonzero values. - Thus, &compressiblebrick; &engine;s may be preferable for - distributed computing. - - Both &brick; and &compressiblebrick; &engine;s have - read and - operator() member functions taking ∫ - and &loc; parameters. The parameters should match the &array;'s - dimensionality. For example, if &array; a has - dimensionality 3, a.read(int, int, int) - and a(int, int, int) should be used. The - former returns a value that cannot be modified, while the latter - can be changed. Using the read member - function can lead to faster code. Alternatively, an index can be - specified using a &loc;. For example, - a.read(Loc<3>(1,-2,5)) and - a(Loc<3>(1,-2,5)) are equivalent to - a.read(1,-2,5)) and - a(1,-2,5). - - The &dynamic; &engine; supports changing domain sizes while - a program is executing. It is basically a one-dimensional - &brick;, explicitly storing values, but permitting the number and - order of stored values to change. Thus, it supports the same - interface as &brick; except that all member functions are - restricted to their one-dimensional versions. For example, - read and - operator() take Loc<1> - or one ∫ parameter. In addition, the one-dimensional domain - can be dynamically resized using create - and destroy. - - - - - - Types of &engine;s: - Brick - explicitly store values - CompressibleBrick - explicitly store values but store only one if all the same - ConstantFunction - convert scalar into an array - DynamicEngine - contiguous, local, resizable, 1D block - ExpressionEngine - evaluate PETE expression - CompFwd - array formed by extracted components from array - ForwardEngine - tut-02.html: use .comp() or .readComp() - IndexFunctionEngine - convert function of indices into an array - IndirectionEngine - incomplete - MultiPatch - ?How do I describe this? - RemoteDynamic - run a Dynamic engine on a specified context - Remote - permit computations on specified context - should discuss with MultiPatch - Stencil - apply a stencil to an array, returning a new Array with the results - UserFunction - Array = apply function to an Array - - - How do I organize these engines into understandable - categories? - - storage - Brick - CompressibleBrick - Dynamic - resizable 1D block - RemoteDynamic - MultiPatch - ?WHAT? - Remote - - computation - CompFwd: project(array)->array - .comp() and .readComp() - view, not a copy - ConstantFunction: scalar(array)->array - explicitly use - IndexFunctionEngine: function(indices)->array - explicitly use - ExpressionEngine: expression(array)->array - created by data-parallel expression - Stencil: stencil(array)->array - implicitly used - explicitly use Stencil<...> type - UserFunction: function(array)->array - explicitly use - - - - Element_t read(Loc<&dim;>) - ElementRef_t operator()(Loc<&dim;>) - Element_t read(int+) - ElementRef_t operator()(int+) - - - Explain the concept of an engine. How does an engine - interact with a container or an &array;? Explain the different - types of engines likely to be used by &pooma; programmers and how - to declare containers using them. Should I list the other engines - that are automatically created? - ]]> - -

- - - - &data-parallel-chapter; - - - - Container Views - - - container - view - - - view of a container - container, view. - - - A view of a - container is a container accessing a subset - of &container;'s domain and values. The subset can include all of - the container's domain. A view is so named because - it is a different way to access, or view, another container's - values. Both the container and its view share the same underlying - engine so changing values in one also changes them in the - other. - - A view is created by following a container's name by - parentheses containing a domain. For example, consider this code - extracted from in . - - Interval<1> N(0, n-1); - Interval<2> vertDomain(N, N); - Interval<1> I(1,n-2); - Interval<1> J(1,n-2); - Array<2, double, Brick> a(vertDomain); - Array<2, double, Brick> b(vertDomain); - a(I,J) = (1.0/9.0) * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - b(I ,J+1) + b(I ,J ) + b(I ,J-1) + - b(I-1,J+1) + b(I-1,J ) + b(I-1,J-1)); - The last statement creates ten views. For example, - - a(I,J) creates a view of - a using the smaller domain specified by - I and J. This omits the - outermost rows of columns of a. The views - of b illustrate the use of views in - data-parallel statements. b(I-1,J-1) has a - subset shifted up one row and left one column compared with - b(I,J). - ]]> - Be sure to list the various arithmetic operations on domains - that can be used. This was deferred from the &array; and domain - chapter. Explain &array;'s comp function. - - - ]]> - - - - - Writing Sequential Programs - - FIXME: Explain the chapter's purpose. - - FIXME: Explain the format of each section. - - FIXME: Explain the order of the sections. - - Proposed order. Basically follow the order in the proposed - reference section. - - starting, stopping - &array; - &dynamicarray; - &field; - &vector; - &matrix; - &tensor; - &engine; - domain - correctness, e.g., PAssert - &pooma; command-line options - - Include views of containers in the appropriate sections. - - &c;: A Reference Manual uses this - structure for &c; libraries: - - - function declarations, separated by rules from rest of text - - - text explanation - - - table of structure members if appropriate - - - example - - - - - STL Tutorial and Reference Guide, second - edition, uses this structure for STL functions: - - - text description with declaration mixed in - - - example program mixed into text. It is an entire program, - not a program fragment. - - - - - A tutorial chapter for containers has - - - explanation of template types - - - bulleted list of container types - - - example constructors - - - example programs - - - member and related functions with example programs - - - list of accessors and relation functions - - - - - The reference chapter for containers has - - - a section listing common members and types for all containers - - - a section listing common member functions for all containers - - - requirements for various container specialties - - - The section describing vectors contains - - - files (header files) - - - class declaration - - - description - - - type definitions - - - constructors, destructors, and related functions - - - comparison operators - - - element access member functions - - - insert and erase member functions - - - notes - - - - - Josuttis's The &cc; Standard Library: A Tutorial - and Reference uses this structure for its STL container - chapter: - - - short introduction - - - common container abilities - - - common container operations (with table) - - - vector abilities - - - vector operations: - - - create, copy, and destroy operations (mostly table) - - - non-modifying operations (mostly table) - - - assignments (mostly table) - - - element access (mostly table) - - - iterator functions (mostly table) - - - inserting and removing elements (mostly table) - - - - - - using vectors as ordinary arrays - - - exception handling - - - example program - - - - -

- Beginning and Ending &pooma; Programs - - Every &pooma; program must begin with a call to - initialize and end with a call to - finalize. These functions respectively - prepare and shut down &pooma;'s run-time structures. - - Files - - - #include "Pooma/Pooma.h" // or "Pooma/Arrays.h" or "Pooma/Fields.h" or ... - - - Declarations - - - - bool Pooma::initialize - - int &argc, - char ** &argv, - bool initRTS = true, - bool getCLArgsArch = true, - bool initArch = true - - - - - bool Pooma::initialize - - Pooma::Options &opts, - bool initRTS = true, - bool initArch = true - - - - - bool Pooma::finalize - - - - - bool Pooma::finalize - - bool quitRTS, - bool quitArch - - - - - Description - - Before its use, the &poomatoolkit; must be initialized by a - call to initialize. This usually occurs in - the main function. The first form removes - and processes any &pooma;-specific arguments from the - command-line arguments argv and - argc. describes these options. - The third, fourth, and fifth arguments all have a default value - of &true;. If initRTS is - &true;, the run-time system is initialized. E.g., the contexts - are prepared for use. If getCLArgsArch is &true, - architecture-specific command-line arguments are removed from - argv and argc. - Architecture-specific initialization occurs if getCLArgsArch is &true;. An architecture is specified - by a hardware interface, e.g., processor type, but frequently is - also associated with an operating system or compiler. For - example, Metrowerks for the Macintosh has an - architecture-specific initialization. The function always - returns &true;. - - initialize's alternative form - assumes the &pooma;-specific and architecture-specific - command-line arguments have already been removed from - argv and argc and stored in - opts. Its other two - parameters have the same meaning, and the two functions' - semantics are otherwise the same. - - After its use, the &poomatoolkit; should be shut down using - a call to finalize. This usually occurs in - the main function. The former, and more - frequently used, form first prints any statistics and turns off - all default &pooma; streams. Then it shuts down the run-time - system if it was previously initialized and then shuts down - architecture-specific objects if they were previously - initialized. The latter form gives provides explicit control - whether the run-time system (quitRTS) and architecture-specific - objects (quitArch) are - shut down. Both functions always returns &true;. - - Including almost any &pooma; header file, rather than just - Pooma/Pooma.h suffices - since most other &pooma; header files include it. - - Example Program - - Since every &pooma; program must call - initialize and - finalize, the simplest &pooma; program also - must call them. This program also illustrates their usual - use. - - &initialize-finalize; - -

- - -

- Global Variables - - &pooma; makes a few global variables available after - initialization. - - - &pooma; Global Variables - - - - - variable - description - - - - - &inform; pinfo - output stream used to print informative messages to the - user while the program executes. The stream accepts a - superset of standard output operations. - - - &inform; pwarn - FIXME: output stream used to print informative messages to the - user while the program executes. The stream accepts a - superset of standard output operations. - - - -

- -

- &pooma; Command-line Options - - Every &pooma; program accepts a set of &pooma;-specific - command-line options to set values at run-time. - - QUESTION: Should I defer documenting &options; to the - reference manual, instead just listing commonly used options in - the previous section? - - UNFINISHED - -

- Options Summary - - - - &dashdash;pooma-info - - enable use of the pinfo, used to - print informative messages to the user while the program - executes. - - - - - - FIXME: Be sure to list default values. - - - -

- -

- TMP: Place these somewhere. - - &pooma; can reorder computations to permit more efficient - computation. When running a sequential program, reordering may - permit omission of unneeded computations. For example, if only - values from a particular field are printed, only computations - involving the field and containers dependent on it need to occur. - When running a distributed program, reordering may permit - computation and communication among processors to overlap. - &pooma; automatically tracks dependences between data-parallel - expressions, ensuring correct ordering. It does not track - statements accessing particular &array; and &field; values so the - programmer must precede these statements with calls to - Pooma::blockAndEvaluate(). Each call forces - the executable to wait until all computation has completed. Thus, - the desired values are known to be available. In practice, some - calls to Pooma::blockAndEvaluate may not be - necessary, but omitting them requires knowledge of &pooma;'s - dependence computations, so the &author; recommends calling - Pooma::blockAndEvaluate before each access to - a particular value in an &array; or &field;. Omitting a necessary - call may lead to a race condition. - for - instructions how to diagnose and eliminate these race - conditions. - ]]> - - - Where talk about various &pooma; streams? - - UNFINISHED - -

- - -

- &benchmark; Programs - - Define a &benchmark; program vs. an example or an - executable. Provide a short overview of how to run these - programs. Provide an overview of how to write these programs. - See src/Utilities/Benchmark.h. -

- - -

- Miscellaneous - - Section 3, "Domains and Views," of - papers/iscope98.pdf describes four types of - domains. - -

- Data-Parallel Statements - - Can we use "An Overview of &pete;" from - papers/PETE_DDJ/ddj_article.html or is this - too low-level? - - Section 3.2.1 of papers/pooma.ps - gives a simple example of data-parallel expression. It also has a - paragraph introducing data-parallel operations and selecting - subsets of domains. Section 3.4 describes the Chained - Expression Object (CEO), apparently a precursor - of &pete;. Regardless, it provides some motivation and - introductory material. - - From Section 4 of - papers/SiamOO98_paper.ps: - - This version of &pete; reduces compile time of user codes - and utilizes compile-time knowledge of expression &domain;s for - better optimization. For example, more efficient loops for - evaluating an expression can be generated if &pete; knows that the - &domain; has unit stride in memory. - - Section 4, "Expressions and Evaluators", of - papers/iscope98.pdf has a good explanation of - &pooma; II's expression trees and expression engines. - - COMMENT: background.html has some related - &pete; material. -

- - -

- Containers - -

- &array; - -

- Section 4 "Future Improvements in - &pooma; II" of - papers/SiamOO98_paper.ps - - An &array; can be thought of as a map from one &domain; to - another.… &array;s depend only on the interface of - &domain;s. Thus, a subset of view of an &array; can be - manipulated in all the same ways as the original &array;. - &array;s can perform indirect addressing because the output - &domain; one one &array; can be used as the input &domain; of - another &array;. &array;s also provide individual element - access. -

- - - - (unformatted) From - papers/GenericProgramming_CSE/dubois.html: - The &pooma; &array; concept provides an example of how these - generic-programming features can lead to flexible and efficient - code. An Array maps a fairly arbitrary input domain to an - arbitrary range of outputs. When used by itself, an &array; - object A refers to all of the values in its - domain. Element-wise mathematical operations or functions can be - applied to an array using straightforward notation, like A + B - or sin(A). Expressions involving Array objects are themselves - Arrays. The operation A(d), where d is a domain object that - describes a subset of A's domain, creates a view of A that - refers to that subset of points. Like an array expression, a - view is also an Array. If d represents a single point in the - domain, this indexing operation returns a single value from the - range. Equivalently, one can index an N-dimensional Array by - specifying N indices, which collectively specify a single point - in the input domain: A(i1, i2, ..., iN). - - The &pooma; multidimensional Array concept is similar to - the &fortran; 90 array facility, but extends it in several - ways. Both &pooma; and &fortran; arrays can have up to seven - dimensions, and can serve as containers for arbitrary - types. Both support the notion of views of a portion of the - array, known as array sections in F90. The &pooma; Array concept - supports more complex domains, including bounded, continuous - (floating-point) domains. Furthermore, Array indexing in &pooma; - is polymorphic; that is, the indexing operation X(i1,i2) can - perform the mapping from domain to range in a variety of ways, - depending on the particular type of the Array being - indexed. - - &fortran; arrays are dense and the elements are arranged - according to column-major conventions. Therefore, X(i1,i2) - refers to element number i1-1+(i2-1)*numberRowsInA. However, as - Fig. 1 shows, &fortran;-style "Brick" storage is not the only - storage format of interest to scientific programmers. For - compatibility with C conventions, one might want to use an array - featuring dense, row-major storage (a C-style Brick). To save - memory, it might be advantageous to use an array that only - stores a single value if all its element values are the - same. Other sparse storage schemes that only store certain - values may also be desirable. To exploit parallelism, it is - convenient for an array's storage to be broken up into patches, - which can be processed independently by different CPUs. Finally, - one can imagine an array with no data at all. For example, the - values can be computed from an expression involving other - arrays, or analytically from the indices. - - - The &pooma; &array; Class Template - - Next we describe &pooma;'s model of the Array concept, the - Array class template. The three most important requirements from - the point of view of overall design are: (1) arbitrary domain, - (2) arbitrary range, and (3) polymorphic indexing. These express - themselves in the template parameters for the &pooma; Array - class. The template - - template <int Dim, class T = double, class EngineTag = Brick> - class Array; - - is a specification for creating a set of classes all named - Array. The template parameters Dim, T, and EngineTag determine - the precise type of the Array. Dim represents the dimension of - the array's domain. T gives the type of array elements, thereby - defining the output range of the array. EngineTag specifies the - the manner of indexing and types of the indices. - - End From - papers/GenericProgramming_CSE/dubois.html: - - Section 2, "Arrays and Engines," of - papers/iscope98.pdf describes both &array;s - and &engine;s. This may or may not duplicate the material in - papers/GenericProgramming_CSE/dubois.html. - -

- Views of &array;s - - Section 3, "Domains and Views," of - papers/iscope98.pdf motivates the need for - views: -

- One of the primary uses of domains is to specify - subsections of &array; objects. Subarrays are a common - feature of array classes; however, it is often difficult to - make such subarrays behave like first-class objects. The - &pooma; II engine concept provides a clean solution to - this problem: subsetting an &array; with a domain object - creates a new &array; that has a view engine. -

- -

- &field; - - QUESTION: Do we include boundary conditions here? - - FINISH: Do we have an example that shows something not possible - with &array;? - - Describe and illustrate multi-material and - multivalue? - - ADD: description of meshes and guard layers. - -

- -

- Engines - - (unformatted) From - papers/GenericProgramming_CSE/dubois.html: - - The Engine Concept - - To implement polymorphic indexing, the &array; class defers - data storage and data lookup to an &engine; object. The - requirements that the &array; template places on its &engine; - provide the definition for the &engine; concept. We'll describe - these by examining a simplified version of the &array; template, - shown in Fig. 2. - - First, the &array; class determines and exports (makes - Engine_t part of &array;'s public interface) the type of the engine - class that it will use: - - typedef Engine<Dim, T, EngineTag> Engine_t; - - This statement declares Engine_t to be an alias for the type - Engine<Dim,T,EngineTag>. This is the first requirement - placed on engine classes: they must be specializations of a - general Engine template whose template parameters are identical to - those of &array;. Next, the &array; template determines the type of - scalar arguments (indices) to be used in operator(), the function - that implements &pooma;'s &fortran;-style indexing syntax X(i1,i2): - - typedef typename Engine_t::Index_t Index_t; - - This statement defines another type alias: - Array<Dim,T,EngineTag>::Index_t is simply an alias for - Engine_t::Index_t. Engine_t::Index_t is a qualified name, which - means that the type Index_t is found in the class Engine_t. This - is the second requirement for the Engine concept: the class - Engine_t must define a public type called Index_t. This line will - not compile if that definition is not supplied. This indirection - is one of the ways that &pooma; supports polymorphic indexing. If - the Engine works with a discrete integer domain, it defines its - Index_t to be an integral type. If the Engine works in a - continuous domain, it defines its Index_t to be a floating-point - type. - - The data lookup is performed in the operator() function. We - see that &array; simply passes the indices on to its engine - object. Thus, we have the third requirement for the Engine - concept: it must provide a version of operator() that takes Dim - values of type Index_t. - - Simply passing the indices on to the engine object may seem - odd. After all, engine(i,j) looks like we're just indexing another - array. There are several advantages to this extra level of - indirection. The &array; class is as faithful a model of the &array; - concept as possible, while the Engine class is a low-level - interface to a user-defined data source. As a result, &array; has a - wide variety of constructors for user convenience, while engines - have but a few. &array; supports a wide variety of overloaded - operator() functions for view creation and indexing. Engines - support indexing only. &array; does not have direct access to the - data, which is managed by the engine object. Finally, &array; has a - wide variety of overloaded mathematical operators and functions, - and works with the Portable Expression Template Engine (PETE) [4] - to provide efficient evaluation of &array; expressions. Engines have - no such support. In general, &array; is much more complex and - feature-laden than Engine. This is the prime advantage of the - separation of interface and implementation: &array; only has to be - implemented once by the &pooma; developers. Engines are simple - enough to be written by users and plugged directly into the &array; - framework. - - Figure 3 illustrates the "Brick" specialization of the - Engine template, which implements &fortran;-style lookup into a - block of memory. First, there is the general Engine template, - which is empty as there is no default behavior for an unknown - EngineTag. The general template is therefore not a model for the - Engine concept and &array; classes attempting to use it will not - compile. Next, there is the definition of the Brick class, a - policy tag whose sole purpose is to select a particular - specialization of the Engine template. Finally, there is the - partial specialization of the Engine template. Examining its body, - we see the required Index_t typedef and the required operator(), - which follows the &fortran; prescription for generating an offset - into the data block based on the row, column, and the number of - rows. All of the requirements are met, so the Brick-Engine class - is a model of the Engine concept. - - End From - papers/GenericProgramming_CSE/dubois.html: - - (unformatted) From - papers/GenericProgramming_CSE/dubois.html: - - Compile-time Versus Run-Time Polymorphism - - Encapsulating the indexing in an Engine class has important - advantages, both in terms of flexibility and efficiency. To - illustrate this point, we introduce the PolarGaussian-Engine - specialization in Fig. 4. This is an analytic engine that - calculates its values directly from its inputs. Unlike the - Brick-Engine, this engine is "indexed" with data of the same type - as its output: it maps a set of T's to a single T. Therefore, the - Index_t typedef selects T as the index type, as opposed to the int - in the Brick-Engine specialization. The operator() function also - differs in that it computes the return value according to an - analytic formula. - - Both Engine<Dim,T,Brick> and - Engine<Dim,T,PolarGaussian> can be plugged in to an &array; by - simply varying the &array;'s EngineTag. This is possible despite the - fact that the two classes exhibit dramatically different behavior - because they are both models of the Engine concept. - - Notice that we have achieved polymorphic indexing without - the use of inheritance or virtual functions. For instance, - consider the following code snippet: - - Array<2, double, Brick> a; - Array<2, double, PolarGaussian> b; - - double x = a(2, 3); // x = a.engine.data[2 + 3 * a.engine.numRows]; - double y = b(2.0, 3.0); // y = exp(-(2.0*2.0+3.0*3.0) / b.engine.delta); - - The data lookup functions for the two &array;s perform completely - different operations. Since this is accomplished using static - types, it is known as compile-time polymorphism. Moreover, - everything is known at compile time, so the functions are fully - inlined and optimized, thereby yielding code equivalent to that - shown in the comments above. - - The flexibility and efficiency of compile-time polymorphism - cannot be duplicated with a run-time implementation. To illustrate - this point, in Fig. 5, we re-implement our &array; concept using the - classic Envelope-Letter pattern [5], with the array class, - RTArray, being the envelope and the run-time-engine, RTEngine, - being the letter. RTArray defers data lookup to the engine object - by invoking the engine's functions through a pointer to the - RTEngine base class. Figure 6 illustrates the RTEngine base class - and Fig. 7 illustrates two descendants: RTBrick and - RTPolarGaussian. - - The run-time implementation provides the same basic - functionality as the compile-time implementation, but it is not as - flexible or as efficient. It lacks flexibility in that the return - type of the indexing operation must be specified in the RTEngine - base class and in the RTArray class. Thus, in Figs. 5 and 6,we see - versions of RTArray::operator() and RTEngine::index functions that - take both int's and T's. If the programmer wants to add another - index-type option, these classes must be modified. This is a - violation of the open-closed principle proposed by Meyer - [6]. Also, since RTEngine descendants will usually only implement - one version of index, we cannot make RTEngine an abstract base - class. Instead, we have the default versions of index throw an - exception. Thus, compile-time error checking is - weakened. Furthermore, since indexing is done via a virtual - function call, it will almost never be inlined, which is not - acceptable in most scientific applications. - - There are advantages to the Envelope-Letter approach. First, - all RTArray objects have the same type, allowing them to be stored - in homogeneous collections. This can simplify the design of some - applications. Second, RTArray objects can change their engines at - runtime, and thus effectively change their types on the fly??this - is the primary reason for using the Envelope-Letter idiom, and can - be very important in some applications. - - For most scientific applications, however, these issues are - minor, and maximum performance for array indexing is of paramount - importance. Our compile-time approach achieves this performance - while providing the desired polymorphic indexing. - - From Section 4 of - papers/SiamOO98_paper.ps: - - The &array; class is templated on an &engine; type that - handles the actual implementation of the mapping from input to - output. Thus, the &array; interface features are completely - separate from the implementation, which could be a single &c; - array, a function of some kind or some other mechanism. This - flexibility allows an expression itself to be viewed through the - &array; interface. Thus, one can write something like - - foo(A*B+C); - where A, B and - C are &array;s and foo is - a function taking an &array; as an argument. The expression - A*B+C - will only be evaluated by the expression engine as needed by - foo. - - In fact, one can even write &engine;s which are wrappers - around external data structures created in non-&pooma; codes and - know to manipulate these structures. Once this is done, the - external entities have access to the entire &array; interface and - can utilize all of the powerful features of - &pooma; II. - - Section 2, "Arrays and Engines," of - papers/iscope98.pdf describes both &array;s - and &engine;s. This may or may not duplicate the material in - papers/GenericProgramming_CSE/dubois.html. - - Section 4, "Expressions and Evaluators", of - papers/iscope98.pdf has a good explanation of - &pooma; II's expression trees and expression engines. - - - &multipatch; Engine - From README: To actually use multiple - contexts effectively, you need to use the MultiPatch engine with - patch engines that are Remote engines. Then the data will be - distributed across multiple contexts instead of being copied on - every context. See the files in example/Doof2d for a simple - example that creates a MultiPatch array that can be distributed - across multiple contexts and performs a stencil computation on - that array. - - -

- -

- - ]]> - - - - Writing Distributed Programs - - Discuss the distributed model and guard cells. See docs/parallelism.html. - - Does any of the parallel implementation described in - papers/SCPaper-95.html still apply? - - ?Tuning program for maximize parallel performance? - - external references to &mpi; and threads - - QUESTION: Are there interesting, short parallel programs in - any &mpi; book that we can convert to &pooma;? - -

- Layouts - - An out-of-date description can be found in Section 3.3, - especially 3.3.2, of papers/pooma.ps - describes the global/local interactions and parallel abstraction - layers. -

- -

- Parallel Communication - - An out-of-date description can be found in - Section 3.3.3 of papers/pooma.ps -

- -

- Using Threads - - QUESTION: Where do threads fit into the manual? Do threads - even work? - - From Section 4, of - papers/SiamOO98_paper.ps - - &pooma; II will make use of a new parallel run-time - system called &smarts; that is under development at the ACL. - &smarts; supports lightweight threads, so the evaluator will be - able to farm out data communication tasks and the evaluation of - subsets of an expression to multiple threads, thus increasing the - overlap of communication and computation. Threads will also be - available at the user level for situations in which a - task-parallel approach is deemed appropriate. -

- - - ]]> - - - - Debugging and Profiling &pooma; Programs - - Consider &dashdash;pooma-debug number. - See also other &pooma; options in src/Utilities/Options.h. - - UNFINISHED -

- Finding Race Conditions From Missing - <function>blockAndEvaluate</function> Calls - - &pooma; may reorder computations so calls to - Pooma::blockAndEvaluate() are necessary - before accessing particular &array; and &field; values. - Omission of necessary calls can lead to race conditions where - the ordering of reads and writes to particular values is - incorrect. To help diagnose if calls to - Pooma::blockAndEvaluate are missing, invoke - a &pooma; executable with the - &dashdash;pooma-blocking-expressions option. - This automatically causes - Pooma::blockAndEvaluate to be called after - each statement. Doing so ensures program correctness, but it - may increase running times, particularly if multiple processors - are used, because computation and communication may not overlap - as much as possible. Of course, program correctness is more - important than execution speed. - - If using - &dashdash;pooma-blocking-expressions changes a - program's output, it is missing one or more calls to - Pooma::blockAndEvaluate. To narrow the - region with a missing call, surround the region in question with - calls to Pooma::blockingExpressions(true) - and Pooma::blockingExpressions(false), - but do not use the - &dashdash;pooma-blocking-expressions option. - Within the region, Pooma::blockAndEvaluate - will be invoked after each statement. Repeatedly reducing the - region's size should reveal where calls are missing. -

- - ]]> - - - - ]]> - - - &pooma; Reference Manual - - - TMP: This Chapter Holds These Comments But Will Be Removed - - For each template parameter need to describe the constraints - on it. - - Remove this section when the following concerns have been - addressed. - - Add a partintro explaining file suffixes such as .h, .cpp, .cmpl.cpp, .mk, .conf. Should we also explain use - of inline even when necessary and the template - model, e.g., including .cpp files. - - QUESTION: What are the key concepts around which to organize - the manual? - - QUESTION: What format should the manual use? - -

- Musser, Derge, and Sanai, §20.0. - It is important to state the requirements on the components - as generally as possible. For example, instead of saying - class X must define a member function - operator++(), we say for any - object x of type X, - ++x is defined. -

- - - - - A Typical &pooma; Class - - - Class Member Notation - - - *_t - - - - type within a class. QUESTION: What is the &cc; name for - this? - - - - - *_m - - - - data member - - - - - - &pooma; Class Vocabulary - - component - - one of several values packaged together. For example, a - three-dimensional vector has three components, i.e., three - values. - - - - element-wise - - applied to each element in the group, e.g., an array - - - - reduction - - repeated application of a binary operator to all elements, - yielding one value - - - - tag - - an enumerated value indicating inclusion in a particular - semantic class. The set of values need not be explicitly - declared. - - - - - - - - - Installing and Configuring &pooma; - - - - Installing &pooma;. - - - Requirements for configuration files. - - - - Include descriptions of using &smarts;, &cheetah;, τ, - &pdt;. - - QUESTION: Does it install on windows and on mac? If so, what - are the instructions? See also INSTALL.{mac,unix,windows}. - - README has some - information on &cheetah; and threads in the Message-Based - Parallelism section. - - Which additional packages are necessary and when? - - What configure options should we list? See configure. Be sure to list - debugging option and how its output relates to config/LINUXgcc.suite.mk. - - config/arch has files - for (OS, compiler) pairs. Explain how to modify a configuration - file. List requirements when making a new configuration file (low - priority). - - config/LINUXgcc.suite.mk has output - from configure. Useful to - relate to configuration files and configure's debugging output. - - - - - - Compilation and &make; Files - - We assume Gnu make. Do we know what assumptions are made? - - How do all these files interact with each other? Ala a make - interpreter, give an example of which files are read and - when. - - - config/Shared/README.make - This has short descriptions of many files, - especially in config/Shared. - - makefile - These appear throughout all directories. What are - the equivalences classes and what are their - parts? - - include.mk - What does this do? Occurs in many directories: - when? Template seems to be config/Shared/include2.mk. - - subdir.mk - list of subdirectories; occurs in several - directories: when? src/subdir.mk is a good - example. - - - objfile.mk - - list of object files to construct, presumably from - *.cmpl.cpp files. - src/Utilities/objfile.mk is an - example. - - - config/Shared/rules.mk - most compiler rules - - config/head.mk - read at beginning of each - makefile? - - config/Shared/tail.mk - read at end of each makefile? - - config/Shared/variables.mk - Is this used? - - config/Shared/compilerules.mk - table of origin and target suffixes and commands - for conversion - - - - - - - - - &array;s - - Include src/Pooma/Arrays.h to use &array;s. - The implementation source code is in src/Array. - - FINISH: Define an array. Introduce its parts. - - ADD: some mention of the maximum supported number of - dimensions somewhere. - -

- The &array; Container - - - Template Parameters - - - - - Parameter - Interpretation - - - - - Dim - dimension - - - T - array element type - - - EngineTag - type of computation engine object - - - -

- - QUESTION: How do I introduce class type definitions, when - they are used, i.e., compile-time or run-time, and when - programmers should use them? - - - Compile-Time Types and Values - - - - - Type or Value - Interpretation - - - - - This_t - the &array; object's type - - - Engine_t - the &array; object's engine's type - - - EngineTag_t - indication of engine's category - - - Element_t - the type of the array elements, i.e., T - - - ElementRef_t - the type of a reference to an array element, - i.e., T&. Equivalently, the type to write to a - single element. - - - Domain_t - the array's domain's type, i.e., the type of the - union of all array indices - - - Layout_t - unknown - - - dimensions - integer equalling the number of dimensions, i.e., - Dim - - - rank - integer equalling the number of dimensions, i.e., - Dim; a synonym for - dimensions - - - -

- -

- Constructors and Destructors - - - Constructors and Destructors - - - - - Function - Effect - - - - - - - Array - - - - Creates an array that will be resized - later. - - - - - Array - const Engine_t& - engine - - - Creates an array with an engine equivalent to - the engine. This array will have the - same values as engine. QUESTION: Why - would a user every want to use this - constructor? - - - - - Array - - const - Engine<Dim2, T2, EngineTag2>& - engine - - - const - Initializer& init - - - - What does this do? - - - ADD ALL CONSTRUCTORS AND DESTRUCTORS. - - - -

- - -

- Initializers - - Add a table. -

- - -

- Element Access - - - &array; Element Access - - - - - Function - Effect - - - - - - - Element_t read - - - - unknown: See line 1839. - - - - - Element_t read - - const - Sub1& s1 - - - const - Sub2& s2 - - - - How does the version with template parameters, - e.g., Sub1 differ from the int - version? - - - - - Element_t operator() - - const - Sub1& s1 - - - const - Sub2& s2 - - - - How does this differ from read(const - Sub1& s1, const Sub2& s2)? - - - ADD ALL reads and - operator()s. - - - -

- - -

- Component Access - - When an array stores elements having components, e.g., an - array of vectors, tensors, or arrays, the - comp returns an array consisting of the - specified components. The original and component array share the - same engine so changing the values in one affects values in the - other. - - For example, if &n; × &n; array a - consists of three-dimensional real-valued vectors, - a.comp(1) returns a &n; × &n; - real-valued array of all the middle vector components. Assigning - to the component array will also modify the middle components of - the vectors in a. - - - &array; Component Access - - - - - Function - Effect - - - - - - - UNKNOWN compute this comp - - const - int& - i1 - - - - unknown: See line 1989. - - - ADD ALL comps. - - - -

- -

- Accessors - - - &array; Accessor Methods - - - - - Function - Effect - - - - - - - int first - - int - d - - - - unknown: See line 2050 - - - ADD ALL other accessor methods, including - engine. - - - -

- - -

- Copying &array;s - - Explain how copied arrays and views of arrays share the - same underlying engine so changing values in one also affects the - other. This is called a shallow copy. -

- - -

- Utility Methods - - - &array; Utility Methods - - - - - Function - Effect - - - - - - - void makeOwnCopy - - - - unknown: See line 2044 - - - ADD ALL other utility methods. - - - -

- - -

- Implementation Details - - As a container, an &array;'s implementation is quite - simple. Its privatedata consists of - an engine, and it has no private - functions. - - - &array; Implementation Data - - - - - Data Member - Meaning - - - - - - - private - Engine_t engine_m - - - engine computing the array's values - - - -

- -

- - -

- &dynamicarray;s: Dynamically-Sized Domains - - A DynamicArray is a read-write array with extra - create/destroy methods. It can act just like a regular Array, but - can have a dynamically-changing domain. See src/DynamicArray/DynamicArray.h. - - ADD: Briefly describe what the class does and an example of - where it is used. - - ADD: Check that its interface is actually the same as for - &array;. - - ADD: Check that the operations on dynamic arrays are - actually the same as for &array;. See src/DynamicArray/DynamicArrayOperators.h, - src/DynamicArray/PoomaDynamicArrayOperators.h, - and src/DynamicArray/VectorDynamicArrayOperators.h. - - -

- Implementation Details - - DynamicArray has no - protected or - private members. -

- - -

- Views of &array;s - - UNFINISHED -

- - -

- &array; Assignments - - &pooma; supports assignments to &array;s of other &array;s - and scalar values. QUESTION: Is the following correct? For the - former, the right-hand side array's domain must be at least as - large as the left-hand side array's domain. Corresponding values - are copied. Assigning a scalar value to an array ensures all the - array elements have the same scalar value. - - UNFINISHED: Add a table containing assignment operators - found one lines 2097–2202. -

- - -

- Printing &array;s - - &array;s support output to but not input from IO streams. - In particular, output to ostreams and file streams is - supported. - - Add a table, using src/Array/Array.h, lines - 2408–2421. See the implementation in src/Array/PrintArray.h. - - QUESTION: How does one print a &dynamicarray;. -

- - -

- Expressions Involving &array;s - - In &pooma;, expressions may contain entire &array;s. That - is, &array;s are first-class objects with respect to expressions. - For example, given &array;s a and - b, the expression a + b - is equivalent to an array containing the element-wise sum of the - two arrays. - - Any finite number of the operators listed below can be used - in an expression. The precedence and order of operation is the - same as with ordinary built-in types. - - QUESTION: Do &field;s also support the same set of - operations? - - QUESTION: Some operations in src/Field/FieldOperators.h use both - &array; and &field;. Do we list them here or in the &field; - section or both or somewhere else? - - In the table below, &array; supplants the exact return types - because they are complicated and rarely need to be explicitly - written down. - - - Operators on &array; - - - - - Operator - Value - - - - - - - - Array acos - const Array<Dim,T,EngineTag>& a - - - - an array containing the element-wise inverse - cosine of the array a - - - ADD ALL other operators appearing in src/Array/ArrayOperators.h, - src/Array/ArrayOperatorSpecializations.h, - src/Array/PoomaArrayOperators.h, - and src/Array/VectorArrayOperators.h. - - - -

- - FINISH: Write one or two examples or refer to ones - previously in the text. -

- - -

- Reducing All &array; Elements to One Value - - These reduction functions repeatedly apply a binary - operation to all array elements to yield a value. These functions - are similar to the Standard Template Library's - accumulate function. For example, - sum repeatedly applies the binary plus - operator to all array elements, yielding the sum of all array - elements. - - FINISH: What order of operation, if any, is - guaranteed? - - FINISH: Add a table of the functions in src/Array/Reductions.h. - - How does one use one's own binary function? See src/Engine/Reduction.h. -

- - -

- Utility Functions - -

- Compressed Data - - Add a table containing - elementsCompressed, - compressed, compress, - and uncompress. -

- - -

- Centering Sizes and Number of Materials - - ADD: a description of numMaterials and - centeringSize found in src/Field/Field.h. These functions - are meaningless for &array; but are provided for consistency with - &field;. -

- -

- Obtaining Subfields - - ADD: a description of subField found - in src/Field/Field.h. - This function, meaningless for &array;, is provided for - consistency with &field;. -

- - -

- TMP: What do we do with these …? Remove this - section. - -

- introduction.html - - &pooma; was designed and implemented by scientists working - at the Los Alamos National Laboratory's Advanced Computing - Laboratory. Between them, these scientists have written and tuned - large applications on almost every commercial and experimental - supercomputer built in the last two decades. As the technology - used in those machines migrates down into departmental computing - servers and desktop multiprocessors, &pooma; is a vehicle for its - designers' experience to migrate as well. In particular, - &pooma;'s authors understand how to get good performance out of - modern architectures, with their many processors and multi-level - memory hierarchies, and how to handle the subtly complex problems - that arise in real-world applications. -

- - QUESTION: Do we describe the &leaffunctor;s specialized for - &array;s in src/Array/Array.h or in the &pete; - reference section? What about the functions in src/Array/CreateLeaf.h? - - QUESTION: What is an EngineFunctor? We - probably should describe it in an analogous way as for - &leaffunctor;s. - - QUESTION: Where do we write about - ExpressionTraits for &array;s? - - QUESTION: Do we describe the ElementProperties - specialization at this place or in its section? - - QUESTION: Do we describe the Patch - specialization for &array;s (src/Array/Array.h:1300) in this - place or in a section for patches? -

- - - - - &field;s - - An &array; is a set of values indexed by - coordinates, one value per coordinate. It models the computer - science idea of an array. Similarly, a &field; is a set of values - indexed by coordinate. It models the mathematical and physical - idea of a field represented by a grid of rectangular cells, each - having at least one value. A &field;'s functionality is a superset - of an &array;'s functionality because: - - - A &field; is distributed through space so one can compute - the distances between cells. - - - Each cell can hold multiple values. For example, a - rectangular cell can have one value on each of its faces. - - - Multiple materials can share the same cell. For example, - different values can be stored in the same cell for carbon, - oxygen, and nitrogen. - - - Also, &field;s' values can be related by relations. Thus, if one - field's values change, a dependent field's values can be - automatically computed when needed. FIXME: See also the unfinished - works chapter's entry concerning relations and arrays. - - QUESTION: Should we add a picture comparing and contrasting - an array and a field? - - QUESTION: How much structure can be copied from the &array; - chapter? - - QUESTION: Where is NewMeshTag, defined in - src/Field/Field.h, - used? - - QUESTION: Do we describe the &leaffunctor;s specialized for - &field;s in src/Field/Field.h or in the &pete; - reference section? Use the same decision for &array;s. - - QUESTION: What do the structure and functions in src/Field/Mesh/PositionFunctions.h - do? - - -

- The &field; Container - - ADD: table of template parameters and table of compile-time - types and values. - - -

- Constructors and Destructors - - ADD: this section similar to &array;s's constructor and - destructor section. -

- -

- Initializers - - Add a table. -

- - -

- Element Access - - ADD: a table ala &array;. Be sure to include - all. -

- - -

- Component Access - - ADD: a table ala &array;. -

- - -

- Obtaining Subfields - - ADD: discussion and a table listing ways to obtain - subfields. Although the implementation may treat subfield views - and other field views similarly (?Is this true?), they are - conceptually different ideas so we present them - separately. - - See src/Field/Field.h's - operator[], - subField, …, - material. -

- - -

- Supporting Relations - - ADD: a table with the member functions including - addRelation, - removeRelations, - applyRelations, and - setDirty. -

- - -

- Accessors - - ADD: a table using lines like src/Field/Field.h:1243–1333. -

- - -

- Utility Methods - - ADD: a table including - makeOwnCopy. -

- - -

- Implementation Details - - ADD: a table similar to &array;'s. - -

- -

- - -

- Views of &field;s - - Be sure to relate to &array; views. Note only three - dimensions are supported. - - Be sure to describe f[i]. Does this - refer to a particular material or a particular value within a - cell? I do not remember. See SubFieldView in - src/Field/Field.h. -

- - -

- &field; Assignments - - ADD: Describe supported assignments, relating to &array;'s - assignments. - - UNFINISHED: Add a table containing assignment operators - found on src/Field/Field.h:2097–2202 - and 1512–1611. -

- - -

- Printing &field;s - - QUESTION: How similar is this to printing &array;s? - - &field;s support output to but not input from IO streams. - In particular, output to ostreams and file streams is - supported. - - Add a table, using src/Field/Field.h, lines - 1996–2009. See the implementation in src/Field/PrintField.h. -

- - -

- Combining &field; Elements - - Like &array;s, &field;s support reduction of all elements to - one value. Additionally, the latter supports computing a field's - values using field stencils. QUESTION: How do I describe this - with a minimum of jargon? - - ADD: something similar to &array; reductions. - - FINISH: Add a table of the functions in src/Field/FieldReductions.h. - - FINISH: Add a table of the functions in src/Field/DiffOps/FieldOffsetReductions.h. - QUESTION: Why is only sum defined? -

- - -

- Expressions Involving &field;s - - Do something similar to &array;'s section. See the - operations defined in src/Field/FieldOperators.h, - src/Field/FieldOperatorSpecializations.h, - src/Field/PoomaFieldOperators.h, and - src/Field/VectorFieldOperators.h. - - Some operations involve both &array; and &field; - parameters. Where do we list them? -

- - -

- &field; Stencils: Faster, Local Computations - - ADD: a description of a stencil. Why is it needed? How - does a user use it? How does a user know when to use one? Add - documentation of the material from src/Field/DiffOps/FieldStencil.h. - - How is FieldShiftEngine used by &field; - stencils? Should it be described here or in the &engine; section? - See the the code in src/Field/DiffOps/FieldShiftEngine.h. -

- - -

- Cell Volumes, Face Areas, Edge Lengths, Normals - - ADD: a description of these functions. See src/Field/Mesh/MeshFunctions.h. - These are initialized in, e.g., src/Field/Mesh/UniformRectilinearMesh.h. - Note that these do not work for NoMesh. -

- - -

- Divergence Operators - - ADD: a table having divergence operators, explaining the - current restrictions imposed by what is implemented. See - src/Field/DiffOps/Div.h - and src/Field/DiffOps/Div.UR.h. What - restrictions does UR (mesh) connote? -

- - -

- Utility Functions - -

- Compressed Data - - Add a table containing - elementsCompressed, - compressed, compress, - and uncompress. -

- - -

- Centering Sizes and Number of Materials - - ADD: a description of numMaterials and - centeringSize found in src/Field/Field.h. - - QUESTION: How do these relate to any method functions? -

- - -

- Obtaining Subfields - - ADD: a description of subField found - in src/Field/Field.h. -

- -

- - -

- &field; Centerings - - DO: Describe the purpose of a centering and its definition. - Describe the ability to obtain canonical centerings. Explain how - to construct a unique centering. See src/Field/FieldDentering.h. -

- - -

- Relative &field; Positions - - Permit specifying field positions relative to a field - location. Describe FieldOffset and - FieldOffsetList. See src/Field/FieldOffset.h -

- - -

- Computing Close-by Field Positions - - Given a field location, return the set of field locations - that are closest using ?Manhattan? distance. See src/Field/NearestNeighbors.h. -

- - -

- Mesh ??? - - Unlike &array;s, &field;s are distributed throughout space - so distances between values within the &field can be computed. A - &field;'s mesh stores this spatial distribution. - - QUESTION: What do we need to write about meshes? What is - unimportant implementation and what should be described in this - reference section? - - QUESTION: Where in here should emphasize vertex, not cell, - positions? VERTEX appears repeatedly in src/Field/Mesh/NoMesh.h. - - - Mesh Types - - - - - Mesh Type - Description - - - - - NoMesh<Dim> - no physical spacing, causing a &field; to mimic - an &array; with multiple engines. - - - UniformRectilinearMesh<Dim,T> - physical spacing formed by the Cartesian product - of ????. - - - -

- - -

- Mesh Accessors - - ADD: a table listing accessors, explaining the difference - between (physical and total) and (cell and vertex) domains. See - src/Field/Mesh/NoMesh.h. - Also, include spacings and - origin in src/Field/Mesh/UniformRectilinearMesh.h. - Note NoMesh does not provide the latter two. -

- -

- - -

- TMP: What do we do with these …? Remove this - section. - - QUESTION: Do we describe the Patch - specialization for &field; at this place or in some common place? - Follow &array;'s lead. - - QUESTION: Where do we describe CreateLeaf and - MakeFieldReturn in src/Field/FieldCreateLeaf.h and - src/Field/FieldMakeReturn.h. - - QUESTION: What do we do with FieldEnginePatch - in src/Field/FieldEngine/FieldEnginePatch.h. -

- - - - - &engine;s - - From a user's point of view, a container makes data available - for reading and writing. In fact, the container's &engine; stores - the data or, if the data is computed, performs a computation to - yield the data. - - FINISH: Introduce the various types of engines. Add a table - with a short description of each engine type. - - FINISH: First, we specify a generic &engine;'s interface. - Then, we present &engine; specializations. - - - Types of &engine;s - - - - - Engine Type - Engine Tag - Description - - - - - Brick - Brick - Explicitly store all elements in, e.g., a &cc; - array. - - - Compressible - CompressibleBrick - If all values are the same, use constant storage - for that single value. Otherwise, explicitly store all - elements. - - - Constant - ConstantFunction - Returns the same constant value for all - indices. - - - Dynamic - Dynamic - Manages a contiguous, local, one-dimensional, - dynamically resizable block of data. - - - Component Forwarding - CompFwd<EngineTag, - Components> - Returns the specified components from - EngineTag's engine. Components are - pieces of multi-value elements such as vectors - and tensors. - - - Expression - ExpressionTag<Expr> - Returns the value of the specified &pete; - expression. - - - Index Function - IndexFunction<Functor> - Makes the function - Functoraccepting indices mimic an - array. - - - MultiPatch - MultiPatch<LayoutTag,PatchTag> - Support distributed computation using several - processors (???contexts???). LayoutTag - indicates how the entire array is distributed among the - processors. Each processor uses a PatchTag - engine. - - - Remote - Remote<EngineTag> - unknown - - - Remote Dynamic - Remote<Dynamic> - unknown: specialization - - - Stencil - StencilEngine<Function, - Expression> - Returns values computed by applying the - user-specified function to sets of contiguous values in the - given engine or container. Compare with user function - engines. - - - User Function - UserFunctionEngine<UserFunction,Expression> - Returns values computed by applying the - user-specified function to the given engine or container. - QUESTION: Is the following claim correct? For each returned - value, only one value from the engine or container is - used. - - - -

- - QUESTION: Where do we describe views? - - QUESTION: What does NewEngine do? Should it be - described when describing views? Should it be omitted as an - implementation detail? - - QUESTION: Where do we describe &engine; patches found in - src/Engine/EnginePatch.h? - All patch data in a separate chapter or engine-specific pieces in - this chapter? - - QUESTION: What is notifyEngineWrite? - See also src/Engine/NotifyEngineWrite.h. - - QUESTION: What aspect of MultiPatch uses IsValid in - src/Engine/IsValidLocation.h? - - QUESTION: Who uses intersections? Where should this be - described? See src/Engine/Intersector.h, src/Engine/IntersectEngine.h, and - src/Engine/ViewEngine.h. - -

- &engine; Compile-Time Interface - - ADD: a table of template parameters ala &array;. ADD: - compile-time types and values. -

- - -

- Constructors and Destructors - - ADD: a table of constructors and destructors ala - &array;'s. -

- - -

- Element Access - - ADD: a table with read and - operator(). -

- - -

- Accessors - - ADD: a table of accessors. -

- - -

- &engine; Assignments - - similar to &array;'s assignments. shallow copies. ADD: a - table with one entry -

- - -

- Utility Methods - - ADD: a table including - makeOwnCopy. - - QUESTION: What are dataObject, - isShared, and related methods? -

- - -

- Implementation Details - - ADD: this section. Explain that - dataBlock_m and data_m point - to the same place. The latter speeds access, but what is the - purpose of the former? -

- - -

- Brick and BrickView Engines - - ADD: description of what a brick means. ADD: whatever - specializations the class has, e.g., - offset. - - QUESTION: What does DoubleSliceHelper do? -

- - -

- Compressible Brick and BrickView Engines - - ADD this. -

- - -

- Dynamic and DynamicView Engines: - - ADD this. Manages a contiguous, local, resizable, 1D block - of data. -

- - -

- Component Engines - - I believe these implement array component-forwarding. See - src/Engine/ForwardingEngine.h. -

- - -

- Expression Engines - - Should this be described in the &pete; section? Unlikely. - See src/Engine/ExpressionEngine.h. -

- - -

- &engine; Functors - - QUESTION: What is an EngineFunctor? Should it - have its own section? See src/Engine/EngineFunctor.h. -

- - -

- <type>FieldEngine</type>: A Hierarchy of &engine;s - - A &field; consists of a hierarchy of materials and - centerings. These are implemented using a hierarchy of engines. - See src/Field/FieldEngine/FieldEngine.h - and src/Field/FieldEngine/FieldEngine.ExprEngine.h. -

- - - - - &benchmark; Programs - - Explain how to use &benchmark; programs, especially the - options. Explain how to write a &benchmark; program. See also - src/Utilities/Benchmark.h - and src/Utilities/Benchmark.cmpl.cpp. - - - - - - Layouts and Partitions: Distribute Computation Among - Contexts - - What is the difference between ReplicatedTag and - DistributedTag? - - - - - - &pete;: Evaluating Parallel Expressions - -

- UNKNOWN - -

- Leaf Tag Classes - - NotifyPreReadTag indicates a term is about to - be read. Why is this needed? Defined in src/Utilities/NotifyPreRead.h. -

- - - - - - Views - - QUESTION: Should this have its own chapter or be part of a - container chapter? - - Describe View0, View1, …, - View7 and View1Implementation. - - QUESTION: What causes the need for AltView0 and - AltComponentView? - - Be sure to describe ComponentView in the same - place. This is specialized for &array;s in src/Array/Array.h:1323–1382. - -

- <type>ViewIndexer<Dim,Dim2></type> - - Defined in src/Utilities/ViewIndexer.h, this - type translates indices between a domain and a view of it. -

- - - - Threads - - Perhaps include information in src/Engine/DataObject.h. - - &pooma; options include UNFINISHED - - - - - - Utility Types - - TMP: What is a good order? - -

- <type>Options</type>: Varying Run-Time Execution - - Each &pooma; executable has a Options object, - created by Pooma::initialize, storing - run-time configurable values found in argv. - Default options are found in - Options::usage. - - See src/Utilities/Options.h and - src/Utilities/Options.cmpl.cpp. - - Scatter the specific options to other parts of the - manual. -

- -

- Check Correctness: <type>CTAssert</type>, - <type>PAssert</type>, <type>PInsist</type>, - <type>SameType</type> - - Assertions ensure program invariants are obeyed. - CTAssert, checked at compile time, incur no run-time - cost. PAssert and PInsist are checked - to run-time, the latter producing an explanatory message if the - assertion fails. Compiling with NOCTAssert and - NOPTAssert disable these checks. Compiling with just - NOPTAssert disables only the run-time checks. - - SameType ensures, at compile-time, two types - are the same. - - These are implemented in src/Utilities/PAssert.h and - src/Utilities/PAssert.cmpl.cpp. -

- -

- <type>Clock</type>: Measuring a Program's Execution Time - - See src/Utilities/Clock.h. -

- - -

- Smart Pointers: <type>RefCountedPtr</type>, - <type>RefCountedBlockPtr</type>, and - <type>DataBlockPtr</type> - - See src/Utilities/{RefCountedPtr,RefCountedBlockPtr,DataBlockPtr}.h. - src/Utilities/RefCounted.h - helps implement it. DataBlockPtr uses - &smarts;. -

- -

- <type>Inform</type>: Formatted Output for Multi-context - Execution - - See src/Utilities/Inform.h and src/Utilities/Inform.cmpl.cpp. -

- -

- <type>Statistics</type>: Report &pooma; Execution Statistics - - Collect and print execution statistics. Defined in - src/Utilities/Statistics.h. -

- -

- Random Numbers: <type>Unique</type> - - See src/Utilities/Unique.h. -

- - - - - Types for Implementing &pooma; - - TMP: What is a good order? - - Describe types defined to implement &pooma; but that users do - not directly use. This chapter has lower priority than other - chapters since users (hopefully) do not need to know about these - classes. - -

- <type>Tester</type>: Check Implementation Correctness - - &pooma; implementation test programs frequently consist of a - series of operations followed by correctness checks. The - Tester object supports these tests, returning a - boolean whether all the correctness checks yield true. Under - verbose output, messages are printed for each test. See src/Utilities/Tester.h. -

- -

- <type>ElementProperties<T></type>: Properties a Type - Supports - - This traits class permits optimizations in other templated - classes. See src/Utilities/ElementProperties.h. - -

- -

- <type>TypeInfo<T></type>: Print a String Describing - the Type - - Print a string describing the type. Defined in src/Utilities/TypeInfo.h. It is - specialized for other types in other files, e.g., src/Engine/EngineTypeInfo.h and - src/Field/FieldTypeInfo.h. - Is this a compile-time version of RTTI? -

- -

- <type>LoopUtils</type>: Loop Computations at Compile Time - - At compile time, LoopUtils supports copying - between arrays and computing the dot product of arrays. See - src/Utilities/MetaProg.h. -

- -

- <type>ModelElement<T></type>: Wrap a Type - - A wrapper class used to differentiate overloaded functions. - Defined in src/Utilities/ModelElement.h. Used - only by &array; and DynamicArray. -

- -

- <type>WrappedInt<int></type>: Wrap a Number - - A wrapper class used to differentiate overloaded functions - among different integers. Defined in src/Utilities/WrappedInt.h. Is this - class deprecated? Is it even necessary? -

- -

- Supporting Empty Classes - - The NoInit tag class indicates certain - initializations should be skipped. Defined in src/Utilities/NoInit.h. - - FIXME: Should be macro, not function. - POOMA_PURIFY_CONSTRUCTORS generates an empty - constructor, copy constructor, and destructor to avoid &purify; - warnings. Defined in src/Utilities/PurifyConstructors.h. - -

- -

- <type>Pooled<T></type>: Fast Memory Allocation of - Small Blocks - - Pooled<T> speeds allocation and - deallocation of memory blocks for small objects with - type T. Defined in src/Utilities/Pooled.h, it is - implemented in src/Utilities/Pool.h and src/Utilities/Pool.cmpl.cpp. - src/Utilities/StaticPool.h - no longer seems to be used. -

- -

- <type>UninitializedVector<T,Dim></type>: Create - Without Initializing - - This class optimizes creation of an array of objects by - avoiding running the default constructors. Later initialization - can occur, perhaps using a loop that can be unrolled. Defined in - src/Utilities/UninitializedVector.h, - this is used only by DomainTraits. -

- - - - Algorithms for Implementing &pooma; - - In src/Utilities/algorithms.h, - copy, delete_back, and - delete_shiftup provide additional algorithms - using iterators. - - - - - TMP: Where do we describe these files? - - - - src/Utilities/Conform.h: tag for - checking whether terms in expression have conforming - domains - - - - src/Utilities/DerefIterator.h: - DerefIterator<T> and - ConstDerefIterator<T> automatically - dereference themselves to maintain const - correctness. - - - - src/Utilities/Observable.h, - src/Utilities/Observer.h, - and src/Utilities/ObserverEvent.h: - Observable<T>, - SingleObserveable<T>, - Observer<T>, and ObserverEvent - implement the observer pattern. What is the observer pattern? - Where is this used in the code? - - - - - - - - TMP: Items to Discuss in Reference Manual - - - - Discuss &options; and related material. Add developer - command-line options listed in Utilities/Options.cmpl.cpp and also - possibly &dashdash;pooma-threads - n. - - - - - ]]> - - - - Future Development - -

- Particles - - docs/ParticlesDoc.txt has - out-of-date information. - - See Section 3.2.3 of - papers/pooma.ps for an out-of-date - description. - - papers/jvwr.ps concerns mainly - particles. papers/8thSIAMPOOMAParticles.pdf, - by Julian Cummings and Bill Humphrey, concerns parallel particle - simulations. papers/iscope98linac.pdf - describes a particle beam simulation using &pooma;; it mainly - concerns particles. - -

- Particles - - Do we want to include such a section? - - Section 3, "Sample Applications" of - papers/SiamOO98_paper.ps describes porting a - particle program written using High-Performance &fortran; to - &pooma; and presumably why particles were added to &pooma;. It - also describes MC++, a Monte Carlo - neutron transport code. - -

- -

- - -

- Composition of &engine;s - - The i,j-th element of the composition - a∘b of two arrays - a and b equals a(b(i,j)). - The composition engine tagged IndirectionTag<Array1, - Array2>, defined in src/Engine/IndirectionEngine.h is - unfinished. -

- - -

- Improving Consistency of Container Interfaces - -

- Relations for &array;s - - Do &array;s currently support relations? If not, why not? - Should they be added? -

- -

- Supporting the Same Number of Dimensions - - &array; and &field; should support the same maximum number - of dimensions. Currently, &array;s support seven dimensions and - &field;s support only three. By definition, &dynamicarray; - supports only one dimension. - - Relations for &array;s. - - External guards for &array;s. - - QUESTION: What is tiny about &matrix;? Should - they be renamed? -

- -

- - -

- <function>where</function> Proxies - - QUESTION: Do we even discuss this broken - feature? Where is it used? Some related code is in - src/Array/Array.h:2511–2520. -

- - -

- Easing Input for Distributed Programs - - Currently, standard input to distributed programs is not - supported. Instead input can be passed via command-line arguments, - which are replicated to each context. &inform; streams support for - input could be added. For context 0, standard input could be - used. Other contexts would use a RemoteProxy to - distribute the value to the other contests. See src/Engine/RemoteEngine.h for example - uses of RemoteProxy. -

- - -

- Improving Consistency Between &pooma; and &cheetah; - - Improve the consistency between &cheetah;'s and &pooma;'s - configurations. Currently, their defaults differ regarding - &cc; exceptions and static/shared libraries. -

- - -

- Very Long Term Development Ideas - - Describe how to write a new configuration file. -

- - - ]]> - - - - Obtaining and Installing &pooma; - - In , we described - how to install &pooma;. In the following section, we describe how - to install &pooma; to support distributed computation. - ]]> - - ADD: Write this section, including extensive instructions - for Unix-like, MS Windows, and MacOS. List the configuration options. - Be sure to describe configuring for parallel execution. - ]]> - -

- Supporting Distributed Computation - - To use multiple processors with &pooma; requires installing - the &cheetah; messaging library and an underlying messaging library - such as the Message Passing Interface (&mpi;) Communications - Library or the &mm; Shared Memory Library. In the following - section, we first describe how to install &mm;. Read it only if - using &mm;, not &mpi;. Then we describe how to install &cheetah; - and configure &pooma; to use it. - -

- Obtaining and Installing the &mm; Shared Memory Library - - &cheetah;, and thus &pooma;, can use Ralf Engelschall's &mm; - Shared Memory Library to pass messages between processors. For - example, the &author; uses this library on a two-processor - computer running &linux;. The library, available at http://www.engelschall.com/sw/mm/, - is available at no cost and has been successfully tested on a - variety of Unix-like platforms. - - We describe how to download and install the &mm; library. - - - Download the library from the &pooma; Download page - (&poomadownloadpage;) available off the &pooma; home page - (&poomahomepage;). - - - Extract the source code using tar xzvf - mm-1.1.3.tar.gz. Change directories into the - resulting source code directory mm-1.1.3. - - - Prepare to compile the source code by configuring it - using the configure command. To change - the default installation directory /usr/local, specify - &dashdash;prefix=directory - option. The other configuration options can be listed by - specifying the &dashdash;help option. Since the - &author; prefers to keep all &pooma;-related code in his - poomasubdirectory, he - uses - - ./configure &dashdash;prefix=${HOME}/pooma/mm-1.1.3 - - - - Create the library by issuing the - make command. This compiles the source - code using a &c; compiler. To use a different compiler than - the &mm; configuration chooses, set the CC - environment variable to the desired compiler before - configuring. - - - Optionally test the library by issuing the make - test command. If successful, the penultimate line - should be OK - ALL TESTS SUCCESSFULLY - PASSED. - - - Install the &mm; Library by issuing the make - install command. This copies the library files to the - installation directory. The mm-1.1.3 directory containing the - source code may now be removed. - - - -

- - -

- Obtaining and Installing the &cheetah; Messaging Library - - The &cheetah; Library decouples communication from - synchronization. Using asynchronous messaging rather than - synchronous messaging permits a message sender to operate without - the cooperation of the message recipient. Thus, implementing - message sending is simpler and processing is more efficiently - overlapped with it. Remote method invocation is also supported. - The library was developed at the Los Alamos National Laboratory's - Advanced Computing Laboratory. - - &cheetah;'s messaging is implemented using an underlying - messaging library such as the Message Passing Interface (&mpi;) - Communications Library - ) - ]]> - or the &mm; Shared Memory Library. &mpi; works on a wide variety - of platforms and has achieved widespread usage. &mm; works under - Unix-like operating systems on any computer with shared memory. Both libraries are - available at no cost. The instructions below work for whichever - library you choose. - - We describe how to download and install &cheetah;. - - - Download the library from the &pooma; Download page - (&poomadownloadpage;) available off the &pooma; home page - (&poomahomepage;). - - - Extract the source code using tar xzvf - cheetah-1.0.tgz. Change directories into the - resulting source code directory cheetah-1.0. - - - Edit a configuration file corresponding to your operating - system and compiler. These .conf files are located in the - config directory. For - example, to use &gcc; with the &linux; operating system, use - config/LINUXGCC.conf. - - The configuration file usually does not need - modification. However, if you are using &mm;, ensure - shmem_default_dir specifies its location. - For example, the &author; modified the value to - "/home/oldham/pooma/mm-1.1.3". - - - Prepare to compile the source code by configuring it - using the configure command. Specify the - configuration file using the &dashdash;arch option. - Its argument should be the configuration file's name, omitting - its .conf suffix. For - example, &dashdash;arch LINUXGCC. Some other - options include - - - &dashdash;help - - lists all the available options - - - - &dashdash;shmem &dashdash;nompi - - indicates use of &mm;, not &mpi; - - - - &dashdash;mpi &dashdash;noshmem - - indicates use of &mpi;, not &mm; - - - - &dashdash;opt - - causes the compiler to produce optimized source code - - - - &dashdash;noex - - prevents use of &cc; exceptions - - - - &dashdash;static - - creates a static library, not a shared library - - - - &dashdash;shared - - creates a shared library, not a static library. This - is the default. - - - - &dashdash;prefix directory - - specifies the installation directory where the - library will be copied rather than the default. - - - - For example, the &author; uses ./configure &dashdash;arch - LINUXGCC &dashdash;shmem &dashdash;nompi &dashdash;noex &dashdash;static &dashdash;prefix - ${HOME}/pooma/cheetah-1.0 &dashdash;opt. The - &dashdash;arch LINUXGCC indicates use of &gcc; - under a &linux; operating system. The &mm; library is used, - but &cc; exceptions are not. The latter choice matches - &pooma;'s default choice. A static library, not a shared - library, is created. This is also &pooma;'s default choice. - The library will be installed in the ${HOME}/pooma/cheetah-1.0. - Finally, the library code will be optimized, hopefully running - faster than unoptimized code. - - - Follow the directions printed by - configure: Change directories to the - lib subdirectory named - by the &dashdash;arch argument and then type - make to compile the source code and create - the library. - - - Optionally ensure the library works correctly by issuing - the make tests command. - - - Install the library by issuing the make - install command. This copies the library files to - the installation directory. The cheetah-1.0 directory containing - the source code may now be removed. - - - -

- -

- Configuring &pooma; When Using &cheetah; - - To use &pooma; with &cheetah;, one must tell &pooma; the - location of the &cheetah; library using the - &dashdash;messaging configuration option. To do this, - - - Set the &cheetah; directory environment variable - CHEETAHDIR to the directory containing the - installed &cheetah; library. For - example, - - declare -x CHEETAHDIR=${HOME}/pooma/cheetah-1.0 - specifies the - installation directory used in the previous section. If using - the csh shell, use setenv - CHEETAHDIR ${HOME}/pooma/cheetah-1.0. - - - When configuring &pooma;, specify the - &dashdash;messaging option. For example, - ./configure &dashdash;arch LINUXgcc &dashdash;opt - &dashdash;messaging configures for &linux;, &gcc;, and an - optimized library using &cheetah;. - - - -

- - - - - Dealing with Compilation Errors - - Base this low-priority section on errors.html. QUESTION: Where is - errors.html? - - - - - - TMP: Notes to Myself - -

- Miscellaneous - - - - Section 5, "Performance," of - papers/iscope98.pdf motivates and explains - stencils. - - - - If there is time, present another example program, e.g., a - Jacobi solver. - - - - If a reference manual for &pooma; implementors is written, - begin with a chapter Under the Hood: How &pooma; - Works, written from the point of view of &cc; - interpreter. For &pete;, use the material in - papers/PETE_DDJ/ddj_article.html, which - gives example code and descriptions of how the code works, and - see material in background.html's - Expression Templates. - - - - QUESTION: How do &pooma; parallel concepts compare with - &fortran; D or high-performance &fortran; FINISH CITE: - {koelbel94:_high_perfor_fortr_handb}? - - - - QUESTION: How do I know when to use a type name versus just - the concept? For example, when do I use array - versus &array;? - - - - Krylov solvers are described in Section 3.5.2 of - papers/pooma.ps. - - - - Section 5, "The Polygon Overlay Problem," describes - porting an ANSI &c; program to &pooma;. - - - - A good example book: STL Tutorial and Reference - Guide: &cc; Programming with the Standard Template - Library, second edition, by David R. Musser, - Gillmer J. Derge, and Atul Sanai, ISBN 0-201-37923-6, - QA76.73.C153.M87 2001. - - - - One STL reference book listed functions in margin notes, - easing finding material. Do this. - - - - QUESTION: Does Berna Massingill at Trinity University have - any interest ior access to any parallel computers? - - - -

- - -

- Existing HTML Tutorials - - All these tutorials are out-of-date, but the ideas and text - may still be relevant. - - - index.html - list of all tutorials. No useful - material. - - introduction.html - data-parallel Laplace solver using Jacobi - iteration ala Doof2d - - background.html - short, indirect introduction to &pete;; parallel - execution model; &cc;; templates; &stl;; expression - templates - - tut-01.html - UNFINISHED - - Layout.html - UNFINISHED - - parallelism.html - UNFINISHED - - self-test.html - UNFINISHED - - threading.html - UNFINISHED - - tut-03.html - UNFINISHED - - tut-04.html - UNFINISHED - - tut-05.html - UNFINISHED - - tut-06.html - UNFINISHED - - tut-07.html - UNFINISHED - - tut-08.html - UNFINISHED - - tut-09.html - UNFINISHED - - tut-10.html - UNFINISHED - - tut-11.html - UNFINISHED - - tut-12.html - UNFINISHED - - tut-13.html - UNFINISHED - - - -

- - - ]]> - - - &bibliography-chapter; - - &glossary-chapter; - - - - - - --- 0 ---- Index: pooma.xml =================================================================== RCS file: pooma.xml diff -N pooma.xml *** /dev/null Fri Mar 23 21:37:44 2001 --- pooma.xml Thu Jan 31 14:10:44 2002 *************** *** 0 **** --- 1,4223 ---- + + + + + + + + + + + + + + + + + + + + + + + + + + C"> + + + C++"> + + + Cheetah" > + + + + + + + + + + Doof2d" > + + Fortran"> + + + + + Make"> + + MM"> + + MPI"> + + + + PDToolkit"> + + PETE"> + + POOMA"> + + POOMA &toolkitcap;"> + + Purify"> + + Smarts"> + + + STL"> + + Tau"> + + + + + + + + + Array"> + + Benchmark"> + + bool"> + + Brick"> + + char"> + + complex"> + + CompressibleBrick"> + + DistributedTag"> + + Domain"> + + + + double"> + + Dynamic"> + + DynamicArray"> + + Engine"> + + false"> + + + Field"> + + float"> + + Grid"> + + Grid<1>"> + + IndirectionList"> + + IndirectionList<int>"> + + Inform"> + + int"> + + Interval"> + + Interval<1>"> + + Layout"> + + LeafFunctor"> + + Loc"> + + Loc<1>"> + + TinyMatrix"> + + MultiPatch"> + + Options"> + + Range"> + + Range<1>"> + + Remote"> + + ReplicatedTag"> + + Stencil"> + + Tensor"> + + true"> + + + Vector"> + + + + + + + + + + + d"> + + + + g++"> + + KCC"> + + Linux"> + + + + + http://pooma.codesourcery.com/pooma/download'> + + + http://www.codesourcery.com/pooma/pooma/'> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]> + + + + &pooma; + A &cc; &toolkitcap; for High-Performance Parallel Scientific Computing + JeffreyD.Oldham + + CodeSourcery, LLC + + + 2002CodeSourcery, LLC () + Los Alamos National Laboratory + + + All rights reserved. This document may not be redistributed in any form without the express permission of the author. + + + + 1.00 + 2002 Jan 31 + jdo + First publication. + + + + + + + + + Preface + + FINISH: Describe the target audience for &pooma; programs and + for this manual: &cc; programmers writing scientific code, possibly + parallel execution. + + Assume familiarity with &cc; template programming and the + standard template library. FIXME: Remove this index + entry.Oldham, + Jeffrey D. + +

+ Notation + + UNFINISHED +

+ + +

+ How to Read This &bookcap; + + FINISH: Write this section in a style similar to Lamport's + LaTeX section 1.2. FINISH: Fix the book title and the section + number. +

+ + +

+ Obtaining &pooma; and Sample Programs + + Available for free from what WWW site? Include what portions + of LICENSE? Be sure to + include CVS instructions as well. + + Which additional packages are necessary and when? + +

+ + +

+ Using and Modifying &pooma; + + &pooma; is available under open source license. It can be + used and modified by anyone, anywhere. Can it be sold? Include + LICENSE. + + QUESTION: How do developers contribute code? + +

+ + +

+ Acknowledgements + ]]> + + + Acknowledgements + ]]> + + This &book; would not have been completed without the help + and encouragement of a lot of people and organizations. Los Alamos + National Laboratory funded the writing of this manual and the + development of the &poomatoolkit;. John Reynders conceived, + advocated, and headed &pooma; development in its early days, and + Scott Haney continued the leadership. Susan Atlas, Subhankar + Banerjee, Timothy Cleland, Julian Cummings, James Crotinger, David + Forslund, Salman Habib, Scott Haney, Paul Hinker, William Humphrey, + Steve Karmesin, Graham Mark, Jeffrey D. Oldham, Ji Qiang, John + Reynders, Robert Ryne, Stephen Smith, M. Srikant, Marydell + Tholburn, and Timothy Williams all helped develop &pooma;. Rod + Oldehoeft and Jeff Brown of Los Alamos National Laboratory + supported CodeSourcery's and Proximation's work, including the + development of this manual. John Hall, Don Marshall, Jean + Marshall, and the rest of the BLANCA team at Los Alamos worked + closely with the developers and provided valuable suggestions for + improvements. + + I am grateful to James Crotinger, Mark Mitchell, and Stephen + Smith who answered my many questions during the writing of this + &book;. + + + + Jeffrey D. Oldham, 2002 January + + + + + ]]> + + + + + ]]> + + + + Programming with &pooma; + + + ]]> + + &introductory-chapter; + + &template-chapter; + + &tutorial-chapter; + + &concepts-chapter; + + &arrays-chapter; + + + + Engines + + Each container has one or more &engine;s to store or compute + its values. As we mentioned in , a container's role is + high-level, supporting access to groups of values, and an engine's + role is low-level, storing or computing values and supporting + access to individual values. This separation permits optimizing + space and computation requirements. + + We begin this chapter by introducing the concept of an engine + and how it is used. Then, we describe the various &engine;s that + &pooma; provides, separating them into engines that store values + and engines that compute values. + + + + +

+ The Concept + + An engine performs the low-level value storage, computation, + and element-wise access for a container. An engine has a domain + and accessor functions returning individual elements. The &pooma; + &engine; class and its specializations implement the engine + concept. Given an index within the domain, an &engine;'s + operator() function returns the + associated value, which can be used or changed. Its + read member function returns the same + value but permitting only use, not modification. The acceptable + indices are determined by each &engine;. Most accept indices + specified using ∫ and Loc<&dim;> + parameters, but an &engine; might accept string or floating-point + parameters. An &engine;'s layout specifies maps its domain + indices to the processors and memory used to store and compute the + associated values. + + Since an engine's main role is to return the individual + values associated with specific domain indices, any implementation + performing this task is an engine. &pooma; &engine;s fall into + three categories: + + + &engine;s that store values. + + + &engine;s that compute their values using other &engine;s' + values. + + + &engine;s that support distributed computation. + + + For example, the &brick; &engine; explicitly stores all its + values, while the &compressiblebrick; engine adds the feature of + reducing its storage requirements if all these values are + identical. A UserFunction &engine; yields values by + applying a function + object to each value returned by another &engine;. A + CompFwd &engine; projects components from another + &engine;. For example, CompFwd will use the second + components of each &vector; in an &array; to form its own &array;. + Since each container has at least one &engine;, we can also + describe the latter category as containers that compute their + values using other containers' values. A &multipatch; &engine; + distributes its domain among various processors and memory spaces, + each responsible for computing values associated with a portion, + or patch, of the domain. The &remote; &engine; also supports + distributed computation. + + Just as multiple containers can use the same engine, + multiple &engine;s can use the same underlying data. As we + mentioned in , &engine;s + have reference + semantics. A copy of an &engine; has a + reference-counted pointer to the &engine;'s data (if any exists). + Thus, copying an &engine; or a container requires little execution + time. If an &engine; has the same data as another &engine; but it + needs its own data to modify, the + makeOwnCopy member function creates such + a copy. + + &engine;s are rarely explicitly declared. Instead a + container is declared using an &engine; tag, and the container + creates the specified &engine; to deal with its values. For + example, a &brick; &engine; is explicitly declared as + Engine<&dim;,T,Brick>, but they are more + frequently created by containers, e.g., + Array<&dim;,T,Brick>. An &engine;'s first two + template parameters specify the domain's dimensionality and the + value type, as described in . Unlike container + declarations, the third template parameter, the &engine; tag, + specifies which &engine; specialization to use. For example, the + &brick; &engine; tag indicates a &brick; &engine; should be used. + Some &engine;s, such as CompFwd, are rarely declared + even using &engine; tags. Instead the &array;'s + comp and + readComp member functions return views of + containers using CompFwd &engine;s. +

+ + +

+ Types of &engine;s + + In this section, we describe the different types of + &engine;s and illustrate their creation, when appropriate. First, + we describe &engine;s that explicitly store values and then + &engine;s that compute values. See . + + + Types of &engine;s + + + + + &engine; tag + description + + + + + &engine;s That Store + + + &brick; + explicitly stores all values; similar to &c; arrays. + + + &compressiblebrick; + stores all values, reducing storage requirements when + all values are identical. + + + &dynamic; + is a one-dimensional &brick; with dynamically + resizable domain. This should be used with &dynamicarray;, + not &array;. + + + &engine;s That Compute + + + CompFwd + extracts specified components of an engine's vectors, + tensors, arrays, etc.; usually created using the + comp container function. + + + ConstantFunction + makes a scalar value behave like a container. + + + IndexFunction<FunctionObject> + makes the FunctionObject's function of + indices behave like a container. + + + ExpressionTag<Expr> + evaluates an expression tree; usually created by + data-parallel expressions. + + + Stencil<Function, Expression> + applies a stencil computation (Function) + to its input (Expression) which is usually a + container; usually created by applying a Stencil + object to a container. A stencil computation can use + multiple neighboring input values. + + + UserFunctionEngine<Function, + Expression> + applies the given function (or function + object) to its input (Expression) + which is usually a container; usually created by applying a + UserFunction object to a container. The + function implements a one-to-one mapping from its input to + values. + + + &engine;s for Distributed Computation + + + MultiPatch<LayoutTag,EngineTag> + runs a separate EngineTag &engine; on + each context (patch) specified by the given layout. This is + the usual &engine; for distributed computation. + + + Remote<EngineTag> + runs the &engine; specified by EngineTag + on a specified context. + + + Remote<Dynamic> + runs a Dynamic one-dimensional, resizable + &engine; on a specified context. This is a specialization of + Remote. + + + +

+ + + &brick; + &engine;s explicitly store values just like &c; + arrays. &compressiblebrick; &engine;s optimize their storage + requirements when all values are identical. Many &array;s use one + of these two &engine;s. &brick;s are the default &engine;s for + &array; and &field; containers because they explicitly store each + value. This explicit storage can require a large amount of space, + particularly if all these values are the same. If all a + compressible brick &engine;'s values are identical, the &engine; + stores that one value rather than many, many copies of the same + value. These engines can both save time as well as space. + Initializing a compressible engine requires setting only one + value, not every value. Using less storage space may also permit + more useful values to be stored in cache, improving cache + performance. Reading a value in a compressed &engine; using the + read member function is as fast as + reading a value in a &brick; &engine;, but writing a value always + requires executing an additional if + conditional. Thus, if an &engine; infrequently has multiple + different values during its life time, a &compressiblebrick; + &engine; may be faster than a &brick; &engine;. If an &engine; is + created and its values are mostly read, not written, a + &compressiblebrick; &engine; may also be faster. Otherwise, a + &brick; &engine; may be preferable. Timing the same program using + the two different &engine; types will reveal which is faster for a + particular situation. In distributed computing, many &engine;s + may have few nonzero values so &compressiblebrick; &engine;s may + be preferable. For distributed computing, a container's domain is + partitioned into regions each computed by a separate processor and + &engine;. If the computation is concentrated in sections of the + domain, many &engine;s may have few, if any, nonzero values. + Thus, &compressiblebrick; &engine;s may be preferable for + distributed computing. + + Both &brick; and &compressiblebrick; &engine;s have + read and + operator() member functions taking ∫ + and &loc; parameters. The parameters should match the &array;'s + dimensionality. For example, if &array; a has + dimensionality 3, a.read(int, int, int) + and a(int, int, int) should be used. The + former returns a value that cannot be modified, while the latter + can be changed. Using the read member + function can lead to faster code. Alternatively, an index can be + specified using a &loc;. For example, + a.read(Loc<3>(1,-2,5)) and + a(Loc<3>(1,-2,5)) are equivalent to + a.read(1,-2,5)) and + a(1,-2,5). + + The &dynamic; &engine; supports changing domain sizes while + a program is executing. It is basically a one-dimensional + &brick;, explicitly storing values, but permitting the number and + order of stored values to change. Thus, it supports the same + interface as &brick; except that all member functions are + restricted to their one-dimensional versions. For example, + read and + operator() take Loc<1> + or one ∫ parameter. In addition, the one-dimensional domain + can be dynamically resized using create + and destroy. + + + + + + Types of &engine;s: + Brick - explicitly store values + CompressibleBrick - explicitly store values but store only one if all the same + ConstantFunction - convert scalar into an array + DynamicEngine - contiguous, local, resizable, 1D block + ExpressionEngine - evaluate PETE expression + CompFwd - array formed by extracted components from array + ForwardEngine + tut-02.html: use .comp() or .readComp() + IndexFunctionEngine - convert function of indices into an array + IndirectionEngine - incomplete + MultiPatch - ?How do I describe this? + RemoteDynamic - run a Dynamic engine on a specified context + Remote - permit computations on specified context + should discuss with MultiPatch + Stencil - apply a stencil to an array, returning a new Array with the results + UserFunction - Array = apply function to an Array + + + How do I organize these engines into understandable + categories? + + storage + Brick + CompressibleBrick + Dynamic - resizable 1D block + RemoteDynamic + MultiPatch - ?WHAT? + Remote + + computation + CompFwd: project(array)->array + .comp() and .readComp() + view, not a copy + ConstantFunction: scalar(array)->array + explicitly use + IndexFunctionEngine: function(indices)->array + explicitly use + ExpressionEngine: expression(array)->array + created by data-parallel expression + Stencil: stencil(array)->array + implicitly used + explicitly use Stencil<...> type + UserFunction: function(array)->array + explicitly use + + + + Element_t read(Loc<&dim;>) + ElementRef_t operator()(Loc<&dim;>) + Element_t read(int+) + ElementRef_t operator()(int+) + + + Explain the concept of an engine. How does an engine + interact with a container or an &array;? Explain the different + types of engines likely to be used by &pooma; programmers and how + to declare containers using them. Should I list the other engines + that are automatically created? + ]]> + +

+ + + + &data-parallel-chapter; + + + + Container Views + + + container + view + + + view of a container + container, view. + + + A view of a + container is a container accessing a subset + of &container;'s domain and values. The subset can include all of + the container's domain. A view is so named because + it is a different way to access, or view, another container's + values. Both the container and its view share the same underlying + engine so changing values in one also changes them in the + other. + + A view is created by following a container's name by + parentheses containing a domain. For example, consider this code + extracted from in . + + Interval<1> N(0, n-1); + Interval<2> vertDomain(N, N); + Interval<1> I(1,n-2); + Interval<1> J(1,n-2); + Array<2, double, Brick> a(vertDomain); + Array<2, double, Brick> b(vertDomain); + a(I,J) = (1.0/9.0) * + (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + + b(I ,J+1) + b(I ,J ) + b(I ,J-1) + + b(I-1,J+1) + b(I-1,J ) + b(I-1,J-1)); + The last statement creates ten views. For example, + + a(I,J) creates a view of + a using the smaller domain specified by + I and J. This omits the + outermost rows of columns of a. The views + of b illustrate the use of views in + data-parallel statements. b(I-1,J-1) has a + subset shifted up one row and left one column compared with + b(I,J). + ]]> + Be sure to list the various arithmetic operations on domains + that can be used. This was deferred from the &array; and domain + chapter. Explain &array;'s comp function. + + + ]]> + + + + + Writing Sequential Programs + + FIXME: Explain the chapter's purpose. + + FIXME: Explain the format of each section. + + FIXME: Explain the order of the sections. + + Proposed order. Basically follow the order in the proposed + reference section. + + starting, stopping + &array; + &dynamicarray; + &field; + &vector; + &matrix; + &tensor; + &engine; + domain + correctness, e.g., PAssert + &pooma; command-line options + + Include views of containers in the appropriate sections. + + &c;: A Reference Manual uses this + structure for &c; libraries: + + + function declarations, separated by rules from rest of text + + + text explanation + + + table of structure members if appropriate + + + example + + + + + STL Tutorial and Reference Guide, second + edition, uses this structure for STL functions: + + + text description with declaration mixed in + + + example program mixed into text. It is an entire program, + not a program fragment. + + + + + A tutorial chapter for containers has + + + explanation of template types + + + bulleted list of container types + + + example constructors + + + example programs + + + member and related functions with example programs + + + list of accessors and relation functions + + + + + The reference chapter for containers has + + + a section listing common members and types for all containers + + + a section listing common member functions for all containers + + + requirements for various container specialties + + + The section describing vectors contains + + + files (header files) + + + class declaration + + + description + + + type definitions + + + constructors, destructors, and related functions + + + comparison operators + + + element access member functions + + + insert and erase member functions + + + notes + + + + + Josuttis's The &cc; Standard Library: A Tutorial + and Reference uses this structure for its STL container + chapter: + + + short introduction + + + common container abilities + + + common container operations (with table) + + + vector abilities + + + vector operations: + + + create, copy, and destroy operations (mostly table) + + + non-modifying operations (mostly table) + + + assignments (mostly table) + + + element access (mostly table) + + + iterator functions (mostly table) + + + inserting and removing elements (mostly table) + + + + + + using vectors as ordinary arrays + + + exception handling + + + example program + + + + +

+ Beginning and Ending &pooma; Programs + + Every &pooma; program must begin with a call to + initialize and end with a call to + finalize. These functions respectively + prepare and shut down &pooma;'s run-time structures. + + Files + + + #include "Pooma/Pooma.h" // or "Pooma/Arrays.h" or "Pooma/Fields.h" or ... + + + Declarations + + + + bool Pooma::initialize + + int &argc, + char ** &argv, + bool initRTS = true, + bool getCLArgsArch = true, + bool initArch = true + + + + + bool Pooma::initialize + + Pooma::Options &opts, + bool initRTS = true, + bool initArch = true + + + + + bool Pooma::finalize + + + + + bool Pooma::finalize + + bool quitRTS, + bool quitArch + + + + + Description + + Before its use, the &poomatoolkit; must be initialized by a + call to initialize. This usually occurs in + the main function. The first form removes + and processes any &pooma;-specific arguments from the + command-line arguments argv and + argc. describes these options. + The third, fourth, and fifth arguments all have a default value + of &true;. If initRTS is + &true;, the run-time system is initialized. E.g., the contexts + are prepared for use. If getCLArgsArch is &true, + architecture-specific command-line arguments are removed from + argv and argc. + Architecture-specific initialization occurs if getCLArgsArch is &true;. An architecture is specified + by a hardware interface, e.g., processor type, but frequently is + also associated with an operating system or compiler. For + example, Metrowerks for the Macintosh has an + architecture-specific initialization. The function always + returns &true;. + + initialize's alternative form + assumes the &pooma;-specific and architecture-specific + command-line arguments have already been removed from + argv and argc and stored in + opts. Its other two + parameters have the same meaning, and the two functions' + semantics are otherwise the same. + + After its use, the &poomatoolkit; should be shut down using + a call to finalize. This usually occurs in + the main function. The former, and more + frequently used, form first prints any statistics and turns off + all default &pooma; streams. Then it shuts down the run-time + system if it was previously initialized and then shuts down + architecture-specific objects if they were previously + initialized. The latter form gives provides explicit control + whether the run-time system (quitRTS) and architecture-specific + objects (quitArch) are + shut down. Both functions always returns &true;. + + Including almost any &pooma; header file, rather than just + Pooma/Pooma.h suffices + since most other &pooma; header files include it. + + Example Program + + Since every &pooma; program must call + initialize and + finalize, the simplest &pooma; program also + must call them. This program also illustrates their usual + use. + + &initialize-finalize; + +

+ + +

+ Global Variables + + &pooma; makes a few global variables available after + initialization. + + + &pooma; Global Variables + + + + + variable + description + + + + + &inform; pinfo + output stream used to print informative messages to the + user while the program executes. The stream accepts a + superset of standard output operations. + + + &inform; pwarn + FIXME: output stream used to print informative messages to the + user while the program executes. The stream accepts a + superset of standard output operations. + + + +

+ +

+ &pooma; Command-line Options + + Every &pooma; program accepts a set of &pooma;-specific + command-line options to set values at run-time. + + QUESTION: Should I defer documenting &options; to the + reference manual, instead just listing commonly used options in + the previous section? + + UNFINISHED + +

+ Options Summary + + + + &dashdash;pooma-info + + enable use of the pinfo, used to + print informative messages to the user while the program + executes. + + + + + + FIXME: Be sure to list default values. + + + +

+ +

+ TMP: Place these somewhere. + + &pooma; can reorder computations to permit more efficient + computation. When running a sequential program, reordering may + permit omission of unneeded computations. For example, if only + values from a particular field are printed, only computations + involving the field and containers dependent on it need to occur. + When running a distributed program, reordering may permit + computation and communication among processors to overlap. + &pooma; automatically tracks dependences between data-parallel + expressions, ensuring correct ordering. It does not track + statements accessing particular &array; and &field; values so the + programmer must precede these statements with calls to + Pooma::blockAndEvaluate(). Each call forces + the executable to wait until all computation has completed. Thus, + the desired values are known to be available. In practice, some + calls to Pooma::blockAndEvaluate may not be + necessary, but omitting them requires knowledge of &pooma;'s + dependence computations, so the &author; recommends calling + Pooma::blockAndEvaluate before each access to + a particular value in an &array; or &field;. Omitting a necessary + call may lead to a race condition. + for + instructions how to diagnose and eliminate these race + conditions. + ]]> + + + Where talk about various &pooma; streams? + + UNFINISHED + +

+ + +

+ &benchmark; Programs + + Define a &benchmark; program vs. an example or an + executable. Provide a short overview of how to run these + programs. Provide an overview of how to write these programs. + See src/Utilities/Benchmark.h. +

+ + +

+ Miscellaneous + + Section 3, "Domains and Views," of + papers/iscope98.pdf describes four types of + domains. + +

+ Data-Parallel Statements + + Can we use "An Overview of &pete;" from + papers/PETE_DDJ/ddj_article.html or is this + too low-level? + + Section 3.2.1 of papers/pooma.ps + gives a simple example of data-parallel expression. It also has a + paragraph introducing data-parallel operations and selecting + subsets of domains. Section 3.4 describes the Chained + Expression Object (CEO), apparently a precursor + of &pete;. Regardless, it provides some motivation and + introductory material. + + From Section 4 of + papers/SiamOO98_paper.ps: + + This version of &pete; reduces compile time of user codes + and utilizes compile-time knowledge of expression &domain;s for + better optimization. For example, more efficient loops for + evaluating an expression can be generated if &pete; knows that the + &domain; has unit stride in memory. + + Section 4, "Expressions and Evaluators", of + papers/iscope98.pdf has a good explanation of + &pooma; II's expression trees and expression engines. + + COMMENT: background.html has some related + &pete; material. +

+ + +

+ Containers + +

+ &array; + +

+ Section 4 "Future Improvements in + &pooma; II" of + papers/SiamOO98_paper.ps + + An &array; can be thought of as a map from one &domain; to + another.… &array;s depend only on the interface of + &domain;s. Thus, a subset of view of an &array; can be + manipulated in all the same ways as the original &array;. + &array;s can perform indirect addressing because the output + &domain; one one &array; can be used as the input &domain; of + another &array;. &array;s also provide individual element + access. +

+ + + + (unformatted) From + papers/GenericProgramming_CSE/dubois.html: + The &pooma; &array; concept provides an example of how these + generic-programming features can lead to flexible and efficient + code. An Array maps a fairly arbitrary input domain to an + arbitrary range of outputs. When used by itself, an &array; + object A refers to all of the values in its + domain. Element-wise mathematical operations or functions can be + applied to an array using straightforward notation, like A + B + or sin(A). Expressions involving Array objects are themselves + Arrays. The operation A(d), where d is a domain object that + describes a subset of A's domain, creates a view of A that + refers to that subset of points. Like an array expression, a + view is also an Array. If d represents a single point in the + domain, this indexing operation returns a single value from the + range. Equivalently, one can index an N-dimensional Array by + specifying N indices, which collectively specify a single point + in the input domain: A(i1, i2, ..., iN). + + The &pooma; multidimensional Array concept is similar to + the &fortran; 90 array facility, but extends it in several + ways. Both &pooma; and &fortran; arrays can have up to seven + dimensions, and can serve as containers for arbitrary + types. Both support the notion of views of a portion of the + array, known as array sections in F90. The &pooma; Array concept + supports more complex domains, including bounded, continuous + (floating-point) domains. Furthermore, Array indexing in &pooma; + is polymorphic; that is, the indexing operation X(i1,i2) can + perform the mapping from domain to range in a variety of ways, + depending on the particular type of the Array being + indexed. + + &fortran; arrays are dense and the elements are arranged + according to column-major conventions. Therefore, X(i1,i2) + refers to element number i1-1+(i2-1)*numberRowsInA. However, as + Fig. 1 shows, &fortran;-style "Brick" storage is not the only + storage format of interest to scientific programmers. For + compatibility with C conventions, one might want to use an array + featuring dense, row-major storage (a C-style Brick). To save + memory, it might be advantageous to use an array that only + stores a single value if all its element values are the + same. Other sparse storage schemes that only store certain + values may also be desirable. To exploit parallelism, it is + convenient for an array's storage to be broken up into patches, + which can be processed independently by different CPUs. Finally, + one can imagine an array with no data at all. For example, the + values can be computed from an expression involving other + arrays, or analytically from the indices. + + + The &pooma; &array; Class Template + + Next we describe &pooma;'s model of the Array concept, the + Array class template. The three most important requirements from + the point of view of overall design are: (1) arbitrary domain, + (2) arbitrary range, and (3) polymorphic indexing. These express + themselves in the template parameters for the &pooma; Array + class. The template + + template <int Dim, class T = double, class EngineTag = Brick> + class Array; + + is a specification for creating a set of classes all named + Array. The template parameters Dim, T, and EngineTag determine + the precise type of the Array. Dim represents the dimension of + the array's domain. T gives the type of array elements, thereby + defining the output range of the array. EngineTag specifies the + the manner of indexing and types of the indices. + + End From + papers/GenericProgramming_CSE/dubois.html: + + Section 2, "Arrays and Engines," of + papers/iscope98.pdf describes both &array;s + and &engine;s. This may or may not duplicate the material in + papers/GenericProgramming_CSE/dubois.html. + +

+ Views of &array;s + + Section 3, "Domains and Views," of + papers/iscope98.pdf motivates the need for + views: +

+ One of the primary uses of domains is to specify + subsections of &array; objects. Subarrays are a common + feature of array classes; however, it is often difficult to + make such subarrays behave like first-class objects. The + &pooma; II engine concept provides a clean solution to + this problem: subsetting an &array; with a domain object + creates a new &array; that has a view engine. +

+ +

+ &field; + + QUESTION: Do we include boundary conditions here? + + FINISH: Do we have an example that shows something not possible + with &array;? + + Describe and illustrate multi-material and + multivalue? + + ADD: description of meshes and guard layers. + +

+ +

+ Engines + + (unformatted) From + papers/GenericProgramming_CSE/dubois.html: + + The Engine Concept + + To implement polymorphic indexing, the &array; class defers + data storage and data lookup to an &engine; object. The + requirements that the &array; template places on its &engine; + provide the definition for the &engine; concept. We'll describe + these by examining a simplified version of the &array; template, + shown in Fig. 2. + + First, the &array; class determines and exports (makes + Engine_t part of &array;'s public interface) the type of the engine + class that it will use: + + typedef Engine<Dim, T, EngineTag> Engine_t; + + This statement declares Engine_t to be an alias for the type + Engine<Dim,T,EngineTag>. This is the first requirement + placed on engine classes: they must be specializations of a + general Engine template whose template parameters are identical to + those of &array;. Next, the &array; template determines the type of + scalar arguments (indices) to be used in operator(), the function + that implements &pooma;'s &fortran;-style indexing syntax X(i1,i2): + + typedef typename Engine_t::Index_t Index_t; + + This statement defines another type alias: + Array<Dim,T,EngineTag>::Index_t is simply an alias for + Engine_t::Index_t. Engine_t::Index_t is a qualified name, which + means that the type Index_t is found in the class Engine_t. This + is the second requirement for the Engine concept: the class + Engine_t must define a public type called Index_t. This line will + not compile if that definition is not supplied. This indirection + is one of the ways that &pooma; supports polymorphic indexing. If + the Engine works with a discrete integer domain, it defines its + Index_t to be an integral type. If the Engine works in a + continuous domain, it defines its Index_t to be a floating-point + type. + + The data lookup is performed in the operator() function. We + see that &array; simply passes the indices on to its engine + object. Thus, we have the third requirement for the Engine + concept: it must provide a version of operator() that takes Dim + values of type Index_t. + + Simply passing the indices on to the engine object may seem + odd. After all, engine(i,j) looks like we're just indexing another + array. There are several advantages to this extra level of + indirection. The &array; class is as faithful a model of the &array; + concept as possible, while the Engine class is a low-level + interface to a user-defined data source. As a result, &array; has a + wide variety of constructors for user convenience, while engines + have but a few. &array; supports a wide variety of overloaded + operator() functions for view creation and indexing. Engines + support indexing only. &array; does not have direct access to the + data, which is managed by the engine object. Finally, &array; has a + wide variety of overloaded mathematical operators and functions, + and works with the Portable Expression Template Engine (PETE) [4] + to provide efficient evaluation of &array; expressions. Engines have + no such support. In general, &array; is much more complex and + feature-laden than Engine. This is the prime advantage of the + separation of interface and implementation: &array; only has to be + implemented once by the &pooma; developers. Engines are simple + enough to be written by users and plugged directly into the &array; + framework. + + Figure 3 illustrates the "Brick" specialization of the + Engine template, which implements &fortran;-style lookup into a + block of memory. First, there is the general Engine template, + which is empty as there is no default behavior for an unknown + EngineTag. The general template is therefore not a model for the + Engine concept and &array; classes attempting to use it will not + compile. Next, there is the definition of the Brick class, a + policy tag whose sole purpose is to select a particular + specialization of the Engine template. Finally, there is the + partial specialization of the Engine template. Examining its body, + we see the required Index_t typedef and the required operator(), + which follows the &fortran; prescription for generating an offset + into the data block based on the row, column, and the number of + rows. All of the requirements are met, so the Brick-Engine class + is a model of the Engine concept. + + End From + papers/GenericProgramming_CSE/dubois.html: + + (unformatted) From + papers/GenericProgramming_CSE/dubois.html: + + Compile-time Versus Run-Time Polymorphism + + Encapsulating the indexing in an Engine class has important + advantages, both in terms of flexibility and efficiency. To + illustrate this point, we introduce the PolarGaussian-Engine + specialization in Fig. 4. This is an analytic engine that + calculates its values directly from its inputs. Unlike the + Brick-Engine, this engine is "indexed" with data of the same type + as its output: it maps a set of T's to a single T. Therefore, the + Index_t typedef selects T as the index type, as opposed to the int + in the Brick-Engine specialization. The operator() function also + differs in that it computes the return value according to an + analytic formula. + + Both Engine<Dim,T,Brick> and + Engine<Dim,T,PolarGaussian> can be plugged in to an &array; by + simply varying the &array;'s EngineTag. This is possible despite the + fact that the two classes exhibit dramatically different behavior + because they are both models of the Engine concept. + + Notice that we have achieved polymorphic indexing without + the use of inheritance or virtual functions. For instance, + consider the following code snippet: + + Array<2, double, Brick> a; + Array<2, double, PolarGaussian> b; + + double x = a(2, 3); // x = a.engine.data[2 + 3 * a.engine.numRows]; + double y = b(2.0, 3.0); // y = exp(-(2.0*2.0+3.0*3.0) / b.engine.delta); + + The data lookup functions for the two &array;s perform completely + different operations. Since this is accomplished using static + types, it is known as compile-time polymorphism. Moreover, + everything is known at compile time, so the functions are fully + inlined and optimized, thereby yielding code equivalent to that + shown in the comments above. + + The flexibility and efficiency of compile-time polymorphism + cannot be duplicated with a run-time implementation. To illustrate + this point, in Fig. 5, we re-implement our &array; concept using the + classic Envelope-Letter pattern [5], with the array class, + RTArray, being the envelope and the run-time-engine, RTEngine, + being the letter. RTArray defers data lookup to the engine object + by invoking the engine's functions through a pointer to the + RTEngine base class. Figure 6 illustrates the RTEngine base class + and Fig. 7 illustrates two descendants: RTBrick and + RTPolarGaussian. + + The run-time implementation provides the same basic + functionality as the compile-time implementation, but it is not as + flexible or as efficient. It lacks flexibility in that the return + type of the indexing operation must be specified in the RTEngine + base class and in the RTArray class. Thus, in Figs. 5 and 6,we see + versions of RTArray::operator() and RTEngine::index functions that + take both int's and T's. If the programmer wants to add another + index-type option, these classes must be modified. This is a + violation of the open-closed principle proposed by Meyer + [6]. Also, since RTEngine descendants will usually only implement + one version of index, we cannot make RTEngine an abstract base + class. Instead, we have the default versions of index throw an + exception. Thus, compile-time error checking is + weakened. Furthermore, since indexing is done via a virtual + function call, it will almost never be inlined, which is not + acceptable in most scientific applications. + + There are advantages to the Envelope-Letter approach. First, + all RTArray objects have the same type, allowing them to be stored + in homogeneous collections. This can simplify the design of some + applications. Second, RTArray objects can change their engines at + runtime, and thus effectively change their types on the fly??this + is the primary reason for using the Envelope-Letter idiom, and can + be very important in some applications. + + For most scientific applications, however, these issues are + minor, and maximum performance for array indexing is of paramount + importance. Our compile-time approach achieves this performance + while providing the desired polymorphic indexing. + + From Section 4 of + papers/SiamOO98_paper.ps: + + The &array; class is templated on an &engine; type that + handles the actual implementation of the mapping from input to + output. Thus, the &array; interface features are completely + separate from the implementation, which could be a single &c; + array, a function of some kind or some other mechanism. This + flexibility allows an expression itself to be viewed through the + &array; interface. Thus, one can write something like + + foo(A*B+C); + where A, B and + C are &array;s and foo is + a function taking an &array; as an argument. The expression + A*B+C + will only be evaluated by the expression engine as needed by + foo. + + In fact, one can even write &engine;s which are wrappers + around external data structures created in non-&pooma; codes and + know to manipulate these structures. Once this is done, the + external entities have access to the entire &array; interface and + can utilize all of the powerful features of + &pooma; II. + + Section 2, "Arrays and Engines," of + papers/iscope98.pdf describes both &array;s + and &engine;s. This may or may not duplicate the material in + papers/GenericProgramming_CSE/dubois.html. + + Section 4, "Expressions and Evaluators", of + papers/iscope98.pdf has a good explanation of + &pooma; II's expression trees and expression engines. + + + &multipatch; Engine + From README: To actually use multiple + contexts effectively, you need to use the MultiPatch engine with + patch engines that are Remote engines. Then the data will be + distributed across multiple contexts instead of being copied on + every context. See the files in example/Doof2d for a simple + example that creates a MultiPatch array that can be distributed + across multiple contexts and performs a stencil computation on + that array. + + +

+ +

+ + ]]> + + + + Writing Distributed Programs + + Discuss the distributed model and guard cells. See docs/parallelism.html. + + Does any of the parallel implementation described in + papers/SCPaper-95.html still apply? + + ?Tuning program for maximize parallel performance? + + external references to &mpi; and threads + + QUESTION: Are there interesting, short parallel programs in + any &mpi; book that we can convert to &pooma;? + +

+ Layouts + + An out-of-date description can be found in Section 3.3, + especially 3.3.2, of papers/pooma.ps + describes the global/local interactions and parallel abstraction + layers. +

+ +

+ Parallel Communication + + An out-of-date description can be found in + Section 3.3.3 of papers/pooma.ps +

+ +

+ Using Threads + + QUESTION: Where do threads fit into the manual? Do threads + even work? + + From Section 4, of + papers/SiamOO98_paper.ps + + &pooma; II will make use of a new parallel run-time + system called &smarts; that is under development at the ACL. + &smarts; supports lightweight threads, so the evaluator will be + able to farm out data communication tasks and the evaluation of + subsets of an expression to multiple threads, thus increasing the + overlap of communication and computation. Threads will also be + available at the user level for situations in which a + task-parallel approach is deemed appropriate. +

+ + + ]]> + + + + Debugging and Profiling &pooma; Programs + + Consider &dashdash;pooma-debug number. + See also other &pooma; options in src/Utilities/Options.h. + + UNFINISHED +

+ Finding Race Conditions From Missing + <function>blockAndEvaluate</function> Calls + + &pooma; may reorder computations so calls to + Pooma::blockAndEvaluate() are necessary + before accessing particular &array; and &field; values. + Omission of necessary calls can lead to race conditions where + the ordering of reads and writes to particular values is + incorrect. To help diagnose if calls to + Pooma::blockAndEvaluate are missing, invoke + a &pooma; executable with the + &dashdash;pooma-blocking-expressions option. + This automatically causes + Pooma::blockAndEvaluate to be called after + each statement. Doing so ensures program correctness, but it + may increase running times, particularly if multiple processors + are used, because computation and communication may not overlap + as much as possible. Of course, program correctness is more + important than execution speed. + + If using + &dashdash;pooma-blocking-expressions changes a + program's output, it is missing one or more calls to + Pooma::blockAndEvaluate. To narrow the + region with a missing call, surround the region in question with + calls to Pooma::blockingExpressions(true) + and Pooma::blockingExpressions(false), + but do not use the + &dashdash;pooma-blocking-expressions option. + Within the region, Pooma::blockAndEvaluate + will be invoked after each statement. Repeatedly reducing the + region's size should reveal where calls are missing. +

+ + ]]> + + + + ]]> + + + &pooma; Reference Manual + + + TMP: This Chapter Holds These Comments But Will Be Removed + + For each template parameter need to describe the constraints + on it. + + Remove this section when the following concerns have been + addressed. + + Add a partintro explaining file suffixes such as .h, .cpp, .cmpl.cpp, .mk, .conf. Should we also explain use + of inline even when necessary and the template + model, e.g., including .cpp files. + + QUESTION: What are the key concepts around which to organize + the manual? + + QUESTION: What format should the manual use? + +

+ Musser, Derge, and Sanai, §20.0. + It is important to state the requirements on the components + as generally as possible. For example, instead of saying + class X must define a member function + operator++(), we say for any + object x of type X, + ++x is defined. +

+ + + + + A Typical &pooma; Class + + + Class Member Notation + + + *_t + + + + type within a class. QUESTION: What is the &cc; name for + this? + + + + + *_m + + + + data member + + + + + + &pooma; Class Vocabulary + + component + + one of several values packaged together. For example, a + three-dimensional vector has three components, i.e., three + values. + + + + element-wise + + applied to each element in the group, e.g., an array + + + + reduction + + repeated application of a binary operator to all elements, + yielding one value + + + + tag + + an enumerated value indicating inclusion in a particular + semantic class. The set of values need not be explicitly + declared. + + + + + + + + + Installing and Configuring &pooma; + + + + Installing &pooma;. + + + Requirements for configuration files. + + + + Include descriptions of using &smarts;, &cheetah;, τ, + &pdt;. + + QUESTION: Does it install on windows and on mac? If so, what + are the instructions? See also INSTALL.{mac,unix,windows}. + + README has some + information on &cheetah; and threads in the Message-Based + Parallelism section. + + Which additional packages are necessary and when? + + What configure options should we list? See configure. Be sure to list + debugging option and how its output relates to config/LINUXgcc.suite.mk. + + config/arch has files + for (OS, compiler) pairs. Explain how to modify a configuration + file. List requirements when making a new configuration file (low + priority). + + config/LINUXgcc.suite.mk has output + from configure. Useful to + relate to configuration files and configure's debugging output. + + + + + + Compilation and &make; Files + + We assume Gnu make. Do we know what assumptions are made? + + How do all these files interact with each other? Ala a make + interpreter, give an example of which files are read and + when. + + + config/Shared/README.make + This has short descriptions of many files, + especially in config/Shared. + + makefile + These appear throughout all directories. What are + the equivalences classes and what are their + parts? + + include.mk + What does this do? Occurs in many directories: + when? Template seems to be config/Shared/include2.mk. + + subdir.mk + list of subdirectories; occurs in several + directories: when? src/subdir.mk is a good + example. + + + objfile.mk + + list of object files to construct, presumably from + *.cmpl.cpp files. + src/Utilities/objfile.mk is an + example. + + + config/Shared/rules.mk + most compiler rules + + config/head.mk + read at beginning of each + makefile? + + config/Shared/tail.mk + read at end of each makefile? + + config/Shared/variables.mk + Is this used? + + config/Shared/compilerules.mk + table of origin and target suffixes and commands + for conversion + + + + + + + + + &array;s + + Include src/Pooma/Arrays.h to use &array;s. + The implementation source code is in src/Array. + + FINISH: Define an array. Introduce its parts. + + ADD: some mention of the maximum supported number of + dimensions somewhere. + +

+ The &array; Container + + + Template Parameters + + + + + Parameter + Interpretation + + + + + Dim + dimension + + + T + array element type + + + EngineTag + type of computation engine object + + + +

+ + QUESTION: How do I introduce class type definitions, when + they are used, i.e., compile-time or run-time, and when + programmers should use them? + + + Compile-Time Types and Values + + + + + Type or Value + Interpretation + + + + + This_t + the &array; object's type + + + Engine_t + the &array; object's engine's type + + + EngineTag_t + indication of engine's category + + + Element_t + the type of the array elements, i.e., T + + + ElementRef_t + the type of a reference to an array element, + i.e., T&. Equivalently, the type to write to a + single element. + + + Domain_t + the array's domain's type, i.e., the type of the + union of all array indices + + + Layout_t + unknown + + + dimensions + integer equalling the number of dimensions, i.e., + Dim + + + rank + integer equalling the number of dimensions, i.e., + Dim; a synonym for + dimensions + + + +

+ +

+ Constructors and Destructors + + + Constructors and Destructors + + + + + Function + Effect + + + + + + + Array + + + + Creates an array that will be resized + later. + + + + + Array + const Engine_t& + engine + + + Creates an array with an engine equivalent to + the engine. This array will have the + same values as engine. QUESTION: Why + would a user every want to use this + constructor? + + + + + Array + + const + Engine<Dim2, T2, EngineTag2>& + engine + + + const + Initializer& init + + + + What does this do? + + + ADD ALL CONSTRUCTORS AND DESTRUCTORS. + + + +

+ + +

+ Initializers + + Add a table. +

+ + +

+ Element Access + + + &array; Element Access + + + + + Function + Effect + + + + + + + Element_t read + + + + unknown: See line 1839. + + + + + Element_t read + + const + Sub1& s1 + + + const + Sub2& s2 + + + + How does the version with template parameters, + e.g., Sub1 differ from the int + version? + + + + + Element_t operator() + + const + Sub1& s1 + + + const + Sub2& s2 + + + + How does this differ from read(const + Sub1& s1, const Sub2& s2)? + + + ADD ALL reads and + operator()s. + + + +

+ + +

+ Component Access + + When an array stores elements having components, e.g., an + array of vectors, tensors, or arrays, the + comp returns an array consisting of the + specified components. The original and component array share the + same engine so changing the values in one affects values in the + other. + + For example, if &n; × &n; array a + consists of three-dimensional real-valued vectors, + a.comp(1) returns a &n; × &n; + real-valued array of all the middle vector components. Assigning + to the component array will also modify the middle components of + the vectors in a. + + + &array; Component Access + + + + + Function + Effect + + + + + + + UNKNOWN compute this comp + + const + int& + i1 + + + + unknown: See line 1989. + + + ADD ALL comps. + + + +

+ +

+ Accessors + + + &array; Accessor Methods + + + + + Function + Effect + + + + + + + int first + + int + d + + + + unknown: See line 2050 + + + ADD ALL other accessor methods, including + engine. + + + +

+ + +

+ Copying &array;s + + Explain how copied arrays and views of arrays share the + same underlying engine so changing values in one also affects the + other. This is called a shallow copy. +

+ + +

+ Utility Methods + + + &array; Utility Methods + + + + + Function + Effect + + + + + + + void makeOwnCopy + + + + unknown: See line 2044 + + + ADD ALL other utility methods. + + + +

+ + +

+ Implementation Details + + As a container, an &array;'s implementation is quite + simple. Its privatedata consists of + an engine, and it has no private + functions. + + + &array; Implementation Data + + + + + Data Member + Meaning + + + + + + + private + Engine_t engine_m + + + engine computing the array's values + + + +

+ +

+ + +

+ &dynamicarray;s: Dynamically-Sized Domains + + A DynamicArray is a read-write array with extra + create/destroy methods. It can act just like a regular Array, but + can have a dynamically-changing domain. See src/DynamicArray/DynamicArray.h. + + ADD: Briefly describe what the class does and an example of + where it is used. + + ADD: Check that its interface is actually the same as for + &array;. + + ADD: Check that the operations on dynamic arrays are + actually the same as for &array;. See src/DynamicArray/DynamicArrayOperators.h, + src/DynamicArray/PoomaDynamicArrayOperators.h, + and src/DynamicArray/VectorDynamicArrayOperators.h. + + +

+ Implementation Details + + DynamicArray has no + protected or + private members. +

+ + +

+ Views of &array;s + + UNFINISHED +

+ + +

+ &array; Assignments + + &pooma; supports assignments to &array;s of other &array;s + and scalar values. QUESTION: Is the following correct? For the + former, the right-hand side array's domain must be at least as + large as the left-hand side array's domain. Corresponding values + are copied. Assigning a scalar value to an array ensures all the + array elements have the same scalar value. + + UNFINISHED: Add a table containing assignment operators + found one lines 2097–2202. +

+ + +

+ Printing &array;s + + &array;s support output to but not input from IO streams. + In particular, output to ostreams and file streams is + supported. + + Add a table, using src/Array/Array.h, lines + 2408–2421. See the implementation in src/Array/PrintArray.h. + + QUESTION: How does one print a &dynamicarray;. +

+ + +

+ Expressions Involving &array;s + + In &pooma;, expressions may contain entire &array;s. That + is, &array;s are first-class objects with respect to expressions. + For example, given &array;s a and + b, the expression a + b + is equivalent to an array containing the element-wise sum of the + two arrays. + + Any finite number of the operators listed below can be used + in an expression. The precedence and order of operation is the + same as with ordinary built-in types. + + QUESTION: Do &field;s also support the same set of + operations? + + QUESTION: Some operations in src/Field/FieldOperators.h use both + &array; and &field;. Do we list them here or in the &field; + section or both or somewhere else? + + In the table below, &array; supplants the exact return types + because they are complicated and rarely need to be explicitly + written down. + + + Operators on &array; + + + + + Operator + Value + + + + + + + + Array acos + const Array<Dim,T,EngineTag>& a + + + + an array containing the element-wise inverse + cosine of the array a + + + ADD ALL other operators appearing in src/Array/ArrayOperators.h, + src/Array/ArrayOperatorSpecializations.h, + src/Array/PoomaArrayOperators.h, + and src/Array/VectorArrayOperators.h. + + + +

+ + FINISH: Write one or two examples or refer to ones + previously in the text. +

+ + +

+ Reducing All &array; Elements to One Value + + These reduction functions repeatedly apply a binary + operation to all array elements to yield a value. These functions + are similar to the Standard Template Library's + accumulate function. For example, + sum repeatedly applies the binary plus + operator to all array elements, yielding the sum of all array + elements. + + FINISH: What order of operation, if any, is + guaranteed? + + FINISH: Add a table of the functions in src/Array/Reductions.h. + + How does one use one's own binary function? See src/Engine/Reduction.h. +

+ + +

+ Utility Functions + +

+ Compressed Data + + Add a table containing + elementsCompressed, + compressed, compress, + and uncompress. +

+ + +

+ Centering Sizes and Number of Materials + + ADD: a description of numMaterials and + centeringSize found in src/Field/Field.h. These functions + are meaningless for &array; but are provided for consistency with + &field;. +

+ +

+ Obtaining Subfields + + ADD: a description of subField found + in src/Field/Field.h. + This function, meaningless for &array;, is provided for + consistency with &field;. +

+ + +

+ TMP: What do we do with these …? Remove this + section. + +

+ introduction.html + + &pooma; was designed and implemented by scientists working + at the Los Alamos National Laboratory's Advanced Computing + Laboratory. Between them, these scientists have written and tuned + large applications on almost every commercial and experimental + supercomputer built in the last two decades. As the technology + used in those machines migrates down into departmental computing + servers and desktop multiprocessors, &pooma; is a vehicle for its + designers' experience to migrate as well. In particular, + &pooma;'s authors understand how to get good performance out of + modern architectures, with their many processors and multi-level + memory hierarchies, and how to handle the subtly complex problems + that arise in real-world applications. +

+ + QUESTION: Do we describe the &leaffunctor;s specialized for + &array;s in src/Array/Array.h or in the &pete; + reference section? What about the functions in src/Array/CreateLeaf.h? + + QUESTION: What is an EngineFunctor? We + probably should describe it in an analogous way as for + &leaffunctor;s. + + QUESTION: Where do we write about + ExpressionTraits for &array;s? + + QUESTION: Do we describe the ElementProperties + specialization at this place or in its section? + + QUESTION: Do we describe the Patch + specialization for &array;s (src/Array/Array.h:1300) in this + place or in a section for patches? +

+ + + + + &field;s + + An &array; is a set of values indexed by + coordinates, one value per coordinate. It models the computer + science idea of an array. Similarly, a &field; is a set of values + indexed by coordinate. It models the mathematical and physical + idea of a field represented by a grid of rectangular cells, each + having at least one value. A &field;'s functionality is a superset + of an &array;'s functionality because: + + + A &field; is distributed through space so one can compute + the distances between cells. + + + Each cell can hold multiple values. For example, a + rectangular cell can have one value on each of its faces. + + + Multiple materials can share the same cell. For example, + different values can be stored in the same cell for carbon, + oxygen, and nitrogen. + + + Also, &field;s' values can be related by relations. Thus, if one + field's values change, a dependent field's values can be + automatically computed when needed. FIXME: See also the unfinished + works chapter's entry concerning relations and arrays. + + QUESTION: Should we add a picture comparing and contrasting + an array and a field? + + QUESTION: How much structure can be copied from the &array; + chapter? + + QUESTION: Where is NewMeshTag, defined in + src/Field/Field.h, + used? + + QUESTION: Do we describe the &leaffunctor;s specialized for + &field;s in src/Field/Field.h or in the &pete; + reference section? Use the same decision for &array;s. + + QUESTION: What do the structure and functions in src/Field/Mesh/PositionFunctions.h + do? + + +

+ The &field; Container + + ADD: table of template parameters and table of compile-time + types and values. + + +

+ Constructors and Destructors + + ADD: this section similar to &array;s's constructor and + destructor section. +

+ +

+ Initializers + + Add a table. +

+ + +

+ Element Access + + ADD: a table ala &array;. Be sure to include + all. +

+ + +

+ Component Access + + ADD: a table ala &array;. +

+ + +

+ Obtaining Subfields + + ADD: discussion and a table listing ways to obtain + subfields. Although the implementation may treat subfield views + and other field views similarly (?Is this true?), they are + conceptually different ideas so we present them + separately. + + See src/Field/Field.h's + operator[], + subField, …, + material. +

+ + +

+ Supporting Relations + + ADD: a table with the member functions including + addRelation, + removeRelations, + applyRelations, and + setDirty. +

+ + +

+ Accessors + + ADD: a table using lines like src/Field/Field.h:1243–1333. +

+ + +

+ Utility Methods + + ADD: a table including + makeOwnCopy. +

+ + +

+ Implementation Details + + ADD: a table similar to &array;'s. + +

+ +

+ + +

+ Views of &field;s + + Be sure to relate to &array; views. Note only three + dimensions are supported. + + Be sure to describe f[i]. Does this + refer to a particular material or a particular value within a + cell? I do not remember. See SubFieldView in + src/Field/Field.h. +

+ + +

+ &field; Assignments + + ADD: Describe supported assignments, relating to &array;'s + assignments. + + UNFINISHED: Add a table containing assignment operators + found on src/Field/Field.h:2097–2202 + and 1512–1611. +

+ + +

+ Printing &field;s + + QUESTION: How similar is this to printing &array;s? + + &field;s support output to but not input from IO streams. + In particular, output to ostreams and file streams is + supported. + + Add a table, using src/Field/Field.h, lines + 1996–2009. See the implementation in src/Field/PrintField.h. +

+ + +

+ Combining &field; Elements + + Like &array;s, &field;s support reduction of all elements to + one value. Additionally, the latter supports computing a field's + values using field stencils. QUESTION: How do I describe this + with a minimum of jargon? + + ADD: something similar to &array; reductions. + + FINISH: Add a table of the functions in src/Field/FieldReductions.h. + + FINISH: Add a table of the functions in src/Field/DiffOps/FieldOffsetReductions.h. + QUESTION: Why is only sum defined? +

+ + +

+ Expressions Involving &field;s + + Do something similar to &array;'s section. See the + operations defined in src/Field/FieldOperators.h, + src/Field/FieldOperatorSpecializations.h, + src/Field/PoomaFieldOperators.h, and + src/Field/VectorFieldOperators.h. + + Some operations involve both &array; and &field; + parameters. Where do we list them? +

+ + +

+ &field; Stencils: Faster, Local Computations + + ADD: a description of a stencil. Why is it needed? How + does a user use it? How does a user know when to use one? Add + documentation of the material from src/Field/DiffOps/FieldStencil.h. + + How is FieldShiftEngine used by &field; + stencils? Should it be described here or in the &engine; section? + See the the code in src/Field/DiffOps/FieldShiftEngine.h. +

+ + +

+ Cell Volumes, Face Areas, Edge Lengths, Normals + + ADD: a description of these functions. See src/Field/Mesh/MeshFunctions.h. + These are initialized in, e.g., src/Field/Mesh/UniformRectilinearMesh.h. + Note that these do not work for NoMesh. +

+ + +

+ Divergence Operators + + ADD: a table having divergence operators, explaining the + current restrictions imposed by what is implemented. See + src/Field/DiffOps/Div.h + and src/Field/DiffOps/Div.UR.h. What + restrictions does UR (mesh) connote? +

+ + +

+ Utility Functions + +

+ Compressed Data + + Add a table containing + elementsCompressed, + compressed, compress, + and uncompress. +

+ + +

+ Centering Sizes and Number of Materials + + ADD: a description of numMaterials and + centeringSize found in src/Field/Field.h. + + QUESTION: How do these relate to any method functions? +

+ + +

+ Obtaining Subfields + + ADD: a description of subField found + in src/Field/Field.h. +

+ +

+ + +

+ &field; Centerings + + DO: Describe the purpose of a centering and its definition. + Describe the ability to obtain canonical centerings. Explain how + to construct a unique centering. See src/Field/FieldDentering.h. +

+ + +

+ Relative &field; Positions + + Permit specifying field positions relative to a field + location. Describe FieldOffset and + FieldOffsetList. See src/Field/FieldOffset.h +

+ + +

+ Computing Close-by Field Positions + + Given a field location, return the set of field locations + that are closest using ?Manhattan? distance. See src/Field/NearestNeighbors.h. +

+ + +

+ Mesh ??? + + Unlike &array;s, &field;s are distributed throughout space + so distances between values within the &field can be computed. A + &field;'s mesh stores this spatial distribution. + + QUESTION: What do we need to write about meshes? What is + unimportant implementation and what should be described in this + reference section? + + QUESTION: Where in here should emphasize vertex, not cell, + positions? VERTEX appears repeatedly in src/Field/Mesh/NoMesh.h. + + + Mesh Types + + + + + Mesh Type + Description + + + + + NoMesh<Dim> + no physical spacing, causing a &field; to mimic + an &array; with multiple engines. + + + UniformRectilinearMesh<Dim,T> + physical spacing formed by the Cartesian product + of ????. + + + +

+ + +

+ Mesh Accessors + + ADD: a table listing accessors, explaining the difference + between (physical and total) and (cell and vertex) domains. See + src/Field/Mesh/NoMesh.h. + Also, include spacings and + origin in src/Field/Mesh/UniformRectilinearMesh.h. + Note NoMesh does not provide the latter two. +

+ +

+ + +

+ TMP: What do we do with these …? Remove this + section. + + QUESTION: Do we describe the Patch + specialization for &field; at this place or in some common place? + Follow &array;'s lead. + + QUESTION: Where do we describe CreateLeaf and + MakeFieldReturn in src/Field/FieldCreateLeaf.h and + src/Field/FieldMakeReturn.h. + + QUESTION: What do we do with FieldEnginePatch + in src/Field/FieldEngine/FieldEnginePatch.h. +

+ + + + + &engine;s + + From a user's point of view, a container makes data available + for reading and writing. In fact, the container's &engine; stores + the data or, if the data is computed, performs a computation to + yield the data. + + FINISH: Introduce the various types of engines. Add a table + with a short description of each engine type. + + FINISH: First, we specify a generic &engine;'s interface. + Then, we present &engine; specializations. + + + Types of &engine;s + + + + + Engine Type + Engine Tag + Description + + + + + Brick + Brick + Explicitly store all elements in, e.g., a &cc; + array. + + + Compressible + CompressibleBrick + If all values are the same, use constant storage + for that single value. Otherwise, explicitly store all + elements. + + + Constant + ConstantFunction + Returns the same constant value for all + indices. + + + Dynamic + Dynamic + Manages a contiguous, local, one-dimensional, + dynamically resizable block of data. + + + Component Forwarding + CompFwd<EngineTag, + Components> + Returns the specified components from + EngineTag's engine. Components are + pieces of multi-value elements such as vectors + and tensors. + + + Expression + ExpressionTag<Expr> + Returns the value of the specified &pete; + expression. + + + Index Function + IndexFunction<Functor> + Makes the function + Functoraccepting indices mimic an + array. + + + MultiPatch + MultiPatch<LayoutTag,PatchTag> + Support distributed computation using several + processors (???contexts???). LayoutTag + indicates how the entire array is distributed among the + processors. Each processor uses a PatchTag + engine. + + + Remote + Remote<EngineTag> + unknown + + + Remote Dynamic + Remote<Dynamic> + unknown: specialization + + + Stencil + StencilEngine<Function, + Expression> + Returns values computed by applying the + user-specified function to sets of contiguous values in the + given engine or container. Compare with user function + engines. + + + User Function + UserFunctionEngine<UserFunction,Expression> + Returns values computed by applying the + user-specified function to the given engine or container. + QUESTION: Is the following claim correct? For each returned + value, only one value from the engine or container is + used. + + + +

+ + QUESTION: Where do we describe views? + + QUESTION: What does NewEngine do? Should it be + described when describing views? Should it be omitted as an + implementation detail? + + QUESTION: Where do we describe &engine; patches found in + src/Engine/EnginePatch.h? + All patch data in a separate chapter or engine-specific pieces in + this chapter? + + QUESTION: What is notifyEngineWrite? + See also src/Engine/NotifyEngineWrite.h. + + QUESTION: What aspect of MultiPatch uses IsValid in + src/Engine/IsValidLocation.h? + + QUESTION: Who uses intersections? Where should this be + described? See src/Engine/Intersector.h, src/Engine/IntersectEngine.h, and + src/Engine/ViewEngine.h. + +

+ &engine; Compile-Time Interface + + ADD: a table of template parameters ala &array;. ADD: + compile-time types and values. +

+ + +

+ Constructors and Destructors + + ADD: a table of constructors and destructors ala + &array;'s. +

+ + +

+ Element Access + + ADD: a table with read and + operator(). +

+ + +

+ Accessors + + ADD: a table of accessors. +

+ + +

+ &engine; Assignments + + similar to &array;'s assignments. shallow copies. ADD: a + table with one entry +

+ + +

+ Utility Methods + + ADD: a table including + makeOwnCopy. + + QUESTION: What are dataObject, + isShared, and related methods? +

+ + +

+ Implementation Details + + ADD: this section. Explain that + dataBlock_m and data_m point + to the same place. The latter speeds access, but what is the + purpose of the former? +

+ + +

+ Brick and BrickView Engines + + ADD: description of what a brick means. ADD: whatever + specializations the class has, e.g., + offset. + + QUESTION: What does DoubleSliceHelper do? +

+ + +

+ Compressible Brick and BrickView Engines + + ADD this. +

+ + +

+ Dynamic and DynamicView Engines: + + ADD this. Manages a contiguous, local, resizable, 1D block + of data. +

+ + +

+ Component Engines + + I believe these implement array component-forwarding. See + src/Engine/ForwardingEngine.h. +

+ + +

+ Expression Engines + + Should this be described in the &pete; section? Unlikely. + See src/Engine/ExpressionEngine.h. +

+ + +

+ &engine; Functors + + QUESTION: What is an EngineFunctor? Should it + have its own section? See src/Engine/EngineFunctor.h. +

+ + +

+ <type>FieldEngine</type>: A Hierarchy of &engine;s + + A &field; consists of a hierarchy of materials and + centerings. These are implemented using a hierarchy of engines. + See src/Field/FieldEngine/FieldEngine.h + and src/Field/FieldEngine/FieldEngine.ExprEngine.h. +

+ + + + + &benchmark; Programs + + Explain how to use &benchmark; programs, especially the + options. Explain how to write a &benchmark; program. See also + src/Utilities/Benchmark.h + and src/Utilities/Benchmark.cmpl.cpp. + + + + + + Layouts and Partitions: Distribute Computation Among + Contexts + + What is the difference between ReplicatedTag and + DistributedTag? + + + + + + &pete;: Evaluating Parallel Expressions + +

+ UNKNOWN + +

+ Leaf Tag Classes + + NotifyPreReadTag indicates a term is about to + be read. Why is this needed? Defined in src/Utilities/NotifyPreRead.h. +

+ + + + + + Views + + QUESTION: Should this have its own chapter or be part of a + container chapter? + + Describe View0, View1, …, + View7 and View1Implementation. + + QUESTION: What causes the need for AltView0 and + AltComponentView? + + Be sure to describe ComponentView in the same + place. This is specialized for &array;s in src/Array/Array.h:1323–1382. + +

+ <type>ViewIndexer<Dim,Dim2></type> + + Defined in src/Utilities/ViewIndexer.h, this + type translates indices between a domain and a view of it. +

+ + + + Threads + + Perhaps include information in src/Engine/DataObject.h. + + &pooma; options include UNFINISHED + + + + + + Utility Types + + TMP: What is a good order? + +

+ <type>Options</type>: Varying Run-Time Execution + + Each &pooma; executable has a Options object, + created by Pooma::initialize, storing + run-time configurable values found in argv. + Default options are found in + Options::usage. + + See src/Utilities/Options.h and + src/Utilities/Options.cmpl.cpp. + + Scatter the specific options to other parts of the + manual. +

+ +

+ Check Correctness: <type>CTAssert</type>, + <type>PAssert</type>, <type>PInsist</type>, + <type>SameType</type> + + Assertions ensure program invariants are obeyed. + CTAssert, checked at compile time, incur no run-time + cost. PAssert and PInsist are checked + to run-time, the latter producing an explanatory message if the + assertion fails. Compiling with NOCTAssert and + NOPTAssert disable these checks. Compiling with just + NOPTAssert disables only the run-time checks. + + SameType ensures, at compile-time, two types + are the same. + + These are implemented in src/Utilities/PAssert.h and + src/Utilities/PAssert.cmpl.cpp. +

+ +

+ <type>Clock</type>: Measuring a Program's Execution Time + + See src/Utilities/Clock.h. +

+ + +

+ Smart Pointers: <type>RefCountedPtr</type>, + <type>RefCountedBlockPtr</type>, and + <type>DataBlockPtr</type> + + See src/Utilities/{RefCountedPtr,RefCountedBlockPtr,DataBlockPtr}.h. + src/Utilities/RefCounted.h + helps implement it. DataBlockPtr uses + &smarts;. +

+ +

+ <type>Inform</type>: Formatted Output for Multi-context + Execution + + See src/Utilities/Inform.h and src/Utilities/Inform.cmpl.cpp. +

+ +

+ <type>Statistics</type>: Report &pooma; Execution Statistics + + Collect and print execution statistics. Defined in + src/Utilities/Statistics.h. +

+ +

+ Random Numbers: <type>Unique</type> + + See src/Utilities/Unique.h. +

+ + + + + Types for Implementing &pooma; + + TMP: What is a good order? + + Describe types defined to implement &pooma; but that users do + not directly use. This chapter has lower priority than other + chapters since users (hopefully) do not need to know about these + classes. + +

+ <type>Tester</type>: Check Implementation Correctness + + &pooma; implementation test programs frequently consist of a + series of operations followed by correctness checks. The + Tester object supports these tests, returning a + boolean whether all the correctness checks yield true. Under + verbose output, messages are printed for each test. See src/Utilities/Tester.h. +

+ +

+ <type>ElementProperties<T></type>: Properties a Type + Supports + + This traits class permits optimizations in other templated + classes. See src/Utilities/ElementProperties.h. + +

+ +

+ <type>TypeInfo<T></type>: Print a String Describing + the Type + + Print a string describing the type. Defined in src/Utilities/TypeInfo.h. It is + specialized for other types in other files, e.g., src/Engine/EngineTypeInfo.h and + src/Field/FieldTypeInfo.h. + Is this a compile-time version of RTTI? +

+ +

+ <type>LoopUtils</type>: Loop Computations at Compile Time + + At compile time, LoopUtils supports copying + between arrays and computing the dot product of arrays. See + src/Utilities/MetaProg.h. +

+ +

+ <type>ModelElement<T></type>: Wrap a Type + + A wrapper class used to differentiate overloaded functions. + Defined in src/Utilities/ModelElement.h. Used + only by &array; and DynamicArray. +

+ +

+ <type>WrappedInt<int></type>: Wrap a Number + + A wrapper class used to differentiate overloaded functions + among different integers. Defined in src/Utilities/WrappedInt.h. Is this + class deprecated? Is it even necessary? +

+ +

+ Supporting Empty Classes + + The NoInit tag class indicates certain + initializations should be skipped. Defined in src/Utilities/NoInit.h. + + FIXME: Should be macro, not function. + POOMA_PURIFY_CONSTRUCTORS generates an empty + constructor, copy constructor, and destructor to avoid &purify; + warnings. Defined in src/Utilities/PurifyConstructors.h. + +

+ +

+ <type>Pooled<T></type>: Fast Memory Allocation of + Small Blocks + + Pooled<T> speeds allocation and + deallocation of memory blocks for small objects with + type T. Defined in src/Utilities/Pooled.h, it is + implemented in src/Utilities/Pool.h and src/Utilities/Pool.cmpl.cpp. + src/Utilities/StaticPool.h + no longer seems to be used. +

+ +

+ <type>UninitializedVector<T,Dim></type>: Create + Without Initializing + + This class optimizes creation of an array of objects by + avoiding running the default constructors. Later initialization + can occur, perhaps using a loop that can be unrolled. Defined in + src/Utilities/UninitializedVector.h, + this is used only by DomainTraits. +

+ + + + Algorithms for Implementing &pooma; + + In src/Utilities/algorithms.h, + copy, delete_back, and + delete_shiftup provide additional algorithms + using iterators. + + + + + TMP: Where do we describe these files? + + + + src/Utilities/Conform.h: tag for + checking whether terms in expression have conforming + domains + + + + src/Utilities/DerefIterator.h: + DerefIterator<T> and + ConstDerefIterator<T> automatically + dereference themselves to maintain const + correctness. + + + + src/Utilities/Observable.h, + src/Utilities/Observer.h, + and src/Utilities/ObserverEvent.h: + Observable<T>, + SingleObserveable<T>, + Observer<T>, and ObserverEvent + implement the observer pattern. What is the observer pattern? + Where is this used in the code? + + + + + + + + TMP: Items to Discuss in Reference Manual + + + + Discuss &options; and related material. Add developer + command-line options listed in Utilities/Options.cmpl.cpp and also + possibly &dashdash;pooma-threads + n. + + + + + ]]> + + + + Future Development + +

+ Particles + + docs/ParticlesDoc.txt has + out-of-date information. + + See Section 3.2.3 of + papers/pooma.ps for an out-of-date + description. + + papers/jvwr.ps concerns mainly + particles. papers/8thSIAMPOOMAParticles.pdf, + by Julian Cummings and Bill Humphrey, concerns parallel particle + simulations. papers/iscope98linac.pdf + describes a particle beam simulation using &pooma;; it mainly + concerns particles. + +

+ Particles + + Do we want to include such a section? + + Section 3, "Sample Applications" of + papers/SiamOO98_paper.ps describes porting a + particle program written using High-Performance &fortran; to + &pooma; and presumably why particles were added to &pooma;. It + also describes MC++, a Monte Carlo + neutron transport code. + +

+ +

+ + +

+ Composition of &engine;s + + The i,j-th element of the composition + a∘b of two arrays + a and b equals a(b(i,j)). + The composition engine tagged IndirectionTag<Array1, + Array2>, defined in src/Engine/IndirectionEngine.h is + unfinished. +

+ + +

+ Improving Consistency of Container Interfaces + +

+ Relations for &array;s + + Do &array;s currently support relations? If not, why not? + Should they be added? +

+ +

+ Supporting the Same Number of Dimensions + + &array; and &field; should support the same maximum number + of dimensions. Currently, &array;s support seven dimensions and + &field;s support only three. By definition, &dynamicarray; + supports only one dimension. + + Relations for &array;s. + + External guards for &array;s. + + QUESTION: What is tiny about &matrix;? Should + they be renamed? +

+ +

+ + +

+ <function>where</function> Proxies + + QUESTION: Do we even discuss this broken + feature? Where is it used? Some related code is in + src/Array/Array.h:2511–2520. +

+ + +

+ Easing Input for Distributed Programs + + Currently, standard input to distributed programs is not + supported. Instead input can be passed via command-line arguments, + which are replicated to each context. &inform; streams support for + input could be added. For context 0, standard input could be + used. Other contexts would use a RemoteProxy to + distribute the value to the other contests. See src/Engine/RemoteEngine.h for example + uses of RemoteProxy. +

+ + +

+ Improving Consistency Between &pooma; and &cheetah; + + Improve the consistency between &cheetah;'s and &pooma;'s + configurations. Currently, their defaults differ regarding + &cc; exceptions and static/shared libraries. +

+ + +

+ Very Long Term Development Ideas + + Describe how to write a new configuration file. +

+ + + ]]> + + + + Obtaining and Installing &pooma; + + In , we described + how to install &pooma;. In the following section, we describe how + to install &pooma; to support distributed computation. + ]]> + + ADD: Write this section, including extensive instructions + for Unix-like, MS Windows, and MacOS. List the configuration options. + Be sure to describe configuring for parallel execution. + ]]> + +

+ Supporting Distributed Computation + + To use multiple processors with &pooma; requires installing + the &cheetah; messaging library and an underlying messaging library + such as the Message Passing Interface (&mpi;) Communications + Library or the &mm; Shared Memory Library. In the following + section, we first describe how to install &mm;. Read it only if + using &mm;, not &mpi;. Then we describe how to install &cheetah; + and configure &pooma; to use it. + +

+ Obtaining and Installing the &mm; Shared Memory Library + + &cheetah;, and thus &pooma;, can use Ralf Engelschall's &mm; + Shared Memory Library to pass messages between processors. For + example, the &author; uses this library on a two-processor + computer running &linux;. The library, available at http://www.engelschall.com/sw/mm/, + is available at no cost and has been successfully tested on a + variety of Unix-like platforms. + + We describe how to download and install the &mm; library. + + + Download the library from the &pooma; Download page + (&poomadownloadpage;) available off the &pooma; home page + (&poomahomepage;). + + + Extract the source code using tar xzvf + mm-1.1.3.tar.gz. Change directories into the + resulting source code directory mm-1.1.3. + + + Prepare to compile the source code by configuring it + using the configure command. To change + the default installation directory /usr/local, specify + &dashdash;prefix=directory + option. The other configuration options can be listed by + specifying the &dashdash;help option. Since the + &author; prefers to keep all &pooma;-related code in his + poomasubdirectory, he + uses + + ./configure &dashdash;prefix=${HOME}/pooma/mm-1.1.3 + + + + Create the library by issuing the + make command. This compiles the source + code using a &c; compiler. To use a different compiler than + the &mm; configuration chooses, set the CC + environment variable to the desired compiler before + configuring. + + + Optionally test the library by issuing the make + test command. If successful, the penultimate line + should be OK - ALL TESTS SUCCESSFULLY + PASSED. + + + Install the &mm; Library by issuing the make + install command. This copies the library files to the + installation directory. The mm-1.1.3 directory containing the + source code may now be removed. + + + +

+ + +

+ Obtaining and Installing the &cheetah; Messaging Library + + The &cheetah; Library decouples communication from + synchronization. Using asynchronous messaging rather than + synchronous messaging permits a message sender to operate without + the cooperation of the message recipient. Thus, implementing + message sending is simpler and processing is more efficiently + overlapped with it. Remote method invocation is also supported. + The library was developed at the Los Alamos National Laboratory's + Advanced Computing Laboratory. + + &cheetah;'s messaging is implemented using an underlying + messaging library such as the Message Passing Interface (&mpi;) + Communications Library + ) + ]]> + or the &mm; Shared Memory Library. &mpi; works on a wide variety + of platforms and has achieved widespread usage. &mm; works under + Unix-like operating systems on any computer with shared memory. Both libraries are + available at no cost. The instructions below work for whichever + library you choose. + + We describe how to download and install &cheetah;. + + + Download the library from the &pooma; Download page + (&poomadownloadpage;) available off the &pooma; home page + (&poomahomepage;). + + + Extract the source code using tar xzvf + cheetah-1.0.tgz. Change directories into the + resulting source code directory cheetah-1.0. + + + Edit a configuration file corresponding to your operating + system and compiler. These .conf files are located in the + config directory. For + example, to use &gcc; with the &linux; operating system, use + config/LINUXGCC.conf. + + The configuration file usually does not need + modification. However, if you are using &mm;, ensure + shmem_default_dir specifies its location. + For example, the &author; modified the value to + "/home/oldham/pooma/mm-1.1.3". + + + Prepare to compile the source code by configuring it + using the configure command. Specify the + configuration file using the &dashdash;arch option. + Its argument should be the configuration file's name, omitting + its .conf suffix. For + example, &dashdash;arch LINUXGCC. Some other + options include + + + &dashdash;help + + lists all the available options + + + + &dashdash;shmem &dashdash;nompi + + indicates use of &mm;, not &mpi; + + + + &dashdash;mpi &dashdash;noshmem + + indicates use of &mpi;, not &mm; + + + + &dashdash;opt + + causes the compiler to produce optimized source code + + + + &dashdash;noex + + prevents use of &cc; exceptions + + + + &dashdash;static + + creates a static library, not a shared library + + + + &dashdash;shared + + creates a shared library, not a static library. This + is the default. + + + + &dashdash;prefix directory + + specifies the installation directory where the + library will be copied rather than the default. + + + + For example, the &author; uses + + ./configure &dashdash;arch LINUXGCC &dashdash;shmem &dashdash;nompi + &dashdash;noex &dashdash;static &dashdash;prefix ${HOME}/pooma/cheetah-1.0 + &dashdash;opt + The + &dashdash;arch LINUXGCC indicates use of &gcc; + under a &linux; operating system. The &mm; library is used, + but &cc; exceptions are not. The latter choice matches + &pooma;'s default choice. A static library, not a shared + library, is created. This is also &pooma;'s default choice. + The library will be installed in the ${HOME}/pooma/cheetah-1.0. + Finally, the library code will be optimized, hopefully running + faster than unoptimized code. + + + Follow the directions printed by + configure: Change directories to the + lib subdirectory named + by the &dashdash;arch argument and then type + make to compile the source code and create + the library. + + + Optionally ensure the library works correctly by issuing + the make tests command. + + + Install the library by issuing the make + install command. This copies the library files to + the installation directory. The cheetah-1.0 directory containing + the source code may now be removed. + + + +

+ +

+ Configuring &pooma; When Using &cheetah; + + To use &pooma; with &cheetah;, one must tell &pooma; the + location of the &cheetah; library using the + &dashdash;messaging configuration option. To do this, + + + Set the &cheetah; directory environment variable + CHEETAHDIR to the directory containing the + installed &cheetah; library. For + example, + + declare -x CHEETAHDIR=${HOME}/pooma/cheetah-1.0 + specifies the + installation directory used in the previous section. If using + the csh shell, use setenv + CHEETAHDIR ${HOME}/pooma/cheetah-1.0. + + + When configuring &pooma;, specify the + &dashdash;messaging option. For example, + ./configure &dashdash;arch LINUXgcc &dashdash;opt + &dashdash;messaging configures for &linux;, &gcc;, and an + optimized library using &cheetah;. + + + +

+ + + + + Dealing with Compilation Errors + + Base this low-priority section on errors.html. QUESTION: Where is + errors.html? + + + + + + TMP: Notes to Myself + +

+ Miscellaneous + + + + Section 5, "Performance," of + papers/iscope98.pdf motivates and explains + stencils. + + + + If there is time, present another example program, e.g., a + Jacobi solver. + + + + If a reference manual for &pooma; implementors is written, + begin with a chapter Under the Hood: How &pooma; + Works, written from the point of view of &cc; + interpreter. For &pete;, use the material in + papers/PETE_DDJ/ddj_article.html, which + gives example code and descriptions of how the code works, and + see material in background.html's + Expression Templates. + + + + QUESTION: How do &pooma; parallel concepts compare with + &fortran; D or high-performance &fortran; FINISH CITE: + {koelbel94:_high_perfor_fortr_handb}? + + + + QUESTION: How do I know when to use a type name versus just + the concept? For example, when do I use array + versus &array;? + + + + Krylov solvers are described in Section 3.5.2 of + papers/pooma.ps. + + + + Section 5, "The Polygon Overlay Problem," describes + porting an ANSI &c; program to &pooma;. + + + + A good example book: STL Tutorial and Reference + Guide: &cc; Programming with the Standard Template + Library, second edition, by David R. Musser, + Gillmer J. Derge, and Atul Sanai, ISBN 0-201-37923-6, + QA76.73.C153.M87 2001. + + + + One STL reference book listed functions in margin notes, + easing finding material. Do this. + + + + QUESTION: Does Berna Massingill at Trinity University have + any interest ior access to any parallel computers? + + + +

+ + +

+ Existing HTML Tutorials + + All these tutorials are out-of-date, but the ideas and text + may still be relevant. + + + index.html + list of all tutorials. No useful + material. + + introduction.html + data-parallel Laplace solver using Jacobi + iteration ala Doof2d + + background.html + short, indirect introduction to &pete;; parallel + execution model; &cc;; templates; &stl;; expression + templates + + tut-01.html + UNFINISHED + + Layout.html + UNFINISHED + + parallelism.html + UNFINISHED + + self-test.html + UNFINISHED + + threading.html + UNFINISHED + + tut-03.html + UNFINISHED + + tut-04.html + UNFINISHED + + tut-05.html + UNFINISHED + + tut-06.html + UNFINISHED + + tut-07.html + UNFINISHED + + tut-08.html + UNFINISHED + + tut-09.html + UNFINISHED + + tut-10.html + UNFINISHED + + tut-11.html + UNFINISHED + + tut-12.html + UNFINISHED + + tut-13.html + UNFINISHED + + + +

+ + + ]]> + + + &bibliography-chapter; + + &glossary-chapter; + + + + + + Index: print.dsl =================================================================== RCS file: print.dsl diff -N print.dsl *** /dev/null Fri Mar 23 21:37:44 2001 --- print.dsl Thu Jan 31 14:10:44 2002 *************** *** 0 **** --- 1,320 ---- + + + + ]> + + + + + + + + ;; $Id: plain.dsl,v 1.2 2000/09/28 12:50:20 ndw Exp $ + ;; + ;; This file is part of the Modular DocBook Stylesheet distribution. + ;; See ../README or http://www.berkshire.net/~norm/dsssl/ + ;; + ;; Example of a customization layer on top of the modular docbook style + ;; sheet. Definitions inserted in this file take precedence over + ;; definitions in the 'use'd stylesheet(s). + + ;; Number chapters and sections. + (define %chapter-autolabel% #t) + (define %section-autolabel% #t) + + ;; Use a readable font size. + (define %visual-acuity% "presbyopic") + ;; Prevent verbatim text from being displayed at a different size. + (define %verbatim-size-factor% 1.1) + + ;; Indent program listings four spaces + (define %indent-programlisting-lines% " ") + + ;; Support two-sided printing. + (define %two-side% #t) ;; does not have any effect + + ;; Produce justified text and hyphenation. + (define %default-quadding% 'justify) + (define %hyphenation% #t) + + ;; Produce footnotes at the bottom of the page, not section end. + (define bop-footnotes #t) + + ;; Use EPS for PS generation and PNG for PDF generation. + ;; Use '-V use-eps' to use EPS files. + (define use-eps #f) + (define %graphic-extensions% + (if use-eps + '("eps" "epsf" "gif" "tif" "tiff" "jpg" "jpeg" "png") + '("gif" "tif" "tiff" "jpg" "jpeg" "png"))) + ; modified from stylesheets/docbook/print/db31.dsl + (define preferred-mediaobject-notations + (if use-eps + (list "EPS" "PS" "JPG" "JPEG" "PNG" "linespecific") + (list "JPG" "JPEG" "PNG" "linespecific"))) + (define preferred-mediaobject-extensions + (if use-eps + (list "eps" "ps" "jpg" "jpeg" "png") + (list "jpg" "jpeg" "png"))) + + ;; Layout variable lists in a reasonable way. + ;; does not work well (define %may-format-variablelist-as-table% #t) + ;; (define %always-format-variablelist-as-table #t) ;; does not work at all + + ;; Float tables and examples. + (define formal-object-float #f) + ;(define %example-rules% #t) Uncomment if use floats. + ;(define %figure-rules% %example-rules%) + ;(define %table-rules% %example-rules%) + + ;; Fix space breaking for xref text. I tried modifying + ;; en-xref-strings from docbook/common/dbl1en.dsl, but I could not get + ;; it to work because the entities in this list are not defined. + + ;; Change the default presentation for various tags. + ; Use mono-space font for computer items. + (element command ($mono-seq$)) + (element envar ($mono-seq$)) + (element errorname ($mono-seq$)) + (element errortype ($mono-seq$)) + (element keywordname ($mono-seq$)) ; new tag aded by Oldham + (element methodname ($mono-seq$)) ; new tag aded by Oldham + (element operator ($mono-seq$)) ; new tag aded by Oldham + (element statement ($mono-seq$)) ; new tag aded by Oldham + (element symbol ($mono-seq$)) + (element token ($mono-seq$)) + (element type ($mono-seq$)) + + ; Number all pages sequentially, rather than separate numbering for + ; various pieces of the preface. + ; Copied from stylesheets/docbook/print/dbdivis.dsl. + (element book + (let* ((bookinfo (select-elements (children (current-node)) + (normalize "bookinfo"))) + (dedication (select-elements (children (current-node)) + (normalize "dedication"))) + (nl (titlepage-info-elements (current-node) bookinfo))) + (make sequence + (if %generate-book-titlepage% + (make sequence + (book-titlepage nl 'recto) + (book-titlepage nl 'verso)) + (empty-sosofo)) + + (if (node-list-empty? dedication) + (empty-sosofo) + (with-mode dedication-page-mode + (process-node-list dedication))) + + (if (not (generate-toc-in-front)) + (process-children) + (empty-sosofo)) + + (if %generate-book-toc% + (make simple-page-sequence + page-n-columns: %page-n-columns% + page-number-restart?: #f ; changed from #t + page-number-format: ($page-number-format$ (normalize "toc")) + use: default-text-style + left-header: ($left-header$ (normalize "toc")) + center-header: ($center-header$ (normalize "toc")) + right-header: ($right-header$ (normalize "toc")) + left-footer: ($left-footer$ (normalize "toc")) + center-footer: ($center-footer$ (normalize "toc")) + right-footer: ($right-footer$ (normalize "toc")) + input-whitespace-treatment: 'collapse + (build-toc (current-node) + (toc-depth (current-node)))) + (empty-sosofo)) + + (let loop ((gilist ($generate-book-lot-list$))) + (if (null? gilist) + (empty-sosofo) + (if (not (node-list-empty? + (select-elements (descendants (current-node)) + (car gilist)))) + (make simple-page-sequence + page-n-columns: %page-n-columns% + page-number-format: ($page-number-format$ (normalize "lot")) + use: default-text-style + left-header: ($left-header$ (normalize "lot")) + center-header: ($center-header$ (normalize "lot")) + right-header: ($right-header$ (normalize "lot")) + left-footer: ($left-footer$ (normalize "lot")) + center-footer: ($center-footer$ (normalize "lot")) + right-footer: ($right-footer$ (normalize "lot")) + input-whitespace-treatment: 'collapse + (build-lot (current-node) (car gilist)) + (loop (cdr gilist))) + (loop (cdr gilist))))) + + (if (generate-toc-in-front) + (process-children) + (empty-sosofo))))) + ; Copied from stylesheets/docbook/print/dbcompon.dsl. + (define ($component$) + (make simple-page-sequence + page-n-columns: %page-n-columns% + page-number-restart?: #f ; changed + page-number-format: ($page-number-format$) + use: default-text-style + left-header: ($left-header$) + center-header: ($center-header$) + right-header: ($right-header$) + left-footer: ($left-footer$) + center-footer: ($center-footer$) + right-footer: ($right-footer$) + start-indent: %body-start-indent% + input-whitespace-treatment: 'collapse + quadding: %default-quadding% + (make sequence + ($component-title$) + (process-children)) + (make-endnotes))) + + ; Center figures. + (element mediaobject + (make paragraph + quadding: 'center ; added + ($mediaobject$))) + + ;; Display verbatim block environments with smaller font. + ; Copied from stylesheets/docbook/print/dbverb.dsl. + (define ($verbatim-display$ indent line-numbers?) + (let* ((width-in-chars (if (attribute-string (normalize "width")) + (string->number (attribute-string (normalize "width"))) + %verbatim-default-width%)) + (fsize (lambda () (if (or (attribute-string (normalize "width")) + (not %verbatim-size-factor%)) + (/ (/ (- %text-width% (inherited-start-indent)) + width-in-chars) + 0.7) + (inherited-font-size)))) ; changed + (vspace (if (INBLOCK?) + 0pt + (if (INLIST?) + %para-sep% + %block-sep%)))) + (make paragraph + use: verbatim-style + space-before: (if (and (string=? (gi (parent)) (normalize "entry")) + (absolute-first-sibling?)) + 0pt + vspace) + space-after: (if (and (string=? (gi (parent)) (normalize "entry")) + (absolute-last-sibling?)) + 0pt + vspace) + font-size: (fsize) + line-spacing: (* (fsize) %line-spacing-factor%) + start-indent: (if (INBLOCK?) + (inherited-start-indent) + (+ %block-start-indent% (inherited-start-indent))) + (if (or indent line-numbers?) + ($linespecific-line-by-line$ indent line-numbers?) + (process-children))))) + + ;; Remove initial and final spaces before programlisting embedded + ;; within a para. + (define ($verbatim-display-embedded$ indent line-numbers?) + (let* ((width-in-chars (if (attribute-string (normalize "width")) + (string->number (attribute-string (normalize "width"))) + %verbatim-default-width%)) + (fsize (lambda () (if (or (attribute-string (normalize "width")) + (not %verbatim-size-factor%)) + (/ (/ (- %text-width% (inherited-start-indent)) + width-in-chars) + 0.7) + (inherited-font-size))))) ; changed + (make paragraph + use: verbatim-style + space-before: 0pt + space-after: 0pt + min-pre-line-spacing: 0pt + min-post-line-spacing: 0pt + keep-with-previous?: #t + keep-with-next?: #t + font-size: (fsize) + line-spacing: (* (fsize) %line-spacing-factor%) + start-indent: (if (INBLOCK?) + (inherited-start-indent) + (+ %block-start-indent% (inherited-start-indent))) + (if (or indent line-numbers?) + ($linespecific-line-by-line$ indent line-numbers?) + (process-children))))) + (element (para programlisting) ; process the programlisting, not para + ($verbatim-display-embedded$ + %indent-programlisting-lines% + %number-programlisting-lines%)) + + ;; Remove initial and final spaces before itemizedlist embedded + ;; within a para. + (define ($list-embedded$) + (make display-group + start-indent: (if (INBLOCK?) + (inherited-start-indent) + (+ %block-start-indent% (inherited-start-indent))) + space-after: 0pt + space-before: 0pt + min-pre-line-spacing: 0pt + min-post-line-spacing: 0pt + keep-with-previous?: #t + keep-with-next?: #t)) + (element (para itemizedlist) + ($list-embedded$)) + (element (para orderedlist) + ($list-embedded$)) + + ;;; From http://cyberelk.net/tim/docbook/selfdocbook/selfdocbook.dsl.html: + ;;; To make URLs line wrap we use the TeX 'url' package. + ;;; See also: jadetex.cfg + ;; First we need to declare the 'formatting-instruction' flow class. + (declare-flow-object-class formatting-instruction + "UNREGISTERED::James Clark//Flow Object Class::formatting-instruction") + ;; Then redefine ulink to use it. + (element ulink + (make sequence + (if (node-list-empty? (children (current-node))) + ; ulink url="...", /ulink + (make formatting-instruction + data: (string-append "\\url{" + (attribute-string (normalize "url")) + "}")) + (if (equal? (attribute-string (normalize "url")) + (data-of (current-node))) + ; ulink url="http://...", http://..., /ulink + (make formatting-instruction + data: (string-append "\\url{" + (attribute-string (normalize "url")) + "}")) + ; ulink url="http://...", some text, /ulink + (make sequence + ($charseq$) + (literal " (") + (make formatting-instruction data: + (string-append "\\url{" + (attribute-string (normalize "url")) + "}")) + (literal ")")))))) + ;;; And redefine filename to use it too. + (element filename + (make formatting-instruction + data: (string-append "\\path{" (data-of (current-node)) "}"))) + + ;; We use ten callouts and only special symbols for nine are permitted. + (define %callout-fancy-bug% #f) + + + + + + + Index: template.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/template.xml,v retrieving revision 1.5 diff -c -p -r1.5 template.xml *** template.xml 2002/01/30 23:51:45 1.5 --- template.xml 2002/01/31 21:10:45 *************** *** 212,218 **** The constructor has two parameters of ! type T. --- 212,218 ---- The constructor has two parameters of ! type const T&. Index: tutorial.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/tutorial.xml,v retrieving revision 1.10 diff -c -p -r1.10 tutorial.xml *** tutorial.xml 2002/01/30 23:51:45 1.10 --- tutorial.xml 2002/01/31 21:10:46 *************** *** 436,443 **** of the array values that are modified. ! &pooma; may reorder computation of statements. Calling ! Pooma::blockAndEvaluate ensures all computation finishes before accessing a particular array element. --- 436,442 ---- of the array values that are modified. ! &pooma; may reorder computation. Pooma::blockAndEvaluate ensures all computation finishes before accessing a particular array element. *************** *** 506,521 ****

! Just before accessing individual &array; values, the code ! contains calls to Pooma::blockAndEvaluate. ! &pooma; may reorder computation or distribute them among various ! processors. Before reading an individual &array; value, calling ! this function ensures all computations affecting its value have ! finished, i.e., it has the correct value. Calling this function is ! necessary only when accessing individual array elements. For ! example, before the data-parallel operation of printing an array, ! &pooma; will call blockAndEvaluate ! itself.

--- 505,519 ---- ! &pooma; may reorder computation or distribute them among ! various processors so, before accessing individual values, ! the code calls Pooma::blockAndEvaluate. Before ! reading an individual &array; value, calling this function ensures ! all computations affecting its value have finished, i.e., it has the ! correct value. Calling this function is necessary only when ! accessing individual array elements. For example, before the ! data-parallel operation of printing an array, &pooma; will call ! blockAndEvaluate itself.

*************** MultiPatch<UniformTag, Remote<Comp *** 1057,1064 **** system-dependent. For example, the mpirun -np 4 Doof2d-Field-distributed -mpi 2 10 1000 command might use &mpi; communication. ! Doof2d-Field-distributed -shmem -np 4 2 10 ! 1000 might use the &mm; Shared Memory Library. --- 1055,1063 ---- system-dependent. For example, the mpirun -np 4 Doof2d-Field-distributed -mpi 2 10 1000 command might use &mpi; communication. ! ! Doof2d-Field-distributed -shmem -np 4 2 10 1000 ! might use the &mm; Shared Memory Library. From oldham at codesourcery.com Thu Jan 31 21:33:45 2002 From: oldham at codesourcery.com (Jeffrey D . Oldham) Date: Thu, 31 Jan 2002 13:33:45 -0800 Subject: Manual Patch: Revise Figures Message-ID: <20020131133345.B29384@vaio.codesourcery.com> These changes mostly shrink the horizontal extent of some figures to avoid intruding into the right margin. 2002-Jan-31 Jeffrey D. Oldham * Makefile: New file moved from 'makefile'. * concepts-101.png: Changed per changes to corresponding mp file. * concepts.mp: Use math times fonts. Reduce horizontal width. * data-parallel-212.png: Changed per changes to corresponding mp file. * data-parallel.mp: Use math times fonts. Reduce horizontal width. * distributed-101.png: Changed per changes to corresponding mp file. * distributed.mp: Use math times fonts. * doof2d.mp: Likewise. * introduction-101.png: Changed per changes to corresponding mp file. * introduction.mp: Use math times fonts. Reduce horizontal width. * macros.ltx: Hack \mapsto since the symbol is broken. * makefile: Moved to 'Makefile'. Applied to mainline Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Makefile =================================================================== RCS file: Makefile diff -N Makefile *** /dev/null Fri Mar 23 21:37:44 2001 --- Makefile Thu Jan 31 14:23:57 2002 *************** *** 0 **** --- 1,66 ---- + ### Oldham, Jeffrey D. + ### 2002Jan31 + ### POOMA + ### + ### Create POOMA Manual Figures + + ## We write our figures using the MetaPost programming language. + ## Applying $(MPOST) to the figures produces EPS (Encapsulated + ## PostScript) files. These can be directly included in TeX files to + ## produce PostScript. We use $(EPSTOPNG) to convert EPS to PNG + ## (Portable Network Graphics) format. + + # Definitions for MetaPost figure creation + TEX= latex + MPOST= mpost + # This non-standard tool converts EPS format into PNG format. + # The EPS files must have font information in its initial comments. + # Set the 'prologue' MetaPost variable to a value >= 2 to ensure this. + # Also the pnmtopng command must be available. + EPSTOPNG= /home/oldham/bin/peps + + # MetaPost macro definitions used in multiple files. + MACRO_SOURCES= box-macros.mp grid-macros.mp + # These MetaPost files describe the figures. + SOURCES= concepts.mp data-parallel.mp distributed.mp doof2d.mp introduction.mp + # MetaPost can produce multiple files per input file. These multiple + # files have names %.[0-9]+. Since make does not deal well with + # producing an indeterminate number of files from the same rule, we + # instead produce mproof-%.ps PostScript files which can be used to + # proof the EPS files. + RESULTS= $(SOURCES:%.mp=mproof-%.ps) + # These files must be in the POOMA CVS tree to ensure creation of the + # figures. + TREE_SOURCES= $(SOURCES) Makefile macros.ltx + + # Create all the EPS and PNG files. The 'mproof-all' target creates + # the EPS files. This should happen before trying to create the PNG + # files, but this rule may not guarantee this ordering. + all: mproof-all \ + concepts-101.png concepts-111.png data-parallel-101.png \ + data-parallel-212.png distributed-101.png \ + doof2d-201.png doof2d-202.png doof2d-203.png \ + doof2d-210.png doof2d-211.png introduction-101.png + + mproof-all: $(RESULTS) + + mproof-%.ps: %.mp macros.ltx + declare -x TEX=latex && $(MPOST) $< && tex mproof.tex $*.[0-9]* && dvips mproof.dvi -o $@ + + # Convert from EPS to PNG. + # Assumes the existence of $(EPSTOPNG). + # There should be a way to generalize these rules to have two + # different '%', but I do not know how to do this. + concepts-%.png: concepts.% + $(EPSTOPNG) -p -o $@ $^ + data-parallel-%.png: data-parallel.% + $(EPSTOPNG) -p -o $@ $^ + distributed-%.png: distributed.% + $(EPSTOPNG) -p -o $@ $^ + doof2d-%.png: doof2d.% + $(EPSTOPNG) -p -o $@ $^ + introduction-%.png: introduction.% + $(EPSTOPNG) -p -o $@ $^ + + clean: + rm -f *.dvi *.aux *.log *.toc *.bak *.blg *.bbl *.glo *.idx *.lof *.lot *.htm *.mpx mpxerr.tex Index: concepts-101.png =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/concepts-101.png,v retrieving revision 1.1 diff -c -p -r1.1 concepts-101.png Binary files /tmp/cvs3EgRvE and concepts-101.png differ Index: concepts.mp =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/concepts.mp,v retrieving revision 1.4 diff -c -p -r1.4 concepts.mp *** concepts.mp 2002/01/30 23:40:12 1.4 --- concepts.mp 2002/01/31 21:23:57 *************** verbatimtex *** 15,20 **** --- 15,21 ---- \documentclass[12pt]{article} \input{macros.ltx} \usepackage{times} + \usepackage{mathptm} \begin{document} etex *************** endfig; *** 122,128 **** beginfig(101) numeric unit; unit = 0.8cm; numeric vertSpace; vertSpace = 2.6unit; % vertical space between sections ! numeric horizSpace; horizSpace = 8unit; % horizontal space between sections % Create and layout boxes for computational Array and Field implementations. numeric interBoxSpace; interBoxSpace = unit; % space between boxes --- 123,129 ---- beginfig(101) numeric unit; unit = 0.8cm; numeric vertSpace; vertSpace = 2.6unit; % vertical space between sections ! numeric horizSpace; horizSpace = 2unit; % horizontal space between sections % Create and layout boxes for computational Array and Field implementations. numeric interBoxSpace; interBoxSpace = unit; % space between boxes *************** beginfig(101) *** 144,154 **** boxit.l1(btex \strut \underline{mathematical concept} etex); boxit.l2(btex \strut \underline{computational implementation} etex); boxit.l3(btex \strut \type{Array}: etex); ! boxit.l4(btex \strut $\mbox{index} \mapsto \mbox{value}$ etex); boxit.l6(btex \strut \type{Field}: etex); ! boxit.l7(btex \strut $\mbox{index} \mapsto \mbox{value}$ etex); boxit.l9(btex \strut \type{Field}: etex); ! boxit.l10(btex \strut $\mbox{indices} \mapsto \mbox{spatial value}$ etex); fixsize(l1,l2,l3,l4,l6,l7,l9,l10); ypart(l1.c - l2.c) = 0; --- 145,158 ---- boxit.l1(btex \strut \underline{mathematical concept} etex); boxit.l2(btex \strut \underline{computational implementation} etex); boxit.l3(btex \strut \type{Array}: etex); ! % boxit.l4(btex \strut $\mbox{index} \mapsto \mbox{value}$ etex); ! boxit.l4(btex etex); boxit.l6(btex \strut \type{Field}: etex); ! % boxit.l7(btex \strut $\mbox{index} \mapsto \mbox{value}$ etex); ! boxit.l7(btex etex); boxit.l9(btex \strut \type{Field}: etex); ! boxit.l10(btex etex); ! % boxit.l10(btex \strut $\mbox{indices} \mapsto \mbox{spatial value}$ etex); fixsize(l1,l2,l3,l4,l6,l7,l9,l10); ypart(l1.c - l2.c) = 0; Index: data-parallel-212.png =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/data-parallel-212.png,v retrieving revision 1.1 diff -c -p -r1.1 data-parallel-212.png Binary files /tmp/cvsLQoLwD and data-parallel-212.png differ Index: data-parallel.mp =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/data-parallel.mp,v retrieving revision 1.2 diff -c -p -r1.2 data-parallel.mp *** data-parallel.mp 2002/01/30 23:40:12 1.2 --- data-parallel.mp 2002/01/31 21:23:58 *************** verbatimtex *** 17,22 **** --- 17,23 ---- \documentclass[12pt]{article} \input{macros.ltx} \usepackage{times} + \usepackage{mathptm} \begin{document} etex *************** endfig; *** 74,80 **** %% An illustratation of the addition of arrays. beginfig(212) ! numeric unit; unit = 0.9cm; % width or height of an individual grid cell numeric nuCells; nuCells = 5; % number of cells in each dimension % This number should be odd. numeric nuArrayCells; nuArrayCells = 3; --- 75,81 ---- %% An illustratation of the addition of arrays. beginfig(212) ! numeric unit; unit = 0.7cm; % width or height of an individual grid cell numeric nuCells; nuCells = 5; % number of cells in each dimension % This number should be odd. numeric nuArrayCells; nuArrayCells = 3; Index: distributed-101.png =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/distributed-101.png,v retrieving revision 1.1 diff -c -p -r1.1 distributed-101.png Binary files /tmp/cvstiHEMC and distributed-101.png differ Index: distributed.mp =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/distributed.mp,v retrieving revision 1.3 diff -c -p -r1.3 distributed.mp *** distributed.mp 2002/01/30 23:40:12 1.3 --- distributed.mp 2002/01/31 21:23:59 *************** verbatimtex *** 15,20 **** --- 15,21 ---- \documentclass[12pt]{article} \input{macros.ltx} \usepackage{times} + \usepackage{mathptm} \begin{document} etex Index: doof2d.mp =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/doof2d.mp,v retrieving revision 1.5 diff -c -p -r1.5 doof2d.mp *** doof2d.mp 2002/01/30 23:40:12 1.5 --- doof2d.mp 2002/01/31 21:24:00 *************** prologues := 2; % >= 2 for PostScript *** 12,17 **** --- 12,18 ---- verbatimtex \documentclass[12pt]{article} \usepackage{times} + \usepackage{mathptm} \input{macros.ltx} \begin{document} Index: introduction-101.png =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/introduction-101.png,v retrieving revision 1.1 diff -c -p -r1.1 introduction-101.png Binary files /tmp/cvsG4g2Ad and introduction-101.png differ Index: introduction.mp =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/introduction.mp,v retrieving revision 1.4 diff -c -p -r1.4 introduction.mp *** introduction.mp 2002/01/30 23:40:12 1.4 --- introduction.mp 2002/01/31 21:24:00 *************** input boxes; *** 13,22 **** input box-macros; verbatimtex ! \documentclass[12pt]{article} \usepackage{amsmath} \input{macros.ltx} \usepackage{times} \begin{document} etex --- 13,28 ---- input box-macros; verbatimtex ! \documentclass[10pt]{article} \usepackage{amsmath} \input{macros.ltx} \usepackage{times} + \usepackage{mathptm} + %% TMP + \renewcommand{\maps}{\ensuremath{\mbox{-}\mbox{}\!>\!}}% + % Produce a representation for a map. + % Requires no parameters. + \begin{document} etex *************** beginfig(101) *** 25,31 **** %% FIXME: Ensure the arrow labels are the same distance above the arrows. %% FIXME: Ensure the boxes all have the same height. %% FIXME: Ensure the arrowheads do not collide. ! numeric unit; unit = 0.8cm; numeric horizSpace; horizSpace = 8unit; numeric vertSpace; vertSpace = unit; numeric nuBoxes; % number of boxes --- 31,37 ---- %% FIXME: Ensure the arrow labels are the same distance above the arrows. %% FIXME: Ensure the boxes all have the same height. %% FIXME: Ensure the arrowheads do not collide. ! numeric unit; unit = 0.65cm; numeric horizSpace; horizSpace = 8unit; numeric vertSpace; vertSpace = unit; numeric nuBoxes; % number of boxes *************** beginfig(101) *** 36,48 **** boxit.b2(btex \textsl{engineering} etex); boxit.b3(btex \strut $\real^{\dimension} \maps \text{values}$ etex); boxit.b4(btex \strut $\text{discrete space} \maps \text{values}$ etex); ! boxit.b5(btex \strut $(\text{layout}, \text{engine}) \maps \text{values}$ etex); boxit.b6(btex \strut linear algebra etex); boxit.b7(btex \strut $\naturalNus^{\dimension} \maps \text{values}$ etex); boxit.b8(btex etex); nuBoxes = 8; boxit.b9(btex \textsl{implementation} etex); ! sameWidthSameHeight(b3,b4,b5,b6,b7,b8); for t = 0 upto nuBoxes+1: fixsize(b[t]); endfor --- 42,57 ---- boxit.b2(btex \textsl{engineering} etex); boxit.b3(btex \strut $\real^{\dimension} \maps \text{values}$ etex); boxit.b4(btex \strut $\text{discrete space} \maps \text{values}$ etex); ! boxit.b5(btex \strut $(\text{layout,} \text{engine}) \maps \text{values}$ etex); boxit.b6(btex \strut linear algebra etex); boxit.b7(btex \strut $\naturalNus^{\dimension} \maps \text{values}$ etex); boxit.b8(btex etex); nuBoxes = 8; boxit.b9(btex \textsl{implementation} etex); ! %%TMP sameWidthSameHeight(b3,b4,b5,b6,b7,b8); ! sameWidthSameHeight(b3,b6); ! sameWidthSameHeight(b4,b7); ! sameWidthSameHeight(b5,b8); for t = 0 upto nuBoxes+1: fixsize(b[t]); endfor *************** beginfig(101) *** 74,81 **** drawunboxed(b9); % Label the boxes. ! label.top(btex continuous field etex, b3.n); ! label.top(btex discrete field etex, b4.n); label.top(btex \pooma\ container etex, b5.n); label.top(btex mathematical array etex, b7.n); % label.top(btex custom implementation etex, b8.n); --- 83,90 ---- drawunboxed(b9); % Label the boxes. ! label.top(btex continuous \avoidfi eld etex, b3.n); ! label.top(btex discrete \avoidfi eld etex, b4.n); label.top(btex \pooma\ container etex, b5.n); label.top(btex mathematical array etex, b7.n); % label.top(btex custom implementation etex, b8.n); Index: macros.ltx =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/figures/macros.ltx,v retrieving revision 1.3 diff -c -p -r1.3 macros.ltx *** macros.ltx 2002/01/30 23:40:12 1.3 --- macros.ltx 2002/01/31 21:24:00 *************** *** 13,19 **** \newcommand{\naturalNus}{\ensuremath{\boldsymbol{N}}}% % Produce a representation for discrete space. % Requires no parameters. ! \newcommand{\maps}{\ensuremath{\rightarrow}}% % Produce a representation for a map. % Requires no parameters. \newcommand{\real}{\ensuremath{\boldsymbol{R}}}% --- 13,20 ---- \newcommand{\naturalNus}{\ensuremath{\boldsymbol{N}}}% % Produce a representation for discrete space. % Requires no parameters. ! \newcommand{\maps}{\ensuremath{\mbox{-}\mbox{}\!>\!}}% ! %% TMP Does not appear for an unknown reason. \newcommand{\maps}{\ensuremath{\mapsto}}% % Produce a representation for a map. % Requires no parameters. \newcommand{\real}{\ensuremath{\boldsymbol{R}}}% Index: makefile =================================================================== RCS file: makefile diff -N makefile *** /tmp/cvsziio0S Thu Jan 31 14:24:00 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,74 **** - ### Oldham, Jeffrey D. - ### 1997 Dec 26 - ### misc - ### - ### LaTeX -> PostScript/PDF/WWW - ### XML -> TeX/DVI/PS/PDF - - # Definitions for PostScript and WWW Creation - TEX= latex - WWWHOMEDIR= /u/oldham/www - LATEX2HTML= latex2html - BASICLATEX2HTMLOPTIONS= -info "" -no_footnode -no_math -html_version 3.2,math - #LATEX2HTMLOPTIONS= -local_icons -split +1 $(BASICLATEX2HTMLOPTIONS) - LATEX2HTMLOPTIONS= -no_navigation -split 0 $(BASICLATEX2HTMLOPTIONS) - MPOST= mpost - - # Definitions for Jade. - JADEDIR= /usr/lib/sgml/stylesheets/docbook - PRINTDOCBOOKDSL= print/docbook.dsl - HTMLDOCBOOKDSL= html/docbook.dsl - XML= dtds/decls/xml.dcl - INDEXOPTIONS= -t 'Index' -i 'index' -g -p - - CXXFLAGS= -g -Wall -pedantic -W -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wcast-align -Wconversion -Wnested-externs -Wundef -Winline -static - - all: manual.ps - - manual.dvi: manual.xml introduction.xml template.xml tutorial.xml \ - concepts.xml arrays.xml data-parallel.xml glossary.xml \ - bibliography.xml - - %.all: %.ps %.pdf %.html - chmod 644 $*.ps $*.pdf - mv $*.ps $*.pdf $* - - %.dvi: %.ltx - $(TEX) $< - # bibtex $* - # $(TEX) $< - $(TEX) $< - - %.ps: %.dvi - dvips -t letter $< -o - - %.pdf.ltx: %.ltx - sed -e 's/^%\\usepackage{times}/\\usepackage{times}/' $< > $@ - - %.pdf: %.pdf.ltx - pdflatex $< - mv $@.pdf $@ - - # This rule assumes index creation. - %.dvi: %.xml genindex.sgm - jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) -V html-index $(XML) $< && \ - perl collateindex.pl $(INDEXOPTIONS) -o genindex.sgm HTML.index && \ - jade -D$(JADEDIR) -t tex -d $(PRINTDOCBOOKDSL) -V tex-backend $(XML) $< && jadetex $*.tex && jadetex $*.tex && jadetex $*.tex - - genindex.sgm: - perl collateindex.pl $(INDEXOPTIONS) -N -o $@ - - %.html: %.xml - jade -D$(JADEDIR) -t sgml -d $(HTMLDOCBOOKDSL) $(XML) $< - - %.pdf: %.xml - jade -D$(JADEDIR) -t tex -d $(PRINTDOCBOOKDSL) $(XML) $< && pdfjadetex $*.tex && pdfjadetex $*.tex - - mproof-%.ps: %.mp - declare -x TEX=latex && $(MPOST) $< && tex mproof.tex $*.[0-9]* && dvips mproof.dvi -o $@ - - %.txt: %.ltx - detex $< > $@ - - clean: - rm -f *.dvi *.aux *.log *.toc *.bak *.blg *.bbl *.glo *.idx *.lof *.lot *.htm *.mpx mpxerr.tex HTML.index manual.tex genindex.sgm --- 0 ---- From oldham at codesourcery.com Thu Jan 31 22:04:17 2002 From: oldham at codesourcery.com (Jeffrey D . Oldham) Date: Thu, 31 Jan 2002 14:04:17 -0800 Subject: Manual Patch: Tidy Programs Message-ID: <20020131140417.A29568@vaio.codesourcery.com> 2002-Jan-31 Jeffrey D. Oldham The changes in this patch 1) Remove duplicates of files. 2) Reformat DocBook output to avoid lines that intrude into the right margin. * array-copy-annotated.patch: Remove this file, which should not have been present. * array-size-annotated.patch: Likewise. * dynamicarray-annotated.patch: Likewise. * examples/array-copy-annotated.patch: Likewise. * examples/array-size-annotated.patch: Likewise. * examples/dynamicarray-annotated.patch: Likewise. * examples/Doof2d/Doof2d-Array-distributed-annotated.patch: Reformat to avoid long lines. * examples/Doof2d/Doof2d-Array-element-annotated.patch: Likewise. * examples/Doof2d/Doof2d-Array-parallel-annotated.patch: Likewise. * examples/Doof2d/Doof2d-Array-stencil-annotated.patch: Likewise. * examples/Doof2d/Doof2d-C-element-annotated.patch: Likewise. * examples/Doof2d/Doof2d-Field-distributed-annotated.patch: Likewise. * examples/Doof2d/Doof2d-Field-parallel-annotated.patch: Likewise. * examples/Doof2d/array-copy-annotated.patch: Remove this file, which should not have been present. * examples/Doof2d/array-size-annotated.patch: Likewise. * examples/Doof2d/dynamicarray-annotated.patch: Likewise. * examples/Doof2d/initialize-finalize-annotated.patch: Likewise. * examples/Doof2d/pairs-templated-annotated.patch: Likewise. * examples/Sequential/Doof2d-Array-distributed-annotated.patch: Likewise. * examples/Sequential/Doof2d-Array-element-annotated.patch: Likewise. * examples/Sequential/Doof2d-Array-parallel-annotated.patch: Likewise. * examples/Sequential/Doof2d-Array-stencil-annotated.patch: Likewise. * examples/Sequential/Doof2d-C-element-annotated.patch: Likewise. * examples/Sequential/Doof2d-Field-distributed-annotated.patch: Likewise. * examples/Sequential/Doof2d-Field-parallel-annotated.patch: Likewise. * examples/Sequential/array-copy-annotated.patch: Reformat to avoid long lines. * examples/Sequential/array-size-annotated.patch: Likewise. * examples/Sequential/pairs-templated-annotated.patch: Likewise. * examples/Sequential/pairs-untemplated-annotated.patch: Likewise. * examples/Templates/Doof2d-Array-distributed-annotated.patch: Remove this file, which should not have been present. * examples/Templates/Doof2d-Array-element-annotated.patch: Likewise. * examples/Templates/Doof2d-Array-parallel-annotated.patch: Likewise. * examples/Templates/Doof2d-Array-stencil-annotated.patch: Likewise. * examples/Templates/Doof2d-C-element-annotated.patch: Likewise. * examples/Templates/Doof2d-Field-distributed-annotated.patch: Likewise. * examples/Templates/Doof2d-Field-parallel-annotated.patch: Likewise. * examples/Templates/array-copy-annotated.patch: Likewise. * examples/Templates/array-size-annotated.patch: Likewise. * examples/Templates/dynamicarray-annotated.patch: Likewise. * examples/Templates/initialize-finalize-annotated.patch: Likewise. * examples/Templates/pairs-templated-annotated.patch: Move this file to the Sequential directory. Applied to mainline. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: array-copy-annotated.patch =================================================================== RCS file: array-copy-annotated.patch diff -N array-copy-annotated.patch *** /tmp/cvsRJePSY Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,77 **** - *** array-copy.cpp Thu Jan 24 11:12:23 2002 - --- array-copy-annotated.cpp Thu Jan 24 11:12:49 2002 - *************** - *** 1,8 **** - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include - - // Changes the Array value at index (0,0). - ! void changeValue(Array<2,int,Brick>& z) - { z(0,0) = 6; } - - --- 1,9 ---- - + - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include <iostream> - - // Changes the Array value at index (0,0). - ! void changeValue(Array<2,int,Brick>& z) - { z(0,0) = 6; } - - *************** - *** 11,17 **** - Pooma::initialize(argc,argv); - - ! Array<2,int,Brick> a(3,4, ModelElement(4)); - ! std::cout << "Initial value:\n"; - ! std::cout << "a: " << a(0,0) << std::endl; - - // Array copies share the same underlying values. - --- 12,18 ---- - Pooma::initialize(argc,argv); - - ! Array<2,int,Brick> a(3,4, ModelElement<int>(4)); - ! std::cout &openopen; "Initial value:\n"; - ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; - - // Array copies share the same underlying values. - *************** - *** 19,35 **** - // Explicit initialization uses reference semantics so changing the - // copy's value at (0,0) also changes the original's value. - ! Array<2,int,Brick> b(a); - b(0,0) = 5; - ! std::cout << "After explicit initialization.\n"; - ! std::cout << "a: " << a(0,0) << std::endl; - ! std::cout << "b: " << b(0,0) << std::endl; - - // Initialization of function arguments also uses reference semantics. - ! std::cout << "After function call:\n"; - changeValue(a); - ! std::cout << "a: " << a(0,0) << std::endl; - ! std::cout << "b: " << b(0,0) << std::endl; - - Pooma::finalize(); - return 0; - } - --- 20,37 ---- - // Explicit initialization uses reference semantics so changing the - // copy's value at (0,0) also changes the original's value. - ! Array<2,int,Brick> b(a); - b(0,0) = 5; - ! std::cout &openopen; "After explicit initialization.\n"; - ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; - ! std::cout &openopen; "b: " &openopen; b(0,0) &openopen; std::endl; - - // Initialization of function arguments also uses reference semantics. - ! std::cout &openopen; "After function call:\n"; - changeValue(a); - ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; - ! std::cout &openopen; "b: " &openopen; b(0,0) &openopen; std::endl; - - Pooma::finalize(); - return 0; - } - + --- 0 ---- Index: array-size-annotated.patch =================================================================== RCS file: array-size-annotated.patch diff -N array-size-annotated.patch *** /tmp/cvsaVwiqN Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,67 **** - *** array-size.cpp Tue Jan 15 12:59:40 2002 - --- array-size-annotated.cpp Tue Jan 15 13:30:07 2002 - *************** - *** 1,5 **** - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include - - // Print an Array's Size - --- 1,6 ---- - + - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include <iostream> - - // Print an Array's Size - *************** - *** 10,22 **** - // member functions. - - ! template - inline - ! long computeArraySize(const Array& a) - { - ! const Loc fs = a.firsts(); - ! const Loc ls = a.lasts(); - ! const Loc lens = a.lengths(); - long size = 1; - ! for (int d = 0; d < Dim; ++d) { - size *= (ls[d] - fs[d] + 1).first(); - // Check that lengths() and our computed lengths agree. - --- 11,23 ---- - // member functions. - - ! template <int Dim, typename Type, typename EngineTag> - inline - ! long computeArraySize(const Array<Dim,Type,EngineTag>& a) - { - ! const Loc<Dim> fs = a.firsts(); - ! const Loc<Dim> ls = a.lasts(); - ! const Loc<Dim> lens = a.lengths(); - long size = 1; - ! for (int d = 0; d < Dim; ++d) { - size *= (ls[d] - fs[d] + 1).first(); - // Check that lengths() and our computed lengths agree. - *************** - *** 30,38 **** - Pooma::initialize(argc,argv); - - ! Array<3,int,Brick> a(3,4,5, ModelElement(4)); - PAssert(computeArraySize(a) == a.size()); - ! std::cout << "The array's size is " << a.size() << ".\n"; - - Pooma::finalize(); - return 0; - } - --- 31,40 ---- - Pooma::initialize(argc,argv); - - ! Array<3,int,Brick> a(3,4,5, ModelElement<int>(4)); - PAssert(computeArraySize(a) == a.size()); - ! std::cout &openopen; "The array's size is " &openopen; a.size() &openopen; ".\n"; - - Pooma::finalize(); - return 0; - } - + --- 0 ---- Index: dynamicarray-annotated.patch =================================================================== RCS file: dynamicarray-annotated.patch diff -N dynamicarray-annotated.patch *** /tmp/cvsrLmG7D Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,80 **** - *** dynamicarray.cpp Mon Jan 21 17:29:38 2002 - --- dynamicarray-annotated.cpp Tue Jan 22 07:06:15 2002 - *************** - *** 1,5 **** - #include "Pooma/Pooma.h" - ! #include "Pooma/DynamicArrays.h" - ! #include - - // Demonstrate using DynamicArrays. - --- 1,6 ---- - + - #include "Pooma/Pooma.h" - ! #include "Pooma/DynamicArrays.h" - ! #include <iostream> - - // Demonstrate using DynamicArrays. - *************** - *** 9,38 **** - Pooma::initialize(argc,argv); - - ! // Create a DynamicArray with one element. - ! DynamicArray<> d0(1); - ! DynamicArray d01(1); - ! DynamicArray d02(1); - - ! // Add five more elements. - d0.create(5); - // Store values in the array. - ! for (int i = d0.domain().first(); i <= d0.domain().last(); ++i) - ! d0(i) = i; - - ! // Delete every other element. - ! d0.destroy(Range<1>(d0.domain().first(),d0.domain().last(),2), BackFill()); - - // Print the resulting array. - ! std::cout << d0 << std::endl; - - // Use the iterator form of 'destroy.' - ! DynamicArray<> d1(6); - for (int i = d1.domain().first(); i <= d1.domain().last(); ++i) - d1(i) = i; - ! int killList[] = { 0, 2, 4 }; - d1.destroy(killList, killList+3); - ! std::cout << d1 << std::endl; - - Pooma::finalize(); - return 0; - } - --- 10,40 ---- - Pooma::initialize(argc,argv); - - ! // Create a DynamicArray with one element. - ! DynamicArray<> d0(1); - ! DynamicArray<double> d01(1); - ! DynamicArray<double, Dynamic> d02(1); - - ! // Add five more elements. - d0.create(5); - // Store values in the array. - ! for (int i = d0.domain().first(); i <= d0.domain().last(); ++i) - ! d0(i) = i; - - ! // Delete every other element. - ! d0.destroy(Range<1>(d0.domain().first(),d0.domain().last(),2), BackFill()); - - // Print the resulting array. - ! std::cout &openopen; d0 &openopen; std::endl; - - // Use the iterator form of 'destroy.' - ! DynamicArray<> d1(6); - for (int i = d1.domain().first(); i <= d1.domain().last(); ++i) - d1(i) = i; - ! int killList[] = { 0, 2, 4 }; - d1.destroy(killList, killList+3); - ! std::cout &openopen; d1 &openopen; std::endl; - - Pooma::finalize(); - return 0; - } - + --- 0 ---- Index: examples/array-copy-annotated.patch =================================================================== RCS file: array-copy-annotated.patch diff -N array-copy-annotated.patch *** /tmp/cvsaoaUyu Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,77 **** - *** array-copy.cpp Thu Jan 24 11:12:23 2002 - --- array-copy-annotated.cpp Thu Jan 24 11:12:49 2002 - *************** - *** 1,8 **** - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include - - // Changes the Array value at index (0,0). - ! void changeValue(Array<2,int,Brick>& z) - { z(0,0) = 6; } - - --- 1,9 ---- - + - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include <iostream> - - // Changes the Array value at index (0,0). - ! void changeValue(Array<2,int,Brick>& z) - { z(0,0) = 6; } - - *************** - *** 11,17 **** - Pooma::initialize(argc,argv); - - ! Array<2,int,Brick> a(3,4, ModelElement(4)); - ! std::cout << "Initial value:\n"; - ! std::cout << "a: " << a(0,0) << std::endl; - - // Array copies share the same underlying values. - --- 12,18 ---- - Pooma::initialize(argc,argv); - - ! Array<2,int,Brick> a(3,4, ModelElement<int>(4)); - ! std::cout &openopen; "Initial value:\n"; - ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; - - // Array copies share the same underlying values. - *************** - *** 19,35 **** - // Explicit initialization uses reference semantics so changing the - // copy's value at (0,0) also changes the original's value. - ! Array<2,int,Brick> b(a); - b(0,0) = 5; - ! std::cout << "After explicit initialization.\n"; - ! std::cout << "a: " << a(0,0) << std::endl; - ! std::cout << "b: " << b(0,0) << std::endl; - - // Initialization of function arguments also uses reference semantics. - ! std::cout << "After function call:\n"; - changeValue(a); - ! std::cout << "a: " << a(0,0) << std::endl; - ! std::cout << "b: " << b(0,0) << std::endl; - - Pooma::finalize(); - return 0; - } - --- 20,37 ---- - // Explicit initialization uses reference semantics so changing the - // copy's value at (0,0) also changes the original's value. - ! Array<2,int,Brick> b(a); - b(0,0) = 5; - ! std::cout &openopen; "After explicit initialization.\n"; - ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; - ! std::cout &openopen; "b: " &openopen; b(0,0) &openopen; std::endl; - - // Initialization of function arguments also uses reference semantics. - ! std::cout &openopen; "After function call:\n"; - changeValue(a); - ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; - ! std::cout &openopen; "b: " &openopen; b(0,0) &openopen; std::endl; - - Pooma::finalize(); - return 0; - } - + --- 0 ---- Index: examples/array-size-annotated.patch =================================================================== RCS file: array-size-annotated.patch diff -N array-size-annotated.patch *** /tmp/cvsh5HZIk Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,67 **** - *** array-size.cpp Tue Jan 15 12:59:40 2002 - --- array-size-annotated.cpp Tue Jan 15 13:30:07 2002 - *************** - *** 1,5 **** - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include - - // Print an Array's Size - --- 1,6 ---- - + - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include <iostream> - - // Print an Array's Size - *************** - *** 10,22 **** - // member functions. - - ! template - inline - ! long computeArraySize(const Array& a) - { - ! const Loc fs = a.firsts(); - ! const Loc ls = a.lasts(); - ! const Loc lens = a.lengths(); - long size = 1; - ! for (int d = 0; d < Dim; ++d) { - size *= (ls[d] - fs[d] + 1).first(); - // Check that lengths() and our computed lengths agree. - --- 11,23 ---- - // member functions. - - ! template <int Dim, typename Type, typename EngineTag> - inline - ! long computeArraySize(const Array<Dim,Type,EngineTag>& a) - { - ! const Loc<Dim> fs = a.firsts(); - ! const Loc<Dim> ls = a.lasts(); - ! const Loc<Dim> lens = a.lengths(); - long size = 1; - ! for (int d = 0; d < Dim; ++d) { - size *= (ls[d] - fs[d] + 1).first(); - // Check that lengths() and our computed lengths agree. - *************** - *** 30,38 **** - Pooma::initialize(argc,argv); - - ! Array<3,int,Brick> a(3,4,5, ModelElement(4)); - PAssert(computeArraySize(a) == a.size()); - ! std::cout << "The array's size is " << a.size() << ".\n"; - - Pooma::finalize(); - return 0; - } - --- 31,40 ---- - Pooma::initialize(argc,argv); - - ! Array<3,int,Brick> a(3,4,5, ModelElement<int>(4)); - PAssert(computeArraySize(a) == a.size()); - ! std::cout &openopen; "The array's size is " &openopen; a.size() &openopen; ".\n"; - - Pooma::finalize(); - return 0; - } - + --- 0 ---- Index: examples/dynamicarray-annotated.patch =================================================================== RCS file: dynamicarray-annotated.patch diff -N dynamicarray-annotated.patch *** /tmp/cvsilZAQa Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,80 **** - *** dynamicarray.cpp Mon Jan 21 17:29:38 2002 - --- dynamicarray-annotated.cpp Tue Jan 22 07:06:15 2002 - *************** - *** 1,5 **** - #include "Pooma/Pooma.h" - ! #include "Pooma/DynamicArrays.h" - ! #include - - // Demonstrate using DynamicArrays. - --- 1,6 ---- - + - #include "Pooma/Pooma.h" - ! #include "Pooma/DynamicArrays.h" - ! #include <iostream> - - // Demonstrate using DynamicArrays. - *************** - *** 9,38 **** - Pooma::initialize(argc,argv); - - ! // Create a DynamicArray with one element. - ! DynamicArray<> d0(1); - ! DynamicArray d01(1); - ! DynamicArray d02(1); - - ! // Add five more elements. - d0.create(5); - // Store values in the array. - ! for (int i = d0.domain().first(); i <= d0.domain().last(); ++i) - ! d0(i) = i; - - ! // Delete every other element. - ! d0.destroy(Range<1>(d0.domain().first(),d0.domain().last(),2), BackFill()); - - // Print the resulting array. - ! std::cout << d0 << std::endl; - - // Use the iterator form of 'destroy.' - ! DynamicArray<> d1(6); - for (int i = d1.domain().first(); i <= d1.domain().last(); ++i) - d1(i) = i; - ! int killList[] = { 0, 2, 4 }; - d1.destroy(killList, killList+3); - ! std::cout << d1 << std::endl; - - Pooma::finalize(); - return 0; - } - --- 10,40 ---- - Pooma::initialize(argc,argv); - - ! // Create a DynamicArray with one element. - ! DynamicArray<> d0(1); - ! DynamicArray<double> d01(1); - ! DynamicArray<double, Dynamic> d02(1); - - ! // Add five more elements. - d0.create(5); - // Store values in the array. - ! for (int i = d0.domain().first(); i <= d0.domain().last(); ++i) - ! d0(i) = i; - - ! // Delete every other element. - ! d0.destroy(Range<1>(d0.domain().first(),d0.domain().last(),2), BackFill()); - - // Print the resulting array. - ! std::cout &openopen; d0 &openopen; std::endl; - - // Use the iterator form of 'destroy.' - ! DynamicArray<> d1(6); - for (int i = d1.domain().first(); i <= d1.domain().last(); ++i) - d1(i) = i; - ! int killList[] = { 0, 2, 4 }; - d1.destroy(killList, killList+3); - ! std::cout &openopen; d1 &openopen; std::endl; - - Pooma::finalize(); - return 0; - } - + --- 0 ---- Index: examples/Doof2d/Doof2d-Array-distributed-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Attic/Doof2d-Array-distributed-annotated.patch,v retrieving revision 1.7 diff -c -p -r1.7 Doof2d-Array-distributed-annotated.patch *** examples/Doof2d/Doof2d-Array-distributed-annotated.patch 2002/01/25 03:27:30 1.7 --- examples/Doof2d/Doof2d-Array-distributed-annotated.patch 2002/01/31 21:52:13 *************** *** 1,57 **** ! *** Doof2d-Array-distributed.cpp Wed Dec 5 14:04:36 2001 ! --- Doof2d-Array-distributed-annotated.cpp Wed Dec 5 14:07:56 2001 *************** ! *** 1,3 **** ! #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations ! --- 1,5 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations *************** ! *** 14,18 **** ! // (i,j). The "C" template parameter permits use of this stencil // operator with both Arrays and Fields. ! template inline typename C::Element_t ! --- 16,20 ---- ! // (i,j). The "C" template parameter permits use of this stencil // operator with both Arrays and Fields. ! template <class C> inline typename C::Element_t *************** ! *** 42,46 **** ! // canot use standard input and output. Instead we use command-line ! // arguments, which are replicated, for input, and we use an Inform ! ! // stream for output. ! Inform output; ! --- 44,48 ---- ! // canot use standard input and output. Instead we use command-line ! // arguments, which are replicated, for input, and we use an Inform ! ! // stream for output. Inform output; ! *************** ! *** 48,52 **** if (argc != 4) { // Incorrect number of command-line arguments. ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; return EXIT_FAILURE; } ! --- 50,54 ---- if (argc != 4) { // Incorrect number of command-line arguments. ! ! output &openopen; argv[0] &openopen; ": number-of-processors number-of-averagings number-of-values" &openopen; std::endl; return EXIT_FAILURE; } *************** ! *** 55,63 **** // Determine the number of processors. long nuProcessors; ! nuProcessors = strtol(argv[1], &tail, 0); --- 1,99 ---- ! *** Doof2d-Array-distributed.cpp Mon Jan 28 20:35:07 2002 ! --- Doof2d-Array-distributed-annotated.cpp Thu Jan 31 09:12:19 2002 *************** ! *** 1,6 **** ! #include // has EXIT_SUCCESS ! ! #include "Pooma/Arrays.h" // has POOMA's Array declarations ! ! // Doof2d: POOMA Arrays, stencil, multiple processor implementation ! ! // Define the stencil class performing the computation. ! --- 1,10 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! ! #include "Pooma/Arrays.h" ! ! // has POOMA's Array declarations ! ! ! // Doof2d: POOMA Arrays, stencil, multiple ! ! // processor implementation + // Define the stencil class performing the computation. *************** ! *** 11,26 **** ! DoofNinePt() : weight(1.0/9.0) {} ! ! ! // This stencil operator is applied to each interior domain position ! ! // (i,j). The "C" template parameter permits use of this stencil // operator with both Arrays and Fields. ! template inline typename C::Element_t ! ! operator()(const C& x, int i, int j) const ! ! { ! ! return ( weight * ! ! ( x.read(i+1,j+1) + x.read(i+1,j ) + x.read(i+1,j-1) + ! ! x.read(i ,j+1) + x.read(i ,j ) + x.read(i ,j-1) + ! ! x.read(i-1,j+1) + x.read(i-1,j ) + x.read(i-1,j-1) ) ); ! } ! ! --- 15,31 ---- ! DoofNinePt() : weight(1.0/9.0) {} ! ! ! // This stencil operator is applied to each interior ! ! // domain position (i,j). The "C" template ! ! // parameter permits use of this stencil // operator with both Arrays and Fields. ! template <class C> inline typename C::Element_t + ! operator()(const C& x, int i, int j) const { + ! return + ! weight * + ! (x.read(i+1,j+1)+x.read(i+1,j)+x.read(i+1,j-1) + + ! x.read(i ,j+1)+x.read(i ,j)+x.read(i ,j-1) + + ! x.read(i-1,j+1)+x.read(i-1,j)+x.read(i-1,j-1)); + } + *************** ! *** 39,52 **** ! Pooma::initialize(argc,argv); ! ! // Since multiple copies of this program may simultaneously run, we ! ! // cannot use standard input and output. Instead we use command-line ! ! // arguments, which are replicated, for input, and we use an Inform ! ! // stream for output. Inform output; ! ! // Read the program input from the command-line arguments. if (argc != 4) { // Incorrect number of command-line arguments. ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; return EXIT_FAILURE; } ! --- 44,63 ---- ! Pooma::initialize(argc,argv); ! ! ! // Since multiple copies of this program may simul- ! ! // taneously run, we cannot use standard input and ! ! // output. Instead we use command-line arguments, ! ! // which are replicated, for input, and we use an ! ! // Inform stream for output. ! Inform output; ! ! ! // Read the program input from the command-line ! ! // arguments. if (argc != 4) { // Incorrect number of command-line arguments. ! ! output &openopen; ! ! argv[0] &openopen; ! ! ": number-of-processors number-of-averagings" ! ! &openopen; " number-of-values" ! ! &openopen; std::endl; return EXIT_FAILURE; } *************** ! *** 55,112 **** // Determine the number of processors. long nuProcessors; ! nuProcessors = strtol(argv[1], &tail, 0); *************** *** 59,149 **** // Determine the number of averagings. long nuAveragings, nuIterations; ! nuAveragings = strtol(argv[2], &tail, 0); ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! ! --- 57,65 ---- ! // Determine the number of processors. ! long nuProcessors; ! ! nuProcessors = strtol(argv[1], &tail, 0); ! ! // Determine the number of averagings. ! long nuAveragings, nuIterations; ! ! nuAveragings = strtol(argv[2], &tail, 0); ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! *************** ! *** 65,69 **** ! // the grid. long n; ! n = strtol(argv[3], &tail, 0); ! // The dimension must be a multiple of the number of processors ! // since we are using a UniformGridLayout. ! --- 67,71 ---- ! // the grid. ! long n; ! ! n = strtol(argv[3], &tail, 0); ! // The dimension must be a multiple of the number of processors ! // since we are using a UniformGridLayout. ! *************** ! *** 71,80 **** // Specify the arrays' domains [0,n) x [0,n). ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! // Set up interior domains [1,n-1) x [1,n-1) for computation. ! Interval<1> I(1,n-2); ! Interval<2> interiorDomain(I,I); - // Create the distributed arrays. - --- 73,82 ---- - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - // Create the distributed arrays. ! *************** ! *** 83,98 **** ! // dimension. Guard layers optimize communication between patches. ! // Internal guards surround each patch. External guards surround ! // the entire array domain. ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), ! GuardLayers<2>(1), // internal ! GuardLayers<2>(0)); // external ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); ! ! // The Array template parameters indicate 2 dimensions and a 'double' ! // value type. MultiPatch indicates multiple computation patches, ! // i.e., distributed computation. The UniformTag indicates the ! // patches should have the same size. Each patch has Brick type. ! Array<2, double, MultiPatch > > a(layout); ! Array<2, double, MultiPatch > > b(layout); - // Set up the initial conditions. - --- 85,100 ---- - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire array domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // The Array template parameters indicate 2 dimensions and a 'double' - // value type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > a(layout); - ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > b(layout); - // Set up the initial conditions. ! *************** ! *** 104,112 **** // Create the stencil performing the computation. ! Stencil stencil; --- 101,148 ---- // Determine the number of averagings. long nuAveragings, nuIterations; ! nuAveragings = strtol(argv[2], &tail, 0); ! ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! ! // Ask the user for the number n of values along one dimension of ! ! // the grid. long n; ! n = strtol(argv[3], &tail, 0); ! ! // The dimension must be a multiple of the number of processors ! ! // since we are using a UniformGridLayout. ! ! n = ((n+nuProcessors-1) / nuProcessors) * nuProcessors; // Specify the arrays' domains [0,n) x [0,n). ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! ! // Set up interior domains [1,n-1) x [1,n-1) for computation. ! Interval<1> I(1,n-2); ! Interval<2> interiorDomain(I,I); // Create the distributed arrays. ! ! // Partition the arrays' domains uniformly, i.e., each patch has the ! ! // same size. The first parameter tells how many patches for each ! ! // dimension. Guard layers optimize communication between patches. ! ! // Internal guards surround each patch. External guards surround ! // the entire array domain. ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), ! GuardLayers<2>(1), // internal ! GuardLayers<2>(0)); // external ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); ! ! ! ! // The Array template parameters indicate 2 dimensions and a 'double' ! ! // value type. MultiPatch indicates multiple computation patches, ! ! // i.e., distributed computation. The UniformTag indicates the ! // patches should have the same size. Each patch has Brick type. ! Array<2, double, MultiPatch > > a(layout); ! Array<2, double, MultiPatch > > b(layout); // Set up the initial conditions. ! ! // All grid values should be zero except for the central value. ! a = b = 0.0; ! ! // Ensure all data-parallel computation finishes before accessing a value. ! Pooma::blockAndEvaluate(); ! b(n/2,n/2) = 1000.0; // Create the stencil performing the computation. ! Stencil stencil; *************** *** 152,160 **** ! for (int k = 0; k < nuIterations; ++k) { ! // Read from b. Write to a. a(interiorDomain) = stencil(b, interiorDomain); ! --- 106,114 ---- // Create the stencil performing the computation. ! Stencil<DoofNinePt> stencil; --- 151,222 ---- ! for (int k = 0; k < nuIterations; ++k) { ! // Read from b. Write to a. a(interiorDomain) = stencil(b, interiorDomain); + + --- 66,137 ---- + // Determine the number of processors. + long nuProcessors; + ! nuProcessors = strtol(argv[1], &tail, 0); + + // Determine the number of averagings. + long nuAveragings, nuIterations; + ! nuAveragings = strtol(argv[2], &tail, 0); + ! nuIterations = (nuAveragings+1)/2; + ! // Each iteration performs two averagings. + + ! // Ask the user for the number n of values along + ! // one dimension of the grid. + long n; + ! n = strtol(argv[3], &tail, 0); + ! // The dimension must be a multiple of the number + ! // of processors since we are using a + ! // UniformGridLayout. + ! n=((n+nuProcessors-1)/nuProcessors)*nuProcessors; + + // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); ! ! // Set up interior domains [1,n-1) x [1,n-1) ! ! // for computation. ! ! Interval<1> I(1,n-2); ! ! Interval<2> interiorDomain(I,I); ! ! // Create the distributed arrays. ! ! ! ! // Partition the arrays' domains uniformly, i.e., ! ! // each patch has the same size. The first para- ! ! // meter tells how many patches for each dimension. ! ! // Guard layers optimize communication between ! ! // patches. Internal guards surround each patch. ! ! // External guards surround the entire array ! ! // domain. ! ! UniformGridPartition<2> ! ! partition(Loc<2>(nuProcessors, nuProcessors), ! ! GuardLayers<2>(1), // internal ! ! GuardLayers<2>(0)); // external ! ! UniformGridLayout<2> layout(vertDomain, partition, ! ! DistributedTag()); ! ! ! ! // The Array template parameters indicate 2 dims ! ! // and a 'double' value type. MultiPatch indicates ! ! // multiple computation patches, i.e, distributed ! ! // computation. The UniformTag indicates the ! ! // patches should have the same size. Each patch ! ! // has Brick type. ! ! Array<2, double, MultiPatch<UniformTag, ! ! Remote<Brick> > > a(layout); ! ! Array<2, double, MultiPatch<UniformTag, ! ! Remote<Brick> > > b(layout); + // Set up the initial conditions. + ! // All grid values should be zero except for the + ! // central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes + ! // before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; + // Create the stencil performing the computation. ! Stencil<DoofNinePt> stencil; *************** *** 164,184 **** a(interiorDomain) = stencil(b, interiorDomain); *************** ! *** 117,121 **** // Print out the final central value. ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; // The arrays are automatically deallocated. ! --- 119,123 ---- // Print out the final central value. ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! ! output &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; // The arrays are automatically deallocated. *************** *** 125,126 **** ! --- 127,129 ---- return EXIT_SUCCESS; } + --- 226,251 ---- a(interiorDomain) = stencil(b, interiorDomain); *************** ! *** 116,121 **** ! // Print out the final central value. ! ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; // The arrays are automatically deallocated. ! --- 141,149 ---- ! // Print out the final central value. ! ! Pooma::blockAndEvaluate(); ! ! // Ensure all computation has finished. ! ! output &openopen; ! ! (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) ! ! &openopen; std::endl; // The arrays are automatically deallocated. *************** *** 125,126 **** ! --- 153,155 ---- return EXIT_SUCCESS; } + Index: examples/Doof2d/Doof2d-Array-element-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Attic/Doof2d-Array-element-annotated.patch,v retrieving revision 1.7 diff -c -p -r1.7 Doof2d-Array-element-annotated.patch *** examples/Doof2d/Doof2d-Array-element-annotated.patch 2002/01/25 03:27:30 1.7 --- examples/Doof2d/Doof2d-Array-element-annotated.patch 2002/01/31 21:52:13 *************** *** 1,5 **** ! *** Doof2d-Array-element.cpp Tue Dec 4 12:02:10 2001 ! --- Doof2d-Array-element-annotated.cpp Wed Jan 23 16:35:29 2002 *************** *** 1,5 **** ! #include // has std::cout, ... --- 1,5 ---- ! *** Doof2d-Array-element.cpp Wed Jan 23 19:18:17 2002 ! --- Doof2d-Array-element-annotated.cpp Thu Jan 31 08:55:57 2002 *************** *** 1,5 **** ! #include // has std::cout, ... *************** *** 7,21 **** ! #include "Pooma/Arrays.h" // has POOMA's Array declarations // Doof2d: POOMA Arrays, element-wise implementation ! --- 1,6 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! ! #include "Pooma/Arrays.h" // has POOMA's Array declarations // Doof2d: POOMA Arrays, element-wise implementation *************** ! *** 7,17 **** int main(int argc, char *argv[]) { ! // Prepare the POOMA library for execution. --- 7,22 ---- ! #include "Pooma/Arrays.h" // has POOMA's Array declarations // Doof2d: POOMA Arrays, element-wise implementation ! --- 1,7 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! ! #include "Pooma/Arrays.h" ! ! // has POOMA's Array declarations // Doof2d: POOMA Arrays, element-wise implementation *************** ! *** 7,37 **** int main(int argc, char *argv[]) { ! // Prepare the POOMA library for execution. *************** *** 25,47 **** long nuAveragings, nuIterations; ! std::cout << "Please enter the number of averagings: "; ! std::cin >> nuAveragings; ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! --- 8,18 ---- ! int main(int argc, char *argv[]) ! { ! ! // Prepare the POOMA library for execution. ! Pooma::initialize(argc,argv); ! ! // Ask the user for the number of averagings. ! long nuAveragings, nuIterations; ! ! std::cout &openopen; "Please enter the number of averagings: "; ! ! std::cin &closeclose; nuAveragings; ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! ! *************** ! *** 19,37 **** ! // the grid. long n; ! std::cout << "Please enter the array size: "; ! std::cin >> n; --- 26,35 ---- long nuAveragings, nuIterations; ! std::cout << "Please enter the number of averagings: "; ! std::cin >> nuAveragings; ! ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! ! // Ask the user for the number n of values along one dimension of ! ! // the grid. long n; ! std::cout << "Please enter the array size: "; ! std::cin >> n; *************** *** 49,57 **** ! // Specify the arrays' domains [0,n) x [0,n). ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! ! // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); --- 37,45 ---- ! // Specify the arrays' domains [0,n) x [0,n). ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! ! ! // Create the arrays. ! ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); *************** *** 60,67 **** ! // All grid values should be zero except for the central value. for (int j = 1; j < n-1; j++) for (int i = 1; i < n-1; i++) ! --- 20,38 ---- ! // the grid. long n; ! std::cout &openopen; "Please enter the array size: "; ! std::cin &closeclose; n; --- 48,68 ---- ! // All grid values should be zero except for the central value. for (int j = 1; j < n-1; j++) for (int i = 1; i < n-1; i++) ! --- 9,42 ---- ! int main(int argc, char *argv[]) ! { ! ! // Prepare the POOMA library for execution. ! Pooma::initialize(argc,argv); ! ! // Ask the user for the number of averagings. ! long nuAveragings, nuIterations; ! ! std::cout &openopen; "Please enter the number of averagings: "; ! ! std::cin &closeclose; nuAveragings; ! ! nuIterations = (nuAveragings+1)/2; ! ! // Each iteration performs two averagings. ! ! ! // Ask the user for the number n of values along ! ! // one dimension of the grid. long n; ! std::cout &openopen; "Please enter the array size: "; ! std::cin &closeclose; n; *************** *** 69,83 **** ! // Specify the arrays' domains [0,n) x [0,n). ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! ! // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); // Set up the initial conditions. ! ! // All grid values should be zero except for the central value. for (int j = 1; j < n-1; j++) for (int i = 1; i < n-1; i++) *************** --- 70,86 ---- ! // Specify the arrays' domains [0,n) x [0,n). ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! ! ! // Create the arrays. ! ! // The Array template parameters indicate ! ! // 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); // Set up the initial conditions. ! ! // All grid values should be zero except for the ! ! // central value. for (int j = 1; j < n-1; j++) for (int i = 1; i < n-1; i++) *************** *************** *** 91,97 **** ! a(i,j) = weight * (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + b(i ,j+1) + b(i ,j ) + b(i ,j-1) + ! --- 44,52 ---- // Perform the simulation. ! for (int k = 0; k < nuIterations; ++k) { --- 94,100 ---- ! a(i,j) = weight * (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + b(i ,j+1) + b(i ,j ) + b(i ,j-1) + ! --- 48,56 ---- // Perform the simulation. ! for (int k = 0; k < nuIterations; ++k) { *************** *** 109,115 **** ! for (int i = 1; i < n-1; i++) b(i,j) = weight * (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + ! --- 54,59 ---- // Read from a. Write to b. ! for (int j = 1; j < n-1; j++) --- 112,118 ---- ! for (int i = 1; i < n-1; i++) b(i,j) = weight * (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + ! --- 58,63 ---- // Read from a. Write to b. ! for (int j = 1; j < n-1; j++) *************** *** 128,142 **** Pooma::finalize(); return EXIT_SUCCESS; } ! --- 63,74 ---- // Print out the final central value. ! ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; ! // The arrays are automatically deallocated. ! ! // Tell the POOMA library execution has finished. Pooma::finalize(); return EXIT_SUCCESS; } --- 131,148 ---- Pooma::finalize(); return EXIT_SUCCESS; } ! --- 67,81 ---- // Print out the final central value. ! ! Pooma::blockAndEvaluate(); ! ! // Ensure all computation has finished. ! ! std::cout &openopen; ! ! (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) ! ! &openopen; std::endl; ! // The arrays are automatically deallocated. ! ! // Tell the POOMA library execution finished. Pooma::finalize(); return EXIT_SUCCESS; } Index: examples/Doof2d/Doof2d-Array-parallel-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Attic/Doof2d-Array-parallel-annotated.patch,v retrieving revision 1.7 diff -c -p -r1.7 Doof2d-Array-parallel-annotated.patch *** examples/Doof2d/Doof2d-Array-parallel-annotated.patch 2002/01/25 03:27:30 1.7 --- examples/Doof2d/Doof2d-Array-parallel-annotated.patch 2002/01/31 21:52:13 *************** *** 1,35 **** ! *** Doof2d-Array-parallel.cpp Tue Dec 4 11:49:43 2001 ! --- Doof2d-Array-parallel-annotated.cpp Wed Jan 23 16:35:54 2002 *************** ! *** 1,4 **** ! #include // has std::cout, ... ! #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations ! --- 1,5 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations *************** ! *** 12,17 **** // Ask the user for the number of averagings. long nuAveragings, nuIterations; ! std::cout << "Please enter the number of averagings: "; ! std::cin >> nuAveragings; ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! --- 13,18 ---- ! // Ask the user for the number of averagings. ! long nuAveragings, nuIterations; ! ! std::cout &openopen; "Please enter the number of averagings: "; ! ! std::cin &closeclose; nuAveragings; ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! ! *************** ! *** 19,43 **** ! // the grid. long n; ! std::cout << "Please enter the array size: "; ! std::cin >> n; --- 1,30 ---- ! *** Doof2d-Array-parallel.cpp Wed Jan 23 19:18:32 2002 ! --- Doof2d-Array-parallel-annotated.cpp Mon Jan 28 20:41:18 2002 *************** ! *** 1,5 **** ! #include // has std::cout, ... ! #include // has EXIT_SUCCESS ! ! #include "Pooma/Arrays.h" // has POOMA's Array declarations ! // Doof2d: POOMA Arrays, data-parallel implementation ! --- 1,7 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! ! #include "Pooma/Arrays.h" ! ! // has POOMA's Array declarations + // Doof2d: POOMA Arrays, data-parallel implementation *************** ! *** 12,43 **** // Ask the user for the number of averagings. long nuAveragings, nuIterations; ! std::cout << "Please enter the number of averagings: "; ! std::cin >> nuAveragings; ! ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! ! // Ask the user for the number n of values along one dimension of ! ! // the grid. long n; ! std::cout << "Please enter the array size: "; ! std::cin >> n; *************** *** 43,61 **** ! Interval<1> J(1,n-2); // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); // Set up the initial conditions. ! // All grid values should be zero except for the central value. a = b = 0.0; ! // Ensure all data-parallel computation finishes before accessing a value. Pooma::blockAndEvaluate(); b(n/2,n/2) = 1000.0; ! --- 20,44 ---- ! // the grid. long n; ! std::cout &openopen; "Please enter the array size: "; ! std::cin &closeclose; n; --- 38,64 ---- ! Interval<1> J(1,n-2); // Create the arrays. ! ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); // Set up the initial conditions. ! ! // All grid values should be zero except for the central value. a = b = 0.0; ! // Ensure all data-parallel computation finishes before accessing a value. Pooma::blockAndEvaluate(); b(n/2,n/2) = 1000.0; ! --- 14,50 ---- ! // Ask the user for the number of averagings. ! long nuAveragings, nuIterations; ! ! std::cout &openopen; "Please enter the number of averagings: "; ! ! std::cin &closeclose; nuAveragings; ! ! nuIterations = (nuAveragings+1)/2; ! ! // Each iteration performs two averagings. ! ! ! // Ask the user for the number n of values along one ! ! // dimension of the grid. long n; ! std::cout &openopen; "Please enter the array size: "; ! std::cin &closeclose; n; *************** *** 64,83 **** ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! ! // Set up interior domains [1,n-1) x [1,n-1) for computation. ! Interval<1> I(1,n-2); ! Interval<1> J(1,n-2); // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); // Set up the initial conditions. ! // All grid values should be zero except for the central value. a = b = 0.0; ! ! // Ensure all data-parallel computation finishes before accessing a value. Pooma::blockAndEvaluate(); b(n/2,n/2) = 1000.0; *************** --- 67,90 ---- ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! ! // Set up interior domains [1,n-1) x [1,n-1) ! ! // for computation. ! Interval<1> I(1,n-2); ! Interval<1> J(1,n-2); // Create the arrays. ! ! // The Array template parameters indicate 2 dimensions, ! ! // a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); // Set up the initial conditions. ! ! // All grid values should be zero except for the ! ! // central value. a = b = 0.0; ! ! // Ensure all data-parallel computation finishes ! ! // before accessing a value. Pooma::blockAndEvaluate(); b(n/2,n/2) = 1000.0; *************** *************** *** 88,94 **** ! // Read from b. Write to a. a(I,J) = weight * (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + ! --- 48,53 ---- // Perform the simulation. ! for (int k = 0; k < nuIterations; ++k) { --- 95,101 ---- ! // Read from b. Write to a. a(I,J) = weight * (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + ! --- 54,59 ---- // Perform the simulation. ! for (int k = 0; k < nuIterations; ++k) { *************** *** 96,116 **** a(I,J) = weight * (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + *************** ! *** 63,67 **** // Print out the final central value. ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; // The arrays are automatically deallocated. ! --- 64,68 ---- // Print out the final central value. ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; // The arrays are automatically deallocated. *************** *** 71,72 **** ! --- 72,74 ---- return EXIT_SUCCESS; } + --- 103,128 ---- a(I,J) = weight * (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + *************** ! *** 62,67 **** ! // Print out the final central value. ! ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; // The arrays are automatically deallocated. ! --- 69,77 ---- ! // Print out the final central value. ! ! Pooma::blockAndEvaluate(); ! ! // Ensure all computation has finished. ! ! std::cout &openopen; ! ! (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) ! ! &openopen; std::endl; // The arrays are automatically deallocated. *************** *** 71,72 **** ! --- 81,83 ---- return EXIT_SUCCESS; } + Index: examples/Doof2d/Doof2d-Array-stencil-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Attic/Doof2d-Array-stencil-annotated.patch,v retrieving revision 1.7 diff -c -p -r1.7 Doof2d-Array-stencil-annotated.patch *** examples/Doof2d/Doof2d-Array-stencil-annotated.patch 2002/01/25 03:27:30 1.7 --- examples/Doof2d/Doof2d-Array-stencil-annotated.patch 2002/01/31 21:52:13 *************** *** 1,73 **** ! *** Doof2d-Array-stencil.cpp Tue Dec 4 11:49:39 2001 ! --- Doof2d-Array-stencil-annotated.cpp Wed Jan 23 16:36:15 2002 *************** *** 1,9 **** ! #include // has std::cout, ... ! #include // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations // Doof2d: POOMA Arrays, stencil implementation ! // Define the stencil class performing the computation. class DoofNinePt { ! --- 1,10 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! #include "Pooma/Arrays.h" // has POOMA's Array declarations // Doof2d: POOMA Arrays, stencil implementation ! ! // Define the stencil class performing the computation. class DoofNinePt { *************** ! *** 14,19 **** ! // This stencil operator is applied to each interior domain position ! // (i,j). The "C" template parameter permits use of this stencil ! // operator with both Arrays and Fields. ! template inline - typename C::Element_t - --- 15,20 ---- - // This stencil operator is applied to each interior domain position - // (i,j). The "C" template parameter permits use of this stencil - ! // operator with both Arrays and Fields. - ! template <class C> - inline typename C::Element_t ! *************** ! *** 26,30 **** } ! inline int lowerExtent(int) const { return 1; } inline int upperExtent(int) const { return 1; } ! --- 27,31 ---- } ! inline int lowerExtent(int) const { return 1; } inline int upperExtent(int) const { return 1; } *************** ! *** 42,47 **** // Ask the user for the number of averagings. long nuAveragings, nuIterations; ! std::cout << "Please enter the number of averagings: "; ! std::cin >> nuAveragings; ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! ! --- 43,48 ---- ! // Ask the user for the number of averagings. ! long nuAveragings, nuIterations; ! ! std::cout &openopen; "Please enter the number of averagings: "; ! ! std::cin &closeclose; nuAveragings; ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! *************** ! *** 49,68 **** ! // the grid. long n; ! std::cout << "Please enter the array size: "; ! std::cin >> n; --- 1,80 ---- ! *** Doof2d-Array-stencil.cpp Wed Jan 23 19:18:49 2002 ! --- Doof2d-Array-stencil-annotated.cpp Thu Jan 31 09:11:12 2002 *************** *** 1,9 **** ! #include // has std::cout, ... ! #include // has EXIT_SUCCESS ! ! #include "Pooma/Arrays.h" // has POOMA's Array declarations // Doof2d: POOMA Arrays, stencil implementation ! // Define the stencil class performing the computation. class DoofNinePt { ! --- 1,11 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! ! #include "Pooma/Arrays.h" ! ! // has POOMA's Array declarations // Doof2d: POOMA Arrays, stencil implementation ! ! // Define a stencil class performing computation. class DoofNinePt { *************** ! *** 12,30 **** ! DoofNinePt() : weight(1.0/9.0) {} ! ! ! // This stencil operator is applied to each interior domain position ! ! // (i,j). The "C" template parameter permits use of this stencil ! // operator with both Arrays and Fields. ! template inline typename C::Element_t ! ! operator()(const C& c, int i, int j) const ! ! { ! ! return ( weight * ! ! ( c.read(i+1,j+1) + c.read(i+1,j ) + c.read(i+1,j-1) + ! ! c.read(i ,j+1) + c.read(i ,j ) + c.read(i ,j-1) + ! ! c.read(i-1,j+1) + c.read(i-1,j ) + c.read(i-1,j-1) ) ); } ! inline int lowerExtent(int) const { return 1; } inline int upperExtent(int) const { return 1; } + + --- 14,33 ---- + DoofNinePt() : weight(1.0/9.0) {} ! ! // This stencil operator is applied to each ! ! // interior domain position (i,j). The "C" ! ! // template parameter permits use of this ! ! // stencil operator with both Arrays & Fields. ! ! template <class C> ! inline ! typename C::Element_t ! ! operator()(const C& c, int i, int j) const { ! ! return ! ! weight * ! ! (c.read(i+1,j+1)+c.read(i+1,j)+c.read(i+1,j-1)+ ! ! c.read(i ,j+1)+c.read(i ,j)+c.read(i ,j-1)+ ! ! c.read(i-1,j+1)+c.read(i-1,j)+c.read(i-1,j-1)); } ! inline int lowerExtent(int) const { return 1; } inline int upperExtent(int) const { return 1; } *************** ! *** 42,82 **** // Ask the user for the number of averagings. long nuAveragings, nuIterations; ! std::cout << "Please enter the number of averagings: "; ! std::cin >> nuAveragings; ! ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! ! // Ask the user for the number n of values along one dimension of ! ! // the grid. long n; ! std::cout << "Please enter the array size: "; ! std::cin >> n; *************** *** 76,94 **** ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! // Set up interior domains [1,n-1) x [1,n-1) for computation. ! Interval<1> I(1,n-2); ! Interval<2> interiorDomain(I,I); // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); // Set up the initial conditions. ! --- 50,69 ---- ! // the grid. long n; ! std::cout &openopen; "Please enter the array size: "; ! std::cin &closeclose; n; --- 83,123 ---- ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! ! // Set up interior domains [1,n-1) x [1,n-1) for computation. ! Interval<1> I(1,n-2); ! Interval<2> interiorDomain(I,I); // Create the arrays. ! ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); // Set up the initial conditions. ! ! // All grid values should be zero except for the central value. ! a = b = 0.0; ! ! // Ensure all data-parallel computation finishes before accessing a value. ! Pooma::blockAndEvaluate(); ! b(n/2,n/2) = 1000.0; ! ! ! // Create the stencil performing the computation. ! ! Stencil stencil; ! ! // Perform the simulation. ! ! for (int k = 0; k < nuIterations; ++k) { ! ! // Read from b. Write to a. ! a(interiorDomain) = stencil(b, interiorDomain); ! ! --- 45,90 ---- ! // Ask the user for the number of averagings. ! long nuAveragings, nuIterations; ! ! std::cout &openopen; "Please enter the number of averagings: "; ! ! std::cin &closeclose; nuAveragings; ! ! nuIterations = (nuAveragings+1)/2; ! ! // Each iteration performs two averagings. ! ! ! // Ask the user for the number n of values along one ! ! // dimension of the grid. long n; ! std::cout &openopen; "Please enter the array size: "; ! std::cin &closeclose; n; *************** *** 97,129 **** ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! // Set up interior domains [1,n-1) x [1,n-1) for computation. ! Interval<1> I(1,n-2); ! Interval<2> interiorDomain(I,I); // Create the arrays. ! // The Array template parameters indicate 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); // Set up the initial conditions. ! *************** ! *** 73,82 **** b(n/2,n/2) = 1000.0; ! ! // Create the stencil performing the computation. ! ! Stencil stencil; ! ! // Perform the simulation. ! ! for (int k = 0; k < nuIterations; ++k) { ! ! // Read from b. Write to a. ! a(interiorDomain) = stencil(b, interiorDomain); ! ! --- 74,83 ---- ! b(n/2,n/2) = 1000.0; ! ! ! // Create the stencil performing the computation. ! Stencil<DoofNinePt> stencil; // Perform the simulation. --- 126,153 ---- ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! ! // Set up interior domains [1,n-1) x [1,n-1) for ! ! // computation. ! Interval<1> I(1,n-2); ! Interval<2> interiorDomain(I,I); // Create the arrays. ! ! // The Array template parameters indicate ! ! // 2 dimensions, a 'double' value // type, and ordinary 'Brick' storage. ! Array<2, double, Brick> a(vertDomain); ! Array<2, double, Brick> b(vertDomain); // Set up the initial conditions. ! ! // All grid values should be zero except for the ! ! // central value. ! a = b = 0.0; ! ! // Ensure all data-parallel computation finishes ! ! // before accessing a value. ! Pooma::blockAndEvaluate(); b(n/2,n/2) = 1000.0; ! ! // Create a stencil performing the computation. ! Stencil<DoofNinePt> stencil; // Perform the simulation. *************** *** 132,152 **** a(interiorDomain) = stencil(b, interiorDomain); *************** ! *** 87,91 **** // Print out the final central value. ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; // The arrays are automatically deallocated. ! --- 88,92 ---- // Print out the final central value. ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; // The arrays are automatically deallocated. *************** *** 95,96 **** ! --- 96,98 ---- return EXIT_SUCCESS; } + --- 156,181 ---- a(interiorDomain) = stencil(b, interiorDomain); *************** ! *** 86,91 **** ! // Print out the final central value. ! ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; // The arrays are automatically deallocated. ! --- 94,102 ---- ! // Print out the final central value. ! ! Pooma::blockAndEvaluate(); ! ! // Ensure all computation has finished. ! ! std::cout &openopen; ! ! (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) ! ! &openopen; std::endl; // The arrays are automatically deallocated. *************** *** 95,96 **** ! --- 106,108 ---- return EXIT_SUCCESS; } + Index: examples/Doof2d/Doof2d-C-element-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Attic/Doof2d-C-element-annotated.patch,v retrieving revision 1.7 diff -c -p -r1.7 Doof2d-C-element-annotated.patch *** examples/Doof2d/Doof2d-C-element-annotated.patch 2002/01/25 03:27:30 1.7 --- examples/Doof2d/Doof2d-C-element-annotated.patch 2002/01/31 21:52:13 *************** *** 1,5 **** ! *** Doof2d-C-element.cpp Tue Dec 4 09:59:18 2001 ! --- Doof2d-C-element-annotated.cpp Wed Jan 23 16:34:20 2002 *************** *** 1,4 **** ! #include // has std::cout, ... --- 1,5 ---- ! *** Doof2d-C-element.cpp Thu Jan 31 08:46:50 2002 ! --- Doof2d-C-element-annotated.cpp Thu Jan 31 08:47:14 2002 *************** *** 1,4 **** ! #include // has std::cout, ... *************** *** 20,32 **** long nuAveragings, nuIterations; ! std::cout << "Please enter the number of averagings: "; ! std::cin >> nuAveragings; ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Use two-dimensional grids of values. double **a; double **b; ! // Ask the user for the number n of values along one dimension of ! // the grid. long n; ! std::cout << "Please enter the array size: "; --- 20,32 ---- long nuAveragings, nuIterations; ! std::cout << "Please enter the number of averagings: "; ! std::cin >> nuAveragings; ! ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Use two-dimensional grids of values. double **a; double **b; ! ! // Ask the user for the number n of values along one dimension of ! // the grid. long n; ! std::cout << "Please enter the array size: "; *************** *** 39,59 **** ! for (int i = 0; i < n; i++) { a[i] = new double[n]; b[i] = new double[n]; ! --- 7,31 ---- int main() { ! // Ask the user for the number of averagings. long nuAveragings, nuIterations; ! std::cout &openopen; "Please enter the number of averagings: "; ! std::cin &closeclose; nuAveragings; ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! // Use two-dimensional grids of values. double **a; double **b; ! // Ask the user for the number n of values along one dimension of ! ! // the grid. long n; ! std::cout &openopen; "Please enter the array size: "; ! std::cin &closeclose; n; --- 39,60 ---- ! for (int i = 0; i < n; i++) { a[i] = new double[n]; b[i] = new double[n]; ! --- 7,32 ---- int main() { ! // Ask the user for the number of averagings. long nuAveragings, nuIterations; ! std::cout &openopen; "Please enter the number of averagings: "; ! std::cin &closeclose; nuAveragings; ! ! nuIterations = (nuAveragings+1)/2; ! ! // Each iteration performs two averagings. ! // Use two-dimensional grids of values. double **a; double **b; ! ! // Ask the user for the number n of values along one ! ! // dimension of the grid. long n; ! std::cout &openopen; "Please enter the array size: "; ! std::cin &closeclose; n; *************** *** 75,81 **** a[i][j] = b[i][j] = 0.0; b[n/2][n/2] = 1000.0; ! ! // In the average, weight elements with this value. const double weight = 1.0/9.0; // Perform the simulation. --- 76,82 ---- a[i][j] = b[i][j] = 0.0; b[n/2][n/2] = 1000.0; ! ! // Average using this weight. const double weight = 1.0/9.0; // Perform the simulation. *************** *** 85,100 **** ! for (int i = 1; i < n-1; i++) a[i][j] = weight * (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + ! --- 33,50 ---- // Set up the initial conditions. ! ! // All grid values should be zero except for the central value. ! for (int j = 0; j < n; j++) ! for (int i = 0; i < n; i++) a[i][j] = b[i][j] = 0.0; b[n/2][n/2] = 1000.0; ! ! // In the average, weight elements with this value. const double weight = 1.0/9.0; // Perform the simulation. --- 86,102 ---- ! for (int i = 1; i < n-1; i++) a[i][j] = weight * (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + ! --- 34,52 ---- // Set up the initial conditions. ! ! // All grid values should be zero except for the ! ! // central value. ! for (int j = 0; j < n; j++) ! for (int i = 0; i < n; i++) a[i][j] = b[i][j] = 0.0; b[n/2][n/2] = 1000.0; ! ! // Average using this weight. const double weight = 1.0/9.0; // Perform the simulation. *************** *** 113,119 **** ! for (int i = 1; i < n-1; i++) b[i][j] = weight * (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + ! --- 52,58 ---- b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); ! // Read from a. Write to b. --- 115,121 ---- ! for (int i = 1; i < n-1; i++) b[i][j] = weight * (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + ! --- 54,60 ---- b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); ! // Read from a. Write to b. *************** *** 132,142 **** ! for (int i = 0; i < n; i++) { delete [] a[i]; delete [] b[i]; ! --- 61,69 ---- } ! // Print out the final central value. ! ! std::cout &openopen; (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) &openopen; std::endl; ! // Deallocate the arrays. ! for (int i = 0; i < n; i++) { --- 134,146 ---- ! for (int i = 0; i < n; i++) { delete [] a[i]; delete [] b[i]; ! --- 63,73 ---- } ! // Print out the final central value. ! ! std::cout &openopen; ! ! (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) ! ! &openopen; std::endl; ! // Deallocate the arrays. ! for (int i = 0; i < n; i++) { *************** *** 144,150 **** delete [] b[i]; *************** *** 73,74 **** ! --- 74,76 ---- return EXIT_SUCCESS; } + --- 148,154 ---- delete [] b[i]; *************** *** 73,74 **** ! --- 78,80 ---- return EXIT_SUCCESS; } + Index: examples/Doof2d/Doof2d-Field-distributed-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Attic/Doof2d-Field-distributed-annotated.patch,v retrieving revision 1.6 diff -c -p -r1.6 Doof2d-Field-distributed-annotated.patch *** examples/Doof2d/Doof2d-Field-distributed-annotated.patch 2002/01/25 03:27:30 1.6 --- examples/Doof2d/Doof2d-Field-distributed-annotated.patch 2002/01/31 21:52:13 *************** *** 1,26 **** ! *** Doof2d-Field-distributed.cpp Wed Dec 5 14:05:10 2001 ! --- Doof2d-Field-distributed-annotated.cpp Wed Jan 23 16:36:34 2002 *************** ! *** 1,3 **** ! #include // has EXIT_SUCCESS ! #include "Pooma/Fields.h" // has POOMA's Field declarations ! --- 1,4 ---- ! ! #include <stdlib.h> // has EXIT_SUCCESS ! #include "Pooma/Fields.h" // has POOMA's Field declarations *************** ! *** 12,16 **** ! // canot use standard input and output. Instead we use command-line ! // arguments, which are replicated, for input, and we use an Inform ! // stream for output. Inform output; ! --- 13,17 ---- ! // canot use standard input and output. Instead we use command-line ! // arguments, which are replicated, for input, and we use an Inform ! ! // stream for output. Inform output; *************** --- 1,41 ---- ! *** Doof2d-Field-distributed.cpp Wed Jan 23 19:20:15 2002 ! --- Doof2d-Field-distributed-annotated.cpp Wed Jan 30 16:40:27 2002 *************** ! *** 1,6 **** ! #include // has EXIT_SUCCESS ! ! #include "Pooma/Fields.h" // has POOMA's Field declarations ! ! // Doof2d: POOMA Fields, data-parallel, multiple processor implementation ! ! int main(int argc, char *argv[]) ! --- 1,9 ---- ! ! #include <stdlib.h> // has EXIT_SUCCESS ! ! #include "Pooma/Fields.h" ! ! // has POOMA's Field declarations ! ! ! // Doof2d: POOMA Fields, data-parallel, multiple ! ! // processor implementation + int main(int argc, char *argv[]) *************** ! *** 9,16 **** ! Pooma::initialize(argc,argv); ! ! ! // Since multiple copies of this program may simultaneously run, we ! ! // canot use standard input and output. Instead we use command-line ! ! // arguments, which are replicated, for input, and we use an Inform ! // stream for output. Inform output; ! --- 12,20 ---- ! Pooma::initialize(argc,argv); ! ! ! // Since multiple copies of this program may ! ! // simultaneously run, we canot use standard input ! ! // and output. Instead we use command-line ! ! // arguments, which are replicated, for input, and we ! ! // use an Inform stream for output. Inform output; *************** *************** *** 30,43 **** ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; return EXIT_FAILURE; } ! --- 19,23 ---- if (argc != 4) { // Incorrect number of command-line arguments. ! ! output &openopen; argv[0] &openopen; ": number-of-processors number-of-averagings number-of-values" &openopen; std::endl; return EXIT_FAILURE; } *************** ! *** 25,33 **** // Determine the number of processors. long nuProcessors; ! nuProcessors = strtol(argv[1], &tail, 0); --- 45,61 ---- ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; return EXIT_FAILURE; } ! --- 22,29 ---- if (argc != 4) { // Incorrect number of command-line arguments. ! ! output &openopen; argv[0] &openopen; ! ! ": number-of-processors number-of-averagings" ! ! &openopen; " number-of-values" ! ! &openopen; std::endl; return EXIT_FAILURE; } *************** ! *** 25,79 **** // Determine the number of processors. long nuProcessors; ! nuProcessors = strtol(argv[1], &tail, 0); *************** *** 45,116 **** // Determine the number of averagings. long nuAveragings, nuIterations; ! nuAveragings = strtol(argv[2], &tail, 0); ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! ! --- 26,34 ---- ! // Determine the number of processors. ! long nuProcessors; ! ! nuProcessors = strtol(argv[1], &tail, 0); ! // Determine the number of averagings. ! long nuAveragings, nuIterations; ! ! nuAveragings = strtol(argv[2], &tail, 0); ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! ! *************** ! *** 35,39 **** ! // the grid. long n; ! n = strtol(argv[3], &tail, 0); ! // The dimension must be a multiple of the number of processors ! // since we are using a UniformGridLayout. ! --- 36,40 ---- ! // the grid. ! long n; ! ! n = strtol(argv[3], &tail, 0); ! // The dimension must be a multiple of the number of processors ! // since we are using a UniformGridLayout. ! *************** ! *** 41,50 **** // Specify the fields' domains [0,n) x [0,n). ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! // Set up interior domains [1,n-1) x [1,n-1) for computation. ! Interval<1> I(1,n-2); ! Interval<1> J(1,n-2); ! ! // Partition the fields' domains uniformly, i.e., each patch has the ! --- 42,51 ---- ! ! // Specify the fields' domains [0,n) x [0,n). ! ! Interval<1> N(0, n-1); ! ! Interval<2> vertDomain(N, N); ! ! // Set up interior domains [1,n-1) x [1,n-1) for computation. ! ! Interval<1> I(1,n-2); ! ! Interval<1> J(1,n-2); ! ! // Partition the fields' domains uniformly, i.e., each patch has the ! *************** ! *** 52,74 **** ! // dimension. Guard layers optimize communication between patches. ! // Internal guards surround each patch. External guards surround ! // the entire field domain. ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), ! GuardLayers<2>(1), // internal ! GuardLayers<2>(0)); // external ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); ! ! // Specify the fields' mesh, i.e., its spatial extent, and its ! // centering type. ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); ! ! // The Field template parameters indicate a mesh and a 'double' ! // value type. MultiPatch indicates multiple computation patches, ! // i.e., distributed computation. The UniformTag indicates the ! // patches should have the same size. Each patch has Brick type. ! Field, double, MultiPatch > > a(cell, layout, mesh); --- 63,104 ---- // Determine the number of averagings. long nuAveragings, nuIterations; ! nuAveragings = strtol(argv[2], &tail, 0); ! ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! ! // Ask the user for the number n of values along one dimension of ! ! // the grid. long n; ! n = strtol(argv[3], &tail, 0); ! ! // The dimension must be a multiple of the number of processors ! ! // since we are using a UniformGridLayout. ! n = ((n+nuProcessors-1) / nuProcessors) * nuProcessors; // Specify the fields' domains [0,n) x [0,n). ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! ! // Set up interior domains [1,n-1) x [1,n-1) for computation. ! Interval<1> I(1,n-2); ! Interval<1> J(1,n-2); ! ! ! ! // Partition the fields' domains uniformly, i.e., each patch has the ! ! // same size. The first parameter tells how many patches for each ! ! // dimension. Guard layers optimize communication between patches. ! ! // Internal guards surround each patch. External guards surround ! // the entire field domain. ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), ! GuardLayers<2>(1), // internal ! GuardLayers<2>(0)); // external ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); ! ! ! ! // Specify the fields' mesh, i.e., its spatial extent, and its ! // centering type. ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); ! ! ! ! // The Field template parameters indicate a mesh and a 'double' ! ! // value type. MultiPatch indicates multiple computation patches, ! ! // i.e., distributed computation. The UniformTag indicates the ! // patches should have the same size. Each patch has Brick type. ! Field, double, MultiPatch > > a(cell, layout, mesh); *************** *** 118,147 **** ! Remote > > b(cell, layout, mesh); // Set up the initial conditions. ! --- 53,75 ---- ! // dimension. Guard layers optimize communication between patches. ! // Internal guards surround each patch. External guards surround ! ! // the entire field domain. ! ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), ! ! GuardLayers<2>(1), // internal ! ! GuardLayers<2>(0)); // external ! ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); ! ! // Specify the fields' mesh, i.e., its spatial extent, and its ! ! // centering type. ! ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); ! ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); ! ! // The Field template parameters indicate a mesh and a 'double' ! // value type. MultiPatch indicates multiple computation patches, ! // i.e., distributed computation. The UniformTag indicates the ! ! // patches should have the same size. Each patch has Brick type. ! ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, ! ! Remote<Brick> > > a(cell, layout, mesh); ! ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, ! ! Remote<Brick> > > b(cell, layout, mesh); // Set up the initial conditions. *************** *** 83,87 **** --- 106,185 ---- ! Remote > > b(cell, layout, mesh); // Set up the initial conditions. ! ! // All grid values should be zero except for the central value. ! a = b = 0.0; ! ! // Ensure all data-parallel computation finishes before accessing a value. ! Pooma::blockAndEvaluate(); ! b(n/2,n/2) = 1000.0; ! --- 32,99 ---- ! // Determine the number of processors. ! long nuProcessors; ! ! nuProcessors = strtol(argv[1], &tail, 0); ! ! // Determine the number of averagings. ! long nuAveragings, nuIterations; ! ! nuAveragings = strtol(argv[2], &tail, 0); ! ! nuIterations = (nuAveragings+1)/2; ! ! // Each iteration performs two averagings. ! ! ! // Ask the user for the number n of values along ! ! // one dimension of the grid. ! long n; ! ! n = strtol(argv[3], &tail, 0); ! ! // The dimension must be a multiple of the number of ! ! // processors since we are using a UniformGridLayout. ! n = ((n+nuProcessors-1) / nuProcessors) * nuProcessors; ! ! // Specify the fields' domains [0,n) x [0,n). ! ! Interval<1> N(0, n-1); ! ! Interval<2> vertDomain(N, N); + ! // Set up interior domains [1,n-1) x [1,n-1) for + ! // computation. + ! Interval<1> I(1,n-2); + ! Interval<1> J(1,n-2); + ! + ! // Partition the fields' domains uniformly, i.e., + ! // each patch has the same size. The first parameter + ! // tells how many patches for each dimension. Guard + ! // layers optimize communication between patches. + ! // Internal guards surround each patch. External + ! // guards surround the entire field domain. + ! UniformGridPartition<2> + ! partition(Loc<2>(nuProcessors, nuProcessors), + ! GuardLayers<2>(1), // internal + ! GuardLayers<2>(0)); // external + ! UniformGridLayout<2> + ! layout(vertDomain, partition, DistributedTag()); + ! + ! // Specify the fields' mesh, i.e., its spatial + ! // extent, and its centering type. + ! UniformRectilinearMesh<2> + ! mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); + ! Centering<2> cell = + ! canonicalCentering<2>(CellType, Continuous, AllDim); + ! + ! // The Field template parameters indicate a mesh and + ! // a 'double' value type. MultiPatch indicates + ! // multiple computation patches, i.e., distributed + ! // computation. The UniformTag indicates the patches + ! // should have the same size. Each patch has Brick + ! // type. + ! Field<UniformRectilinearMesh<2>, double, + ! MultiPatch<UniformTag, Remote<Brick&closecloseclose; + ! a(cell, layout, mesh); + ! Field<UniformRectilinearMesh<2>, double, + ! MultiPatch<UniformTag, Remote<Brick&closecloseclose; + ! b(cell, layout, mesh); + // Set up the initial conditions. + ! // All grid values should be zero except for the + ! // central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes + ! // before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; *************** *** 83,87 **** *************** *** 149,176 **** ! for (int k = 0; k < nuIterations; ++k) { // Read from b. Write to a. a(I,J) = weight * ! --- 84,88 ---- // Perform the simulation. ! for (int k = 0; k < nuIterations; ++k) { // Read from b. Write to a. a(I,J) = weight * *************** ! *** 99,103 **** // Print out the final central value. ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; // The fields are automatically deallocated. ! --- 100,104 ---- // Print out the final central value. ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! ! output &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; // The fields are automatically deallocated. *************** *** 107,108 **** ! --- 108,110 ---- return EXIT_SUCCESS; } + --- 187,219 ---- ! for (int k = 0; k < nuIterations; ++k) { // Read from b. Write to a. a(I,J) = weight * ! --- 103,107 ---- // Perform the simulation. ! for (int k = 0; k < nuIterations; ++k) { // Read from b. Write to a. a(I,J) = weight * *************** ! *** 98,103 **** ! // Print out the final central value. ! ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; // The fields are automatically deallocated. ! --- 118,126 ---- ! // Print out the final central value. ! ! Pooma::blockAndEvaluate(); ! ! // Ensure all computation has finished. ! ! output &openopen; ! ! (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) ! ! &openopen; std::endl; // The fields are automatically deallocated. *************** *** 107,108 **** ! --- 130,132 ---- return EXIT_SUCCESS; } + Index: examples/Doof2d/Doof2d-Field-parallel-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Attic/Doof2d-Field-parallel-annotated.patch,v retrieving revision 1.6 diff -c -p -r1.6 Doof2d-Field-parallel-annotated.patch *** examples/Doof2d/Doof2d-Field-parallel-annotated.patch 2002/01/25 03:27:30 1.6 --- examples/Doof2d/Doof2d-Field-parallel-annotated.patch 2002/01/31 21:52:13 *************** *** 1,5 **** ! *** Doof2d-Field-parallel.cpp Tue Dec 4 11:47:58 2001 ! --- Doof2d-Field-parallel-annotated.cpp Wed Jan 23 16:37:19 2002 *************** *** 1,5 **** ! #include // has std::cout, ... --- 1,5 ---- ! *** Doof2d-Field-parallel.cpp Wed Jan 23 19:20:33 2002 ! --- Doof2d-Field-parallel-annotated.cpp Thu Jan 31 09:07:32 2002 *************** *** 1,5 **** ! #include // has std::cout, ... *************** *** 7,37 **** ! #include "Pooma/Fields.h" // has POOMA's Field declarations // Doof2d: POOMA Fields, data-parallel implementation ! --- 1,6 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! ! #include "Pooma/Fields.h" // has POOMA's Field declarations // Doof2d: POOMA Fields, data-parallel implementation *************** ! *** 12,17 **** // Ask the user for the number of averagings. long nuAveragings, nuIterations; ! std::cout << "Please enter the number of averagings: "; ! std::cin >> nuAveragings; ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! --- 13,18 ---- ! // Ask the user for the number of averagings. ! long nuAveragings, nuIterations; ! ! std::cout &openopen; "Please enter the number of averagings: "; ! ! std::cin &closeclose; nuAveragings; ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! ! *************** ! *** 19,44 **** ! // the grid. long n; ! std::cout << "Please enter the field size: "; ! std::cin >> n; --- 7,30 ---- ! #include "Pooma/Fields.h" // has POOMA's Field declarations // Doof2d: POOMA Fields, data-parallel implementation ! --- 1,7 ---- ! ! #include <iostream> // has std::cout, ... ! #include <stdlib.h> // has EXIT_SUCCESS ! ! #include "Pooma/Fields.h" ! ! // has POOMA's Field declarations // Doof2d: POOMA Fields, data-parallel implementation *************** ! *** 12,49 **** // Ask the user for the number of averagings. long nuAveragings, nuIterations; ! std::cout << "Please enter the number of averagings: "; ! std::cin >> nuAveragings; ! ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. ! ! // Ask the user for the number n of values along one dimension of ! ! // the grid. long n; ! std::cout << "Please enter the field size: "; ! std::cin >> n; *************** *** 40,64 **** ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! // Set up interior domains [1,n-1) x [1,n-1) for computation. ! Interval<1> I(1,n-2); ! Interval<1> J(1,n-2); ! ! // Specify the fields' mesh, i.e., its spatial extent, and its ! // centering type. ! DomainLayout<2> layout(vertDomain); ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); // Create the fields. ! // The Field template parameters indicate a mesh, a 'double' value ! // type, and ordinary 'Brick' storage. ! Field, double, Brick> a(cell, layout, mesh); ! Field, double, Brick> b(cell, layout, mesh); // Set up the initial conditions. ! --- 20,45 ---- ! // the grid. long n; ! std::cout &openopen; "Please enter the field size: "; ! std::cin &closeclose; n; --- 33,70 ---- ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! ! // Set up interior domains [1,n-1) x [1,n-1) for computation. ! Interval<1> I(1,n-2); ! Interval<1> J(1,n-2); ! ! ! ! // Specify the fields' mesh, i.e., its spatial extent, and its ! // centering type. ! DomainLayout<2> layout(vertDomain); ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); // Create the fields. ! ! // The Field template parameters indicate a mesh, a 'double' value ! // type, and ordinary 'Brick' storage. ! Field, double, Brick> a(cell, layout, mesh); ! Field, double, Brick> b(cell, layout, mesh); // Set up the initial conditions. ! ! // All grid values should be zero except for the central value. ! a = b = 0.0; ! ! // Ensure all data-parallel computation finishes before accessing a value. ! Pooma::blockAndEvaluate(); ! b(n/2,n/2) = 1000.0; ! --- 14,60 ---- ! // Ask the user for the number of averagings. ! long nuAveragings, nuIterations; ! ! std::cout&openopen;"Please enter the number of averagings: "; ! ! std::cin &closeclose; nuAveragings; ! ! nuIterations = (nuAveragings+1)/2; ! ! // Each iteration performs two averagings. ! ! ! // Ask the user for the number n of values along ! ! // one dimension of the grid. long n; ! std::cout &openopen; "Please enter the field size: "; ! std::cin &closeclose; n; *************** *** 67,89 **** ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! // Set up interior domains [1,n-1) x [1,n-1) for computation. ! Interval<1> I(1,n-2); ! Interval<1> J(1,n-2); ! ! // Specify the fields' mesh, i.e., its spatial extent, and its ! ! // centering type. ! DomainLayout<2> layout(vertDomain); ! ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); ! ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); // Create the fields. ! // The Field template parameters indicate a mesh, a 'double' value ! ! // type, and ordinary 'Brick' storage. ! ! Field<UniformRectilinearMesh<2>, double, Brick> a(cell, layout, mesh); ! ! Field<UniformRectilinearMesh<2>, double, Brick> b(cell, layout, mesh); // Set up the initial conditions. *************** *** 53,58 **** --- 73,108 ---- ! Interval<1> N(0, n-1); ! Interval<2> vertDomain(N, N); ! ! // Set up interior domains [1,n-1) x [1,n-1) for ! ! // computation. ! Interval<1> I(1,n-2); ! Interval<1> J(1,n-2); ! ! ! ! // Specify the fields' mesh, i.e., its spatial ! ! // extent, and its centering type. ! DomainLayout<2> layout(vertDomain); ! ! UniformRectilinearMesh<2> ! ! mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); ! ! Centering<2> cell = ! ! canonicalCentering<2>(CellType, Continuous, AllDim); // Create the fields. ! ! // The Field template parameters indicate a mesh, a ! ! // 'double' value type, and ordinary 'Brick' ! ! // storage. ! ! Field<UniformRectilinearMesh<2>, double, Brick> ! ! a(cell, layout, mesh); ! ! Field<UniformRectilinearMesh<2>, double, Brick> ! ! b(cell, layout, mesh); // Set up the initial conditions. + ! // All grid values should be zero except for the + ! // central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes + ! // before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; *************** *** 53,58 **** *************** *** 92,98 **** ! // Read from b. Write to a. a(I,J) = weight * (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + ! --- 54,59 ---- // Perform the simulation. ! for (int k = 0; k < nuIterations; ++k) { --- 111,117 ---- ! // Read from b. Write to a. a(I,J) = weight * (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + ! --- 64,69 ---- // Perform the simulation. ! for (int k = 0; k < nuIterations; ++k) { *************** *** 100,120 **** a(I,J) = weight * (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + *************** ! *** 69,73 **** // Print out the final central value. ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; // The fields are automatically deallocated. ! --- 70,74 ---- // Print out the final central value. ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; // The fields are automatically deallocated. *************** *** 77,78 **** ! --- 78,80 ---- return EXIT_SUCCESS; } + --- 119,144 ---- a(I,J) = weight * (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + *************** ! *** 68,73 **** ! // Print out the final central value. ! ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; // The fields are automatically deallocated. ! --- 79,87 ---- ! // Print out the final central value. ! ! Pooma::blockAndEvaluate(); ! ! // Ensure all computation has finished. ! ! std::cout &openopen; ! ! (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) ! ! &openopen; std::endl; // The fields are automatically deallocated. *************** *** 77,78 **** ! --- 91,93 ---- return EXIT_SUCCESS; } + Index: examples/Doof2d/array-copy-annotated.patch =================================================================== RCS file: array-copy-annotated.patch diff -N array-copy-annotated.patch *** /tmp/cvsqJ3CRs Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,77 **** - *** array-copy.cpp Thu Jan 24 11:12:23 2002 - --- array-copy-annotated.cpp Thu Jan 24 11:12:49 2002 - *************** - *** 1,8 **** - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include - - // Changes the Array value at index (0,0). - ! void changeValue(Array<2,int,Brick>& z) - { z(0,0) = 6; } - - --- 1,9 ---- - + - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include <iostream> - - // Changes the Array value at index (0,0). - ! void changeValue(Array<2,int,Brick>& z) - { z(0,0) = 6; } - - *************** - *** 11,17 **** - Pooma::initialize(argc,argv); - - ! Array<2,int,Brick> a(3,4, ModelElement(4)); - ! std::cout << "Initial value:\n"; - ! std::cout << "a: " << a(0,0) << std::endl; - - // Array copies share the same underlying values. - --- 12,18 ---- - Pooma::initialize(argc,argv); - - ! Array<2,int,Brick> a(3,4, ModelElement<int>(4)); - ! std::cout &openopen; "Initial value:\n"; - ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; - - // Array copies share the same underlying values. - *************** - *** 19,35 **** - // Explicit initialization uses reference semantics so changing the - // copy's value at (0,0) also changes the original's value. - ! Array<2,int,Brick> b(a); - b(0,0) = 5; - ! std::cout << "After explicit initialization.\n"; - ! std::cout << "a: " << a(0,0) << std::endl; - ! std::cout << "b: " << b(0,0) << std::endl; - - // Initialization of function arguments also uses reference semantics. - ! std::cout << "After function call:\n"; - changeValue(a); - ! std::cout << "a: " << a(0,0) << std::endl; - ! std::cout << "b: " << b(0,0) << std::endl; - - Pooma::finalize(); - return 0; - } - --- 20,37 ---- - // Explicit initialization uses reference semantics so changing the - // copy's value at (0,0) also changes the original's value. - ! Array<2,int,Brick> b(a); - b(0,0) = 5; - ! std::cout &openopen; "After explicit initialization.\n"; - ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; - ! std::cout &openopen; "b: " &openopen; b(0,0) &openopen; std::endl; - - // Initialization of function arguments also uses reference semantics. - ! std::cout &openopen; "After function call:\n"; - changeValue(a); - ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; - ! std::cout &openopen; "b: " &openopen; b(0,0) &openopen; std::endl; - - Pooma::finalize(); - return 0; - } - + --- 0 ---- Index: examples/Doof2d/array-size-annotated.patch =================================================================== RCS file: array-size-annotated.patch diff -N array-size-annotated.patch *** /tmp/cvsrt0L1q Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,67 **** - *** array-size.cpp Tue Jan 15 12:59:40 2002 - --- array-size-annotated.cpp Tue Jan 15 13:30:07 2002 - *************** - *** 1,5 **** - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include - - // Print an Array's Size - --- 1,6 ---- - + - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include <iostream> - - // Print an Array's Size - *************** - *** 10,22 **** - // member functions. - - ! template - inline - ! long computeArraySize(const Array& a) - { - ! const Loc fs = a.firsts(); - ! const Loc ls = a.lasts(); - ! const Loc lens = a.lengths(); - long size = 1; - ! for (int d = 0; d < Dim; ++d) { - size *= (ls[d] - fs[d] + 1).first(); - // Check that lengths() and our computed lengths agree. - --- 11,23 ---- - // member functions. - - ! template <int Dim, typename Type, typename EngineTag> - inline - ! long computeArraySize(const Array<Dim,Type,EngineTag>& a) - { - ! const Loc<Dim> fs = a.firsts(); - ! const Loc<Dim> ls = a.lasts(); - ! const Loc<Dim> lens = a.lengths(); - long size = 1; - ! for (int d = 0; d < Dim; ++d) { - size *= (ls[d] - fs[d] + 1).first(); - // Check that lengths() and our computed lengths agree. - *************** - *** 30,38 **** - Pooma::initialize(argc,argv); - - ! Array<3,int,Brick> a(3,4,5, ModelElement(4)); - PAssert(computeArraySize(a) == a.size()); - ! std::cout << "The array's size is " << a.size() << ".\n"; - - Pooma::finalize(); - return 0; - } - --- 31,40 ---- - Pooma::initialize(argc,argv); - - ! Array<3,int,Brick> a(3,4,5, ModelElement<int>(4)); - PAssert(computeArraySize(a) == a.size()); - ! std::cout &openopen; "The array's size is " &openopen; a.size() &openopen; ".\n"; - - Pooma::finalize(); - return 0; - } - + --- 0 ---- Index: examples/Doof2d/dynamicarray-annotated.patch =================================================================== RCS file: dynamicarray-annotated.patch diff -N dynamicarray-annotated.patch *** /tmp/cvs0gWRWo Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,80 **** - *** dynamicarray.cpp Mon Jan 21 17:29:38 2002 - --- dynamicarray-annotated.cpp Tue Jan 22 07:06:15 2002 - *************** - *** 1,5 **** - #include "Pooma/Pooma.h" - ! #include "Pooma/DynamicArrays.h" - ! #include - - // Demonstrate using DynamicArrays. - --- 1,6 ---- - + - #include "Pooma/Pooma.h" - ! #include "Pooma/DynamicArrays.h" - ! #include <iostream> - - // Demonstrate using DynamicArrays. - *************** - *** 9,38 **** - Pooma::initialize(argc,argv); - - ! // Create a DynamicArray with one element. - ! DynamicArray<> d0(1); - ! DynamicArray d01(1); - ! DynamicArray d02(1); - - ! // Add five more elements. - d0.create(5); - // Store values in the array. - ! for (int i = d0.domain().first(); i <= d0.domain().last(); ++i) - ! d0(i) = i; - - ! // Delete every other element. - ! d0.destroy(Range<1>(d0.domain().first(),d0.domain().last(),2), BackFill()); - - // Print the resulting array. - ! std::cout << d0 << std::endl; - - // Use the iterator form of 'destroy.' - ! DynamicArray<> d1(6); - for (int i = d1.domain().first(); i <= d1.domain().last(); ++i) - d1(i) = i; - ! int killList[] = { 0, 2, 4 }; - d1.destroy(killList, killList+3); - ! std::cout << d1 << std::endl; - - Pooma::finalize(); - return 0; - } - --- 10,40 ---- - Pooma::initialize(argc,argv); - - ! // Create a DynamicArray with one element. - ! DynamicArray<> d0(1); - ! DynamicArray<double> d01(1); - ! DynamicArray<double, Dynamic> d02(1); - - ! // Add five more elements. - d0.create(5); - // Store values in the array. - ! for (int i = d0.domain().first(); i <= d0.domain().last(); ++i) - ! d0(i) = i; - - ! // Delete every other element. - ! d0.destroy(Range<1>(d0.domain().first(),d0.domain().last(),2), BackFill()); - - // Print the resulting array. - ! std::cout &openopen; d0 &openopen; std::endl; - - // Use the iterator form of 'destroy.' - ! DynamicArray<> d1(6); - for (int i = d1.domain().first(); i <= d1.domain().last(); ++i) - d1(i) = i; - ! int killList[] = { 0, 2, 4 }; - d1.destroy(killList, killList+3); - ! std::cout &openopen; d1 &openopen; std::endl; - - Pooma::finalize(); - return 0; - } - + --- 0 ---- Index: examples/Doof2d/initialize-finalize-annotated.patch =================================================================== RCS file: initialize-finalize-annotated.patch diff -N initialize-finalize-annotated.patch *** /tmp/cvsxFjk1o Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,20 **** - *** initialize-finalize.cpp Thu Jan 24 11:14:13 2002 - --- initialize-finalize-annotated.cpp Thu Jan 24 11:14:17 2002 - *************** - *** 1,4 **** - #include "Pooma/Pooma.h" - ! #include - - int main(int argc, char *argv[]) - --- 1,5 ---- - + - #include "Pooma/Pooma.h" - ! #include <iostream> - - int main(int argc, char *argv[]) - *************** - *** 11,12 **** - --- 12,14 ---- - return 0; - } - + --- 0 ---- Index: examples/Doof2d/pairs-templated-annotated.patch =================================================================== RCS file: pairs-templated-annotated.patch diff -N pairs-templated-annotated.patch *** /tmp/cvsq1PS0o Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,37 **** - *** pairs-templated.cpp Mon Jan 7 16:11:56 2002 - --- pairs-templated-annotated.cpp Wed Jan 23 12:33:13 2002 - *************** - *** 1,15 **** - // Declare a template class storing a pair of values with the same type. - ! template - struct pair { - ! pair(const int& left, const int& right) - : left_(left), right_(right) {} - - ! T left_; - T right_; - }; - - ! // Define a class storing a pair of integers. - ! pair pair1; - - ! // Define a class storing a pair of doubles; - ! pair pair2; - --- 1,17 ---- - + - // Declare a template class storing a pair of values with the same type. - ! template <typename T> // - struct pair { - ! pair(const T& left, const T& right) // - : left_(left), right_(right) {} - - ! T left_; // - T right_; - }; - - ! // Use a class storing a pair of integers. - ! pair<int> pair1; - - ! // Use a class storing a pair of doubles; - ! pair<double> pair2; - ! --- 0 ---- Index: examples/Sequential/Doof2d-Array-distributed-annotated.patch =================================================================== RCS file: Doof2d-Array-distributed-annotated.patch diff -N Doof2d-Array-distributed-annotated.patch *** /tmp/cvs5nG7Ho Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,184 **** - *** Doof2d-Array-distributed.cpp Wed Dec 5 14:04:36 2001 - --- Doof2d-Array-distributed-annotated.cpp Wed Dec 5 14:07:56 2001 - *************** - *** 1,3 **** - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has POOMA's Array declarations - - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has POOMA's Array declarations - - *************** - *** 14,18 **** - // (i,j). The "C" template parameter permits use of this stencil - // operator with both Arrays and Fields. - ! template - inline - typename C::Element_t - --- 16,20 ---- - // (i,j). The "C" template parameter permits use of this stencil - // operator with both Arrays and Fields. - ! template <class C> - inline - typename C::Element_t - *************** - *** 42,46 **** - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - --- 44,48 ---- - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - *************** - *** 48,52 **** - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; - return EXIT_FAILURE; - } - --- 50,54 ---- - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output &openopen; argv[0] &openopen; ": number-of-processors number-of-averagings number-of-values" &openopen; std::endl; - return EXIT_FAILURE; - } - *************** - *** 55,63 **** - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 57,65 ---- - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 65,69 **** - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - --- 67,71 ---- - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - *************** - *** 71,80 **** - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the distributed arrays. - --- 73,82 ---- - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the distributed arrays. - *************** - *** 83,98 **** - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire array domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // The Array template parameters indicate 2 dimensions and a 'double' - // value type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Array<2, double, MultiPatch > > a(layout); - ! Array<2, double, MultiPatch > > b(layout); - - // Set up the initial conditions. - --- 85,100 ---- - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire array domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // The Array template parameters indicate 2 dimensions and a 'double' - // value type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > a(layout); - ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > b(layout); - - // Set up the initial conditions. - *************** - *** 104,112 **** - - // Create the stencil performing the computation. - ! Stencil stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - --- 106,114 ---- - - // Create the stencil performing the computation. - ! Stencil<DoofNinePt> stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - *************** - *** 117,121 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 119,123 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The arrays are automatically deallocated. - *************** - *** 125,126 **** - --- 127,129 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Sequential/Doof2d-Array-element-annotated.patch =================================================================== RCS file: Doof2d-Array-element-annotated.patch diff -N Doof2d-Array-element-annotated.patch *** /tmp/cvsyWNCZn Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,143 **** - *** Doof2d-Array-element.cpp Tue Dec 4 12:02:10 2001 - --- Doof2d-Array-element-annotated.cpp Wed Jan 23 16:35:29 2002 - *************** - *** 1,5 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - ! #include "Pooma/Arrays.h" // has POOMA's Array declarations - - // Doof2d: POOMA Arrays, element-wise implementation - --- 1,6 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - ! #include "Pooma/Arrays.h" // has POOMA's Array declarations - - // Doof2d: POOMA Arrays, element-wise implementation - *************** - *** 7,17 **** - int main(int argc, char *argv[]) - { - ! // Prepare the POOMA library for execution. - Pooma::initialize(argc,argv); - - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 8,18 ---- - int main(int argc, char *argv[]) - { - ! // Prepare the POOMA library for execution. - Pooma::initialize(argc,argv); - - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,37 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - ! // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Create the arrays. - // The Array template parameters indicate 2 dimensions, a 'double' value - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - for (int j = 1; j < n-1; j++) - for (int i = 1; i < n-1; i++) - --- 20,38 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - ! // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Create the arrays. - // The Array template parameters indicate 2 dimensions, a 'double' value - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - for (int j = 1; j < n-1; j++) - for (int i = 1; i < n-1; i++) - *************** - *** 43,51 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - ! a(i,j) = weight * - (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + - b(i ,j+1) + b(i ,j ) + b(i ,j-1) + - --- 44,52 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - ! a(i,j) = weight * - (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + - b(i ,j+1) + b(i ,j ) + b(i ,j-1) + - *************** - *** 53,58 **** - - // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b(i,j) = weight * - (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + - --- 54,59 ---- - - // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b(i,j) = weight * - (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + - *************** - *** 62,71 **** - - // Print out the final central value. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - ! // The arrays are automatically deallocated. - - ! // Tell the POOMA library execution has finished. - Pooma::finalize(); - return EXIT_SUCCESS; - } - --- 63,74 ---- - - // Print out the final central value. - ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - ! // The arrays are automatically deallocated. - - ! // Tell the POOMA library execution has finished. - Pooma::finalize(); - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Sequential/Doof2d-Array-parallel-annotated.patch =================================================================== RCS file: Doof2d-Array-parallel-annotated.patch diff -N Doof2d-Array-parallel-annotated.patch *** /tmp/cvsV9LpYm Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,116 **** - *** Doof2d-Array-parallel.cpp Tue Dec 4 11:49:43 2001 - --- Doof2d-Array-parallel-annotated.cpp Wed Jan 23 16:35:54 2002 - *************** - *** 1,4 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has POOMA's Array declarations - - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has POOMA's Array declarations - - *************** - *** 12,17 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 13,18 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,43 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Create the arrays. - // The Array template parameters indicate 2 dimensions, a 'double' value - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - // All grid values should be zero except for the central value. - a = b = 0.0; - ! // Ensure all data-parallel computation finishes before accessing a value. - Pooma::blockAndEvaluate(); - b(n/2,n/2) = 1000.0; - --- 20,44 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Create the arrays. - // The Array template parameters indicate 2 dimensions, a 'double' value - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - // All grid values should be zero except for the central value. - a = b = 0.0; - ! // Ensure all data-parallel computation finishes before accessing a value. - Pooma::blockAndEvaluate(); - b(n/2,n/2) = 1000.0; - *************** - *** 47,52 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - --- 48,53 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - *************** - *** 63,67 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 64,68 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The arrays are automatically deallocated. - *************** - *** 71,72 **** - --- 72,74 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Sequential/Doof2d-Array-stencil-annotated.patch =================================================================== RCS file: Doof2d-Array-stencil-annotated.patch diff -N Doof2d-Array-stencil-annotated.patch *** /tmp/cvscMIWSn Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,152 **** - *** Doof2d-Array-stencil.cpp Tue Dec 4 11:49:39 2001 - --- Doof2d-Array-stencil-annotated.cpp Wed Jan 23 16:36:15 2002 - *************** - *** 1,9 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has POOMA's Array declarations - - // Doof2d: POOMA Arrays, stencil implementation - - ! // Define the stencil class performing the computation. - class DoofNinePt - { - --- 1,10 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has POOMA's Array declarations - - // Doof2d: POOMA Arrays, stencil implementation - - ! // Define the stencil class performing the computation. - class DoofNinePt - { - *************** - *** 14,19 **** - // This stencil operator is applied to each interior domain position - // (i,j). The "C" template parameter permits use of this stencil - ! // operator with both Arrays and Fields. - ! template - inline - typename C::Element_t - --- 15,20 ---- - // This stencil operator is applied to each interior domain position - // (i,j). The "C" template parameter permits use of this stencil - ! // operator with both Arrays and Fields. - ! template <class C> - inline - typename C::Element_t - *************** - *** 26,30 **** - } - - ! inline int lowerExtent(int) const { return 1; } - inline int upperExtent(int) const { return 1; } - - --- 27,31 ---- - } - - ! inline int lowerExtent(int) const { return 1; } - inline int upperExtent(int) const { return 1; } - - *************** - *** 42,47 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 43,48 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 49,68 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the arrays. - // The Array template parameters indicate 2 dimensions, a 'double' value - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - --- 50,69 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the arrays. - // The Array template parameters indicate 2 dimensions, a 'double' value - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - *************** - *** 73,82 **** - b(n/2,n/2) = 1000.0; - - ! // Create the stencil performing the computation. - ! Stencil stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - --- 74,83 ---- - b(n/2,n/2) = 1000.0; - - ! // Create the stencil performing the computation. - ! Stencil<DoofNinePt> stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - *************** - *** 87,91 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 88,92 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The arrays are automatically deallocated. - *************** - *** 95,96 **** - --- 96,98 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Sequential/Doof2d-C-element-annotated.patch =================================================================== RCS file: Doof2d-C-element-annotated.patch diff -N Doof2d-C-element-annotated.patch *** /tmp/cvsfhxNpo Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,150 **** - *** Doof2d-C-element.cpp Tue Dec 4 09:59:18 2001 - --- Doof2d-C-element-annotated.cpp Wed Jan 23 16:34:20 2002 - *************** - *** 1,4 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - - // Doof2d: C-like, element-wise implementation - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - - // Doof2d: C-like, element-wise implementation - *************** - *** 6,30 **** - int main() - { - ! // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - ! // Use two-dimensional grids of values. - double **a; - double **b; - - // Ask the user for the number n of values along one dimension of - ! // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - ! // Allocate the arrays. - typedef double* doublePtr; - a = new doublePtr[n]; - b = new doublePtr[n]; - ! for (int i = 0; i < n; i++) { - a[i] = new double[n]; - b[i] = new double[n]; - --- 7,31 ---- - int main() - { - ! // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - ! // Use two-dimensional grids of values. - double **a; - double **b; - - // Ask the user for the number n of values along one dimension of - ! // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - ! // Allocate the arrays. - typedef double* doublePtr; - a = new doublePtr[n]; - b = new doublePtr[n]; - ! for (int i = 0; i < n; i++) { - a[i] = new double[n]; - b[i] = new double[n]; - *************** - *** 32,49 **** - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - ! for (int j = 0; j < n; j++) - ! for (int i = 0; i < n; i++) - a[i][j] = b[i][j] = 0.0; - b[n/2][n/2] = 1000.0; - - ! // In the average, weight elements with this value. - const double weight = 1.0/9.0; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - a[i][j] = weight * - (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + - --- 33,50 ---- - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - ! for (int j = 0; j < n; j++) - ! for (int i = 0; i < n; i++) - a[i][j] = b[i][j] = 0.0; - b[n/2][n/2] = 1000.0; - - ! // In the average, weight elements with this value. - const double weight = 1.0/9.0; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - a[i][j] = weight * - (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + - *************** - *** 51,57 **** - b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); - - ! // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b[i][j] = weight * - (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + - --- 52,58 ---- - b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); - - ! // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b[i][j] = weight * - (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + - *************** - *** 60,68 **** - } - - ! // Print out the final central value. - ! std::cout << (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) << std::endl; - - ! // Deallocate the arrays. - ! for (int i = 0; i < n; i++) { - delete [] a[i]; - delete [] b[i]; - --- 61,69 ---- - } - - ! // Print out the final central value. - ! std::cout &openopen; (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) &openopen; std::endl; - - ! // Deallocate the arrays. - ! for (int i = 0; i < n; i++) { - delete [] a[i]; - delete [] b[i]; - *************** - *** 73,74 **** - --- 74,76 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Sequential/Doof2d-Field-distributed-annotated.patch =================================================================== RCS file: Doof2d-Field-distributed-annotated.patch diff -N Doof2d-Field-distributed-annotated.patch *** /tmp/cvsCgy7wo Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,176 **** - *** Doof2d-Field-distributed.cpp Wed Dec 5 14:05:10 2001 - --- Doof2d-Field-distributed-annotated.cpp Wed Jan 23 16:36:34 2002 - *************** - *** 1,3 **** - ! #include // has EXIT_SUCCESS - #include "Pooma/Fields.h" // has POOMA's Field declarations - - --- 1,4 ---- - ! - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Fields.h" // has POOMA's Field declarations - - *************** - *** 12,16 **** - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - --- 13,17 ---- - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - *************** - *** 18,22 **** - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; - return EXIT_FAILURE; - } - --- 19,23 ---- - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output &openopen; argv[0] &openopen; ": number-of-processors number-of-averagings number-of-values" &openopen; std::endl; - return EXIT_FAILURE; - } - *************** - *** 25,33 **** - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 26,34 ---- - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 35,39 **** - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - --- 36,40 ---- - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - *************** - *** 41,50 **** - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Partition the fields' domains uniformly, i.e., each patch has the - --- 42,51 ---- - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Partition the fields' domains uniformly, i.e., each patch has the - *************** - *** 52,74 **** - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire field domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // The Field template parameters indicate a mesh and a 'double' - // value type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Field, double, MultiPatch > > a(cell, layout, mesh); - ! Field, double, MultiPatch > > b(cell, layout, mesh); - - // Set up the initial conditions. - --- 53,75 ---- - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire field domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // The Field template parameters indicate a mesh and a 'double' - // value type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, - ! Remote<Brick> > > a(cell, layout, mesh); - ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, - ! Remote<Brick> > > b(cell, layout, mesh); - - // Set up the initial conditions. - *************** - *** 83,87 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - a(I,J) = weight * - --- 84,88 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - a(I,J) = weight * - *************** - *** 99,103 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The fields are automatically deallocated. - --- 100,104 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The fields are automatically deallocated. - *************** - *** 107,108 **** - --- 108,110 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Sequential/Doof2d-Field-parallel-annotated.patch =================================================================== RCS file: Doof2d-Field-parallel-annotated.patch diff -N Doof2d-Field-parallel-annotated.patch *** /tmp/cvsLMrrLq Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,120 **** - *** Doof2d-Field-parallel.cpp Tue Dec 4 11:47:58 2001 - --- Doof2d-Field-parallel-annotated.cpp Wed Jan 23 16:37:19 2002 - *************** - *** 1,5 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - ! #include "Pooma/Fields.h" // has POOMA's Field declarations - - // Doof2d: POOMA Fields, data-parallel implementation - --- 1,6 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - ! #include "Pooma/Fields.h" // has POOMA's Field declarations - - // Doof2d: POOMA Fields, data-parallel implementation - *************** - *** 12,17 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 13,18 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,44 **** - // the grid. - long n; - ! std::cout << "Please enter the field size: "; - ! std::cin >> n; - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! DomainLayout<2> layout(vertDomain); - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // Create the fields. - // The Field template parameters indicate a mesh, a 'double' value - ! // type, and ordinary 'Brick' storage. - ! Field, double, Brick> a(cell, layout, mesh); - ! Field, double, Brick> b(cell, layout, mesh); - - // Set up the initial conditions. - --- 20,45 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the field size: "; - ! std::cin &closeclose; n; - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! DomainLayout<2> layout(vertDomain); - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // Create the fields. - // The Field template parameters indicate a mesh, a 'double' value - ! // type, and ordinary 'Brick' storage. - ! Field<UniformRectilinearMesh<2>, double, Brick> a(cell, layout, mesh); - ! Field<UniformRectilinearMesh<2>, double, Brick> b(cell, layout, mesh); - - // Set up the initial conditions. - *************** - *** 53,58 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - --- 54,59 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - *************** - *** 69,73 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The fields are automatically deallocated. - --- 70,74 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The fields are automatically deallocated. - *************** - *** 77,78 **** - --- 78,80 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Sequential/array-copy-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/array-copy-annotated.patch,v retrieving revision 1.1 diff -c -p -r1.1 array-copy-annotated.patch *** examples/Sequential/array-copy-annotated.patch 2002/01/25 03:27:30 1.1 --- examples/Sequential/array-copy-annotated.patch 2002/01/31 21:52:13 *************** *** 1,5 **** *** array-copy.cpp Thu Jan 24 11:12:23 2002 ! --- array-copy-annotated.cpp Thu Jan 24 11:12:49 2002 *************** *** 1,8 **** #include "Pooma/Pooma.h" --- 1,5 ---- *** array-copy.cpp Thu Jan 24 11:12:23 2002 ! --- array-copy-annotated.cpp Thu Jan 31 09:22:57 2002 *************** *** 1,8 **** #include "Pooma/Pooma.h" *************** *** 21,27 **** { z(0,0) = 6; } *************** ! *** 11,17 **** Pooma::initialize(argc,argv); ! Array<2,int,Brick> a(3,4, ModelElement(4)); --- 21,27 ---- { z(0,0) = 6; } *************** ! *** 11,35 **** Pooma::initialize(argc,argv); ! Array<2,int,Brick> a(3,4, ModelElement(4)); *************** *** 29,53 **** ! std::cout << "a: " << a(0,0) << std::endl; // Array copies share the same underlying values. - --- 12,18 ---- - Pooma::initialize(argc,argv); - - ! Array<2,int,Brick> a(3,4, ModelElement<int>(4)); - ! std::cout &openopen; "Initial value:\n"; - ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; ! // Array copies share the same underlying values. ! *************** ! *** 19,35 **** ! // Explicit initialization uses reference semantics so changing the ! // copy's value at (0,0) also changes the original's value. ! Array<2,int,Brick> b(a); b(0,0) = 5; ! std::cout << "After explicit initialization.\n"; ! std::cout << "a: " << a(0,0) << std::endl; ! std::cout << "b: " << b(0,0) << std::endl; ! ! // Initialization of function arguments also uses reference semantics. ! std::cout << "After function call:\n"; changeValue(a); ! std::cout << "a: " << a(0,0) << std::endl; --- 29,44 ---- ! std::cout << "a: " << a(0,0) << std::endl; // Array copies share the same underlying values. ! ! // Explicit initialization uses reference semantics so changing the ! ! // copy's value at (0,0) also changes the original's value. ! Array<2,int,Brick> b(a); b(0,0) = 5; ! std::cout << "After explicit initialization.\n"; ! std::cout << "a: " << a(0,0) << std::endl; ! std::cout << "b: " << b(0,0) << std::endl; ! ! ! ! // Initialization of function arguments also uses reference semantics. ! std::cout << "After function call:\n"; changeValue(a); ! std::cout << "a: " << a(0,0) << std::endl; *************** *** 56,71 **** Pooma::finalize(); return 0; } ! --- 20,37 ---- ! // Explicit initialization uses reference semantics so changing the ! // copy's value at (0,0) also changes the original's value. ! Array<2,int,Brick> b(a); b(0,0) = 5; ! std::cout &openopen; "After explicit initialization.\n"; ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; ! std::cout &openopen; "b: " &openopen; b(0,0) &openopen; std::endl; ! ! // Initialization of function arguments also uses reference semantics. ! std::cout &openopen; "After function call:\n"; changeValue(a); ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; --- 47,72 ---- Pooma::finalize(); return 0; } ! --- 12,39 ---- ! Pooma::initialize(argc,argv); ! ! ! Array<2,int,Brick> a(3,4, ModelElement<int>(4)); ! ! std::cout &openopen; "Initial value:\n"; ! ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; ! ! // Array copies share the same underlying values. ! ! ! // Explicit initialization uses reference semantics ! ! // so changing the copy's value at (0,0) also ! ! // changes the original's value. ! Array<2,int,Brick> b(a); b(0,0) = 5; ! std::cout &openopen; "After explicit initialization.\n"; ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; ! std::cout &openopen; "b: " &openopen; b(0,0) &openopen; std::endl; ! ! ! ! // Initialization of function arguments also uses ! ! // reference semantics. ! std::cout &openopen; "After function call:\n"; changeValue(a); ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; Index: examples/Sequential/array-size-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/array-size-annotated.patch,v retrieving revision 1.1 diff -c -p -r1.1 array-size-annotated.patch *** examples/Sequential/array-size-annotated.patch 2002/01/25 03:27:30 1.1 --- examples/Sequential/array-size-annotated.patch 2002/01/31 21:52:13 *************** *** 1,21 **** ! *** array-size.cpp Tue Jan 15 12:59:40 2002 ! --- array-size-annotated.cpp Tue Jan 15 13:30:07 2002 *************** ! *** 1,5 **** #include "Pooma/Pooma.h" #include "Pooma/Arrays.h" ! #include // Print an Array's Size - --- 1,6 ---- - + - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include <iostream> ! // Print an Array's Size ! *************** ! *** 10,22 **** // member functions. ! template --- 1,16 ---- ! *** array-size.cpp Tue Jan 15 13:30:53 2002 ! --- array-size-annotated.cpp Thu Jan 31 09:24:16 2002 *************** ! *** 1,25 **** #include "Pooma/Pooma.h" #include "Pooma/Arrays.h" ! #include // Print an Array's Size ! ! // This program illustrates using the Array member functions. ! ! // computeArraySize's computation is redundant because Array's size() ! ! // function computes the same value, but it illustrates using Array // member functions. ! template *************** *** 27,65 **** ! const Loc lens = a.lengths(); long size = 1; ! for (int d = 0; d < Dim; ++d) { ! size *= (ls[d] - fs[d] + 1).first(); // Check that lengths() and our computed lengths agree. ! --- 11,23 ---- // member functions. ! ! template <int Dim, typename Type, typename EngineTag> inline ! long computeArraySize(const Array<Dim,Type,EngineTag>& a) { ! ! const Loc<Dim> fs = a.firsts(); ! const Loc<Dim> ls = a.lasts(); ! const Loc<Dim> lens = a.lengths(); long size = 1; ! for (int d = 0; d < Dim; ++d) { ! size *= (ls[d] - fs[d] + 1).first(); // Check that lengths() and our computed lengths agree. *************** *** 30,38 **** Pooma::initialize(argc,argv); ! Array<3,int,Brick> a(3,4,5, ModelElement(4)); ! PAssert(computeArraySize(a) == a.size()); ! std::cout << "The array's size is " << a.size() << ".\n"; Pooma::finalize(); return 0; } ! --- 31,40 ---- Pooma::initialize(argc,argv); ! Array<3,int,Brick> a(3,4,5, ModelElement<int>(4)); ! PAssert(computeArraySize(a) == a.size()); ! ! std::cout &openopen; "The array's size is " &openopen; a.size() &openopen; ".\n"; Pooma::finalize(); return 0; --- 22,78 ---- ! const Loc lens = a.lengths(); long size = 1; ! for (int d = 0; d < Dim; ++d) { ! ! size *= lens[d].first(); // Check that lengths() and our computed lengths agree. ! ! PAssert((ls[d] - fs[d] + 1).first() == a.length(d)); ! } ! return size; ! --- 1,27 ---- ! + ! #include "Pooma/Pooma.h" ! #include "Pooma/Arrays.h" ! ! #include <iostream> ! ! // Print an Array's Size ! ! ! // This program illustrates using the Array member ! ! // functions. computeArraySize's computation is ! ! // redundant because Array's size() function computes ! ! // the same value, but it illustrates using Array // member functions. ! ! template <int Dim,typename Type,typename EngineTag> inline ! long computeArraySize(const Array<Dim,Type,EngineTag>& a) { ! ! const Loc<Dim> fs = a.firsts(); ! const Loc<Dim> ls = a.lasts(); ! const Loc<Dim> lens = a.lengths(); long size = 1; ! for (int d = 0; d < Dim; ++d) { ! ! size *= lens[d].first(); // Check that lengths() and our computed lengths agree. + ! PAssert((ls[d]-fs[d]+1).first()==a.length(d)); + } + return size; *************** *** 30,38 **** Pooma::initialize(argc,argv); ! Array<3,int,Brick> a(3,4,5, ModelElement(4)); ! ! PAssert(computeArraySize(a) == a.size()); ! std::cout << "The array's size is " << a.size() << ".\n"; Pooma::finalize(); return 0; } ! --- 32,42 ---- Pooma::initialize(argc,argv); ! Array<3,int,Brick> a(3,4,5, ModelElement<int>(4)); ! ! PAssert(computeArraySize(a) == a.size()); ! ! std::cout &openopen; ! ! "The array's size is " &openopen; a.size() &openopen; ".\n"; Pooma::finalize(); return 0; Index: examples/Sequential/pairs-templated-annotated.patch =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/programs/Attic/pairs-templated-annotated.patch,v retrieving revision 1.4 diff -c -p -r1.4 pairs-templated-annotated.patch *** examples/Sequential/pairs-templated-annotated.patch 2002/01/25 03:27:30 1.4 --- examples/Sequential/pairs-templated-annotated.patch 2002/01/31 21:52:13 *************** *** 1,8 **** *** pairs-templated.cpp Mon Jan 7 16:11:56 2002 ! --- pairs-templated-annotated.cpp Wed Jan 23 12:33:13 2002 *************** *** 1,15 **** ! // Declare a template class storing a pair of values with the same type. ! template struct pair { ! pair(const int& left, const int& right) --- 1,8 ---- *** pairs-templated.cpp Mon Jan 7 16:11:56 2002 ! --- pairs-templated-annotated.cpp Thu Jan 31 08:44:35 2002 *************** *** 1,15 **** ! ! // Declare a template class storing a pair of values with the same type. ! template struct pair { ! pair(const int& left, const int& right) *************** *** 17,25 **** ! // Define a class storing a pair of doubles; ! pair pair2; ! --- 1,17 ---- ! + ! // Declare a template class storing a pair of values with the same type. ! template <typename T> // struct pair { ! pair(const T& left, const T& right) // --- 17,26 ---- ! // Define a class storing a pair of doubles; ! pair pair2; ! --- 1,18 ---- ! ! ! ! // Declare a template class storing a pair of values ! ! // with the same type. ! template <typename T> // struct pair { ! pair(const T& left, const T& right) // Index: examples/Sequential/pairs-untemplated-annotated.patch =================================================================== RCS file: pairs-untemplated-annotated.patch diff -N pairs-untemplated-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- pairs-untemplated-annotated.patch Thu Jan 31 14:52:13 2002 *************** *** 0 **** --- 1,35 ---- + *** pairs-untemplated.cpp Wed Dec 26 13:48:10 2001 + --- pairs-untemplated-annotated.cpp Wed Dec 26 14:02:58 2001 + *************** + *** 1,5 **** + // Declare a class storing a pair of integers. + struct pairOfInts { + ! pairOfInts(const int& left, const int& right) + : left_(left), right_(right) {} + + --- 1,6 ---- + + + // Declare a class storing a pair of integers. + struct pairOfInts { + ! pairOfInts(const int& left, const int& right) + : left_(left), right_(right) {} + + *************** + *** 10,14 **** + // Declare a class storing a pair of doubles. + struct pairOfDoubles { + ! pairOfDoubles(const double& left, const double& right) + : left_(left), right_(right) {} + + --- 11,15 ---- + // Declare a class storing a pair of doubles. + struct pairOfDoubles { + ! pairOfDoubles(const double& left, const double& right) + : left_(left), right_(right) {} + + *************** + *** 16,17 **** + --- 17,19 ---- + double right_; + }; + + Index: examples/Templates/Doof2d-Array-distributed-annotated.patch =================================================================== RCS file: Doof2d-Array-distributed-annotated.patch diff -N Doof2d-Array-distributed-annotated.patch *** /tmp/cvsXqyFoA Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,184 **** - *** Doof2d-Array-distributed.cpp Wed Dec 5 14:04:36 2001 - --- Doof2d-Array-distributed-annotated.cpp Wed Dec 5 14:07:56 2001 - *************** - *** 1,3 **** - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has POOMA's Array declarations - - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has POOMA's Array declarations - - *************** - *** 14,18 **** - // (i,j). The "C" template parameter permits use of this stencil - // operator with both Arrays and Fields. - ! template - inline - typename C::Element_t - --- 16,20 ---- - // (i,j). The "C" template parameter permits use of this stencil - // operator with both Arrays and Fields. - ! template <class C> - inline - typename C::Element_t - *************** - *** 42,46 **** - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - --- 44,48 ---- - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - *************** - *** 48,52 **** - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; - return EXIT_FAILURE; - } - --- 50,54 ---- - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output &openopen; argv[0] &openopen; ": number-of-processors number-of-averagings number-of-values" &openopen; std::endl; - return EXIT_FAILURE; - } - *************** - *** 55,63 **** - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 57,65 ---- - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 65,69 **** - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - --- 67,71 ---- - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - *************** - *** 71,80 **** - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the distributed arrays. - --- 73,82 ---- - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the distributed arrays. - *************** - *** 83,98 **** - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire array domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // The Array template parameters indicate 2 dimensions and a 'double' - // value type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Array<2, double, MultiPatch > > a(layout); - ! Array<2, double, MultiPatch > > b(layout); - - // Set up the initial conditions. - --- 85,100 ---- - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire array domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // The Array template parameters indicate 2 dimensions and a 'double' - // value type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > a(layout); - ! Array<2, double, MultiPatch<UniformTag, Remote<Brick> > > b(layout); - - // Set up the initial conditions. - *************** - *** 104,112 **** - - // Create the stencil performing the computation. - ! Stencil stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - --- 106,114 ---- - - // Create the stencil performing the computation. - ! Stencil<DoofNinePt> stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - *************** - *** 117,121 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 119,123 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The arrays are automatically deallocated. - *************** - *** 125,126 **** - --- 127,129 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Templates/Doof2d-Array-element-annotated.patch =================================================================== RCS file: Doof2d-Array-element-annotated.patch diff -N Doof2d-Array-element-annotated.patch *** /tmp/cvsu9r3UC Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,143 **** - *** Doof2d-Array-element.cpp Tue Dec 4 12:02:10 2001 - --- Doof2d-Array-element-annotated.cpp Wed Jan 23 16:35:29 2002 - *************** - *** 1,5 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - ! #include "Pooma/Arrays.h" // has POOMA's Array declarations - - // Doof2d: POOMA Arrays, element-wise implementation - --- 1,6 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - ! #include "Pooma/Arrays.h" // has POOMA's Array declarations - - // Doof2d: POOMA Arrays, element-wise implementation - *************** - *** 7,17 **** - int main(int argc, char *argv[]) - { - ! // Prepare the POOMA library for execution. - Pooma::initialize(argc,argv); - - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 8,18 ---- - int main(int argc, char *argv[]) - { - ! // Prepare the POOMA library for execution. - Pooma::initialize(argc,argv); - - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,37 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - ! // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Create the arrays. - // The Array template parameters indicate 2 dimensions, a 'double' value - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - for (int j = 1; j < n-1; j++) - for (int i = 1; i < n-1; i++) - --- 20,38 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - ! // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Create the arrays. - // The Array template parameters indicate 2 dimensions, a 'double' value - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - for (int j = 1; j < n-1; j++) - for (int i = 1; i < n-1; i++) - *************** - *** 43,51 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - ! a(i,j) = weight * - (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + - b(i ,j+1) + b(i ,j ) + b(i ,j-1) + - --- 44,52 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - ! a(i,j) = weight * - (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + - b(i ,j+1) + b(i ,j ) + b(i ,j-1) + - *************** - *** 53,58 **** - - // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b(i,j) = weight * - (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + - --- 54,59 ---- - - // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b(i,j) = weight * - (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + - *************** - *** 62,71 **** - - // Print out the final central value. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - ! // The arrays are automatically deallocated. - - ! // Tell the POOMA library execution has finished. - Pooma::finalize(); - return EXIT_SUCCESS; - } - --- 63,74 ---- - - // Print out the final central value. - ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - ! // The arrays are automatically deallocated. - - ! // Tell the POOMA library execution has finished. - Pooma::finalize(); - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Templates/Doof2d-Array-parallel-annotated.patch =================================================================== RCS file: Doof2d-Array-parallel-annotated.patch diff -N Doof2d-Array-parallel-annotated.patch *** /tmp/cvs9dVaoH Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,116 **** - *** Doof2d-Array-parallel.cpp Tue Dec 4 11:49:43 2001 - --- Doof2d-Array-parallel-annotated.cpp Wed Jan 23 16:35:54 2002 - *************** - *** 1,4 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has POOMA's Array declarations - - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has POOMA's Array declarations - - *************** - *** 12,17 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 13,18 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,43 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Create the arrays. - // The Array template parameters indicate 2 dimensions, a 'double' value - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - // All grid values should be zero except for the central value. - a = b = 0.0; - ! // Ensure all data-parallel computation finishes before accessing a value. - Pooma::blockAndEvaluate(); - b(n/2,n/2) = 1000.0; - --- 20,44 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - ! // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Create the arrays. - // The Array template parameters indicate 2 dimensions, a 'double' value - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - // All grid values should be zero except for the central value. - a = b = 0.0; - ! // Ensure all data-parallel computation finishes before accessing a value. - Pooma::blockAndEvaluate(); - b(n/2,n/2) = 1000.0; - *************** - *** 47,52 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - --- 48,53 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - *************** - *** 63,67 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 64,68 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The arrays are automatically deallocated. - *************** - *** 71,72 **** - --- 72,74 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Templates/Doof2d-Array-stencil-annotated.patch =================================================================== RCS file: Doof2d-Array-stencil-annotated.patch diff -N Doof2d-Array-stencil-annotated.patch *** /tmp/cvsasNZwL Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,152 **** - *** Doof2d-Array-stencil.cpp Tue Dec 4 11:49:39 2001 - --- Doof2d-Array-stencil-annotated.cpp Wed Jan 23 16:36:15 2002 - *************** - *** 1,9 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has POOMA's Array declarations - - // Doof2d: POOMA Arrays, stencil implementation - - ! // Define the stencil class performing the computation. - class DoofNinePt - { - --- 1,10 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Arrays.h" // has POOMA's Array declarations - - // Doof2d: POOMA Arrays, stencil implementation - - ! // Define the stencil class performing the computation. - class DoofNinePt - { - *************** - *** 14,19 **** - // This stencil operator is applied to each interior domain position - // (i,j). The "C" template parameter permits use of this stencil - ! // operator with both Arrays and Fields. - ! template - inline - typename C::Element_t - --- 15,20 ---- - // This stencil operator is applied to each interior domain position - // (i,j). The "C" template parameter permits use of this stencil - ! // operator with both Arrays and Fields. - ! template <class C> - inline - typename C::Element_t - *************** - *** 26,30 **** - } - - ! inline int lowerExtent(int) const { return 1; } - inline int upperExtent(int) const { return 1; } - - --- 27,31 ---- - } - - ! inline int lowerExtent(int) const { return 1; } - inline int upperExtent(int) const { return 1; } - - *************** - *** 42,47 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 43,48 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 49,68 **** - // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the arrays. - // The Array template parameters indicate 2 dimensions, a 'double' value - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - --- 50,69 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - // Specify the arrays' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<2> interiorDomain(I,I); - - // Create the arrays. - // The Array template parameters indicate 2 dimensions, a 'double' value - // type, and ordinary 'Brick' storage. - ! Array<2, double, Brick> a(vertDomain); - ! Array<2, double, Brick> b(vertDomain); - - // Set up the initial conditions. - *************** - *** 73,82 **** - b(n/2,n/2) = 1000.0; - - ! // Create the stencil performing the computation. - ! Stencil stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - --- 74,83 ---- - b(n/2,n/2) = 1000.0; - - ! // Create the stencil performing the computation. - ! Stencil<DoofNinePt> stencil; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(interiorDomain) = stencil(b, interiorDomain); - - *************** - *** 87,91 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The arrays are automatically deallocated. - --- 88,92 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The arrays are automatically deallocated. - *************** - *** 95,96 **** - --- 96,98 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Templates/Doof2d-C-element-annotated.patch =================================================================== RCS file: Doof2d-C-element-annotated.patch diff -N Doof2d-C-element-annotated.patch *** /tmp/cvsT2P9dR Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,150 **** - *** Doof2d-C-element.cpp Tue Dec 4 09:59:18 2001 - --- Doof2d-C-element-annotated.cpp Wed Jan 23 16:34:20 2002 - *************** - *** 1,4 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - - // Doof2d: C-like, element-wise implementation - --- 1,5 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - - // Doof2d: C-like, element-wise implementation - *************** - *** 6,30 **** - int main() - { - ! // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - ! // Use two-dimensional grids of values. - double **a; - double **b; - - // Ask the user for the number n of values along one dimension of - ! // the grid. - long n; - ! std::cout << "Please enter the array size: "; - ! std::cin >> n; - - ! // Allocate the arrays. - typedef double* doublePtr; - a = new doublePtr[n]; - b = new doublePtr[n]; - ! for (int i = 0; i < n; i++) { - a[i] = new double[n]; - b[i] = new double[n]; - --- 7,31 ---- - int main() - { - ! // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - ! // Use two-dimensional grids of values. - double **a; - double **b; - - // Ask the user for the number n of values along one dimension of - ! // the grid. - long n; - ! std::cout &openopen; "Please enter the array size: "; - ! std::cin &closeclose; n; - - ! // Allocate the arrays. - typedef double* doublePtr; - a = new doublePtr[n]; - b = new doublePtr[n]; - ! for (int i = 0; i < n; i++) { - a[i] = new double[n]; - b[i] = new double[n]; - *************** - *** 32,49 **** - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - ! for (int j = 0; j < n; j++) - ! for (int i = 0; i < n; i++) - a[i][j] = b[i][j] = 0.0; - b[n/2][n/2] = 1000.0; - - ! // In the average, weight elements with this value. - const double weight = 1.0/9.0; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - a[i][j] = weight * - (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + - --- 33,50 ---- - - // Set up the initial conditions. - ! // All grid values should be zero except for the central value. - ! for (int j = 0; j < n; j++) - ! for (int i = 0; i < n; i++) - a[i][j] = b[i][j] = 0.0; - b[n/2][n/2] = 1000.0; - - ! // In the average, weight elements with this value. - const double weight = 1.0/9.0; - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - a[i][j] = weight * - (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + - *************** - *** 51,57 **** - b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); - - ! // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b[i][j] = weight * - (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + - --- 52,58 ---- - b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); - - ! // Read from a. Write to b. - ! for (int j = 1; j < n-1; j++) - ! for (int i = 1; i < n-1; i++) - b[i][j] = weight * - (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + - *************** - *** 60,68 **** - } - - ! // Print out the final central value. - ! std::cout << (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) << std::endl; - - ! // Deallocate the arrays. - ! for (int i = 0; i < n; i++) { - delete [] a[i]; - delete [] b[i]; - --- 61,69 ---- - } - - ! // Print out the final central value. - ! std::cout &openopen; (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) &openopen; std::endl; - - ! // Deallocate the arrays. - ! for (int i = 0; i < n; i++) { - delete [] a[i]; - delete [] b[i]; - *************** - *** 73,74 **** - --- 74,76 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Templates/Doof2d-Field-distributed-annotated.patch =================================================================== RCS file: Doof2d-Field-distributed-annotated.patch diff -N Doof2d-Field-distributed-annotated.patch *** /tmp/cvsAOUbGW Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,176 **** - *** Doof2d-Field-distributed.cpp Wed Dec 5 14:05:10 2001 - --- Doof2d-Field-distributed-annotated.cpp Wed Jan 23 16:36:34 2002 - *************** - *** 1,3 **** - ! #include // has EXIT_SUCCESS - #include "Pooma/Fields.h" // has POOMA's Field declarations - - --- 1,4 ---- - ! - ! #include <stdlib.h> // has EXIT_SUCCESS - #include "Pooma/Fields.h" // has POOMA's Field declarations - - *************** - *** 12,16 **** - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - --- 13,17 ---- - // canot use standard input and output. Instead we use command-line - // arguments, which are replicated, for input, and we use an Inform - ! // stream for output. - Inform output; - - *************** - *** 18,22 **** - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; - return EXIT_FAILURE; - } - --- 19,23 ---- - if (argc != 4) { - // Incorrect number of command-line arguments. - ! output &openopen; argv[0] &openopen; ": number-of-processors number-of-averagings number-of-values" &openopen; std::endl; - return EXIT_FAILURE; - } - *************** - *** 25,33 **** - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 26,34 ---- - // Determine the number of processors. - long nuProcessors; - ! nuProcessors = strtol(argv[1], &tail, 0); - - // Determine the number of averagings. - long nuAveragings, nuIterations; - ! nuAveragings = strtol(argv[2], &tail, 0); - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 35,39 **** - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - --- 36,40 ---- - // the grid. - long n; - ! n = strtol(argv[3], &tail, 0); - // The dimension must be a multiple of the number of processors - // since we are using a UniformGridLayout. - *************** - *** 41,50 **** - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Partition the fields' domains uniformly, i.e., each patch has the - --- 42,51 ---- - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Partition the fields' domains uniformly, i.e., each patch has the - *************** - *** 52,74 **** - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire field domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // The Field template parameters indicate a mesh and a 'double' - // value type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Field, double, MultiPatch > > a(cell, layout, mesh); - ! Field, double, MultiPatch > > b(cell, layout, mesh); - - // Set up the initial conditions. - --- 53,75 ---- - // dimension. Guard layers optimize communication between patches. - // Internal guards surround each patch. External guards surround - ! // the entire field domain. - ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), - ! GuardLayers<2>(1), // internal - ! GuardLayers<2>(0)); // external - ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // The Field template parameters indicate a mesh and a 'double' - // value type. MultiPatch indicates multiple computation patches, - // i.e., distributed computation. The UniformTag indicates the - ! // patches should have the same size. Each patch has Brick type. - ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, - ! Remote<Brick> > > a(cell, layout, mesh); - ! Field<UniformRectilinearMesh<2>, double, MultiPatch<UniformTag, - ! Remote<Brick> > > b(cell, layout, mesh); - - // Set up the initial conditions. - *************** - *** 83,87 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - a(I,J) = weight * - --- 84,88 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - // Read from b. Write to a. - a(I,J) = weight * - *************** - *** 99,103 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The fields are automatically deallocated. - --- 100,104 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! output &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The fields are automatically deallocated. - *************** - *** 107,108 **** - --- 108,110 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Templates/Doof2d-Field-parallel-annotated.patch =================================================================== RCS file: Doof2d-Field-parallel-annotated.patch diff -N Doof2d-Field-parallel-annotated.patch *** /tmp/cvsJmrxJ1 Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,120 **** - *** Doof2d-Field-parallel.cpp Tue Dec 4 11:47:58 2001 - --- Doof2d-Field-parallel-annotated.cpp Wed Jan 23 16:37:19 2002 - *************** - *** 1,5 **** - ! #include // has std::cout, ... - ! #include // has EXIT_SUCCESS - ! #include "Pooma/Fields.h" // has POOMA's Field declarations - - // Doof2d: POOMA Fields, data-parallel implementation - --- 1,6 ---- - ! - ! #include <iostream> // has std::cout, ... - ! #include <stdlib.h> // has EXIT_SUCCESS - ! #include "Pooma/Fields.h" // has POOMA's Field declarations - - // Doof2d: POOMA Fields, data-parallel implementation - *************** - *** 12,17 **** - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout << "Please enter the number of averagings: "; - ! std::cin >> nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - --- 13,18 ---- - // Ask the user for the number of averagings. - long nuAveragings, nuIterations; - ! std::cout &openopen; "Please enter the number of averagings: "; - ! std::cin &closeclose; nuAveragings; - nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. - - *************** - *** 19,44 **** - // the grid. - long n; - ! std::cout << "Please enter the field size: "; - ! std::cin >> n; - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! DomainLayout<2> layout(vertDomain); - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // Create the fields. - // The Field template parameters indicate a mesh, a 'double' value - ! // type, and ordinary 'Brick' storage. - ! Field, double, Brick> a(cell, layout, mesh); - ! Field, double, Brick> b(cell, layout, mesh); - - // Set up the initial conditions. - --- 20,45 ---- - // the grid. - long n; - ! std::cout &openopen; "Please enter the field size: "; - ! std::cin &closeclose; n; - - // Specify the fields' domains [0,n) x [0,n). - ! Interval<1> N(0, n-1); - ! Interval<2> vertDomain(N, N); - - // Set up interior domains [1,n-1) x [1,n-1) for computation. - ! Interval<1> I(1,n-2); - ! Interval<1> J(1,n-2); - - // Specify the fields' mesh, i.e., its spatial extent, and its - ! // centering type. - ! DomainLayout<2> layout(vertDomain); - ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); - ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); - - // Create the fields. - // The Field template parameters indicate a mesh, a 'double' value - ! // type, and ordinary 'Brick' storage. - ! Field<UniformRectilinearMesh<2>, double, Brick> a(cell, layout, mesh); - ! Field<UniformRectilinearMesh<2>, double, Brick> b(cell, layout, mesh); - - // Set up the initial conditions. - *************** - *** 53,58 **** - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - --- 54,59 ---- - - // Perform the simulation. - ! for (int k = 0; k < nuIterations; ++k) { - ! // Read from b. Write to a. - a(I,J) = weight * - (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + - *************** - *** 69,73 **** - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; - - // The fields are automatically deallocated. - --- 70,74 ---- - // Print out the final central value. - Pooma::blockAndEvaluate(); // Ensure all computation has finished. - ! std::cout &openopen; (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) &openopen; std::endl; - - // The fields are automatically deallocated. - *************** - *** 77,78 **** - --- 78,80 ---- - return EXIT_SUCCESS; - } - + --- 0 ---- Index: examples/Templates/array-copy-annotated.patch =================================================================== RCS file: array-copy-annotated.patch diff -N array-copy-annotated.patch *** /tmp/cvsmquTO8 Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,77 **** - *** array-copy.cpp Thu Jan 24 11:12:23 2002 - --- array-copy-annotated.cpp Thu Jan 24 11:12:49 2002 - *************** - *** 1,8 **** - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include - - // Changes the Array value at index (0,0). - ! void changeValue(Array<2,int,Brick>& z) - { z(0,0) = 6; } - - --- 1,9 ---- - + - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include <iostream> - - // Changes the Array value at index (0,0). - ! void changeValue(Array<2,int,Brick>& z) - { z(0,0) = 6; } - - *************** - *** 11,17 **** - Pooma::initialize(argc,argv); - - ! Array<2,int,Brick> a(3,4, ModelElement(4)); - ! std::cout << "Initial value:\n"; - ! std::cout << "a: " << a(0,0) << std::endl; - - // Array copies share the same underlying values. - --- 12,18 ---- - Pooma::initialize(argc,argv); - - ! Array<2,int,Brick> a(3,4, ModelElement<int>(4)); - ! std::cout &openopen; "Initial value:\n"; - ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; - - // Array copies share the same underlying values. - *************** - *** 19,35 **** - // Explicit initialization uses reference semantics so changing the - // copy's value at (0,0) also changes the original's value. - ! Array<2,int,Brick> b(a); - b(0,0) = 5; - ! std::cout << "After explicit initialization.\n"; - ! std::cout << "a: " << a(0,0) << std::endl; - ! std::cout << "b: " << b(0,0) << std::endl; - - // Initialization of function arguments also uses reference semantics. - ! std::cout << "After function call:\n"; - changeValue(a); - ! std::cout << "a: " << a(0,0) << std::endl; - ! std::cout << "b: " << b(0,0) << std::endl; - - Pooma::finalize(); - return 0; - } - --- 20,37 ---- - // Explicit initialization uses reference semantics so changing the - // copy's value at (0,0) also changes the original's value. - ! Array<2,int,Brick> b(a); - b(0,0) = 5; - ! std::cout &openopen; "After explicit initialization.\n"; - ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; - ! std::cout &openopen; "b: " &openopen; b(0,0) &openopen; std::endl; - - // Initialization of function arguments also uses reference semantics. - ! std::cout &openopen; "After function call:\n"; - changeValue(a); - ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; - ! std::cout &openopen; "b: " &openopen; b(0,0) &openopen; std::endl; - - Pooma::finalize(); - return 0; - } - + --- 0 ---- Index: examples/Templates/array-size-annotated.patch =================================================================== RCS file: array-size-annotated.patch diff -N array-size-annotated.patch *** /tmp/cvs3lu4Nf Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,67 **** - *** array-size.cpp Tue Jan 15 12:59:40 2002 - --- array-size-annotated.cpp Tue Jan 15 13:30:07 2002 - *************** - *** 1,5 **** - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include - - // Print an Array's Size - --- 1,6 ---- - + - #include "Pooma/Pooma.h" - #include "Pooma/Arrays.h" - ! #include <iostream> - - // Print an Array's Size - *************** - *** 10,22 **** - // member functions. - - ! template - inline - ! long computeArraySize(const Array& a) - { - ! const Loc fs = a.firsts(); - ! const Loc ls = a.lasts(); - ! const Loc lens = a.lengths(); - long size = 1; - ! for (int d = 0; d < Dim; ++d) { - size *= (ls[d] - fs[d] + 1).first(); - // Check that lengths() and our computed lengths agree. - --- 11,23 ---- - // member functions. - - ! template <int Dim, typename Type, typename EngineTag> - inline - ! long computeArraySize(const Array<Dim,Type,EngineTag>& a) - { - ! const Loc<Dim> fs = a.firsts(); - ! const Loc<Dim> ls = a.lasts(); - ! const Loc<Dim> lens = a.lengths(); - long size = 1; - ! for (int d = 0; d < Dim; ++d) { - size *= (ls[d] - fs[d] + 1).first(); - // Check that lengths() and our computed lengths agree. - *************** - *** 30,38 **** - Pooma::initialize(argc,argv); - - ! Array<3,int,Brick> a(3,4,5, ModelElement(4)); - PAssert(computeArraySize(a) == a.size()); - ! std::cout << "The array's size is " << a.size() << ".\n"; - - Pooma::finalize(); - return 0; - } - --- 31,40 ---- - Pooma::initialize(argc,argv); - - ! Array<3,int,Brick> a(3,4,5, ModelElement<int>(4)); - PAssert(computeArraySize(a) == a.size()); - ! std::cout &openopen; "The array's size is " &openopen; a.size() &openopen; ".\n"; - - Pooma::finalize(); - return 0; - } - + --- 0 ---- Index: examples/Templates/dynamicarray-annotated.patch =================================================================== RCS file: dynamicarray-annotated.patch diff -N dynamicarray-annotated.patch *** /tmp/cvskK1Xwm Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,80 **** - *** dynamicarray.cpp Mon Jan 21 17:29:38 2002 - --- dynamicarray-annotated.cpp Tue Jan 22 07:06:15 2002 - *************** - *** 1,5 **** - #include "Pooma/Pooma.h" - ! #include "Pooma/DynamicArrays.h" - ! #include - - // Demonstrate using DynamicArrays. - --- 1,6 ---- - + - #include "Pooma/Pooma.h" - ! #include "Pooma/DynamicArrays.h" - ! #include <iostream> - - // Demonstrate using DynamicArrays. - *************** - *** 9,38 **** - Pooma::initialize(argc,argv); - - ! // Create a DynamicArray with one element. - ! DynamicArray<> d0(1); - ! DynamicArray d01(1); - ! DynamicArray d02(1); - - ! // Add five more elements. - d0.create(5); - // Store values in the array. - ! for (int i = d0.domain().first(); i <= d0.domain().last(); ++i) - ! d0(i) = i; - - ! // Delete every other element. - ! d0.destroy(Range<1>(d0.domain().first(),d0.domain().last(),2), BackFill()); - - // Print the resulting array. - ! std::cout << d0 << std::endl; - - // Use the iterator form of 'destroy.' - ! DynamicArray<> d1(6); - for (int i = d1.domain().first(); i <= d1.domain().last(); ++i) - d1(i) = i; - ! int killList[] = { 0, 2, 4 }; - d1.destroy(killList, killList+3); - ! std::cout << d1 << std::endl; - - Pooma::finalize(); - return 0; - } - --- 10,40 ---- - Pooma::initialize(argc,argv); - - ! // Create a DynamicArray with one element. - ! DynamicArray<> d0(1); - ! DynamicArray<double> d01(1); - ! DynamicArray<double, Dynamic> d02(1); - - ! // Add five more elements. - d0.create(5); - // Store values in the array. - ! for (int i = d0.domain().first(); i <= d0.domain().last(); ++i) - ! d0(i) = i; - - ! // Delete every other element. - ! d0.destroy(Range<1>(d0.domain().first(),d0.domain().last(),2), BackFill()); - - // Print the resulting array. - ! std::cout &openopen; d0 &openopen; std::endl; - - // Use the iterator form of 'destroy.' - ! DynamicArray<> d1(6); - for (int i = d1.domain().first(); i <= d1.domain().last(); ++i) - d1(i) = i; - ! int killList[] = { 0, 2, 4 }; - d1.destroy(killList, killList+3); - ! std::cout &openopen; d1 &openopen; std::endl; - - Pooma::finalize(); - return 0; - } - + --- 0 ---- Index: examples/Templates/initialize-finalize-annotated.patch =================================================================== RCS file: initialize-finalize-annotated.patch diff -N initialize-finalize-annotated.patch *** /tmp/cvs9Bbo4s Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,20 **** - *** initialize-finalize.cpp Thu Jan 24 11:14:13 2002 - --- initialize-finalize-annotated.cpp Thu Jan 24 11:14:17 2002 - *************** - *** 1,4 **** - #include "Pooma/Pooma.h" - ! #include - - int main(int argc, char *argv[]) - --- 1,5 ---- - + - #include "Pooma/Pooma.h" - ! #include <iostream> - - int main(int argc, char *argv[]) - *************** - *** 11,12 **** - --- 12,14 ---- - return 0; - } - + --- 0 ---- Index: examples/Templates/pairs-templated-annotated.patch =================================================================== RCS file: pairs-templated-annotated.patch diff -N pairs-templated-annotated.patch *** /tmp/cvsAVPLxz Thu Jan 31 14:52:13 2002 --- /dev/null Fri Mar 23 21:37:44 2001 *************** *** 1,37 **** - *** pairs-templated.cpp Mon Jan 7 16:11:56 2002 - --- pairs-templated-annotated.cpp Wed Jan 23 12:33:13 2002 - *************** - *** 1,15 **** - // Declare a template class storing a pair of values with the same type. - ! template - struct pair { - ! pair(const int& left, const int& right) - : left_(left), right_(right) {} - - ! T left_; - T right_; - }; - - ! // Define a class storing a pair of integers. - ! pair pair1; - - ! // Define a class storing a pair of doubles; - ! pair pair2; - --- 1,17 ---- - + - // Declare a template class storing a pair of values with the same type. - ! template <typename T> // - struct pair { - ! pair(const T& left, const T& right) // - : left_(left), right_(right) {} - - ! T left_; // - T right_; - }; - - ! // Use a class storing a pair of integers. - ! pair<int> pair1; - - ! // Use a class storing a pair of doubles; - ! pair<double> pair2; - ! --- 0 ---- From oldham at mail.codesourcery.com Thu Jan 31 22:25:50 2002 From: oldham at mail.codesourcery.com (Jeffrey) Date: Thu, 31 Jan 2002 14:25:50 -0800 Subject: Manual Patch: Programs Message-ID: <20020131142550.A29745@vaio.codesourcery.com> The files containing the DocBook annotations for programs included in the POOMA manual got mangled. Hopefully, the attached changes ensured every file appears exactly once. Sorry, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- ? programs-2002Jan31.patch Index: Makefile =================================================================== RCS file: Makefile diff -N Makefile *** /dev/null Fri Mar 23 21:37:44 2001 --- Makefile Thu Jan 31 15:19:46 2002 *************** *** 0 **** --- 1,15 ---- + ### Oldham, Jeffrey D. + ### 2001Nov27 + ### Pooma + ### + ### Produce Annotated Source Code + + ## These rules combine executable code, which can be compiled and run, + ## with DocBook annotations used in the manual to explain the code. + + all: array-copy-annotated.cpp dynamicarray-annotated.cpp \ + initialize-finalize-annotated.cpp \ + pairs-templated-annotated.cpp pairs-untemplated-annotated.cpp + + %-annotated.cpp: %-annotated.patch %.cpp + patch -o $@ < $< Index: array-copy-annotated.patch =================================================================== RCS file: array-copy-annotated.patch diff -N array-copy-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- array-copy-annotated.patch Thu Jan 31 15:19:46 2002 *************** *** 0 **** --- 1,78 ---- + *** array-copy.cpp Thu Jan 24 11:12:23 2002 + --- array-copy-annotated.cpp Thu Jan 31 09:22:57 2002 + *************** + *** 1,8 **** + #include "Pooma/Pooma.h" + #include "Pooma/Arrays.h" + ! #include + + // Changes the Array value at index (0,0). + ! void changeValue(Array<2,int,Brick>& z) + { z(0,0) = 6; } + + --- 1,9 ---- + + + #include "Pooma/Pooma.h" + #include "Pooma/Arrays.h" + ! #include <iostream> + + // Changes the Array value at index (0,0). + ! void changeValue(Array<2,int,Brick>& z) + { z(0,0) = 6; } + + *************** + *** 11,35 **** + Pooma::initialize(argc,argv); + + ! Array<2,int,Brick> a(3,4, ModelElement(4)); + ! std::cout << "Initial value:\n"; + ! std::cout << "a: " << a(0,0) << std::endl; + + // Array copies share the same underlying values. + + ! // Explicit initialization uses reference semantics so changing the + ! // copy's value at (0,0) also changes the original's value. + ! Array<2,int,Brick> b(a); + b(0,0) = 5; + ! std::cout << "After explicit initialization.\n"; + ! std::cout << "a: " << a(0,0) << std::endl; + ! std::cout << "b: " << b(0,0) << std::endl; + ! + ! // Initialization of function arguments also uses reference semantics. + ! std::cout << "After function call:\n"; + changeValue(a); + ! std::cout << "a: " << a(0,0) << std::endl; + ! std::cout << "b: " << b(0,0) << std::endl; + + Pooma::finalize(); + return 0; + } + --- 12,39 ---- + Pooma::initialize(argc,argv); + + ! Array<2,int,Brick> a(3,4, ModelElement<int>(4)); + ! std::cout &openopen; "Initial value:\n"; + ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; + + // Array copies share the same underlying values. + + ! // Explicit initialization uses reference semantics + ! // so changing the copy's value at (0,0) also + ! // changes the original's value. + ! Array<2,int,Brick> b(a); + b(0,0) = 5; + ! std::cout &openopen; "After explicit initialization.\n"; + ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; + ! std::cout &openopen; "b: " &openopen; b(0,0) &openopen; std::endl; + ! + ! // Initialization of function arguments also uses + ! // reference semantics. + ! std::cout &openopen; "After function call:\n"; + changeValue(a); + ! std::cout &openopen; "a: " &openopen; a(0,0) &openopen; std::endl; + ! std::cout &openopen; "b: " &openopen; b(0,0) &openopen; std::endl; + + Pooma::finalize(); + return 0; + } + + Index: array-size-annotated.patch =================================================================== RCS file: array-size-annotated.patch diff -N array-size-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- array-size-annotated.patch Thu Jan 31 15:19:46 2002 *************** *** 0 **** --- 1,80 ---- + *** array-size.cpp Tue Jan 15 13:30:53 2002 + --- array-size-annotated.cpp Thu Jan 31 09:24:16 2002 + *************** + *** 1,25 **** + #include "Pooma/Pooma.h" + #include "Pooma/Arrays.h" + ! #include + + // Print an Array's Size + + ! // This program illustrates using the Array member functions. + ! // computeArraySize's computation is redundant because Array's size() + ! // function computes the same value, but it illustrates using Array + // member functions. + + ! template + inline + ! long computeArraySize(const Array& a) + { + ! const Loc fs = a.firsts(); + ! const Loc ls = a.lasts(); + ! const Loc lens = a.lengths(); + long size = 1; + ! for (int d = 0; d < Dim; ++d) { + ! size *= lens[d].first(); + // Check that lengths() and our computed lengths agree. + ! PAssert((ls[d] - fs[d] + 1).first() == a.length(d)); + } + return size; + --- 1,27 ---- + + + #include "Pooma/Pooma.h" + #include "Pooma/Arrays.h" + ! #include <iostream> + + // Print an Array's Size + + ! // This program illustrates using the Array member + ! // functions. computeArraySize's computation is + ! // redundant because Array's size() function computes + ! // the same value, but it illustrates using Array + // member functions. + + ! template <int Dim,typename Type,typename EngineTag> + inline + ! long computeArraySize(const Array<Dim,Type,EngineTag>& a) + { + ! const Loc<Dim> fs = a.firsts(); + ! const Loc<Dim> ls = a.lasts(); + ! const Loc<Dim> lens = a.lengths(); + long size = 1; + ! for (int d = 0; d < Dim; ++d) { + ! size *= lens[d].first(); + // Check that lengths() and our computed lengths agree. + ! PAssert((ls[d]-fs[d]+1).first()==a.length(d)); + } + return size; + *************** + *** 30,38 **** + Pooma::initialize(argc,argv); + + ! Array<3,int,Brick> a(3,4,5, ModelElement(4)); + ! PAssert(computeArraySize(a) == a.size()); + ! std::cout << "The array's size is " << a.size() << ".\n"; + + Pooma::finalize(); + return 0; + } + --- 32,42 ---- + Pooma::initialize(argc,argv); + + ! Array<3,int,Brick> a(3,4,5, ModelElement<int>(4)); + ! PAssert(computeArraySize(a) == a.size()); + ! std::cout &openopen; + ! "The array's size is " &openopen; a.size() &openopen; ".\n"; + + Pooma::finalize(); + return 0; + } + + Index: dynamicarray-annotated.patch =================================================================== RCS file: dynamicarray-annotated.patch diff -N dynamicarray-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- dynamicarray-annotated.patch Thu Jan 31 15:19:46 2002 *************** *** 0 **** --- 1,80 ---- + *** dynamicarray.cpp Mon Jan 21 17:29:38 2002 + --- dynamicarray-annotated.cpp Tue Jan 22 07:06:15 2002 + *************** + *** 1,5 **** + #include "Pooma/Pooma.h" + ! #include "Pooma/DynamicArrays.h" + ! #include + + // Demonstrate using DynamicArrays. + --- 1,6 ---- + + + #include "Pooma/Pooma.h" + ! #include "Pooma/DynamicArrays.h" + ! #include <iostream> + + // Demonstrate using DynamicArrays. + *************** + *** 9,38 **** + Pooma::initialize(argc,argv); + + ! // Create a DynamicArray with one element. + ! DynamicArray<> d0(1); + ! DynamicArray d01(1); + ! DynamicArray d02(1); + + ! // Add five more elements. + d0.create(5); + // Store values in the array. + ! for (int i = d0.domain().first(); i <= d0.domain().last(); ++i) + ! d0(i) = i; + + ! // Delete every other element. + ! d0.destroy(Range<1>(d0.domain().first(),d0.domain().last(),2), BackFill()); + + // Print the resulting array. + ! std::cout << d0 << std::endl; + + // Use the iterator form of 'destroy.' + ! DynamicArray<> d1(6); + for (int i = d1.domain().first(); i <= d1.domain().last(); ++i) + d1(i) = i; + ! int killList[] = { 0, 2, 4 }; + d1.destroy(killList, killList+3); + ! std::cout << d1 << std::endl; + + Pooma::finalize(); + return 0; + } + --- 10,40 ---- + Pooma::initialize(argc,argv); + + ! // Create a DynamicArray with one element. + ! DynamicArray<> d0(1); + ! DynamicArray<double> d01(1); + ! DynamicArray<double, Dynamic> d02(1); + + ! // Add five more elements. + d0.create(5); + // Store values in the array. + ! for (int i = d0.domain().first(); i <= d0.domain().last(); ++i) + ! d0(i) = i; + + ! // Delete every other element. + ! d0.destroy(Range<1>(d0.domain().first(),d0.domain().last(),2), BackFill()); + + // Print the resulting array. + ! std::cout &openopen; d0 &openopen; std::endl; + + // Use the iterator form of 'destroy.' + ! DynamicArray<> d1(6); + for (int i = d1.domain().first(); i <= d1.domain().last(); ++i) + d1(i) = i; + ! int killList[] = { 0, 2, 4 }; + d1.destroy(killList, killList+3); + ! std::cout &openopen; d1 &openopen; std::endl; + + Pooma::finalize(); + return 0; + } + + Index: initialize-finalize-annotated.patch =================================================================== RCS file: initialize-finalize-annotated.patch diff -N initialize-finalize-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- initialize-finalize-annotated.patch Thu Jan 31 15:19:46 2002 *************** *** 0 **** --- 1,20 ---- + *** initialize-finalize.cpp Thu Jan 24 11:14:13 2002 + --- initialize-finalize-annotated.cpp Thu Jan 24 11:14:17 2002 + *************** + *** 1,4 **** + #include "Pooma/Pooma.h" + ! #include + + int main(int argc, char *argv[]) + --- 1,5 ---- + + + #include "Pooma/Pooma.h" + ! #include <iostream> + + int main(int argc, char *argv[]) + *************** + *** 11,12 **** + --- 12,14 ---- + return 0; + } + + Index: pairs-templated-annotated.patch =================================================================== RCS file: pairs-templated-annotated.patch diff -N pairs-templated-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- pairs-templated-annotated.patch Thu Jan 31 15:19:46 2002 *************** *** 0 **** --- 1,38 ---- + *** pairs-templated.cpp Mon Jan 7 16:11:56 2002 + --- pairs-templated-annotated.cpp Thu Jan 31 08:44:35 2002 + *************** + *** 1,15 **** + ! // Declare a template class storing a pair of values with the same type. + ! template + struct pair { + ! pair(const int& left, const int& right) + : left_(left), right_(right) {} + + ! T left_; + T right_; + }; + + ! // Define a class storing a pair of integers. + ! pair pair1; + + ! // Define a class storing a pair of doubles; + ! pair pair2; + --- 1,18 ---- + ! + ! // Declare a template class storing a pair of values + ! // with the same type. + ! template <typename T> // + struct pair { + ! pair(const T& left, const T& right) // + : left_(left), right_(right) {} + + ! T left_; // + T right_; + }; + + ! // Use a class storing a pair of integers. + ! pair<int> pair1; + + ! // Use a class storing a pair of doubles; + ! pair<double> pair2; + ! Index: pairs-untemplated-annotated.patch =================================================================== RCS file: pairs-untemplated-annotated.patch diff -N pairs-untemplated-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- pairs-untemplated-annotated.patch Thu Jan 31 15:19:46 2002 *************** *** 0 **** --- 1,35 ---- + *** pairs-untemplated.cpp Wed Dec 26 13:48:10 2001 + --- pairs-untemplated-annotated.cpp Wed Dec 26 14:02:58 2001 + *************** + *** 1,5 **** + // Declare a class storing a pair of integers. + struct pairOfInts { + ! pairOfInts(const int& left, const int& right) + : left_(left), right_(right) {} + + --- 1,6 ---- + + + // Declare a class storing a pair of integers. + struct pairOfInts { + ! pairOfInts(const int& left, const int& right) + : left_(left), right_(right) {} + + *************** + *** 10,14 **** + // Declare a class storing a pair of doubles. + struct pairOfDoubles { + ! pairOfDoubles(const double& left, const double& right) + : left_(left), right_(right) {} + + --- 11,15 ---- + // Declare a class storing a pair of doubles. + struct pairOfDoubles { + ! pairOfDoubles(const double& left, const double& right) + : left_(left), right_(right) {} + + *************** + *** 16,17 **** + --- 17,19 ---- + double right_; + }; + + -------------- next part -------------- Index: Doof2d-Array-distributed-annotated.patch =================================================================== RCS file: Doof2d-Array-distributed-annotated.patch diff -N Doof2d-Array-distributed-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- Doof2d-Array-distributed-annotated.patch Thu Jan 31 15:14:50 2002 *************** *** 0 **** --- 1,251 ---- + *** Doof2d-Array-distributed.cpp Mon Jan 28 20:35:07 2002 + --- Doof2d-Array-distributed-annotated.cpp Thu Jan 31 09:12:19 2002 + *************** + *** 1,6 **** + ! #include // has EXIT_SUCCESS + ! #include "Pooma/Arrays.h" // has POOMA's Array declarations + + ! // Doof2d: POOMA Arrays, stencil, multiple processor implementation + + // Define the stencil class performing the computation. + --- 1,10 ---- + ! + ! #include <iostream> // has std::cout, ... + ! #include <stdlib.h> // has EXIT_SUCCESS + ! #include "Pooma/Arrays.h" + ! // has POOMA's Array declarations + + ! // Doof2d: POOMA Arrays, stencil, multiple + ! // processor implementation + + // Define the stencil class performing the computation. + *************** + *** 11,26 **** + DoofNinePt() : weight(1.0/9.0) {} + + ! // This stencil operator is applied to each interior domain position + ! // (i,j). The "C" template parameter permits use of this stencil + // operator with both Arrays and Fields. + ! template + inline + typename C::Element_t + ! operator()(const C& x, int i, int j) const + ! { + ! return ( weight * + ! ( x.read(i+1,j+1) + x.read(i+1,j ) + x.read(i+1,j-1) + + ! x.read(i ,j+1) + x.read(i ,j ) + x.read(i ,j-1) + + ! x.read(i-1,j+1) + x.read(i-1,j ) + x.read(i-1,j-1) ) ); + } + + --- 15,31 ---- + DoofNinePt() : weight(1.0/9.0) {} + + ! // This stencil operator is applied to each interior + ! // domain position (i,j). The "C" template + ! // parameter permits use of this stencil + // operator with both Arrays and Fields. + ! template <class C> + inline + typename C::Element_t + ! operator()(const C& x, int i, int j) const { + ! return + ! weight * + ! (x.read(i+1,j+1)+x.read(i+1,j)+x.read(i+1,j-1) + + ! x.read(i ,j+1)+x.read(i ,j)+x.read(i ,j-1) + + ! x.read(i-1,j+1)+x.read(i-1,j)+x.read(i-1,j-1)); + } + + *************** + *** 39,52 **** + Pooma::initialize(argc,argv); + + ! // Since multiple copies of this program may simultaneously run, we + ! // cannot use standard input and output. Instead we use command-line + ! // arguments, which are replicated, for input, and we use an Inform + ! // stream for output. + Inform output; + + ! // Read the program input from the command-line arguments. + if (argc != 4) { + // Incorrect number of command-line arguments. + ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; + return EXIT_FAILURE; + } + --- 44,63 ---- + Pooma::initialize(argc,argv); + + ! // Since multiple copies of this program may simul- + ! // taneously run, we cannot use standard input and + ! // output. Instead we use command-line arguments, + ! // which are replicated, for input, and we use an + ! // Inform stream for output. + Inform output; + + ! // Read the program input from the command-line + ! // arguments. + if (argc != 4) { + // Incorrect number of command-line arguments. + ! output &openopen; + ! argv[0] &openopen; + ! ": number-of-processors number-of-averagings" + ! &openopen; " number-of-values" + ! &openopen; std::endl; + return EXIT_FAILURE; + } + *************** + *** 55,112 **** + // Determine the number of processors. + long nuProcessors; + ! nuProcessors = strtol(argv[1], &tail, 0); + + // Determine the number of averagings. + long nuAveragings, nuIterations; + ! nuAveragings = strtol(argv[2], &tail, 0); + ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + ! // Ask the user for the number n of values along one dimension of + ! // the grid. + long n; + ! n = strtol(argv[3], &tail, 0); + ! // The dimension must be a multiple of the number of processors + ! // since we are using a UniformGridLayout. + ! n = ((n+nuProcessors-1) / nuProcessors) * nuProcessors; + + // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + ! // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<2> interiorDomain(I,I); + + // Create the distributed arrays. + ! // Partition the arrays' domains uniformly, i.e., each patch has the + ! // same size. The first parameter tells how many patches for each + ! // dimension. Guard layers optimize communication between patches. + ! // Internal guards surround each patch. External guards surround + ! // the entire array domain. + ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), + ! GuardLayers<2>(1), // internal + ! GuardLayers<2>(0)); // external + ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); + ! + ! // The Array template parameters indicate 2 dimensions and a 'double' + ! // value type. MultiPatch indicates multiple computation patches, + ! // i.e., distributed computation. The UniformTag indicates the + ! // patches should have the same size. Each patch has Brick type. + ! Array<2, double, MultiPatch > > a(layout); + ! Array<2, double, MultiPatch > > b(layout); + + // Set up the initial conditions. + ! // All grid values should be zero except for the central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; + + // Create the stencil performing the computation. + ! Stencil stencil; + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(interiorDomain) = stencil(b, interiorDomain); + + --- 66,137 ---- + // Determine the number of processors. + long nuProcessors; + ! nuProcessors = strtol(argv[1], &tail, 0); + + // Determine the number of averagings. + long nuAveragings, nuIterations; + ! nuAveragings = strtol(argv[2], &tail, 0); + ! nuIterations = (nuAveragings+1)/2; + ! // Each iteration performs two averagings. + + ! // Ask the user for the number n of values along + ! // one dimension of the grid. + long n; + ! n = strtol(argv[3], &tail, 0); + ! // The dimension must be a multiple of the number + ! // of processors since we are using a + ! // UniformGridLayout. + ! n=((n+nuProcessors-1)/nuProcessors)*nuProcessors; + + // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + ! // Set up interior domains [1,n-1) x [1,n-1) + ! // for computation. + ! Interval<1> I(1,n-2); + ! Interval<2> interiorDomain(I,I); + + // Create the distributed arrays. + ! + ! // Partition the arrays' domains uniformly, i.e., + ! // each patch has the same size. The first para- + ! // meter tells how many patches for each dimension. + ! // Guard layers optimize communication between + ! // patches. Internal guards surround each patch. + ! // External guards surround the entire array + ! // domain. + ! UniformGridPartition<2> + ! partition(Loc<2>(nuProcessors, nuProcessors), + ! GuardLayers<2>(1), // internal + ! GuardLayers<2>(0)); // external + ! UniformGridLayout<2> layout(vertDomain, partition, + ! DistributedTag()); + ! + ! // The Array template parameters indicate 2 dims + ! // and a 'double' value type. MultiPatch indicates + ! // multiple computation patches, i.e, distributed + ! // computation. The UniformTag indicates the + ! // patches should have the same size. Each patch + ! // has Brick type. + ! Array<2, double, MultiPatch<UniformTag, + ! Remote<Brick> > > a(layout); + ! Array<2, double, MultiPatch<UniformTag, + ! Remote<Brick> > > b(layout); + + // Set up the initial conditions. + ! // All grid values should be zero except for the + ! // central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes + ! // before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; + + // Create the stencil performing the computation. + ! Stencil<DoofNinePt> stencil; + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(interiorDomain) = stencil(b, interiorDomain); + + *************** + *** 116,121 **** + + // Print out the final central value. + ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; + + // The arrays are automatically deallocated. + --- 141,149 ---- + + // Print out the final central value. + ! Pooma::blockAndEvaluate(); + ! // Ensure all computation has finished. + ! output &openopen; + ! (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) + ! &openopen; std::endl; + + // The arrays are automatically deallocated. + *************** + *** 125,126 **** + --- 153,155 ---- + return EXIT_SUCCESS; + } + + Index: Doof2d-Array-element-annotated.patch =================================================================== RCS file: Doof2d-Array-element-annotated.patch diff -N Doof2d-Array-element-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- Doof2d-Array-element-annotated.patch Thu Jan 31 15:14:50 2002 *************** *** 0 **** --- 1,149 ---- + *** Doof2d-Array-element.cpp Wed Jan 23 19:18:17 2002 + --- Doof2d-Array-element-annotated.cpp Thu Jan 31 08:55:57 2002 + *************** + *** 1,5 **** + ! #include // has std::cout, ... + ! #include // has EXIT_SUCCESS + ! #include "Pooma/Arrays.h" // has POOMA's Array declarations + + // Doof2d: POOMA Arrays, element-wise implementation + --- 1,7 ---- + ! + ! #include <iostream> // has std::cout, ... + ! #include <stdlib.h> // has EXIT_SUCCESS + ! #include "Pooma/Arrays.h" + ! // has POOMA's Array declarations + + // Doof2d: POOMA Arrays, element-wise implementation + *************** + *** 7,37 **** + int main(int argc, char *argv[]) + { + ! // Prepare the POOMA library for execution. + Pooma::initialize(argc,argv); + + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout << "Please enter the number of averagings: "; + ! std::cin >> nuAveragings; + ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + ! // Ask the user for the number n of values along one dimension of + ! // the grid. + long n; + ! std::cout << "Please enter the array size: "; + ! std::cin >> n; + + ! // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + ! + ! // Create the arrays. + ! // The Array template parameters indicate 2 dimensions, a 'double' value + // type, and ordinary 'Brick' storage. + ! Array<2, double, Brick> a(vertDomain); + ! Array<2, double, Brick> b(vertDomain); + + // Set up the initial conditions. + ! // All grid values should be zero except for the central value. + for (int j = 1; j < n-1; j++) + for (int i = 1; i < n-1; i++) + --- 9,42 ---- + int main(int argc, char *argv[]) + { + ! // Prepare the POOMA library for execution. + Pooma::initialize(argc,argv); + + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout &openopen; "Please enter the number of averagings: "; + ! std::cin &closeclose; nuAveragings; + ! nuIterations = (nuAveragings+1)/2; + ! // Each iteration performs two averagings. + + ! // Ask the user for the number n of values along + ! // one dimension of the grid. + long n; + ! std::cout &openopen; "Please enter the array size: "; + ! std::cin &closeclose; n; + + ! // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + ! + ! // Create the arrays. + ! // The Array template parameters indicate + ! // 2 dimensions, a 'double' value + // type, and ordinary 'Brick' storage. + ! Array<2, double, Brick> a(vertDomain); + ! Array<2, double, Brick> b(vertDomain); + + // Set up the initial conditions. + ! // All grid values should be zero except for the + ! // central value. + for (int j = 1; j < n-1; j++) + for (int i = 1; i < n-1; i++) + *************** + *** 43,51 **** + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + // Read from b. Write to a. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + ! a(i,j) = weight * + (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + + b(i ,j+1) + b(i ,j ) + b(i ,j-1) + + --- 48,56 ---- + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + // Read from b. Write to a. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + ! a(i,j) = weight * + (b(i+1,j+1) + b(i+1,j ) + b(i+1,j-1) + + b(i ,j+1) + b(i ,j ) + b(i ,j-1) + + *************** + *** 53,58 **** + + // Read from a. Write to b. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + b(i,j) = weight * + (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + + --- 58,63 ---- + + // Read from a. Write to b. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + b(i,j) = weight * + (a(i+1,j+1) + a(i+1,j ) + a(i+1,j-1) + + *************** + *** 62,71 **** + + // Print out the final central value. + ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; + + ! // The arrays are automatically deallocated. + + ! // Tell the POOMA library execution has finished. + Pooma::finalize(); + return EXIT_SUCCESS; + } + --- 67,81 ---- + + // Print out the final central value. + ! Pooma::blockAndEvaluate(); + ! // Ensure all computation has finished. + ! std::cout &openopen; + ! (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) + ! &openopen; std::endl; + + ! // The arrays are automatically deallocated. + + ! // Tell the POOMA library execution finished. + Pooma::finalize(); + return EXIT_SUCCESS; + } + + Index: Doof2d-Array-parallel-annotated.patch =================================================================== RCS file: Doof2d-Array-parallel-annotated.patch diff -N Doof2d-Array-parallel-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- Doof2d-Array-parallel-annotated.patch Thu Jan 31 15:14:50 2002 *************** *** 0 **** --- 1,128 ---- + *** Doof2d-Array-parallel.cpp Wed Jan 23 19:18:32 2002 + --- Doof2d-Array-parallel-annotated.cpp Mon Jan 28 20:41:18 2002 + *************** + *** 1,5 **** + ! #include // has std::cout, ... + ! #include // has EXIT_SUCCESS + ! #include "Pooma/Arrays.h" // has POOMA's Array declarations + + // Doof2d: POOMA Arrays, data-parallel implementation + --- 1,7 ---- + ! + ! #include <iostream> // has std::cout, ... + ! #include <stdlib.h> // has EXIT_SUCCESS + ! #include "Pooma/Arrays.h" + ! // has POOMA's Array declarations + + // Doof2d: POOMA Arrays, data-parallel implementation + *************** + *** 12,43 **** + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout << "Please enter the number of averagings: "; + ! std::cin >> nuAveragings; + ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + ! // Ask the user for the number n of values along one dimension of + ! // the grid. + long n; + ! std::cout << "Please enter the array size: "; + ! std::cin >> n; + + // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + ! // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<1> J(1,n-2); + + // Create the arrays. + ! // The Array template parameters indicate 2 dimensions, a 'double' value + // type, and ordinary 'Brick' storage. + ! Array<2, double, Brick> a(vertDomain); + ! Array<2, double, Brick> b(vertDomain); + + // Set up the initial conditions. + ! // All grid values should be zero except for the central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; + --- 14,50 ---- + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout &openopen; "Please enter the number of averagings: "; + ! std::cin &closeclose; nuAveragings; + ! nuIterations = (nuAveragings+1)/2; + ! // Each iteration performs two averagings. + + ! // Ask the user for the number n of values along one + ! // dimension of the grid. + long n; + ! std::cout &openopen; "Please enter the array size: "; + ! std::cin &closeclose; n; + + // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + ! // Set up interior domains [1,n-1) x [1,n-1) + ! // for computation. + ! Interval<1> I(1,n-2); + ! Interval<1> J(1,n-2); + + // Create the arrays. + ! // The Array template parameters indicate 2 dimensions, + ! // a 'double' value + // type, and ordinary 'Brick' storage. + ! Array<2, double, Brick> a(vertDomain); + ! Array<2, double, Brick> b(vertDomain); + + // Set up the initial conditions. + ! // All grid values should be zero except for the + ! // central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes + ! // before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; + *************** + *** 47,52 **** + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(I,J) = weight * + (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + + --- 54,59 ---- + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(I,J) = weight * + (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + + *************** + *** 62,67 **** + + // Print out the final central value. + ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; + + // The arrays are automatically deallocated. + --- 69,77 ---- + + // Print out the final central value. + ! Pooma::blockAndEvaluate(); + ! // Ensure all computation has finished. + ! std::cout &openopen; + ! (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) + ! &openopen; std::endl; + + // The arrays are automatically deallocated. + *************** + *** 71,72 **** + --- 81,83 ---- + return EXIT_SUCCESS; + } + + Index: Doof2d-Array-stencil-annotated.patch =================================================================== RCS file: Doof2d-Array-stencil-annotated.patch diff -N Doof2d-Array-stencil-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- Doof2d-Array-stencil-annotated.patch Thu Jan 31 15:14:50 2002 *************** *** 0 **** --- 1,181 ---- + *** Doof2d-Array-stencil.cpp Wed Jan 23 19:18:49 2002 + --- Doof2d-Array-stencil-annotated.cpp Thu Jan 31 09:11:12 2002 + *************** + *** 1,9 **** + ! #include // has std::cout, ... + ! #include // has EXIT_SUCCESS + ! #include "Pooma/Arrays.h" // has POOMA's Array declarations + + // Doof2d: POOMA Arrays, stencil implementation + + ! // Define the stencil class performing the computation. + class DoofNinePt + { + --- 1,11 ---- + ! + ! #include <iostream> // has std::cout, ... + ! #include <stdlib.h> // has EXIT_SUCCESS + ! #include "Pooma/Arrays.h" + ! // has POOMA's Array declarations + + // Doof2d: POOMA Arrays, stencil implementation + + ! // Define a stencil class performing computation. + class DoofNinePt + { + *************** + *** 12,30 **** + DoofNinePt() : weight(1.0/9.0) {} + + ! // This stencil operator is applied to each interior domain position + ! // (i,j). The "C" template parameter permits use of this stencil + ! // operator with both Arrays and Fields. + ! template + inline + typename C::Element_t + ! operator()(const C& c, int i, int j) const + ! { + ! return ( weight * + ! ( c.read(i+1,j+1) + c.read(i+1,j ) + c.read(i+1,j-1) + + ! c.read(i ,j+1) + c.read(i ,j ) + c.read(i ,j-1) + + ! c.read(i-1,j+1) + c.read(i-1,j ) + c.read(i-1,j-1) ) ); + } + + ! inline int lowerExtent(int) const { return 1; } + inline int upperExtent(int) const { return 1; } + + --- 14,33 ---- + DoofNinePt() : weight(1.0/9.0) {} + + ! // This stencil operator is applied to each + ! // interior domain position (i,j). The "C" + ! // template parameter permits use of this + ! // stencil operator with both Arrays & Fields. + ! template <class C> + inline + typename C::Element_t + ! operator()(const C& c, int i, int j) const { + ! return + ! weight * + ! (c.read(i+1,j+1)+c.read(i+1,j)+c.read(i+1,j-1)+ + ! c.read(i ,j+1)+c.read(i ,j)+c.read(i ,j-1)+ + ! c.read(i-1,j+1)+c.read(i-1,j)+c.read(i-1,j-1)); + } + + ! inline int lowerExtent(int) const { return 1; } + inline int upperExtent(int) const { return 1; } + + *************** + *** 42,82 **** + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout << "Please enter the number of averagings: "; + ! std::cin >> nuAveragings; + ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + ! // Ask the user for the number n of values along one dimension of + ! // the grid. + long n; + ! std::cout << "Please enter the array size: "; + ! std::cin >> n; + + // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + ! // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<2> interiorDomain(I,I); + + // Create the arrays. + ! // The Array template parameters indicate 2 dimensions, a 'double' value + // type, and ordinary 'Brick' storage. + ! Array<2, double, Brick> a(vertDomain); + ! Array<2, double, Brick> b(vertDomain); + + // Set up the initial conditions. + ! // All grid values should be zero except for the central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; + + ! // Create the stencil performing the computation. + ! Stencil stencil; + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(interiorDomain) = stencil(b, interiorDomain); + + --- 45,90 ---- + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout &openopen; "Please enter the number of averagings: "; + ! std::cin &closeclose; nuAveragings; + ! nuIterations = (nuAveragings+1)/2; + ! // Each iteration performs two averagings. + + ! // Ask the user for the number n of values along one + ! // dimension of the grid. + long n; + ! std::cout &openopen; "Please enter the array size: "; + ! std::cin &closeclose; n; + + // Specify the arrays' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + ! // Set up interior domains [1,n-1) x [1,n-1) for + ! // computation. + ! Interval<1> I(1,n-2); + ! Interval<2> interiorDomain(I,I); + + // Create the arrays. + ! // The Array template parameters indicate + ! // 2 dimensions, a 'double' value + // type, and ordinary 'Brick' storage. + ! Array<2, double, Brick> a(vertDomain); + ! Array<2, double, Brick> b(vertDomain); + + // Set up the initial conditions. + ! // All grid values should be zero except for the + ! // central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes + ! // before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; + + ! // Create a stencil performing the computation. + ! Stencil<DoofNinePt> stencil; + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(interiorDomain) = stencil(b, interiorDomain); + + *************** + *** 86,91 **** + + // Print out the final central value. + ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; + + // The arrays are automatically deallocated. + --- 94,102 ---- + + // Print out the final central value. + ! Pooma::blockAndEvaluate(); + ! // Ensure all computation has finished. + ! std::cout &openopen; + ! (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) + ! &openopen; std::endl; + + // The arrays are automatically deallocated. + *************** + *** 95,96 **** + --- 106,108 ---- + return EXIT_SUCCESS; + } + + Index: Doof2d-C-element-annotated.patch =================================================================== RCS file: Doof2d-C-element-annotated.patch diff -N Doof2d-C-element-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- Doof2d-C-element-annotated.patch Thu Jan 31 15:14:50 2002 *************** *** 0 **** --- 1,154 ---- + *** Doof2d-C-element.cpp Thu Jan 31 08:46:50 2002 + --- Doof2d-C-element-annotated.cpp Thu Jan 31 08:47:14 2002 + *************** + *** 1,4 **** + ! #include // has std::cout, ... + ! #include // has EXIT_SUCCESS + + // Doof2d: C-like, element-wise implementation + --- 1,5 ---- + ! + ! #include <iostream> // has std::cout, ... + ! #include <stdlib.h> // has EXIT_SUCCESS + + // Doof2d: C-like, element-wise implementation + *************** + *** 6,30 **** + int main() + { + ! // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout << "Please enter the number of averagings: "; + ! std::cin >> nuAveragings; + ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + ! // Use two-dimensional grids of values. + double **a; + double **b; + + ! // Ask the user for the number n of values along one dimension of + ! // the grid. + long n; + ! std::cout << "Please enter the array size: "; + ! std::cin >> n; + + ! // Allocate the arrays. + typedef double* doublePtr; + a = new doublePtr[n]; + b = new doublePtr[n]; + ! for (int i = 0; i < n; i++) { + a[i] = new double[n]; + b[i] = new double[n]; + --- 7,32 ---- + int main() + { + ! // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout &openopen; "Please enter the number of averagings: "; + ! std::cin &closeclose; nuAveragings; + ! nuIterations = (nuAveragings+1)/2; + ! // Each iteration performs two averagings. + + ! // Use two-dimensional grids of values. + double **a; + double **b; + + ! // Ask the user for the number n of values along one + ! // dimension of the grid. + long n; + ! std::cout &openopen; "Please enter the array size: "; + ! std::cin &closeclose; n; + + ! // Allocate the arrays. + typedef double* doublePtr; + a = new doublePtr[n]; + b = new doublePtr[n]; + ! for (int i = 0; i < n; i++) { + a[i] = new double[n]; + b[i] = new double[n]; + *************** + *** 32,49 **** + + // Set up the initial conditions. + ! // All grid values should be zero except for the central value. + ! for (int j = 0; j < n; j++) + ! for (int i = 0; i < n; i++) + a[i][j] = b[i][j] = 0.0; + b[n/2][n/2] = 1000.0; + + ! // Average using this weight. + const double weight = 1.0/9.0; + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + a[i][j] = weight * + (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + + --- 34,52 ---- + + // Set up the initial conditions. + ! // All grid values should be zero except for the + ! // central value. + ! for (int j = 0; j < n; j++) + ! for (int i = 0; i < n; i++) + a[i][j] = b[i][j] = 0.0; + b[n/2][n/2] = 1000.0; + + ! // Average using this weight. + const double weight = 1.0/9.0; + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + a[i][j] = weight * + (b[i+1][j+1] + b[i+1][j ] + b[i+1][j-1] + + *************** + *** 51,57 **** + b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); + + ! // Read from a. Write to b. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + b[i][j] = weight * + (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + + --- 54,60 ---- + b[i-1][j+1] + b[i-1][j ] + b[i-1][j-1]); + + ! // Read from a. Write to b. + ! for (int j = 1; j < n-1; j++) + ! for (int i = 1; i < n-1; i++) + b[i][j] = weight * + (a[i+1][j+1] + a[i+1][j ] + a[i+1][j-1] + + *************** + *** 60,68 **** + } + + ! // Print out the final central value. + ! std::cout << (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) << std::endl; + + ! // Deallocate the arrays. + ! for (int i = 0; i < n; i++) { + delete [] a[i]; + delete [] b[i]; + --- 63,73 ---- + } + + ! // Print out the final central value. + ! std::cout &openopen; + ! (nuAveragings % 2 ? a[n/2][n/2] : b[n/2][n/2]) + ! &openopen; std::endl; + + ! // Deallocate the arrays. + ! for (int i = 0; i < n; i++) { + delete [] a[i]; + delete [] b[i]; + *************** + *** 73,74 **** + --- 78,80 ---- + return EXIT_SUCCESS; + } + + Index: Doof2d-Field-distributed-annotated.patch =================================================================== RCS file: Doof2d-Field-distributed-annotated.patch diff -N Doof2d-Field-distributed-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- Doof2d-Field-distributed-annotated.patch Thu Jan 31 15:14:50 2002 *************** *** 0 **** --- 1,219 ---- + *** Doof2d-Field-distributed.cpp Wed Jan 23 19:20:15 2002 + --- Doof2d-Field-distributed-annotated.cpp Wed Jan 30 16:40:27 2002 + *************** + *** 1,6 **** + ! #include // has EXIT_SUCCESS + ! #include "Pooma/Fields.h" // has POOMA's Field declarations + + ! // Doof2d: POOMA Fields, data-parallel, multiple processor implementation + + int main(int argc, char *argv[]) + --- 1,9 ---- + ! + ! #include <stdlib.h> // has EXIT_SUCCESS + ! #include "Pooma/Fields.h" + ! // has POOMA's Field declarations + + ! // Doof2d: POOMA Fields, data-parallel, multiple + ! // processor implementation + + int main(int argc, char *argv[]) + *************** + *** 9,16 **** + Pooma::initialize(argc,argv); + + ! // Since multiple copies of this program may simultaneously run, we + ! // canot use standard input and output. Instead we use command-line + ! // arguments, which are replicated, for input, and we use an Inform + ! // stream for output. + Inform output; + + --- 12,20 ---- + Pooma::initialize(argc,argv); + + ! // Since multiple copies of this program may + ! // simultaneously run, we canot use standard input + ! // and output. Instead we use command-line + ! // arguments, which are replicated, for input, and we + ! // use an Inform stream for output. + Inform output; + + *************** + *** 18,22 **** + if (argc != 4) { + // Incorrect number of command-line arguments. + ! output << argv[0] << ": number-of-processors number-of-averagings number-of-values" << std::endl; + return EXIT_FAILURE; + } + --- 22,29 ---- + if (argc != 4) { + // Incorrect number of command-line arguments. + ! output &openopen; argv[0] &openopen; + ! ": number-of-processors number-of-averagings" + ! &openopen; " number-of-values" + ! &openopen; std::endl; + return EXIT_FAILURE; + } + *************** + *** 25,79 **** + // Determine the number of processors. + long nuProcessors; + ! nuProcessors = strtol(argv[1], &tail, 0); + + // Determine the number of averagings. + long nuAveragings, nuIterations; + ! nuAveragings = strtol(argv[2], &tail, 0); + ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + ! // Ask the user for the number n of values along one dimension of + ! // the grid. + long n; + ! n = strtol(argv[3], &tail, 0); + ! // The dimension must be a multiple of the number of processors + ! // since we are using a UniformGridLayout. + n = ((n+nuProcessors-1) / nuProcessors) * nuProcessors; + + // Specify the fields' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + ! // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<1> J(1,n-2); + ! + ! // Partition the fields' domains uniformly, i.e., each patch has the + ! // same size. The first parameter tells how many patches for each + ! // dimension. Guard layers optimize communication between patches. + ! // Internal guards surround each patch. External guards surround + ! // the entire field domain. + ! UniformGridPartition<2> partition(Loc<2>(nuProcessors, nuProcessors), + ! GuardLayers<2>(1), // internal + ! GuardLayers<2>(0)); // external + ! UniformGridLayout<2> layout(vertDomain, partition, DistributedTag()); + ! + ! // Specify the fields' mesh, i.e., its spatial extent, and its + ! // centering type. + ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); + ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); + ! + ! // The Field template parameters indicate a mesh and a 'double' + ! // value type. MultiPatch indicates multiple computation patches, + ! // i.e., distributed computation. The UniformTag indicates the + ! // patches should have the same size. Each patch has Brick type. + ! Field, double, MultiPatch > > a(cell, layout, mesh); + ! Field, double, MultiPatch > > b(cell, layout, mesh); + + // Set up the initial conditions. + ! // All grid values should be zero except for the central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; + --- 32,99 ---- + // Determine the number of processors. + long nuProcessors; + ! nuProcessors = strtol(argv[1], &tail, 0); + + // Determine the number of averagings. + long nuAveragings, nuIterations; + ! nuAveragings = strtol(argv[2], &tail, 0); + ! nuIterations = (nuAveragings+1)/2; + ! // Each iteration performs two averagings. + + ! // Ask the user for the number n of values along + ! // one dimension of the grid. + long n; + ! n = strtol(argv[3], &tail, 0); + ! // The dimension must be a multiple of the number of + ! // processors since we are using a UniformGridLayout. + n = ((n+nuProcessors-1) / nuProcessors) * nuProcessors; + + // Specify the fields' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + ! // Set up interior domains [1,n-1) x [1,n-1) for + ! // computation. + ! Interval<1> I(1,n-2); + ! Interval<1> J(1,n-2); + ! + ! // Partition the fields' domains uniformly, i.e., + ! // each patch has the same size. The first parameter + ! // tells how many patches for each dimension. Guard + ! // layers optimize communication between patches. + ! // Internal guards surround each patch. External + ! // guards surround the entire field domain. + ! UniformGridPartition<2> + ! partition(Loc<2>(nuProcessors, nuProcessors), + ! GuardLayers<2>(1), // internal + ! GuardLayers<2>(0)); // external + ! UniformGridLayout<2> + ! layout(vertDomain, partition, DistributedTag()); + ! + ! // Specify the fields' mesh, i.e., its spatial + ! // extent, and its centering type. + ! UniformRectilinearMesh<2> + ! mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); + ! Centering<2> cell = + ! canonicalCentering<2>(CellType, Continuous, AllDim); + ! + ! // The Field template parameters indicate a mesh and + ! // a 'double' value type. MultiPatch indicates + ! // multiple computation patches, i.e., distributed + ! // computation. The UniformTag indicates the patches + ! // should have the same size. Each patch has Brick + ! // type. + ! Field<UniformRectilinearMesh<2>, double, + ! MultiPatch<UniformTag, Remote<Brick&closecloseclose; + ! a(cell, layout, mesh); + ! Field<UniformRectilinearMesh<2>, double, + ! MultiPatch<UniformTag, Remote<Brick&closecloseclose; + ! b(cell, layout, mesh); + + // Set up the initial conditions. + ! // All grid values should be zero except for the + ! // central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes + ! // before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; + *************** + *** 83,87 **** + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + // Read from b. Write to a. + a(I,J) = weight * + --- 103,107 ---- + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + // Read from b. Write to a. + a(I,J) = weight * + *************** + *** 98,103 **** + + // Print out the final central value. + ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! output << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; + + // The fields are automatically deallocated. + --- 118,126 ---- + + // Print out the final central value. + ! Pooma::blockAndEvaluate(); + ! // Ensure all computation has finished. + ! output &openopen; + ! (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) + ! &openopen; std::endl; + + // The fields are automatically deallocated. + *************** + *** 107,108 **** + --- 130,132 ---- + return EXIT_SUCCESS; + } + + Index: Doof2d-Field-parallel-annotated.patch =================================================================== RCS file: Doof2d-Field-parallel-annotated.patch diff -N Doof2d-Field-parallel-annotated.patch *** /dev/null Fri Mar 23 21:37:44 2001 --- Doof2d-Field-parallel-annotated.patch Thu Jan 31 15:14:50 2002 *************** *** 0 **** --- 1,144 ---- + *** Doof2d-Field-parallel.cpp Wed Jan 23 19:20:33 2002 + --- Doof2d-Field-parallel-annotated.cpp Thu Jan 31 09:07:32 2002 + *************** + *** 1,5 **** + ! #include // has std::cout, ... + ! #include // has EXIT_SUCCESS + ! #include "Pooma/Fields.h" // has POOMA's Field declarations + + // Doof2d: POOMA Fields, data-parallel implementation + --- 1,7 ---- + ! + ! #include <iostream> // has std::cout, ... + ! #include <stdlib.h> // has EXIT_SUCCESS + ! #include "Pooma/Fields.h" + ! // has POOMA's Field declarations + + // Doof2d: POOMA Fields, data-parallel implementation + *************** + *** 12,49 **** + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout << "Please enter the number of averagings: "; + ! std::cin >> nuAveragings; + ! nuIterations = (nuAveragings+1)/2; // Each iteration performs two averagings. + + ! // Ask the user for the number n of values along one dimension of + ! // the grid. + long n; + ! std::cout << "Please enter the field size: "; + ! std::cin >> n; + + // Specify the fields' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + ! // Set up interior domains [1,n-1) x [1,n-1) for computation. + ! Interval<1> I(1,n-2); + ! Interval<1> J(1,n-2); + ! + ! // Specify the fields' mesh, i.e., its spatial extent, and its + ! // centering type. + ! DomainLayout<2> layout(vertDomain); + ! UniformRectilinearMesh<2> mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); + ! Centering<2> cell = canonicalCentering<2>(CellType, Continuous, AllDim); + + // Create the fields. + ! // The Field template parameters indicate a mesh, a 'double' value + ! // type, and ordinary 'Brick' storage. + ! Field, double, Brick> a(cell, layout, mesh); + ! Field, double, Brick> b(cell, layout, mesh); + + // Set up the initial conditions. + ! // All grid values should be zero except for the central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; + --- 14,60 ---- + // Ask the user for the number of averagings. + long nuAveragings, nuIterations; + ! std::cout&openopen;"Please enter the number of averagings: "; + ! std::cin &closeclose; nuAveragings; + ! nuIterations = (nuAveragings+1)/2; + ! // Each iteration performs two averagings. + + ! // Ask the user for the number n of values along + ! // one dimension of the grid. + long n; + ! std::cout &openopen; "Please enter the field size: "; + ! std::cin &closeclose; n; + + // Specify the fields' domains [0,n) x [0,n). + ! Interval<1> N(0, n-1); + ! Interval<2> vertDomain(N, N); + + ! // Set up interior domains [1,n-1) x [1,n-1) for + ! // computation. + ! Interval<1> I(1,n-2); + ! Interval<1> J(1,n-2); + ! + ! // Specify the fields' mesh, i.e., its spatial + ! // extent, and its centering type. + ! DomainLayout<2> layout(vertDomain); + ! UniformRectilinearMesh<2> + ! mesh(layout, Vector<2>(0.0), Vector<2>(1.0, 1.0)); + ! Centering<2> cell = + ! canonicalCentering<2>(CellType, Continuous, AllDim); + + // Create the fields. + ! // The Field template parameters indicate a mesh, a + ! // 'double' value type, and ordinary 'Brick' + ! // storage. + ! Field<UniformRectilinearMesh<2>, double, Brick> + ! a(cell, layout, mesh); + ! Field<UniformRectilinearMesh<2>, double, Brick> + ! b(cell, layout, mesh); + + // Set up the initial conditions. + ! // All grid values should be zero except for the + ! // central value. + a = b = 0.0; + ! // Ensure all data-parallel computation finishes + ! // before accessing a value. + Pooma::blockAndEvaluate(); + b(n/2,n/2) = 1000.0; + *************** + *** 53,58 **** + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(I,J) = weight * + (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + + --- 64,69 ---- + + // Perform the simulation. + ! for (int k = 0; k < nuIterations; ++k) { + ! // Read from b. Write to a. + a(I,J) = weight * + (b(I+1,J+1) + b(I+1,J ) + b(I+1,J-1) + + *************** + *** 68,73 **** + + // Print out the final central value. + ! Pooma::blockAndEvaluate(); // Ensure all computation has finished. + ! std::cout << (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) << std::endl; + + // The fields are automatically deallocated. + --- 79,87 ---- + + // Print out the final central value. + ! Pooma::blockAndEvaluate(); + ! // Ensure all computation has finished. + ! std::cout &openopen; + ! (nuAveragings % 2 ? a(n/2,n/2) : b(n/2,n/2)) + ! &openopen; std::endl; + + // The fields are automatically deallocated. + *************** + *** 77,78 **** + --- 91,93 ---- + return EXIT_SUCCESS; + } + + Index: Makefile =================================================================== RCS file: Makefile diff -N Makefile *** /dev/null Fri Mar 23 21:37:44 2001 --- Makefile Thu Jan 31 15:14:50 2002 *************** *** 0 **** --- 1,16 ---- + ### Oldham, Jeffrey D. + ### 2001Nov27 + ### Pooma + ### + ### Produce Annotated Source Code for the POOMA Manual + + ## These rules combine executable code, which can be compiled and run, + ## with DocBook annotations used in the manual to explain the code. + + all: Doof2d-C-element-annotated.cpp Doof2d-Array-element-annotated.cpp \ + Doof2d-Array-parallel-annotated.cpp Doof2d-Array-stencil-annotated.cpp \ + Doof2d-Array-distributed-annotated.cpp \ + Doof2d-Field-parallel-annotated.cpp Doof2d-Field-distributed-annotated.cpp + + %-annotated.cpp: %-annotated.patch %.cpp + patch -o $@ < $< From oldham at codesourcery.com Thu Jan 31 22:57:00 2002 From: oldham at codesourcery.com (Jeffrey D . Oldham) Date: Thu, 31 Jan 2002 14:57:00 -0800 Subject: Manual Patch: Example Code 1 of x Message-ID: <20020131145700.A29944@vaio.codesourcery.com> This is the first of x changes to the example code written for the manual. 2002-Jan-31 Jeffrey D. Oldham * Doof2d/Doof2d-Array-distributed.cpp (main): Fix typo in comment. * Doof2d/Doof2d-C-element.cpp (main): Shorten comment. * Sequential/pairs-templated.cpp: New file. * Sequential/pairs-untemplated.cpp: Likewise. Applied to mainline Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Doof2d/Doof2d-Array-distributed.cpp =================================================================== RCS file: /home/pooma/Repository/r2/examples/Manual/Doof2d/Doof2d-Array-distributed.cpp,v retrieving revision 1.3 diff -c -p -r1.3 Doof2d-Array-distributed.cpp *** Doof2d/Doof2d-Array-distributed.cpp 2002/01/25 03:45:54 1.3 --- Doof2d/Doof2d-Array-distributed.cpp 2002/01/31 22:49:54 *************** int main(int argc, char *argv[]) *** 39,45 **** Pooma::initialize(argc,argv); // Since multiple copies of this program may simultaneously run, we ! // canot use standard input and output. Instead we use command-line // arguments, which are replicated, for input, and we use an Inform // stream for output. Inform output; --- 39,45 ---- Pooma::initialize(argc,argv); // Since multiple copies of this program may simultaneously run, we ! // cannot use standard input and output. Instead we use command-line // arguments, which are replicated, for input, and we use an Inform // stream for output. Inform output; Index: Doof2d/Doof2d-C-element.cpp =================================================================== RCS file: /home/pooma/Repository/r2/examples/Manual/Doof2d/Doof2d-C-element.cpp,v retrieving revision 1.3 diff -c -p -r1.3 Doof2d-C-element.cpp *** Doof2d/Doof2d-C-element.cpp 2002/01/25 03:45:54 1.3 --- Doof2d/Doof2d-C-element.cpp 2002/01/31 22:49:54 *************** int main() *** 37,43 **** a[i][j] = b[i][j] = 0.0; b[n/2][n/2] = 1000.0; ! // In the average, weight elements with this value. const double weight = 1.0/9.0; // Perform the simulation. --- 37,43 ---- a[i][j] = b[i][j] = 0.0; b[n/2][n/2] = 1000.0; ! // Average using this weight. const double weight = 1.0/9.0; // Perform the simulation. Index: Sequential/pairs-templated.cpp =================================================================== RCS file: pairs-templated.cpp diff -N pairs-templated.cpp *** /dev/null Fri Mar 23 21:37:44 2001 --- pairs-templated.cpp Thu Jan 31 15:49:54 2002 *************** *** 0 **** --- 1,15 ---- + // Declare a template class storing a pair of values with the same type. + template + struct pair { + pair(const int& left, const int& right) + : left_(left), right_(right) {} + + T left_; + T right_; + }; + + // Define a class storing a pair of integers. + pair pair1; + + // Define a class storing a pair of doubles; + pair pair2; Index: Sequential/pairs-untemplated.cpp =================================================================== RCS file: pairs-untemplated.cpp diff -N pairs-untemplated.cpp *** /dev/null Fri Mar 23 21:37:44 2001 --- pairs-untemplated.cpp Thu Jan 31 15:49:54 2002 *************** *** 0 **** --- 1,17 ---- + // Declare a class storing a pair of integers. + struct pairOfInts { + pairOfInts(const int& left, const int& right) + : left_(left), right_(right) {} + + int left_; + int right_; + }; + + // Declare a class storing a pair of doubles. + struct pairOfDoubles { + pairOfDoubles(const double& left, const double& right) + : left_(left), right_(right) {} + + double left_; + double right_; + };