DOCSLIB.ORG

A Bit of Prolog Course Wrap-Up

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Bit of Prolog Course Wrap-Up A Bit of Prolog Course Wrap-Up CS F331 Programming Languages CSCE A331 Programming Language Concepts Lecture Slides Monday, April 27, 2020 Glenn G. Chappell Department of Computer Science University of Alaska Fairbanks [email protected] © 2017–2020 Glenn G. Chappell Review 2020-04-27 CS F331 / CSCE A331 Spring 2020 2 Review Introduction to Scheme Scheme is a Lisp-family PL with a minimalist design philosophy. Scheme code consists of parenthesized lists, which may contain atoms or other lists. List items are separated by space; blanks and newlines between list items are treated the same. (define (hello-world) (begin (display "Hello, world!") (newline) ) ) When a list is evaluated, the first item should be a procedure (think “function”); the remaining items are its arguments. 2020-04-27 CS F331 / CSCE A331 Spring 2020 3 Review Scheme: Macros [1/5] We have noted that Scheme (and other Lisp-family PLs) offer excellent support for reflection: the ability of a program to examine and modify its own code. The most common way that reflection is done in Scheme is through the use of a macro: a procedure-like entity that takes its arguments unevaluated. Because the arguments of a macro are not evaluated before the macro sees them, the macro has access not only to their values, but also to their structure (AST). It can do anything it wants with that structure, transforming the code in arbitrary ways. After the macro has transformed the code, the resulting code is evaluated. (A macro may return the transformed code unevaluated, by quoting it.) 2020-04-27 CS F331 / CSCE A331 Spring 2020 4 Review Scheme: Macros [2/5] One kind of Scheme macro is the pattern-based macro. We give a pattern that code can match. Any matching code is transformed in a manner that we specify. The resulting code is evaluated. (Again, to avoid this last step, we can quote the transformed code). Define a single-pattern macro using define-syntax-rule. (define-syntax-rule (PATTERN) TEMPLATE) Here is our own version of quote: myquote. (define-syntax-rule (myquote x) 'x ) 2020-04-27 CS F331 / CSCE A331 Spring 2020 5 Review Scheme: Macros [3/5] define-syntax-rule accepts the dot syntax, just like define. Here is a quoting macro that goes inside the list it quotes. qlist is like list, except that it does not evaluate its arguments. (define-syntax-rule (qlist . args) 'args ) Try it. > (qlist (+ 1 3) (* 3 8)) ; Arguments NOT evaluated ((+ 1 3) (* 3 8)) > (list (+ 1 3) (* 3 8)) ; Arguments evaluated (4 24) 2020-04-27 CS F331 / CSCE A331 Spring 2020 6 Review Scheme: Macros [4/5] A more general way to define macros uses define-syntax. This allows for multiple patterns. The first matching pattern is used. (define-syntax IDENTIFIER (syntax-rules () [(PATTERN1) TEMPLATE1] … [(PATTERNn) TEMPLATEn] ) ) 2020-04-27 CS F331 / CSCE A331 Spring 2020 7 Review Scheme: Macros [5/5] (define-syntax IDENTIFIER (syntax-rules (KEYWORD1 … KEYWORDm) [(PATTERN1) TEMPLATE1] … [(PATTERNn) TEMPLATEn] ) ) The mysterious list after syntax-rules is the list of keywords. A keyword in a pattern matches only that exact word. For example, the “else” facility in the cond construction might be implemented as a keyword. 2020-04-27 CS F331 / CSCE A331 Spring 2020 8 A Bit of Prolog 2020-04-27 CS F331 / CSCE A331 Spring 2020 9 A Bit of Prolog Logic Programming Languages [1/3] In the late 1960s, Stanford researcher Cordell Green proposed representing a computer program in terms of logical statements. The result was a programming paradigm that became known as logic programming. In logic programming, a computer program can be thought of as a knowledge base. It typically contains two kinds of knowledge. § Facts. Statements that are known to be true. § Rules. Ways to find other true statements from those known. Execution is then driven by a query: essentially a question. The computer attempts to answer the question using facts and rules. 2020-04-27 CS F331 / CSCE A331 Spring 2020 10 A Bit of Prolog Logic Programming Languages [2/3] In a typical logic programming language: § A program consists of facts and rules. § Execution begins with a query, which establishes a goal. During execution, various subgoals may be established. § Execution is primarily interactive, based on a source file. § Execution is about finding what can be proven—not what is true. § So negation says something fails to be provable, not that it is false. § Unification* is the primary proof tool. § Typing is dynamic and implicit. *See the next slide. 2020-04-27 CS F331 / CSCE A331 Spring 2020 11 A Bit of Prolog Logic Programming Languages [3/3] Execution in logic PLs is typically based on unification. To unify two constructions means to make them the same by setting values of variables as necessary. Can we unify X and 42? Yes. Set X to 42. Unification, in full generality, includes assignment and expression evaluation as special cases. But unification can also do things that assignment/evaluation cannot do. Can we unify [A, 6] and [4, B]? Yes. Set A to 4, B to 6. Can we unify [A, 6] and [B, 7]? No. 2020-04-27 CS F331 / CSCE A331 Spring 2020 12 A Bit of Prolog History In the early 1970s, a group at the U. of Aix-Marseille (France) began an effort to produce a logic programming language. The group was led by Alain Colmeraur, and Cordell Green’s ideas were their starting point. The PL was called Prolog, short for “PROgrammation en LOGique” (French for “programming in logic”). The first version of Prolog was released in 1972. Prolog was, and continues to be, the most important logic PL. Prolog execution is driven by a query, which establishes a goal. The primary execution strategy involves unification. Prolog attempts to unify using backtracking search. 2020-04-27 CS F331 / CSCE A331 Spring 2020 13 A Bit of Prolog Code Prolog programs consist of facts and rules. Here is a Prolog fact. is_child(glenn, gilford). If something can be unified with a fact, then it is considered to be proven. Here are two Prolog rules. is_parent(A, B) :- is_child(B, A). is_grandparent(A, B): is_parent(A, X), is_parent(X, B). In order to be unified with the head of a rule (part before “:-”), the various parts in the tail (the rest) must be proven. 2020-04-27 CS F331 / CSCE A331 Spring 2020 14 Course Wrap-Up 2020-04-27 CS F331 / CSCE A331 Spring 2020 15 Course Wrap-Up From the First Day of Class: Course Overview — Description In this class, we study programming languages with a view toward the following. § How programming languages are specified, and how these specifications are used. § What different kinds of programming languages are like. § How certain features differ between various programming languages. 2020-04-27 CS F331 / CSCE A331 Spring 2020 16 Course Wrap-Up From the First Day of Class: Course Overview — Goals After taking this class, you should: § Understand the concepts of syntax and semantics, and how syntax can be specified. § Understand, and have experience implementing, basic lexical analysis, parsing, and interpretation. § Understand the various kinds of programming languages and the primary ways in which they differ. § Understand standard programming language features and the forms these take in different programming languages. § Be familiar with the impact (local, global, etc.) that choice of programming language has on programmers and users. § Have a basic programming proficiency in multiple significantly different programming languages. 2020-04-27 CS F331 / CSCE A331 Spring 2020 17 Course Wrap-Up From the First Day of Class: Course Overview — Topics The following topics will be covered: § Formal Languages & Grammars. § PL Feature. Execution I: compilers, interpreters. § PL #1. Lua. Red: Track 1 — Syntax & semantics § Lexing & Parsing. of programming languages § PL Feature. Type Systems. Blue: Track 2 — Programming- § PL #2. Haskell. language features & categories, and specific programming languages § PL Feature. Values & variables. § PL #3. Forth. § Semantics & Interpretation. We are § PL Feature. Reflection. here. § PL #4. Scheme. § PL Feature. Execution II: execution models, flow of control. § PL #5. Prolog. We lost a week of classes, so we did not have time to cover these. 2020-04-27 CS F331 / CSCE A331 Spring 2020 18 Course Wrap-Up Specification [1/2] We covered specifying the syntax of a programming language. Our primary tool was the (phrase structure) grammar, specified in practice using EBNF or something similar. statement → ‘print’ ‘(’ print_arg { ‘,’ print_arg } ‘)’ We also covered informal methods and regular expressions. We took a close look at two classes of formal languages—and the associated grammars that generate them—regular languages and context-free languages. We briefly mentioned formal methods for specifying semantics, but did not actually use any of these. 2020-04-27 CS F331 / CSCE A331 Spring 2020 19 Course Wrap-Up Specification [2/2] Our 2 main classes of languages are in the Chomsky Hierarchy. Language Category Generator Recognizer Number Name Type 3 Regular Grammar in which each production Deterministic Finite has one of the following forms. Automaton • A → ε Think: Program that uses a small, fixed amount of memory. • A → b • A → bC Another kind of generator: regular expressions. Type 2 Context- Grammar in which the left-hand side Nondeterministic Push-Down Free of each production consists of a Automaton single nonterminal. Think: Finite Automaton + Stack • A → [anything] (roughly). Type 1 Context- Don’t worry about it. Don’t worry about it. Sensitive Type 0 Computably Grammar (no restrictions). Turing Machine Enumerable Think: Computer Program 2020-04-27 CS F331 / CSCE A331 Spring 2020 20 Course Wrap-Up Lexing, Parsing, Interpretation We looked at how to write a lexical analyzer (lexer) and a syntax analyzer (parser).
Load more

