Computing Fundamentals 1 Equations and Reduction in CafeOBJ

Slides:



Advertisements
Similar presentations
Introduction to Proofs
Advertisements

Semantics Static semantics Dynamic semantics attribute grammars
Computing Fundamentals 2 Introduction to CafeOBJ Lecturer: Patrick Browne Lecture Room: K408 Lab Room: A308 Based on work by: Nakamura Masaki, João Pascoal.
ICE1341 Programming Languages Spring 2005 Lecture #6 Lecture #6 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
ML: a quasi-functional language with strong typing Conventional syntax: - val x = 5; (*user input *) val x = 5: int (*system response*) - fun len lis =
Copyright © 2006 Addison-Wesley. All rights reserved. 3.5 Dynamic Semantics Meanings of expressions, statements, and program units Static semantics – type.
CS 355 – Programming Languages
Copyright © Cengage Learning. All rights reserved. CHAPTER 1 SPEAKING MATHEMATICALLY SPEAKING MATHEMATICALLY.
Comp 205: Comparative Programming Languages Semantics of Imperative Programming Languages denotational semantics operational semantics logical semantics.
School of Computing and Mathematics, University of Huddersfield CAS2545: WEEK 11 LECTURE: n The meaning of Algebraic Specifications TUTORIAL/PRACTICAL:
Computing Fundamentals 1 Introduction to CafeOBJ Lecturer: Patrick Browne Lecture Room: K308 Lab Room: A308 Based on work by: Nakamura Masaki, João Pascoal.
TR1413: Discrete Mathematics For Computer Science Lecture 3: Formal approach to propositional logic.
Computing Fundamentals 1 Lecture 1 Lecturer: Patrick Browne Room K308 Based on Chapter 1. A Logical approach to Discrete.
School of Computing and Mathematics, University of Huddersfield CIA2326 Week 14 LECTURE: How to reason with Algebraic Specifications TUTORIAL/PRACTICAL:
Dr. Muhammed Al-Mulhem 1ICS ICS 535 Design and Implementation of Programming Languages Part 1 Fundamentals (Chapter 4) Axiomatic Semantics ICS 535.
Computing Fundamentals 1 Lecture 6 A Theory of Sets Lecturer: Patrick Browne Room K308 Based on Chapter 11. A Logical approach.
Computing Fundamentals 2 CafeOBJ. Equational logic State is a list of variables with associated values. Evaluation of an expression E in a state is performed.
Describing Syntax and Semantics
EE1J2 - Slide 1 EE1J2 – Discrete Maths Lecture 6 Limitations of propositional logic Introduction to predicate logic Symbols, terms and formulae, Parse.
Propositional Calculus Math Foundations of Computer Science.
Discrete Math 6A Max Welling. Recap 1. Proposition: statement that is true or false. 2. Logical operators: NOT, AND, OR, XOR, ,  3. Compound proposition:
Equational Reasoning Math Foundations of Computer Science.
Copyright © Cengage Learning. All rights reserved. CHAPTER 11 ANALYSIS OF ALGORITHM EFFICIENCY ANALYSIS OF ALGORITHM EFFICIENCY.
The ACL2 Proof Assistant Formal Methods Jeremy Johnson.
Systems Architecture I1 Propositional Calculus Objective: To provide students with the concepts and techniques from propositional calculus so that they.
Introduction to Python
Reading and Writing Mathematical Proofs
Math 3121 Abstract Algebra I Section 0: Sets. The axiomatic approach to Mathematics The notion of definition - from the text: "It is impossible to define.
MATH 224 – Discrete Mathematics
© Kenneth C. Louden, Chapter 11 - Functional Programming, Part III: Theory Programming Languages: Principles and Practice, 2nd Ed. Kenneth C. Louden.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
Propositional Calculus CS 270: Mathematical Foundations of Computer Science Jeremy Johnson.
© Kenneth C. Louden, Chapter 11 - Functional Programming, Part III: Theory Programming Languages: Principles and Practice, 2nd Ed. Kenneth C. Louden.
3.2 Semantics. 2 Semantics Attribute Grammars The Meanings of Programs: Semantics Sebesta Chapter 3.
Chapter 3 Part II Describing Syntax and Semantics.
Programming Languages and Design Lecture 3 Semantic Specifications of Programming Languages Instructor: Li Ma Department of Computer Science Texas Southern.
CSE Winter 2008 Introduction to Program Verification January 31 proofs through simplification.
Copyright © Cengage Learning. All rights reserved.
1 Introduction to Abstract Mathematics Chapter 2: The Logic of Quantified Statements. Predicate Calculus Instructor: Hayk Melikya 2.3.
Great Theoretical Ideas in Computer Science.
Naïve Set Theory. Basic Definitions Naïve set theory is the non-axiomatic treatment of set theory. In the axiomatic treatment, which we will only allude.
Mathematical Preliminaries
Introduction to Python Dr. José M. Reyes Álamo. 2 Three Rules of Programming Rule 1: Think before you program Rule 2: A program is a human-readable set.
CS412/413 Introduction to Compilers Radu Rugina Lecture 13 : Static Semantics 18 Feb 02.
Copyright © Cengage Learning. All rights reserved. CHAPTER 8 RELATIONS.
1 Section 7.1 First-Order Predicate Calculus Predicate calculus studies the internal structure of sentences where subjects are applied to predicates existentially.
1 Proving Properties of Recursive List Functions CS 270 Math Foundations of CS Jeremy Johnson.
COMP 412, FALL Type Systems C OMP 412 Rice University Houston, Texas Fall 2000 Copyright 2000, Robert Cartwright, all rights reserved. Students.
Week 1 Real Numbers and Their Properties (Section 1.6, 1.7, 1.8)
Certifying and Synthesizing Membership Equational Proofs Patrick Lincoln (SRI) joint work with Steven Eker (SRI), Jose Meseguer (Urbana) and Grigore Rosu.
1 Interactive Computer Theorem Proving CS294-9 September 7, 2006 Adam Chlipala UC Berkeley Lecture 3: Data structures and Induction.
The Relation Induced by a Partition
Describing Syntax and Semantics
Introduction to Logic for Artificial Intelligence Lecture 2
ML: a quasi-functional language with strong typing
Propositional Calculus: Boolean Functions and Expressions
2.5 and 2.6 Properties of Equality and Congruence
Great Theoretical Ideas in Computer Science
Proving Properties of Recursive List Functions
Propositional Calculus: Boolean Algebra and Simplification
Programming Languages 2nd edition Tucker and Noonan
Copyright © Cengage Learning. All rights reserved.
MA/CSSE 474 More Math Review Theory of Computation
This Lecture Substitution model
Copyright © Cengage Learning. All rights reserved.
OBJ first-order functional language based on equational logic
Programming Languages 2nd edition Tucker and Noonan
Representations & Reasoning Systems (RRS) (2.2)
COMPILER CONSTRUCTION
Presentation transcript:

