1. Introduction to CS 270 Math Foundations of CS
Mark Boady and Jeremy Johnson
Drexel University
The picture is from the Franklin Institute award ceremony where Ed Clarke (pictured with me) won the Bower prize (main award) for his foundational work in computer verification.

2. Course Description
Introduces formal logic and its connections to Computer Science. Students learn to translate statements about the behavior of computer programs into logical claims and to prove such assertions both by hand and using automated tools. Considers approaches to proving termination, correctness, and safety for programs. Discusses propositional and predicate logic, logical inference, recursion and recursively defined sets, mathematical induction, and structural induction.

3. Course Goals
For students to learn how to formally specify and reason about properties of computer systems. To appreciate what it means to prove something and the value of formalism. To become aware of tools for formal specification and automatic deduction. To use logical thinking to become better programmers and systems designers.

4. Course Objectives
To use recursion and divide and conquer to solve problems
To provide recursive definitions of patterns and data structures
To formally specify the input/output requirements of programs
To use induction and other proof techniques to prove properties of algorithms, data structures, programs, and computer systems
To use logic to describe the state of systems and to use logical deduction (by hand and using tools) to prove properties of systems
To understand the power and limitations of formal logic.

5. Course Topics Functional Programming
Recursion, Recursive Definitions and Induction
Propositional and Predicate Logic
Formal Proof using Natural Deduction
Applications of Logic to Computer Science
Program Specification and Verification
Termination Analysis
Test Case and Counter Example Generation
Automated Reasoning

6. Course Lectures Week 1 [Functional Programming and Recursion]
Course Introduction (formal specification and reasoning and computer verification)
Functional programming in Scheme (DrRacket)
Week 2 [Recursion and Induction]
Recursive algorithms and recurrence relations
Informal introduction to induction
List Processing and Natural Numbers
Week 3 [Propositional Logic and Equational Reasoning]
Boolean functions and Boolean expressions, syntax and semantics
Boolean algebra and simplification, logic circuits

7. Course Lectures Week 4 [Deduction] Week 5 [Elementary Metamathematics]
Derivations and formal proofs (LogicLab)
Indirect Proofs
Week 5 [Elementary Metamathematics]
Proof tactics, strategies and derived rules (LogicLab)
Normal forms, Soundness and Completeness
Tautology prover
Week 6 [Formal Specifications and Predicate Logic]
Syntax and semantics
Comparison to propositional calculus
Formal specifications

8. Course Lectures
Week 7 [Satisfiability, SAT Solvers and NP Completeness]
Reduction to satisfiability (MiniSAT)
DPLL algorithm for satisfiability
Week 8 [Structural Induction]
Induction principle and inductive proofs
Proofs about recursive algorithms and data structures (lists, trees, expressions)
Week 9 [Equational reasoning and termination]
Rewrite rules, focus and context, and axioms (J-Bob)
Definitional axiom and termination (J-Bob)
Week 10 [Induction and reasoning about recursive programs]
Inductive proofs about lists (J-Bob)
Inductive proofs about expression trees (J-Bob)

9. Textbook Little Schemer & Little Prover
The Little Prover is the required text on induction on program verification. This book uses the scheme programming language which is gently introduced in the text “The Little Schemer”. We will be using the Racket programming language for programming assignments. Racket is derived from Scheme and the part of Racket that we will use is, with some minor differences, essentially the same as Scheme.

10. Optional Textbook Logic & Proof (CMU OLI)
This text covers propositional (sentential) and predicate logic and will be used as a resource for the part of the course that covers these topics. We will use Logic Lab, which is available through the text, for deriving and checking formal proofs using natural deduction. The text may be used without paying for it as we will not use its auto-grading tools.

11. Optional Textbook Foundations of Computer Science
This text covers mathematical techniques that are relevant to Computer Science, such as logic, grammars, finite state machines and algorithm analysis

12. Software (LogicLab)
LogicLab is included in the required OLI text and will be used for assignments and the midterm. LogicLab provides an interactive user interface for deriving and grading natural deduction proofs. It also provides a tutor which assists students learn how to do proofs and gives hints when they get stuck (the tutor is only available for practice problems).

13. Software (MiniSAT)
MiniSAT is a very powerful program for solving the satisfiability problem (finding an assignment of boolean variables to true or false in a way that a logical formula is satisfied). MiniSAT is introduced so illustrate a production quality tool for practical applications of logic. It is available for download at and is installed on the CS computers (tux).

14. Software (DrRacket)
DrRacket will be used for programming assignments. DrRacket is an IDE for writing, running, debugging and experimenting with Racket programs. The Racket programming language is derived from the Scheme programming language which is well suited for functional programming (functions are treated as first class objects, i.e. they can be passed as arguments to functions and returned as results). Pure functional programs have no side effects and hence no assignments and loops. They rely on recursion for iteration. In this class, we use a functional programming language because they are easier to reason about mathematically then imperative languages like Java and C++. In CS 360 students will learn more about functional programming and will use the more modern functional programming language Haskell. We use Racket instead of Haskell since it is easier to learn and provides a simpler language to reason about for students first learning about computer verification. DrRacket is available for download at racket-lang.org. It is also available on the CS computers (tux).