Recommended publications
  • A New Macro-Programming Paradigm in Data Collection Sensor Networks
    SpaceTime Oriented Programming: A New Macro-Programming Paradigm in Data Collection Sensor Networks Hiroshi Wada and Junichi Suzuki Department of Computer Science University of Massachusetts, Boston Program Insert This paper proposes a new programming paradigm for wireless sensor networks (WSNs). It is designed to significantly reduce the complexity of WSN programming by providing a new high- level programming abstraction to specify spatio-temporal data collections in a WSN from a global viewpoint as a whole rather than sensor nodes as individuals. Abstract SpaceTime Oriented Programming (STOP) is new macro-programming paradigm for wireless sensor networks (WSNs) in that it supports both spatial and temporal aspects of sensor data and it provides a high-level abstraction to express data collections from a global viewpoint for WSNs as a whole rather than sensor nodes as individuals. STOP treats space and time as first-class citizens and combines them as spacetime continuum. A spacetime is a three dimensional object that consists of a two special dimensions and a time playing the role of the third dimension. STOP allows application developers to program data collections to spacetime, and abstracts away the details in WSNs, such as how many nodes are deployed in a WSN, how nodes are connected with each other, and how to route data queries in a WSN. Moreover, STOP provides a uniform means to specify data collections for the past and future. Using the STOP application programming interfaces (APIs), application programs (STOP macro programs) can obtain a “snapshot” space at a given time in a given spatial resolutions (e.g., a space containing data on at least 60% of nodes in a give spacetime at 30 minutes ago.) and a discrete set of spaces that meet specified spatial and temporal resolutions.
    [Show full text]
  • Functional and Logic Programming - Wolfgang Schreiner
    COMPUTER SCIENCE AND ENGINEERING - Functional and Logic Programming - Wolfgang Schreiner FUNCTIONAL AND LOGIC PROGRAMMING Wolfgang Schreiner Research Institute for Symbolic Computation (RISC-Linz), Johannes Kepler University, A-4040 Linz, Austria, [email protected]. Keywords: declarative programming, mathematical functions, Haskell, ML, referential transparency, term reduction, strict evaluation, lazy evaluation, higher-order functions, program skeletons, program transformation, reasoning, polymorphism, functors, generic programming, parallel execution, logic formulas, Horn clauses, automated theorem proving, Prolog, SLD-resolution, unification, AND/OR tree, constraint solving, constraint logic programming, functional logic programming, natural language processing, databases, expert systems, computer algebra. Contents 1. Introduction 2. Functional Programming 2.1 Mathematical Foundations 2.2 Programming Model 2.3 Evaluation Strategies 2.4 Higher Order Functions 2.5 Parallel Execution 2.6 Type Systems 2.7 Implementation Issues 3. Logic Programming 3.1 Logical Foundations 3.2. Programming Model 3.3 Inference Strategy 3.4 Extra-Logical Features 3.5 Parallel Execution 4. Refinement and Convergence 4.1 Constraint Logic Programming 4.2 Functional Logic Programming 5. Impacts on Computer Science Glossary BibliographyUNESCO – EOLSS Summary SAMPLE CHAPTERS Most programming languages are models of the underlying machine, which has the advantage of a rather direct translation of a program statement to a sequence of machine instructions. Some languages, however, are based on models that are derived from mathematical theories, which has the advantages of a more concise description of a program and of a more natural form of reasoning and transformation. In functional languages, this basis is the concept of a mathematical function which maps a given argument values to some result value.
    [Show full text]
  • SQL Processing with SAS® Tip Sheet
    SQL Processing with SAS® Tip Sheet This tip sheet is associated with the SAS® Certified Professional Prep Guide Advanced Programming Using SAS® 9.4. For more information, visit www.sas.com/certify Basic Queries ModifyingBasic Queries Columns PROC SQL <options>; SELECT col-name SELECT column-1 <, ...column-n> LABEL= LABEL=’column label’ FROM input-table <WHERE expression> SELECT col-name <GROUP BY col-name> FORMAT= FORMAT=format. <HAVING expression> <ORDER BY col-name> <DESC> <,...col-name>; Creating a SELECT col-name AS SQL Query Order of Execution: new column new-col-name Filtering Clause Description WHERE CALCULATED new columns new-col-name SELECT Retrieve data from a table FROM Choose and join tables Modifying Rows WHERE Filter the data GROUP BY Aggregate the data INSERT INTO table SET column-name=value HAVING Filter the aggregate data <, ...column-name=value>; ORDER BY Sort the final data Inserting rows INSERT INTO table <(column-list)> into tables VALUES (value<,...value>); INSERT INTO table <(column-list)> Managing Tables SELECT column-1<,...column-n> FROM input-table; CREATE TABLE table-name Eliminating SELECT DISTINCT CREATE TABLE (column-specification-1<, duplicate rows col-name<,...col-name> ...column-specification-n>); WHERE col-name IN DESCRIBE TABLE table-name-1 DESCRIBE TABLE (value1, value2, ...) <,...table-name-n>; WHERE col-name LIKE “_string%” DROP TABLE table-name-1 DROP TABLE WHERE col-name BETWEEN <,...table-name-n>; Filtering value AND value rows WHERE col-name IS NULL WHERE date-value Managing Views “<01JAN2019>”d WHERE time-value “<14:45:35>”t CREATE VIEW CREATE VIEW table-name AS query; WHERE datetime-value “<01JAN201914:45:35>”dt DESCRIBE VIEW view-name-1 DESCRIBE VIEW <,...view-name-n>; Remerging Summary Statistics DROP VIEW DROP VIEW view-name-1 <,...view-name-n>; SELECT col-name, summary function(argument) FROM input table; Copyright © 2019 SAS Institute Inc.
    [Show full text]
  • Rexx to the Rescue!
    Session: G9 Rexx to the Rescue! Damon Anderson Anixter May 21, 2008 • 9:45 a.m. – 10:45 a.m. Platform: DB2 for z/OS Rexx is a powerful tool that can be used in your daily life as an z/OS DB2 Professional. This presentation will cover setup and execution for the novice. It will include Edit macro coding examples used by DBA staff to solve everyday tasks. DB2 data access techniques will be covered as will an example of calling a stored procedure. Examples of several homemade DBA tools built with Rexx will be provided. Damon Anderson is a Senior Technical DBA and Technical Architect at Anixter Inc. He has extensive experience in DB2 and IMS, data replication, ebusiness, Disaster Recovery, REXX, ISPF Dialog Manager, and related third-party tools and technologies. He is a certified DB2 Database Administrator. He has written articles for the IDUG Solutions Journal and presented at IDUG and regional user groups. Damon can be reached at [email protected] 1 Rexx to the Rescue! 5 Key Bullet Points: • Setting up and executing your first Rexx exec • Rexx execs versus edit macros • Edit macro capabilities and examples • Using Rexx with DB2 data • Examples to clone data, compare databases, generate utilities and more. 2 Agenda: • Overview of Anixter’s business, systems environment • The Rexx “Setup Problem” Knowing about Rexx but not knowing how to start using it. • Rexx execs versus Edit macros, including coding your first “script” macro. • The setup and syntax for accessing DB2 • Discuss examples for the purpose of providing tips for your Rexx execs • A few random tips along the way.
    [Show full text]
  • The Semantics of Syntax Applying Denotational Semantics to Hygienic Macro Systems
    The Semantics of Syntax Applying Denotational Semantics to Hygienic Macro Systems Neelakantan R. Krishnaswami University of Birmingham <[email protected]> 1. Introduction body of a macro definition do not interfere with names oc- Typically, when semanticists hear the words “Scheme” or curring in the macro’s arguments. Consider this definition of and “Lisp”, what comes to mind is “untyped lambda calculus a short-circuiting operator: plus higher-order state and first-class control”. Given our (define-syntax and typical concerns, this seems to be the essence of Scheme: it (syntax-rules () is a dynamically typed applied lambda calculus that sup- ((and e1 e2) (let ((tmp e1)) ports mutable data and exposes first-class continuations to (if tmp the programmer. These features expose a complete com- e2 putational substrate to programmers so elegant that it can tmp))))) even be characterized mathematically; every monadically- representable effect can be implemented with state and first- In this definition, even if the variable tmp occurs freely class control [4]. in e2, it will not be in the scope of the variable definition However, these days even mundane languages like Java in the body of the and macro. As a result, it is important to support higher-order functions and state. So from the point interpret the body of the macro not merely as a piece of raw of view of a working programmer, the most distinctive fea- syntax, but as an alpha-equivalence class. ture of Scheme is something quite different – its support for 2.2 Open Recursion macros. The intuitive explanation is that a macro is a way of defining rewrites on abstract syntax trees.
    [Show full text]
  • Belgium a Logic Meta-Programming Framework for Supporting The
    Vrije Universiteit Brussel - Belgium Faculty of Sciences In Collaboration with Ecole des Mines de Nantes - France 2003 ERSITEIT IV B N R U U S E S J I E R L V S C S I E A N R B T E IA N VIN TE CERE ECOLE DES MINES DE NANTES A Logic Meta-Programming Framework for Supporting the Refactoring Process A Thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science (Thesis research conducted in the EMOOSE exchange) By: Francisca Mu˜nozBravo Promotor: Prof. Dr. Theo D’Hondt (Vrije Universiteit Brussel) Co-Promotors: Dr. Tom Tourw´eand Dr. Tom Mens (Vrije Universiteit Brussel) Abstract The objective of this thesis is to provide automated support for recognizing design flaws in object oriented code, suggesting proper refactorings and performing automatically the ones selected by the user. Software suffers from inevitable changes throughout the development and the maintenance phase, and this usually affects its internal structure negatively. This makes new changes diffi- cult to implement and the code drifts away from the original design. The introduced structural disorder can be countered by applying refactorings, a kind of code transformation that improves the internal structure without affecting the behavior of the application. There are several tools that support applying refactorings in an automated way, but little help for deciding where to apply a refactoring and which refactoring could be applied. This thesis presents an advanced refactoring tool that provides support for the earlier phases of the refactoring process, by detecting and analyzing bad code smells in a software application, proposing appropriate refactorings that solve these smells, and letting the user decide which one to apply.
    [Show full text]
  • Concatenative Programming
    Concatenative Programming From Ivory to Metal Jon Purdy ● Why Concatenative Programming Matters (2012) ● Spaceport (2012–2013) Compiler engineering ● Facebook (2013–2014) Site integrity infrastructure (Haxl) ● There Is No Fork: An Abstraction for Efficient, Concurrent, and Concise Data Access (ICFP 2014) ● Xamarin/Microsoft (2014–2017) Mono runtime (performance, GC) What I Want in a ● Prioritize reading & modifying code over writing it Programming ● Be expressive—syntax closely Language mirroring high-level semantics ● Encourage “good” code (reusable, refactorable, testable, &c.) ● “Make me do what I want anyway” ● Have an “obvious” efficient mapping to real hardware (C) ● Be small—easy to understand & implement tools for ● Be a good citizen—FFI, embedding ● Don’t “assume you’re the world” ● Forth (1970) Notable Chuck Moore Concatenative ● PostScript (1982) Warnock, Geschke, & Paxton Programming ● Joy (2001) Languages Manfred von Thun ● Factor (2003) Slava Pestov &al. ● Cat (2006) Christopher Diggins ● Kitten (2011) Jon Purdy ● Popr (2012) Dustin DeWeese ● … History Three ● Lambda Calculus (1930s) Alonzo Church Formal Systems of ● Turing Machine (1930s) Computation Alan Turing ● Recursive Functions (1930s) Kurt Gödel Church’s Lambdas e ::= x Variables λx.x ≅ λy.y | λx. e Functions λx.(λy.x) ≅ λy.(λz.y) | e1 e2 Applications λx.M[x] ⇒ λy.M[y] α-conversion (λx.λy.λz.xz(yz))(λx.λy.x)(λx.λy.x) ≅ (λy.λz.(λx.λy.x)z(yz))(λx.λy.x) (λx.M)E ⇒ M[E/x] β-reduction ≅ λz.(λx.λy.x)z((λx.λy.x)z) ≅ λz.(λx.λy.x)z((λx.λy.x)z) ≅ λz.z Turing’s Machines ⟨ ⟩ M
    [Show full text]
  • Logic Programming Lecture 19 Tuesday, April 5, 2016 1 Logic Programming 2 Prolog
    Harvard School of Engineering and Applied Sciences — CS 152: Programming Languages Logic programming Lecture 19 Tuesday, April 5, 2016 1 Logic programming Logic programming has its roots in automated theorem proving. Logic programming differs from theorem proving in that logic programming uses the framework of a logic to specify and perform computation. Essentially, a logic program computes values, using mechanisms that are also useful for deduction. Logic programming typically restricts itself to well-behaved fragments of logic. We can think of logic programs as having two interpretations. In the declarative interpretation, a logic pro- gram declares what is being computed. In the procedural interpretation, a logic program program describes how a computation takes place. In the declarative interpretation, one can reason about the correctness of a program without needing to think about underlying computation mechanisms; this makes declarative programs easier to understand, and to develop. A lot of the time, once we have developed a declarative program using a logic programming language, we also have an executable specification, that is, a procedu- ral interpretation that tells us how to compute what we described. This is one of the appealing features of logic programming. (In practice, executable specifications obtained this way are often inefficient; an under- standing of the underlying computational mechanism is needed to make the execution of the declarative program efficient.) We’ll consider some of the concepts of logic programming by considering the programming language Prolog, which was developed in the early 70s, initially as a programming language for natural language processing. 2 Prolog We start by introducing some terminology and syntax.
    [Show full text]
  • Metaprogramming with Julia
    Metaprogramming with Julia https://szufel.pl Programmers effort vs execution speed Octave R Python Matlab time, time, log scale - C JavaScript Java Go Julia C rozmiar kodu Sourcewego w KB Source: http://www.oceanographerschoice.com/2016/03/the-julia-language-is-the-way-of-the-future/ 2 Metaprogramming „Metaprogramming is a programming technique in which computer programs have the ability to treat other programs as their data. It means that a program can be designed to read, generate, analyze or transform other programs, and even modify itself while running.” (source: Wikipedia) julia> code = Meta.parse("x=5") :(x = 5) julia> dump(code) Expr head: Symbol = args: Array{Any}((2,)) 1: Symbol x 2: Int64 5 3 Metaprogramming (cont.) julia> code = Meta.parse("x=5") :(x = 5) julia> dump(code) Expr head: Symbol = args: Array{Any}((2,)) 1: Symbol x 2: Int64 5 julia> eval(code) 5 julia> x 5 4 Julia Compiler system not quite accurate picture... Source: https://www.researchgate.net/ publication/301876510_High- 5 level_GPU_programming_in_Julia Example 1. Select a field from an object function getValueOfA(x) return x.a end function getValueOf(x, name::String) return getproperty(x, Symbol(name)) end function getValueOf2(name::String) field = Symbol(name) code = quote (obj) -> obj.$field end return eval(code) end function getValueOf3(name::String) return eval(Meta.parse("obj -> obj.$name")) end 6 Let’s test using BenchmarkTools struct MyStruct a b end x = MyStruct(5,6) @btime getValueOfA($x) @btime getValueOf($x,"a") const getVal2 = getValueOf2("a") @btime
    [Show full text]
  • Chapter 11. Knowledge Representation and Reasoning the Quest for Artificial Intelligence, Nilsson, N
    Chapter 11. Knowledge Representation and Reasoning The Quest for Artificial Intelligence, Nilsson, N. J., 2009. Lecture Notes on Artificial Intelligence Summarized by Ha, Jung-Woo and Lee, Beom-Jin Biointelligence Laboratory School of Computer Science and Engineering Seoul National Univertisy http://bi.snu.ac.kr Contents 11.1 Deductions in Symbolic Logic Deductions in Symbolic Logic 11.2 The Situation Calculus The Situation Calculus 11.3 Logic Programming Logic Programming 11.4 Semantic Networks Semantic Networks 11.5 Scripts and Frames Scripts and Frames Appendix © 2016, SNU CSE Biointelligence Lab., http://bi.snu.ac.kr 2 Overview Methods for knowledge representation and reasoning from Mid-1960s and Mid-1970s Symbolic logic and its deductions Predicate calculus For proving theories Situation calculus Logic programming: PROLOG Sematic networks: HAM, MEMS, MENTAL Script and Frames © 2016, SNU CSE Biointelligence Lab., http://bi.snu.ac.kr 3 Introduction Knowledge For intelligent system The mean to draw conclusion from or act on Knowledge representation Procedural Coordinate and control the specific action (ex. hitting a tennis ball) Programs using the knowledge Specific task program Declarative Declarative sentence (I am a 25 years old) Symbolic structures General task program © 2016, SNU CSE Biointelligence Lab., http://bi.snu.ac.kr 4 Chapter 11. Knowledge Representation and Reasoning 11.1 Deductions in Symbolic Logic © 2016, SNU CSE Biointelligence Lab., http://bi.snu.ac.kr 5 Deductions in Symbolic Logic The predicate calculus From Aristotle to G. Boole and McCarthy Ex. Aristotle syllogism 1. (∀ x)[Man(x) ⊃ Mortal(x)] (The expression “(∀ x)” is a way of writing “for all x”; and the expression “⊃” is a way of writing "implies that." “Man(x)” is a way of writing “x is a man”; and “Mortal(x)” is a way of writing “x is mortal.” Thus, the entire expression is a way of writing “for all x, x is a man implies that x is mortal” or, equivalently, “all men are mortal.”) 2.
    [Show full text]
  • Towards Flexible Goal-Oriented Logic Programming
    FACULTY OF SCIENCES Towards Flexible Goal-Oriented Logic Programming ir. Benoit Desouter Dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Computer Science Supervisors: prof. dr. ir. Tom Schrijvers prof. dr. ir. Marko van Dooren Department of Applied Mathematics, Computer Science and Statistics Faculty of Sciences, Ghent University ii Acknowledgments As it feels more natural to thank people in the language that we have used on a daily basis during the journey towards completing this PhD thesis, I'll use Dutch for most of the next few pages. In de eerste plaats wil ik mijn promotoren Tom en Marko bedanken. Tom, bedankt voor het geduld als ik occasioneel iets maar half begreep, en om er altijd vertrouwen in te blijven hebben. Je hebt me heel wat kansen aangereikt, waardoor ik van heel wat onderwerpen iets heb opgestoken. Marko, hoewel je er pas halverwege bijkwam, toonde je al snel interesse voor het onderwerp en heb je er vanuit je eigen expertise heel wat aan toegevoegd. Je deur stond altijd voor me open als ik even een tussentijdse statusupdate wou geven. Bedankt voor de babbels over vanalles en nog wat, en om me grondig te betrekken bij het geven van Programmeren 1. Ik heb nog heel wat bijgeleerd over objec- tori¨entatie door jouw visie, slides en codevoorbeelden. Daarnaast ook bedankt om mijn lokale LATEX-goeroe te zijn: niettegenstaande ik LATEX al tien jaar lang gebruik, heb ik voor het precies goed krijgen van deze thesis heel wat nieuwe pakketten en trucjes moeten gebruiken, met regelmatig vreemde out- put of cryptische foutmeldingen tot gevolg die ik niet altijd alleen kon oplossen | of het zou me op zijn minst veel meer tijd gekost hebben.
    [Show full text]
  • Dynamic Economics Quantitative Methods and Applications to Macro and Micro
    Dynamic Economics Quantitative Methods and Applications to Macro and Micro J¶er^ome Adda and Nicola Pavoni MACT1 2003-2004. I Overview Dynamic Programming Theory ² { Contraction mapping theorem. { Euler equation Numerical Methods ² Econometric Methods ² Applications ² MACT1 2003-2004. I Numerical Methods Examples: Cake Eating Deterministic Cake eating: ² V (K) = max u(c) + ¯V (K c) c ¡ with { K: size of cake. K 0 ¸ { c: amount of cake consumed. c 0 ¸ Stochastic Cake eating: ² V (K; y) = max u(c) + ¯Ey0 V (K0; y0) c K0 = K c + y ¡ Discrete Cake eating: ² V (K; ") = max[u(K; "); ¯E 0 V (½K; "0)] ½ [0; 1] " 2 MACT1 2003-2004. I How do we Solve These Models? Not necessarily a closed form solution for V (:). ² Numerical approximations. ² MACT1 2003-2004. I Solution Methods Value function iterations. (Contraction Mapping Th.) ² Policy function iterations. (Contraction Mapping Th.) ² Projection methods. (Euler equation) ² MACT1 2003-2004. I Value Function Iterations Value Function Iterations Vn(S) = max u(action; S) + ¯EVn 1(S0) action ¡ Vn(:) = T Vn 1(:) ¡ Take advantage of the Contraction Mapping Theorem. If T is ² the contraction operator, we use the fact that d(Vn; Vn 1) ¯d(Vn 1; Vn 2) ¡ · ¡ ¡ n Vn(:) = T V0(:) This guarantee that: ² 1. successive iterations will converge to the (unique) ¯xed point. 2. starting guess for V0 can be arbitrary. Successive iterations: ² { Start with a given V0(:). Usually V0(:) = 0. { Compute V1(:) = T V0(:) { Iterate Vn(:) = T Vn 1(:) ¡ { Stop when d(Vn; Vn 1) < ". ¡ MACT1 2003-2004. I Value Function Iterations: Deterministic Cake Eating Model: ² V (K) = max u(c) + ¯V (K c) c ¡ Can be rewritten as: ² V (K) = max u(K K0) + ¯V (K0) K0 ¡ The iterations will be on ² Vn(K) = max u(K K0) + ¯Vn 1(K0) K0 ¡ ¡ example: take u(c) = ln(c).
    [Show full text]