Computing Fundamentals 1 Equations and Reduction in CafeOBJ Lecturer: Patrick Browne

Why a specification language? High level programming languages (HLP), like Python or Java, can be considered formal specifications. They specify what the machine should do. However, HLP are not good at expressing our understanding of a domain. They are too low level and contain too much detail. Using HLP it is difficult to identify design errors, assumptions are not made explicit, they are implementation dependent. HLP focus on how system tasks are performed. They don’t allow us to reason about the system or describe what the system does. Domains of interest include: a theory of sets, a theory of integers, a theory of bank accounts, a theory of a hospital records, a theory of traffic flow.

Why a specification language? CafeOBJ allows us to reason about what a system does rather than about the detailed algorithms . CafeOBJ is based on rigorous mathematic (equational logic, a lattice of types, functions, equations, axioms, syntactic and semantic domains). This makes CafeOBJ useful for teaching mathematics. CafeOBJ is executable. Even though it allows us to focus the what a program should do (i.e. specification), CafeOBJ also allows to run ‘specifications’ and produce results. Thus we can check our work (prototype) and get a result (compute). In sort we can: Specify Prototype Reason and study proofs Compute

Why a specification language? CafeOBJ has conceptual semantics based on the logic of equations. CafeOBJ has operational semantics based based on term rewriting. These two interpretations are closely related. Usually we talk about syntactic 'terms' and semantic 'expressions'. A good specification should be written in such a way that it can be used to predict how the system will behave.

