Pipeline Pattern for Parallel MCTS

Total Page:16

File Type:pdf, Size:1020Kb

Pipeline Pattern for Parallel MCTS Pipeline Pattern for Parallel MCTS S. Ali Mirsoleimani1;2, Jaap van den Herik1, Aske Plaat1 and Jos Vermaseren2 1Leiden Centre of Data Science, Leiden University Niels Bohrweg 1, 2333 CA Leiden, The Netherlands 2Nikhef Theory Group, Nikhef Science Park 105, 1098 XG Amsterdam, The Netherlands Keywords: MCTS, Parallelization, Pipeline Pattern, Search Overhead Abstract: In this paper, we present a new algorithm for parallel Monte Carlo tree search (MCTS). It is based on the pipeline pattern and allows flexible management of the control flow of the operations in parallel MCTS. The pipeline pattern provides for the first structured parallel programming approach to MCTS. The Pipeline Pattern for Parallel MCTS algorithm (called 3PMCTS) scales very well to a higher number of cores when compared to the existing methods. The observed speedup is 21 on a 24-core machine. 1 Introduction parallel thread for execution on separate processors (Chaslot et al., 2008a; Schaefers and Platzner, 2014; Mirsoleimani et al., 2015a). This type of parallelism In recent years there has been much interest in the is called iteration-level parallelism (ILP). Close anal- Monte Carlo tree search (MCTS) algorithm. In 2006 ysis has learned us that each iteration in the chunk it was a new, adaptive, randomized optimization algo- can also be decomposed into separate operations for rithm (Coulom, 2006; Kocsis and Szepesvari,´ 2006). parallelization. Based on this idea, we introduce In fields as diverse as Artificial Intelligence, Opera- operation-level parallelism (OLP). The main point tions Research, and High Energy Physics, research is to assign each operation of MCTS to a separate has established that MCTS can find valuable approx- processing element for execution by separate proces- imate answers without domain-dependent heuristics sors. This leads to flexibility in managing the control (Kuipers et al., 2013). The strength of the MCTS flow of operations in the MCTS algorithm. The main algorithm is that it provides answers with a random contribution of this paper is introducing a new algo- amount of error for any fixed computational budget rithm based on the pipeline pattern for parallel MCTS (Goodfellow et al., 2016). Much effort has been (3PMCTS) and showing its benefits. put into the development of parallel algorithms for MCTS to reduce the running time. The efforts are The remainder of the paper is organized as fol- applied to a broad spectrum of parallel systems; rang- lows. In section 2 the required background informa- ing from small shared-memory multicore machines tion is briefly described. Section 3 provides necessary to large distributed-memory clusters. In the last two definitions and explanations for the design of 3PM- years, parallel MCTS played a major role in the suc- CTS. Section 4 gives the explanations for the imple- cess of AI by defeating humans in the game of Go mentation the 3PMCTS algorithm, Section 5 shows (Silver et al., 2016; Hassabis and Silver, 2017). the experimental setup, and Section 6 gives the exper- The general MCTS algorithm has four operations imental results. Finally, in Section 7 we conclude the inside its main loop (see Algorithm 1). This loop is paper. a good candidate for parallelization. Hence, a signif- icant effort has been put into the development of par- allelization methods for MCTS (Chaslot et al., 2008a; Yoshizoe et al., 2011; Fern and Lewis, 2011; Schae- 2 Background fers and Platzner, 2014; Mirsoleimani et al., 2015b). To implement these methods, the computation associ- ated with each iteration is assumed to be independent (Mirsoleimani et al., 2015a). Therefore, we can as- Below we discuss MCTS in Section 2.1, in Sec- sign a chunk of iterations as a separate task to each tion 2.2 the parallelization of MCTS is explained. 2.1 The MCTS Algorithm with the maximum number of visits). The purpose of MCTS is to approximate the The MCTS algorithm iteratively repeats four steps game-theoretic value of the actions that may be se- or operations to construct a search tree until a pre- lected from the current state by iteratively creating a defined computational budget (i.e., time or iteration partial search tree (Browne et al., 2012). How the constraint) is reached (Chaslot et al., 2008b; Coulom, search tree is built depends on how nodes in the tree 2006). Algorithm 1 shows the general MCTS algo- are selected (i.e., tree selection policy). In particular, rithm. nodes in the tree are selected according to the esti- In the beginning, the search tree has only a root mated probability that they are better than the current (v0) which represents the initial state in a domain. best action. It is essential to reduce the estimation er- Each node in the search tree resembles a state of the ror of the nodes’ values as quickly as possible. There- domain, and directed edges to child nodes represent fore, the tree selection policy in the MCTS algorithm actions leading to the succeeding states. Figure 1 il- aims at balancing exploitation (look in areas which lustrates one iteration of the MCTS algorithm on a appear to be promising) and exploration (look in ar- search tree that already has nine nodes. The non- eas that have not been well sampled yet) (Kocsis and terminal and internal nodes are represented by circles. Szepesvari,´ 2006). Squares show the terminal nodes. The Upper Confidence Bounds for Trees (UCT) algorithm addresses the exploitation-exploration 1.S ELECT: A path of nodes inside the search tree is selected from the root node until a non-terminal dilemma in the selection step of the MCTS algorithm leaf with unvisited children is reached (v ). Each using the UCB1 policy (Kocsis and Szepesvari,´ 6 j of the nodes inside the path is selected based on a 2006). A child node is selected to maximize: predefined tree selection policy (see Figure 1a). s 2ln(N(v)) 2.E XPAND: One of the children (v ) of the selected UCT( j) = X j + 2Cp (1) 9 N(v j) non-terminal leaf (v6) is generated randomly and added to the tree together with the selected path Q(v j) where X j = is an approximation of the game- (see Figure 1b). N(v j) theoretic value of node j. Q(v j) is the total reward of 3.P LAYOUT: From the given state of the newly all playouts that passed through node j, N(v j) is the added node, a sequence of randomly simulated ac- number of times node j has been visited, N(v) is the tions (i.e., RANDOMSIMULATION) is performed number of times the parent of node j has been vis- until a terminal state in the domain is reached. The ited, and Cp ≥ 0 is a constant. The left-hand term is terminal state is evaluated using a utility function for exploitation and the right-hand term is for explo- (i.e., EVALUATION) to produce a reward value D ration (Kocsis and Szepesvari,´ 2006). The decrease or (see Figure 1c). increase in the amount of exploration can be adjusted 4.B ACKUP: For each node in the selected path, the by Cp in the exploration term (see Section 6). number N(v) of times it has been visited is incre- mented by 1 and its total reward value Q(v) is up- 2.2 Parallelization of MCTS dated according to D (Browne et al., 2012). These values are required by the tree selection policy Parallelization of MCTS consists of a precise arrange- (see Figure 1d). ment of tasks and data dependencies. In section 2.2.1 As soon as the computational budget is exhausted, the we explain how to decompose MCTS into tasks. In best child of the root node is returned (e.g., the one section 2.2.2 we investigate what types of data depen- dencies exist among these tasks. In Section 2.2.3 the existing parallelization methods for MCTS are dis- Algorithm 1: The general MCTS algorithm. cussed. 1 Function MCTS(s0) 2.2.1 Decomposition into Tasks 2 v0 := creat root node with state s0; 3 while within search budget do 4 < vl ;sl > := SELECT(v0;s0); The first step towards parallelizing MCTS is to find 5 < vl ;sl > := EXPAND(vl ;sl ); concurrent tasks in MCTS. As stated above, there are 6 D := PLAYOUT(vl ;sl ); two levels of task decomposition in MCTS. 7 BACKUP(v ,D); l 1. Iteration-level tasks (ILT): In MCTS the compu- 8 end tation associated with each iteration is indepen- 9 return action a for the best child of v0 dent. Therefore, these are candidates to guide a v0 v0 v0 v0 v1 v2 v3 ∆ v1 v2 v3 v1 v2 v3 v1 v2 v3 v4 v5 v6 v7 ∆ v4 v5 v6 v7 v4 v5 v6 v7 v4 v5 v6 v7 v8 v9 ∆ v v v v v 8 8 9 ∆ 8 9 (a) SELECT (b) EXPAND (c) PLAYOUT (d) BACKUP Figure 1: One iteration of MCTS. task decomposition by mapping a chunk of itera- tions onto a task. v0 2. Operation-level tasks (OLT): The task decom- position for MCTS occurs inside each iteration. v1 v2 v3 Each of the four MCTS operations can be treated as a separate task. 2 v4 v5 v6 v7 2.2.2 Data Dependencies 1 3 v8 v9 v10 The second step is dealing adequately with the data dependency. When a search tree is shared among mul- Figure 2: Tree parallelization. The curly arrows represent tiple parallel threads, There are two levels of data de- threads. The rectangles are terminal leaf nodes. pendency. 1. Iteration-level dependencies (ILD): Strictly speaking, in MCTS, iteration j has a soft de- pendency to its predecessor iteration j − 1.
Recommended publications
  • Asp Net Core Request Pipeline
    Asp Net Core Request Pipeline Is Royce always cowled and multilobate when achromatize some wall very instanter and lawlessly? Hobbyless and flustered brazensVladamir regressively? cocainizing her intangibles tiptoed or cluster advertently. Is Patric fuzzed or paintable when cogs some theocracy Or gray may choose to berry the request. Json files etc and community of response body is not inject all low maintenance, we will be same coin. Another through components that asp and cto of. How extensible it crashes, just by one of startup class controller. Do the extended with really very complex scenarios when he enjoys sharing it ever was to delete models first user makes for node. Even add to implement captcha in startup class to the same concept is the reason you want to. Let us a pipeline to any incoming request processing, firefox still create an output? For an app to build a cup of. Razor pages uses handler methods to deal of incoming HTTP request. Ask how the above mentioned in last middleware, the come to tell who are ready simply obsolete at asp and options. Have asp and asp net core request pipeline but will not be mapped to pipeline io threads to work both. The internet and when creating sawdust in snippets or improvements that by one description be a request pipeline branching. Help editing this article, ordinary code inside of hosting infrastructure asp and actions before, we issue was not. The body to deal with minimal footprint to entity framework of needed loans for each middleware will take a docker, that receive criticism.
    [Show full text]
  • Stclang: State Thread Composition As a Foundation for Monadic Dataflow Parallelism Sebastian Ertel∗ Justus Adam Norman A
    STCLang: State Thread Composition as a Foundation for Monadic Dataflow Parallelism Sebastian Ertel∗ Justus Adam Norman A. Rink Dresden Research Lab Chair for Compiler Construction Chair for Compiler Construction Huawei Technologies Technische Universität Dresden Technische Universität Dresden Dresden, Germany Dresden, Germany Dresden, Germany [email protected] [email protected] [email protected] Andrés Goens Jeronimo Castrillon Chair for Compiler Construction Chair for Compiler Construction Technische Universität Dresden Technische Universität Dresden Dresden, Germany Dresden, Germany [email protected] [email protected] Abstract using monad-par and LVars to expose parallelism explicitly Dataflow execution models are used to build highly scalable and reach the same level of performance, showing that our parallel systems. A programming model that targets parallel programming model successfully extracts parallelism that dataflow execution must answer the following question: How is present in an algorithm. Further evaluation shows that can parallelism between two dependent nodes in a dataflow smap is expressive enough to implement parallel reductions graph be exploited? This is difficult when the dataflow lan- and our programming model resolves short-comings of the guage or programming model is implemented by a monad, stream-based programming model for current state-of-the- as is common in the functional community, since express- art big data processing systems. ing dependence between nodes by a monadic bind suggests CCS Concepts • Software and its engineering → Func- sequential execution. Even in monadic constructs that explic- tional languages. itly separate state from computation, problems arise due to the need to reason about opaquely defined state.
    [Show full text]
  • Let's Get Functional
    5 LET’S GET FUNCTIONAL I’ve mentioned several times that F# is a functional language, but as you’ve learned from previous chapters you can build rich applications in F# without using any functional techniques. Does that mean that F# isn’t really a functional language? No. F# is a general-purpose, multi paradigm language that allows you to program in the style most suited to your task. It is considered a functional-first lan- guage, meaning that its constructs encourage a functional style. In other words, when developing in F# you should favor functional approaches whenever possible and switch to other styles as appropriate. In this chapter, we’ll see what functional programming really is and how functions in F# differ from those in other languages. Once we’ve estab- lished that foundation, we’ll explore several data types commonly used with functional programming and take a brief side trip into lazy evaluation. The Book of F# © 2014 by Dave Fancher What Is Functional Programming? Functional programming takes a fundamentally different approach toward developing software than object-oriented programming. While object-oriented programming is primarily concerned with managing an ever-changing system state, functional programming emphasizes immutability and the application of deterministic functions. This difference drastically changes the way you build software, because in object-oriented programming you’re mostly concerned with defining classes (or structs), whereas in functional programming your focus is on defining functions with particular emphasis on their input and output. F# is an impure functional language where data is immutable by default, though you can still define mutable data or cause other side effects in your functions.
    [Show full text]
  • BIOVIA Pipeline Pilot System Requirements
    SYSTEM REQUIREMENTS PIPELINE PILOT 2020 Copyright Notice ©2019 Dassault Systèmes. All rights reserved. 3DEXPERIENCE, the Compass icon and the 3DS logo, CATIA, SOLIDWORKS, ENOVIA, DELMIA, SIMULIA, GEOVIA, EXALEAD, 3DVIA, 3DSWYM, BIOVIA, NETVIBES, IFWE and 3DEXCITE, are commercial trademarks or registered trademarks of Dassault Systèmes, a French "société européenne" (Versailles Commercial Register # B 322 306 440), or its subsidiaries in the U.S. and/or other countries. All other trademarks are owned by their respective owners. Use of any Dassault Systèmes or its subsidiaries trademarks is subject to their express written approval. Acknowledgments and References To print photographs or files of computational results (figures and/or data) obtained by using Dassault Systèmes software, acknowledge the source in an appropriate format. For example: "Computational results were obtained by using Dassault Systèmes BIOVIA software programs. Pipeline Pilot Server was used to perform the calculations and to generate the graphical results." Dassault Systèmes may grant permission to republish or reprint its copyrighted materials. Requests should be submitted to Dassault Systèmes Customer Support, either by visiting https://www.3ds.com/support/ and clicking Call us or Submit a request, or by writing to: Dassault Systèmes Customer Support 10, Rue Marcel Dassault 78140 Vélizy-Villacoublay FRANCE Contents About This Document 1 Definitions 1 Additional Information 1 Dassault Systèmes Support Resources 1 Pipeline Pilot Server Requirements 2 Minimum Hardware
    [Show full text]
  • Fast Linux I/O in the Unix Tradition
    — preprint only: final version will appear in OSR, July 2008 — PipesFS: Fast Linux I/O in the Unix Tradition Willem de Bruijn Herbert Bos Vrije Universiteit Amsterdam Vrije Universiteit Amsterdam and NICTA [email protected] [email protected] ABSTRACT ory wall” [26]). To improve throughput, it is now essential This paper presents PipesFS, an I/O architecture for Linux to avoid all unnecessary memory operations. Inefficient I/O 2.6 that increases I/O throughput and adds support for het- primitives exacerbate the effects of the memory wall by in- erogeneous parallel processors by (1) collapsing many I/O curring unnecessary copying and context switching, and as interfaces onto one: the Unix pipeline, (2) increasing pipe a result of these cache misses. efficiency and (3) exploiting pipeline modularity to spread computation across all available processors. Contribution. We revisit the Unix pipeline as a generic model for streaming I/O, but modify it to reduce overhead, PipesFS extends the pipeline model to kernel I/O and com- extend it to integrate kernel processing and complement it municates with applications through a Linux virtual filesys- with support for anycore execution. We link kernel and tem (VFS), where directory nodes represent operations and userspace processing through a virtual filesystem, PipesFS, pipe nodes export live kernel data. Users can thus interact that presents kernel operations as directories and live data as with kernel I/O through existing calls like mkdir, tools like pipes. This solution avoids new interfaces and so unlocks all grep, most languages and even shell scripts.
    [Show full text]
  • Making a Faster Curry with Extensional Types
    Making a Faster Curry with Extensional Types Paul Downen Simon Peyton Jones Zachary Sullivan Microsoft Research Zena M. Ariola Cambridge, UK University of Oregon [email protected] Eugene, Oregon, USA [email protected] [email protected] [email protected] Abstract 1 Introduction Curried functions apparently take one argument at a time, Consider these two function definitions: which is slow. So optimizing compilers for higher-order lan- guages invariably have some mechanism for working around f1 = λx: let z = h x x in λy:e y z currying by passing several arguments at once, as many as f = λx:λy: let z = h x x in e y z the function can handle, which is known as its arity. But 2 such mechanisms are often ad-hoc, and do not work at all in higher-order functions. We show how extensional, call- It is highly desirable for an optimizing compiler to η ex- by-name functions have the correct behavior for directly pand f1 into f2. The function f1 takes only a single argu- expressing the arity of curried functions. And these exten- ment before returning a heap-allocated function closure; sional functions can stand side-by-side with functions native then that closure must subsequently be called by passing the to practical programming languages, which do not use call- second argument. In contrast, f2 can take both arguments by-name evaluation. Integrating call-by-name with other at once, without constructing an intermediate closure, and evaluation strategies in the same intermediate language ex- this can make a huge difference to run-time performance in presses the arity of a function in its type and gives a princi- practice [Marlow and Peyton Jones 2004].
    [Show full text]
  • Pipecheck: 3D Scanning Solution Pipeline Integrity Assessment
    NDT SOLUTIONS 3D3D SCANNING SCANNING SOLUTION SOLUTION FORFOR PIPELINE PIPELINE INTEGRITY INTEGRITY ASSESSMENTASSESSMENT CODE-COMPLIANT CODE-COMPLIANT Pipeline operators and NDT service companies are facing an increasing pressure from regulation authorities and environmentalist groups to guarantee pipeline networks integrity, while wanting to keep maintenance costs as low as possible. Field crews are experiencing pressure to complete inspection as quickly as possible so the excavation site can be backfilled, and the pipeline, put back into service in the shortest time. Thus, the use of surface inspection tools that are reliable, efficient and user-friendly is of paramount importance. Creaform has developed the PipecheckTM solution for pipeline integrity assessment. The solution includes a HandySCAN 3DTM portable handheld scanner and the Pipecheck software. Thanks to this unique 3D scanning technology and innovative software, surface inspection has been reinvented completely! RELIABLE. EFFICIENT. EASY. INTRODUCING PIPECHECK. PIPECHECK SOFTWARE MODULES CORROSION MECHANICAL DAMAGE Pipecheck’s pipeline corrosion software module offers very fast and As its name states, this software module has been developed reliable data processing that generates instant, on-site results. specifically for pipeline mechanical damage analysis. This module In comparison with traditional measurement methods, this software features numerous key functionalities that increase dent understanding offers accuracy and repeatability that are beyond expectations. and facilitate the decision making process. ADVANCED FUNCTIONALITIES CORROSION IN ILI CORRELATION MECHANICAL DAMAGE STRAIGHTENING OPERATION TOOL Being able to separate material loss depth Traditional methods for depth measurement The ILI Correlation tool is used to correlate from a mechanical damage deformation is (pit gauge) on field bends can’t be used in-line inspection data with the Pipecheck 3D no longer a dream.
    [Show full text]
  • Characteristics of Workloads Using the Pipeline Programming Model
    Characteristics of Workloads Using the Pipeline Programming Model Christian Bienia and Kai Li Department of Computer Science, Princeton University {cbienia, li}@cs.princeton.edu Abstract covered by their applications. Second, we demonstrate that Pipeline parallel programming is a frequently used model to the programs using the pipeline model have different char- program applications on multiprocessors. Despite its popu- acteristics compared to other workloads. The differences larity, there is a lack of studies of the characteristics of such are significant and systematic in nature, which justifies the workloads. This paper gives an overview of the pipeline existence of pipelined programs in the PARSEC benchmark model and its typical implementations for multiprocessors. suite [2]. This suggests that pipelined workloads should be We present implementation choices and analyze their im- considered for the inclusion in future benchmark programs pact on the program. We furthermore show that workloads for computer architecture studies. that use the pipeline model have their own unique charac- The remainder of the paper is structured as follows: teristics that should be considered when selecting a set of Section 2 presents a survey of the pipeline parallelization benchmarks. Such information can be beneficial for pro- model. In Section 3 we discuss how we studied the impact gram developers as well as for computer architects who of the pipeline model on the workload characteristics, and want to understand the behavior of applications. we present our experimental results in Section 4. Related work is discussed in Section 5 before we conclude in Sec- 1 Introduction tion 6. Modern parallel workloads are becoming increasingly di- verse and use a wide range of techniques and methods to 2 Pipeline Programming Model take advantage of multiprocessors.
    [Show full text]
  • Elastic Pipeline Design of High Performance Micro-Controller YL8MCU for Signal Processing of Digital Home Appliances
    Send Orders for Reprints to [email protected] The Open Automation and Control Systems Journal, 2015, 7, 863-872 863 Open Access Elastic Pipeline Design of High Performance Micro-Controller YL8MCU for Signal Processing of Digital Home Appliances Fulong Chen1,*, Yunxiang Sun2, Chuanxin Zhao2, Jie Yang2, Heping Ye2, Junru Zhu2, and Qimei Tang2 1Department of Computer Science & Technology, Anhui Normal University, Wuhu, Anhui 241002, China 2Network and Information Security Engineering Research Center, Anhui Normal University, Wuhu, Anhui 241002, China Abstract-With the growing complexity of the structure and function of the digital home appliance controllers, the higher requirements on the design of integrated circuits are expected. In view of the lower efficiency of the traditional large scale integrated circuit design, such as long design cycle, high investment and bad flexibility, therefore, the traditional design method is unable to meet the rapid product development. A design and its implementation scheme based on System-on- Programmable-Chip (SoPC) technologies with the Intellectual Property (IP) core parametric technology and elastic design method are proposed for the Micro-controller Unit (MCU) YL8MCU applied in digital home appliances. It makes used of Reduced Instruction Set Computer (RISC) framework and 5-stage pipeline technology for designing the instruction sys- tem and hardware structure so as to improve the speed of processing data and instructions. Finally the correctness and fea- sibility of its function is verified with the integrated verification, the IP function module verification based on coverage and the simulation test of the controlling flow for the washer. The results show that YL8MCU meets the requirements of digital home appliances and supports system integration on chip.
    [Show full text]
  • Interleaving Data and Effects"
    Archived version from NCDOCKS Institutional Repository http://libres.uncg.edu/ir/asu/ Interleaving data and effects By: Robert Atkey and Patricia Johann Abstract: The study of programming with and reasoning about inductive datatypes such as lists and trees has benefited from the simple categorical principle of initial algebras. In initial algebra semantics, each inductive datatype is represented by an initial f-algebra for an appropriate functor f. The initial algebra principle then supports the straightforward derivation of definitional principles and proof principles for these datatypes. This technique has been expanded to a whole methodology of structured functional programming, often called origami programming.In this article we show how to extend initial algebra semantics from pure inductive datatypes to inductive datatypes interleaved with computational effects. Inductive datatypes interleaved with effects arise naturally in many computational settings. For example, incrementally reading characters from a file generates a list of characters interleaved with input/output actions, and lazily constructed infinite values can be represented by pure data interleaved with the possibility of non-terminating computation. Straightforward application of initial algebra techniques to effectful datatypes leads either to unsound conclusions if we ignore the possibility of effects, or to unnecessarily complicated reasoning because the pure and effectful concerns must be considered simultaneously. We show how pure and effectful concerns can be separated using the abstraction of initial f-and-m-algebras, where the functor f describes the pure part of a datatype and the monad m describes the interleaved effects. Because initial f-and-m-algebras are the analogue for the effectful setting of initial f- algebras, they support the extension of the standard definitional and proof principles to the effectful setting.
    [Show full text]
  • Pipelines Guide and Reference
    Pipelines Guide and Reference Ed Tomlinson Jeff Hennick René Jansen Version 4.01-GA of March 20, 2021 THE REXX LANGUAGE ASSOCIATION NetRexx Programming Series ISBN 978-90-819090-3-7 Publication Data ©Copyright The Rexx Language Association, 2011- 2021 All original material in this publication is published under the Creative Commons - Share Alike 3.0 License as stated at http://creativecommons.org/licenses/by-nc-sa/3.0/us/legalcode. The responsible publisher of this edition is identified as IBizz IT Services and Consultancy, Amsteldijk 14, 1074 HR Amsterdam, a registered company governed by the laws of the Kingdom of The Netherlands. This edition is registered under ISBN 978-90-819090-3-7 ISBN 978-90-819090-3-7 9 789081 909037 I Contents The NetR Programming Series i 1 Introduction 1 2 The Pipeline Concept 2 2.1 What is a Pipeline? 2 2.2 Stage 2 2.3 Device Driver 3 3 Running pipelines 4 3.1 Configuration 4 3.2 From the NetREXX Workspace (nrws) with direct execution 5 3.3 From the command line with direct execution 6 3.4 Precompiled Pipelines 6 3.5 Compiled from an .njp file 7 3.6 Compiled from an .njp file with additional stage definitions in NetREXX 7 4 Example Session 8 5 Write your own Filters 12 6 More advanced Pipelines 14 7 Device Drivers 15 8 Record Selection 17 9 Filters 18 10 Other Stages 19 11 Multi-Stream Pipelines 20 12 Pipeline Stalls 22 13 How to use a pipe in a NetR program 24 II 14 Giving commands to the operating system 27 14.1 Built-ins 27 15 TCP/IP Networking 28 16 Selecting from relational databases 30 17 The Pipes Runner 31 18 The Pipes Compiler 32 19 Built-in Stages 33 20 Differences with CMS Pipelines 34 Index 83 III The NetR Programming Series This book is part of a library, the NetR Programming Series, documenting the NetREXX programming language and its use and applications.
    [Show full text]
  • Exploring Languages with Interpreters and Functional Programming Chapter 16
    Exploring Languages with Interpreters and Functional Programming Chapter 16 H. Conrad Cunningham 15 October 2018 Contents 16 Haskell Function Concepts 2 16.1 Chapter Introduction . .2 16.2 Strictness . .2 16.3 Currying and Partial Application . .3 16.4 Operator Sections . .4 16.5 Combinators . .5 16.6 Functional Composition . .7 16.7 Function Pipelines . .7 16.8 Lambda Expressions . .9 16.9 Application Operator $ ....................... 10 16.10Eager Evaluation Using seq and $! ................. 11 16.11What Next? . 12 16.12Exercises . 13 16.13Acknowledgements . 13 16.14References . 14 16.15Terms and Concepts . 14 Copyright (C) 2016, 2017, 2018, H. Conrad Cunningham Professor of Computer and Information Science University of Mississippi 211 Weir Hall P.O. Box 1848 University, MS 38677 (662) 915-5358 Browser Advisory: The HTML version of this textbook requires a browser that supports the display of MathML. A good choice as of October 2018 is a recent version of Firefox from Mozilla. 1 16 Haskell Function Concepts 16.1 Chapter Introduction The previous chapter introduced the concepts of first-class and higher-order functions and generalized common computational patterns to construct a library of useful higher-order functions to process lists. This chapter continues to examine those concepts and their implications for Haskell programming. It explores strictness, currying, partial application, com- binators, operator sections, functional composition, inline function definitions, evaluation strategies, and related methods. The Haskell module for this chapter is in FunctionConcepts.hs. 16.2 Strictness In the discussion of the fold functions, the previous chapter introduced the concept of strictness. In this section, we explore that in more depth.
    [Show full text]