Backtracking Iterators
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Lecture 4 Dynamic Programming
1/17 Lecture 4 Dynamic Programming Last update: Jan 19, 2021 References: Algorithms, Jeff Erickson, Chapter 3. Algorithms, Gopal Pandurangan, Chapter 6. Dynamic Programming 2/17 Backtracking is incredible powerful in solving all kinds of hard prob- lems, but it can often be very slow; usually exponential. Example: Fibonacci numbers is defined as recurrence: 0 if n = 0 Fn =8 1 if n = 1 > Fn 1 + Fn 2 otherwise < ¡ ¡ > A direct translation in:to recursive program to compute Fibonacci number is RecFib(n): if n=0 return 0 if n=1 return 1 return RecFib(n-1) + RecFib(n-2) Fibonacci Number 3/17 The recursive program has horrible time complexity. How bad? Let's try to compute. Denote T(n) as the time complexity of computing RecFib(n). Based on the recursion, we have the recurrence: T(n) = T(n 1) + T(n 2) + 1; T(0) = T(1) = 1 ¡ ¡ Solving this recurrence, we get p5 + 1 T(n) = O(n); = 1.618 2 So the RecFib(n) program runs at exponential time complexity. RecFib Recursion Tree 4/17 Intuitively, why RecFib() runs exponentially slow. Problem: redun- dant computation! How about memorize the intermediate computa- tion result to avoid recomputation? Fib: Memoization 5/17 To optimize the performance of RecFib, we can memorize the inter- mediate Fn into some kind of cache, and look it up when we need it again. MemFib(n): if n = 0 n = 1 retujrjn n if F[n] is undefined F[n] MemFib(n-1)+MemFib(n-2) retur n F[n] How much does it improve upon RecFib()? Assuming accessing F[n] takes constant time, then at most n additions will be performed (we never recompute). -
Graph Traversals
Graph Traversals CS200 - Graphs 1 Tree traversal reminder Pre order A A B D G H C E F I In order B C G D H B A E C F I Post order D E F G H D B E I F C A Level order G H I A B C D E F G H I Connected Components n The connected component of a node s is the largest set of nodes reachable from s. A generic algorithm for creating connected component(s): R = {s} while ∃edge(u, v) : u ∈ R∧v ∉ R add v to R n Upon termination, R is the connected component containing s. q Breadth First Search (BFS): explore in order of distance from s. q Depth First Search (DFS): explores edges from the most recently discovered node; backtracks when reaching a dead- end. 3 Graph Traversals – Depth First Search n Depth First Search starting at u DFS(u): mark u as visited and add u to R for each edge (u,v) : if v is not marked visited : DFS(v) CS200 - Graphs 4 Depth First Search A B C D E F G H I J K L M N O P CS200 - Graphs 5 Question n What determines the order in which DFS visits nodes? n The order in which a node picks its outgoing edges CS200 - Graphs 6 DepthGraph Traversalfirst search algorithm Depth First Search (DFS) dfs(in v:Vertex) mark v as visited for (each unvisited vertex u adjacent to v) dfs(u) n Need to track visited nodes n Order of visiting nodes is not completely specified q if nodes have priority, then the order may become deterministic for (each unvisited vertex u adjacent to v in priority order) n DFS applies to both directed and undirected graphs n Which graph implementation is suitable? CS200 - Graphs 7 Iterative DFS: explicit Stack dfs(in v:Vertex) s – stack for keeping track of active vertices s.push(v) mark v as visited while (!s.isEmpty()) { if (no unvisited vertices adjacent to the vertex on top of the stack) { s.pop() //backtrack else { select unvisited vertex u adjacent to vertex on top of the stack s.push(u) mark u as visited } } CS200 - Graphs 8 Breadth First Search (BFS) n Is like level order in trees A B C D n Which is a BFS traversal starting E F G H from A? A. -
Scala−−, a Type Inferred Language Project Report
Scala−−, a type inferred language Project Report Da Liu [email protected] Contents 1 Background 2 2 Introduction 2 3 Type Inference 2 4 Language Prototype Features 3 5 Project Design 4 6 Implementation 4 6.1 Benchmarkingresults . 4 7 Discussion 9 7.1 About scalac ....................... 9 8 Lessons learned 10 9 Language Specifications 10 9.1 Introdution ......................... 10 9.2 Lexicalsyntax........................ 10 9.2.1 Identifiers ...................... 10 9.2.2 Keywords ...................... 10 9.2.3 Literals ....................... 11 9.2.4 Punctions ...................... 12 9.2.5 Commentsandwhitespace. 12 9.2.6 Operations ..................... 12 9.3 Syntax............................ 12 9.3.1 Programstructure . 12 9.3.2 Expressions ..................... 14 9.3.3 Statements ..................... 14 9.3.4 Blocksandcontrolflow . 14 9.4 Scopingrules ........................ 16 9.5 Standardlibraryandcollections. 16 9.5.1 println,mapandfilter . 16 9.5.2 Array ........................ 16 9.5.3 List ......................... 17 9.6 Codeexample........................ 17 9.6.1 HelloWorld..................... 17 9.6.2 QuickSort...................... 17 1 of 34 10 Reference 18 10.1Typeinference ....................... 18 10.2 Scalaprogramminglanguage . 18 10.3 Scala programming language development . 18 10.4 CompileScalatoLLVM . 18 10.5Benchmarking. .. .. .. .. .. .. .. .. .. .. 18 11 Source code listing 19 1 Background Scala is becoming drawing attentions in daily production among var- ious industries. Being as a general purpose programming language, it is influenced by many ancestors including, Erlang, Haskell, Java, Lisp, OCaml, Scheme, and Smalltalk. Scala has many attractive features, such as cross-platform taking advantage of JVM; as well as with higher level abstraction agnostic to the developer providing immutability with persistent data structures, pattern matching, type inference, higher or- der functions, lazy evaluation and many other functional programming features. -
Exhaustive Recursion and Backtracking
CS106B Handout #19 J Zelenski Feb 1, 2008 Exhaustive recursion and backtracking In some recursive functions, such as binary search or reversing a file, each recursive call makes just one recursive call. The "tree" of calls forms a linear line from the initial call down to the base case. In such cases, the performance of the overall algorithm is dependent on how deep the function stack gets, which is determined by how quickly we progress to the base case. For reverse file, the stack depth is equal to the size of the input file, since we move one closer to the empty file base case at each level. For binary search, it more quickly bottoms out by dividing the remaining input in half at each level of the recursion. Both of these can be done relatively efficiently. Now consider a recursive function such as subsets or permutation that makes not just one recursive call, but several. The tree of function calls has multiple branches at each level, which in turn have further branches, and so on down to the base case. Because of the multiplicative factors being carried down the tree, the number of calls can grow dramatically as the recursion goes deeper. Thus, these exhaustive recursion algorithms have the potential to be very expensive. Often the different recursive calls made at each level represent a decision point, where we have choices such as what letter to choose next or what turn to make when reading a map. Might there be situations where we can save some time by focusing on the most promising options, without committing to exploring them all? In some contexts, we have no choice but to exhaustively examine all possibilities, such as when trying to find some globally optimal result, But what if we are interested in finding any solution, whichever one that works out first? At each decision point, we can choose one of the available options, and sally forth, hoping it works out. -
The Scala Experience Safe Programming Can Be Fun!
The Scala Programming Language Mooly Sagiv Slides taken from Martin Odersky (EPFL) Donna Malayeri (CMU) Hila Peleg (Technion) Modern Functional Programming • Higher order • Modules • Pattern matching • Statically typed with type inference • Two viable alternatives • Haskel • Pure lazy evaluation and higher order programming leads to Concise programming • Support for domain specific languages • I/O Monads • Type classes • ML/Ocaml/F# • Eager call by value evaluation • Encapsulated side-effects via references • [Object orientation] Then Why aren’t FP adapted? • Education • Lack of OO support • Subtyping increases the complexity of type inference • Programmers seeks control on the exact implementation • Imperative programming is natural in certain situations Why Scala? (Coming from OCaml) • Runs on the JVM/.NET • Can use any Java code in Scala • Combines functional and imperative programming in a smooth way • Effective libraries • Inheritance • General modularity mechanisms The Java Programming Language • Designed by Sun 1991-95 • Statically typed and type safe • Clean and Powerful libraries • Clean references and arrays • Object Oriented with single inheritance • Interfaces with multiple inheritance • Portable with JVM • Effective JIT compilers • Support for concurrency • Useful for Internet Java Critique • Downcasting reduces the effectiveness of static type checking • Many of the interesting errors caught at runtime • Still better than C, C++ • Huge code blowouts • Hard to define domain specific knowledge • A lot of boilerplate code • -
1 Ocaml for the Masses
PROGRAMMING LANGUAGES OCaml for the Masses Why the next language you learn should be functional Yaron Minsky, Jane Street Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function. - John Carmack Functional programming is an old idea with a distinguished history. Lisp, a functional language inspired by Alonzo Church’s lambda calculus, was one of the first programming languages developed at the dawn of the computing age. Statically typed functional languages such as OCaml and Haskell are newer, but their roots go deep—ML, from which they descend, dates back to work by Robin Milner in the early ’70s relating to the pioneering LCF (Logic for Computable Functions) theorem prover. Functional programming has also been enormously influential. Many fundamental advances in programming language design, from garbage collection to generics to type inference, came out of the functional world and were commonplace there decades before they made it to other languages. Yet functional languages never really made it to the mainstream. They came closest, perhaps, in the days of Symbolics and the Lisp machines, but those days seem quite remote now. Despite a resurgence of functional programming in the past few years, it remains a technology more talked about than used. It is tempting to conclude from this record that functional languages don’t have what it takes. They may make sense for certain limited applications, and contain useful concepts to be imported into other languages; but imperative and object-oriented languages are simply better suited to the vast majority of software engineering tasks. -
Backtrack Parsing Context-Free Grammar Context-Free Grammar
Context-free Grammar Problems with Regular Context-free Grammar Language and Is English a regular language? Bad question! We do not even know what English is! Two eggs and bacon make(s) a big breakfast Backtrack Parsing Can you slide me the salt? He didn't ought to do that But—No! Martin Kay I put the wine you brought in the fridge I put the wine you brought for Sandy in the fridge Should we bring the wine you put in the fridge out Stanford University now? and University of the Saarland You said you thought nobody had the right to claim that they were above the law Martin Kay Context-free Grammar 1 Martin Kay Context-free Grammar 2 Problems with Regular Problems with Regular Language Language You said you thought nobody had the right to claim [You said you thought [nobody had the right [to claim that they were above the law that [they were above the law]]]] Martin Kay Context-free Grammar 3 Martin Kay Context-free Grammar 4 Problems with Regular Context-free Grammar Language Nonterminal symbols ~ grammatical categories Is English mophology a regular language? Bad question! We do not even know what English Terminal Symbols ~ words morphology is! They sell collectables of all sorts Productions ~ (unordered) (rewriting) rules This concerns unredecontaminatability Distinguished Symbol This really is an untiable knot. But—Probably! (Not sure about Swahili, though) Not all that important • Terminals and nonterminals are disjoint • Distinguished symbol Martin Kay Context-free Grammar 5 Martin Kay Context-free Grammar 6 Context-free Grammar Context-free -
Lecture12: Trees II Tree Traversal Preorder Traversal Preorder Traversal
Tree Traversal • Process of visiting nodes in a tree systematically CSED233: Data Structures (2013F) . Some algorithms need to visit all nodes in a tree. Example: printing, counting nodes, etc. Lecture12: Trees II • Implementation . Can be done easily by recursion Computers”R”Us . Order of visits does matter. Bohyung Han Sales Manufacturing R&D CSE, POSTECH [email protected] US International Laptops Desktops Europe Asia Canada CSED233: Data Structures 2 by Prof. Bohyung Han, Fall 2013 Preorder Traversal Preorder Traversal • A preorder traversal of the subtree rooted at node n: . Visit node n (process the node's data). 1 . Recursively perform a preorder traversal of the left child. Recursively perform a preorder traversal of the right child. 2 7 • A preorder traversal starts at the root. public void preOrderTraversal(Node n) 3 6 8 12 { if (n == null) return; 4 5 9 System.out.print(n.value+" "); preOrderTraversal(n.left); preOrderTraversal(n.right); 10 11 } CSED233: Data Structures CSED233: Data Structures 3 by Prof. Bohyung Han, Fall 2013 4 by Prof. Bohyung Han, Fall 2013 Inorder Traversal Inorder Traversal • A preorder traversal of the subtree rooted at node n: . Recursively perform a preorder traversal of the left child. 6 . Visit node n (process the node's data). Recursively perform a preorder traversal of the right child. 4 11 • An iorder traversal starts at the root. public void inOrderTraversal(Node n) 2 5 7 12 { if (n == null) return; 1 3 9 inOrderTraversal(n.left); System.out.print(n.value+" "); inOrderTraversal(n.right); } 8 10 CSED233: Data Structures CSED233: Data Structures 5 by Prof. -
An Overview of the Scala Programming Language
An Overview of the Scala Programming Language Second Edition Martin Odersky, Philippe Altherr, Vincent Cremet, Iulian Dragos Gilles Dubochet, Burak Emir, Sean McDirmid, Stéphane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Lex Spoon, Matthias Zenger École Polytechnique Fédérale de Lausanne (EPFL) 1015 Lausanne, Switzerland Technical Report LAMP-REPORT-2006-001 Abstract guage for component software needs to be scalable in the sense that the same concepts can describe small as well as Scala fuses object-oriented and functional programming in large parts. Therefore, we concentrate on mechanisms for a statically typed programming language. It is aimed at the abstraction, composition, and decomposition rather than construction of components and component systems. This adding a large set of primitives which might be useful for paper gives an overview of the Scala language for readers components at some level of scale, but not at other lev- who are familar with programming methods and program- els. Second, we postulate that scalable support for compo- ming language design. nents can be provided by a programming language which unies and generalizes object-oriented and functional pro- gramming. For statically typed languages, of which Scala 1 Introduction is an instance, these two paradigms were up to now largely separate. True component systems have been an elusive goal of the To validate our hypotheses, Scala needs to be applied software industry. Ideally, software should be assembled in the design of components and component systems. Only from libraries of pre-written components, just as hardware is serious application by a user community can tell whether the assembled from pre-fabricated chips. -
Backtracking / Branch-And-Bound
Backtracking / Branch-and-Bound Optimisation problems are problems that have several valid solutions; the challenge is to find an optimal solution. How optimal is defined, depends on the particular problem. Examples of optimisation problems are: Traveling Salesman Problem (TSP). We are given a set of n cities, with the distances between all cities. A traveling salesman, who is currently staying in one of the cities, wants to visit all other cities and then return to his starting point, and he is wondering how to do this. Any tour of all cities would be a valid solution to his problem, but our traveling salesman does not want to waste time: he wants to find a tour that visits all cities and has the smallest possible length of all such tours. So in this case, optimal means: having the smallest possible length. 1-Dimensional Clustering. We are given a sorted list x1; : : : ; xn of n numbers, and an integer k between 1 and n. The problem is to divide the numbers into k subsets of consecutive numbers (clusters) in the best possible way. A valid solution is now a division into k clusters, and an optimal solution is one that has the nicest clusters. We will define this problem more precisely later. Set Partition. We are given a set V of n objects, each having a certain cost, and we want to divide these objects among two people in the fairest possible way. In other words, we are looking for a subdivision of V into two subsets V1 and V2 such that X X cost(v) − cost(v) v2V1 v2V2 is as small as possible. -
How to Run Your Favorite Language on Web Browsers
Benjamin Canou, Emmanuel Chailloux and Jérôme Vouillon Laboratoire d'Informatique de Paris 6 (LIP6) Laboratoire Preuves Programmes et Systèmes (PPS) How to Run your Favorite. Language on Browsers The Revenge of Virtual Machines WWW 2012, Lyon, France Introduction. Introduction . 3/20 What ? I You have a favorite language I You have just designed or extended one I You want to run it on a Web browser Why ? I To program a new Web app I To program your client with the same language than your server I To run an online demo of an existing app Introduction . 4/20 How ? I Use applets I Write an interpreter in JavaScript I Write a compiler to JavaScript Or as we present in this talk: I Reuse the language bytecode compiler I Write a bytecode interpreter in JavaScript I Write a bytecode to JavaScript expander Introduction . 5/20 An experiment report: I Project Ocsigen: use OCaml to code entire Web apps I OBrowser: an OCaml bytecode interpreter I js_of_ocaml: an OCaml bytecode expander Retrospectively, a good approach: I Reasonable time to obtain a first platform I Good performance achievable I Fidelity to language/concurrency models Core techniques. Bytecode interpretation (1/3). 7/20 Main method: 1. Make the bytecode file network compliant (ex. JSON array) 2. Choose/implement the representation of values 3. Write a minimal runtime and standard library 4. Write the main interpretation loop 5. Run tests and extend the library as needed Possible improvements: I Use core, well supported/optimized JavaScript control structures I Use simple, array based memory representation I Preliminary bytecode cleanup pass Bytecode interpretation (2/3). -
Efficient Stackless Hierarchy Traversal on Gpus with Backtracking in Constant Time
High Performance Graphics (2016) Ulf Assarsson and Warren Hunt (Editors) Efficient Stackless Hierarchy Traversal on GPUs with Backtracking in Constant Time Nikolaus Binder† and Alexander Keller‡ NVIDIA Corporation 1 1 1 2 3 2 3 2 3 4 5 6 7 4 5 6 7 4 5 6 7 10 11 10 11 10 11 22 23 22 23 22 23 a) b) c) 44 45 44 45 44 45 Figure 1: Backtracking from the current node with key 22 to the next node with key 3, which has been postponed most recently, by a) iterating along parent and sibling references, b) using references to uncle and grand uncle, c) using a stack, or as we propose, a perfect hash directly mapping the key for the next node to its address without using a stack. The heat maps visualize the reduction in the number of backtracking steps. Abstract The fastest acceleration schemes for ray tracing rely on traversing a bounding volume hierarchy (BVH) for efficient culling and use backtracking, which in the worst case may expose cost proportional to the depth of the hierarchy in either time or state memory. We show that the next node in such a traversal actually can be determined in constant time and state memory. In fact, our newly proposed parallel software implementation requires only a few modifications of existing traversal methods and outperforms the fastest stack-based algorithms on GPUs. In addition, it reduces memory access during traversal, making it a very attractive building block for ray tracing hardware. Categories and Subject Descriptors (according to ACM CCS): I.3.3 [Computer Graphics]: Picture/Image Generation—Ray Trac- ing 1.