Computing < Maths < World The role of CafeOBJ on this course is to provide a functional and logic based language that can be used to represent the mathematical concepts such as logic, sets, and functions. Which in turn can be used to model real world systems. Programming language. We use it as a specification &

Predefined Modules1 Module Type Operators Constants BOOL Bool not and and-also xor or or-else implies iff true, false NAT Nat NzNat Zero * + >= > <= < quo rem divides s p 0 1 2 3 ... INT Int Idem, mais - e – -2 ... FLOAT Float * / + - < <= > >= exp log sqrt abs sin atan etc. 1.2 ... pi STRING String string= string> string< string>= string<= length substring ++ upcase downcase etc. “a string" ... 1.Slide is an approximate translation of lecture notes by João Pascoal Faria at: http://paginas.fe.up.pt/~jpf/teach/MFES/index.html To find out what modules exist, type show modules To find out about a particular module type show moduleName BOOL is automatically imported CafeOBJ is written in LISP, the LISP implementaion is indicate with #! Here is and equation from INT describing addition: eq M + N = #! (+ m n).

CafeOBJ Equational Logic Equational calculus derives (proves) a term equation from a conditional-equational axiom set. The deduction rules in this calculus are: Reflexivity: Any term is provably equal to itself (t = t). Transitivity: If t1 is provably equal to t2 and t2 is provably equal to t3, then t1 is provably equal to t3. Symmetry: If t1 is provably equal to t2, then t2 is provably equal to t1. Congruence: If t1 is provably equal to t2, then any two terms are provably equal which consist of some context built around t1 and t2. e.g. f(t1)=f(t2).

Writing equations in CafeOBJ CafeOBJ statements are equations in which instances of the LHS pattern are replaced by corresponding instances of the RHS if the LHS matches the input expression. The matching process occurs "top-down, left-to-right.“ The first equation that matches is used. The definition of a function can be broken into several equations, giving us a multi-line definition: e.g. eq fact(0) = s(0) . eq fact(s(N)) = s(N) * fact(N) . Variables in CafeOBJ equations are universally quantified (∀N) equations Variables Axiom: Let “l = r if c” be an axiom of the axiom set. For any substitution of terms for the variables in l, r and c (giving terms l’, c’ and r’), the terms l’ and r’ are provably equal if the condition c’ is provably equal to true.

Variables in CafeOBJ Variables in CafeOBJ equations are universally quantified (∀N) equations Terms with variables, are instantiated by substituting the variables with ground terms. Here is an example from Jose Meseguer’s CC373 lecture notes. https://courses.engr.illinois.edu/cs373/

Writing equations in CafeOBJ In CafeOBJ computation is reduction of a well-formed term (or expression) to a normal form. An expression in normal form cannot be reduced any further. An expression is a ground if it contains no variables. If a term is normal form and is ground we say it is in ground normal form. The ground normal form can be considered as a value. Reduction can be viewed as a sequence of term rewrites, that treat the equation 0 + N = N as a left to right rewrite rule 0 + N -> N. This replaces (0 + N) with N. Reduction rewrites a term into a simpler form.

Writing equations in CafeOBJ In general when writing equations we should follow the following rules: The RHS should not be a single variable. All variables in the RHS must appear in the LHS. The scope of a constant is the module it is declared in (or a proof score or interactive session). The scope of a variable is only inside of the equation. So, during evaluation a variable, say X, will have the same value in a given equation, but it may have different values in different equations in the same module.