15. Prerequisites and Grading
Programming skills (CS 172)
Course Requirements and Grading
In class labs (20%)
Weekly homework assignments (40%)
Midterms (20%) and Final (20%) exam
Midterms tentatively week 6
Final exam during finals week

16. Getting Help Office Hours Piazza
Jeremy Johnson [MWF 3-4] in UC 139, Mark Boady [M 3-4, T 3-5 and R 3-4] in UC 138
Steve Earth [T 4-6, R 10-12] and Cameron Graybill [T 6-8]
Piazza
piazza.com/drexel/fall2015/cs270/home

17. Getting Help (piazza)

18. Class Logistics Announcements will be posted in piazza
Use Piazza to ask questions
The course staff will regularly monitor and reply to questions in a timely manner
Weekly assignments will be due by 9am on Wednesday unless stated otherwise
Late assignments will not be accepted except for extenuating circumstances - students must get permission from their instructor

19. Class Logistics Students must attend labs to get credit
Labs will be held in class on Friday for Prof. Johnson’s sections
Labs will be held in class on Wednesday for Prof. Boady’s sections
In extenuating circumstances students may request to make up a lab
Don’t fall behind
Come to class prepared
Go to office hours and get help if you are having difficulty

20. Software Bugs
In 1980, NORAD reported that the US was under missile attack. The problem was caused by a faulty circuit, a possibility the reporting software hadn’t taken into account. A similar event occurred in the Soviet Union in 1983.
The Therac-25 medical radiation therapy device was involved in several cases where massive overdoses of radiation were administered to patients in , a side effect of the buggy software powering the device.
In 1996, a European Ariane 5 rocket was set to deliver a payload of satellites into Earth orbit, but problems with the software caused the launch rocket to veer off its path a mere 37 seconds after launch.
The following slides review some classic software bugs that had catastrophic consequences. These are shown to illustrate the importance of ensuring that safety critical software is correct.

21. Software Bugs
In 1994 in Scotland, a Chinook helicopter crashed and killed all 29 passengers. While initially the pilot was blamed for the crash, that decision was later overturned since there was evidence that a systems error had been the actual cause.
One of the subcontractors NASA used when building its Mars climate orbiter had used English units instead of the intended metric system, which caused the orbiter’s thrusters to work incorrectly. Due to this bug, the orbiter crashed almost immediately when it arrived at Mars in The cost of the project was $327 million, not to mention the lost time (it took almost a year for the orbiter to reach Mars).
In 2002 NIST estimated that programming errors cost the US economy $60B annually

22. Software Attacks Hacking into your car via the entertainment system
Through GPS spoofing Iran was able to capture a US Drone (RQ 170) in 2009.
hijacked-US-drone-says-Iranian-engineer
Wireless attack on pacemaker (Barnaby Jones)
weaponise-a-pacemaker

23. Hardware Bug Intel FDIV Bug
Intel P5 Pentium floating point unit
$500M
Error as high as the fourth significant digit of a decimal number, but the possibilities of this happening are 1 in 360 billion.
Approximately 8000 bugs introduced in during design of Pentium 4.
This slide shows a famous hardware bug that has significant economic consequences for Intel. The bug was discovered in 1994 by Professor Thomas R. Nicely at Lynchburg College while performing some number theoretic computations. The bug was not noticed for a year after the chip was released. The bug was attributed to 5 missing entries in a lookup table used by the division algorithm (radix 4 SRT). Ultimately Intel was forced to recall the defective chips. Since the bug appears very infrequently it is not likely to be detected with random testing, and the bug had the consequence that chip manufacturers started to use formal verification methods. See en.wikipedia.org/wiki/Pentium_FDIV_bug

24. Verification and Validation
Verification and Validation is the process of checking that a SW/HW system meets specifications and fulfills its intended purpose

25. Empirical Testing
Traditionally, errors in hardware and software have been detected empirically by testing
Number of possibilities too large so only a small subset can be tested
E.G. Testing arithmetic operations on all 264 double precision floating point numbers is infeasible
Approximately how much time would it take?

26. Formal Methods
In the context of hardware and software systems, formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics

27. Success Stories
Verified the cache coherence protocol in the IEEE Futurebus+ Standard
Analysis of Microsoft Windows device drivers using SLAM
Non-overflow proof for Airbus A380 flight control software
Verification of Pentium 4 floating-point unit with a mixture of STE and theorem proving
NICTA’s embedded L4 microkernel
Compcert compiler
These are examples where formal verification methods were used to assure correctness of industrial scale software.

28. Limitations
It is not possible to write a program that can check in general whether a program is correct or not.
Halting problem is undecidable [Alan Turing]
3n+1 problem
Twin prime conjecture
Predicate logic is undecidable
tml