Reducing an Expressionin CafeOBJ An equation LHS=RHS is applicable to a given expression X, if we can substitute the variables occurring in some LHS with the values in expression X. This is also expressed as "LHS matches X“. Then we can replace X by Y, where Y is the expression obtained from RHS by replacing the variables occurring in LHS by their corresponding values. Such a replacement step a is called a reduction. For instance, given the equation and a reduction eq sqr X = X*X . – A definition red sqr 2 -- Reduction gives 2*2 = 4 The expression sqr 2 matches the left-hand side sqr X, with 2 being substituted for the variable X.

Reduction Reduction is a sequence of rewrites. open BOOL . red true and (not(false) or (not true)) The diagram shows 4 rewrites CafeOBJ actually does 6 rewrites. >[1] rule: eq (not A:Bool) = (A xor true) { A:Bool |-> false } <[1] (not false):Bool --> (false xor true):Bool >[2] rule: eq (false xor A:Bool) = A { A:Bool |-> true } <[2] (false xor true):Bool --> (true):Bool >[3] rule: eq (not A:Bool) = (A xor true) { A:Bool |-> true } <[3] (not true):Bool --> (true xor true):Bool >[4] rule: eq (A:Bool xor A) = false { A:Bool |-> true } <[4] (true xor true):Bool --> (false):Bool >[5] rule: eq (false or A:Bool) = A { A:Bool |-> true } <[5] (true or false):Bool --> (true):Bool >[6] rule: eq (true and A:Bool) = A { A:Bool |-> true } <[6] (true and true):Bool --> (true):Bool

Reduction Reduction with variables in term and result. Result is normal form, not ground. Uses rightmost-innermost reduction. red T:Bool and ((not F:Bool) or (not T)) . CafeOBJ uses 14 rewrites We simplify to 4 =R=> represents rewrite. Term-1 (not F) =R=> (F xor true) Term-2 (not T) =R=> (T xor true) Term-3 (T xor true) or (F xor true) =R=> ((T and F) xor true) Term-4 T and ((T xor true) or (F xor true)) =R=> ((F and T)xor T)

Reduction Reduction with variables in term and ground normal form result. open BOOL red (a:Bool or (not a)) . Gives: true As an intermediate step: (not a) =R=> (a xor true)

Trace of Reduction (a ˅ ~a) Because we have (a xor true) we can write: red a:Bool or (a xor true) . 1>[1] rule: eq (A or B) = ((A and B) xor (A xor B)) { A: |-> (a xor true), B |-> a } 1<[1] (a or (a xor true)) --> (((a xor true) and a) xor ((a xor true) xor a)) 1>[2] rule: eq (A and (B xor C)) = ((A and B) xor (A and C)){ A |-> a, B |-> true, C |-> a } 1<[2] ((a xor true) and a) --> ((a and true) xor (a and a)) 1>[3] rule: eq (true and A) = A { A |-> a } 1<[3] (a and true) --> a 1>[4] rule: eq (A and A) = A {A |-> a } 1<[4] (a and a) --> a 1>[5] rule: eq (A xor A) = false { A |-> a } 1<[5] (a xor a) --> (false) 1>[6] rule: eq (AC xor (A xor A))= (AC xor false) { AC |-> true, A |-> a } 1<[6] ((a xor true) xor a)--> (true xor false)

Reduction(a ˅ ~a) 1>[7] rule: eq (false xor A) = A { A |-> true } 1<[7] (true xor false) --> (true) 1>[8] rule: eq (false xor A) = A { A |-> true } 1<[8] (false xor true) --> (true) (true):Bool Everywhere you see rule: it means that the reduction found a matching equation in the BOOL module. The square brackets indicate the rule number in the this particular reduction [1]..[8] The grater-than sign > indicates starting a rewrite with the curled brackets {} showing a substitution. The variables in capitals are from the BOOL module. The less-than sign < indicates ending a rewrite replacing the LHS with the RHS. Using the commutativity property, the system may changed the order of the arguments. The commutative rule is applied.

Automatic Theorem Proving The CafeOBJ environment includes automatic theorem proving (ATP) software. The ATP will try to show that some statements (often called a conjecture, goal, conclusion) is a logical consequence of a set of statements (often called hypothesis, assumptions or axioms). The ATP in CafeOBJ is based on (Prover9). Most of the logic problems on this course use the ATP. We set up problems such as Portia, Superman, and Family using a different1 logical notation than the normal CafeOBJ equations. This notation is an alternative to the standard CafeOBJ notation, such as BOOL that we used in Lab1. If we were focusing on software engineering, instead of mathematics, then we would use CafeOBJ‘s standard notation to prove various properties of programs or specifications. See: CafeOBJ as a Tool for Behavioral System Verification Akira Mori1 and Kokichi Futatsugi2 Software Component Search based on Behavioral Specification Akira Mori, Toshimi Sawada, Kokichi Futatsugi, Akishi Seo,Masaaki Ihshiguro

Automatic Theorem Proving The basic steps in our examples are: Declare some predicates (sister). Define the axioms using the logical notation1 (-> , <->, |, &, ~, ax) Write the conjecture to be proved (goal). If the ATP can prove a goal we can examine the proof. We may compare it to other proof methods such as ordinary reduction, truth table, or a manual proof. This notation is an alternative to the standard CafeOBJ notation, such as BOOL If we were focusing on software engineering, instead of mathematics, then we would use CafeOBJ‘s standard notation to prove various properties of programs or specifications.

Half-Adder eq halfAdder(x,y) = pair(x xor y, x and y) . eq sum(pair(x,y)) = x . eq carry(pair(x,y)) = y . red halfAdder(true,true) . red sum(halfAdder(true,true)) . red carry(halfAdder(true,true)) .

Full-adder fullAdder(A,B,C-IN) = pair(sum.., carry.. OR carry) http://www.doctronics.co.uk/4008.htm Will need nested functions e.g. sum(HA(sum(HA(A,B)),C-IN))

Checking Signatures mod SIGNATURE { [ A B C D E] op a : A -> B op b : B -> C op c : C -> A **> When a function has 2 arguments they can be considered as the cross-product of two domains. op d : A C -> D op e : B B -> E var u : A var w : B var x : C var y : D var z : E} **> Why are some of these reduction OK while others cause error. open SIGNATURE . red e(a(u), w) . red e(a(c(x)),a(u)) . red b(x) . red a(c(b(a(y)))) . red d(c(x),x) .

Equivalence Class Let r be an equivalence relation on B. Then [b]r , the equivalence class of b, is the subset of elements of B that are equivalent (under r) to b. The equivalence classes of an equivalence relation R partition the set A into disjoint nonempty subsets whose union is the entire set. CafeOBJ reduction can show [s s 0]. red s s 0 == s 0 + s 0 .

Equivalence Class

mod! NATURAL { [Natural] op 0 : -> Natural op _+_ : Natural Natural -> Natural ops (s_) (p_) : Natural -> Natural vars M N : Natural eq s p N = N . eq p s N = N . eq N + 0 = N . eq N + s M = s (N + M) .}

Peano In CafeOBJ & Python mod! PEANO{ [Nat] op 0 : -> Nat op _+_ : Nat Nat -> Nat op p_ : Nat -> Nat op s_ : Nat -> Nat vars M N : Nat eq s p N = N . eq p s N = N . eq N + 0 = N . eq N + s M = s(N + M) . } def add(a, b): if a == 0: return b return add(a-1, b+1) Similarity: addition defined recursively. The base cases are quit similar. Differences: Syntax. Python version uses existing types and type inference. CafeOBJ defines addition it does not depend on pre-existing types and operations. Proofs are possible in CafeOBJ but not in Python.

Peano.py