VIDEOS 1 TO 50

Pre- and Post-Conditions - Software Debugging

Published: 2015/02/23

Channel: Udacity

LAFF-On 2.2.2 The Weakest Precondition Part 1

Published: 2017/04/05

Channel: UTAustinX LAFF-On Programming for Correctness

LAFF-On 2.2.2 Weakest Precondition Part 2

Published: 2017/04/05

Channel: UTAustinX LAFF-On Programming for Correctness

LAFF-On 2.4.2 If Command Weakest Precondition

Published: 2017/04/10

Channel: UTAustinX LAFF-On Programming for Correctness

Devon Stewart - Higher Order Abstract Syntax

Published: 2015/12/31

Channel: Brainium

Fusepool P3: Virtuoso CSV to RDF transformation

Published: 2016/05/02

Channel: Fusepool P3

Episode 9: Eliciting Beliefs

Published: 2011/01/20

Channel: Matt Caulfield

How Donald Trump Answers A Question

Published: 2015/12/30

Channel: Nerdwriter1

Lecture 10B | MIT 6.001 Structure and Interpretation, 1986

Published: 2009/04/08

Channel: MIT OpenCourseWare

ZuriHac 2015 - Discrimination is Wrong: Improving Productivity

Published: 2015/07/28

Channel: GoogleTechTalks

Clausal Form

Published: 2010/04/06

Channel: BillWadge

Playing Castlevania Lament (pt 1) using Human Level Artificial Intelligence

Published: 2013/08/16

Channel: electronicdave2

Continuously Train & Deploy Spark ML and Tensorflow AI Models from Jupyter Notebook to Production

Published: 2017/01/22

Channel: PipelineAI: Deploy ML and AI Models

Artificial Intelligence plays a video game (RYGAR -- displays robot's thoughts)(pt 8)

Published: 2014/03/20

Channel: electronicdave2

Making a bird origami using Human Level Artificial Intelligence

Published: 2013/08/08

Channel: electronicdave2

Artificial Intelligence plays video game (RYGAR -- part 5)

Published: 2014/03/12

Channel: electronicdave2

Artificial Intelligence plays a video game (RYGAR -- part 7)

Published: 2014/03/19

Channel: electronicdave2

Artificial Intelligence plays video game (RYGAR -- part 6)

Published: 2014/03/15

Channel: electronicdave2

Truth-functional Proofs with Replacement Rules Part 1_HD.mp4 - YouTube.mp4

Published: 2011/09/06

Channel: Tom Caswell

Artificial Intelligence plays Battlefield 4 (robot tank)

Published: 2013/11/08

Channel: electronicdave2

MOOC Information Extraction

Published: 2016/09/07

Channel: MOOCs UGC

Operation Interstellar by George O. Smith

Published: 2016/05/22

Channel: Sci-Fi Audiobooks Unleashed

Lecture - 35 Contexts

Published: 2008/09/22

Channel: nptelhrd

**Predicate transformer semantics** were introduced by Edsger Dijkstra in his seminal paper "Guarded commands, nondeterminacy and formal derivation of programs". They define the semantics of an imperative programming paradigm by assigning to each *statement* in this language a corresponding *predicate transformer*: a total function between two *predicates* on the state space of the statement. In this sense, predicate transformer semantics are a kind of denotational semantics. Actually, in guarded commands, Dijkstra uses only one kind of predicate transformer: the well-known **weakest preconditions** (see below).

Moreover, predicate transformer semantics are a reformulation of Floyd–Hoare logic. Whereas Hoare logic is presented as a deductive system, predicate transformer semantics (either by **weakest-preconditions** or by **strongest-postconditions** see below) are **complete strategies** to build valid deductions of Hoare logic. In other words, they provide an effective algorithm to reduce the problem of verifying a Hoare triple to the problem of proving a first-order formula. Technically, predicate transformer semantics perform a kind of symbolic execution of statements into predicates: execution runs *backward* in the case of weakest-preconditions, or runs *forward* in the case of strongest-postconditions.

Given a *statement* *S*, the **weakest-precondition** of *S* is a function mapping any postcondition *R* to a precondition *P*. Actually, the result of this function, denoted , is the "weakest" precondition on the initial state ensuring that execution of *S* terminates in a final state satisfying *R*.

More formally, let us use variable *x* to denote *abusively* the tuple of variables involved in statement *S*. Then, a given *Hoare triple* is provable in Hoare logic for **total correctness** if and only if the first-order predicate below holds:

Formally, weakest-preconditions are defined recursively over the abstract syntax of statements. Actually, weakest-precondition semantics is a continuation-passing style semantics of state transformers where the predicate in parameter is a continuation.

We give below two equivalent weakest-preconditions for the assignment statement. In these formulas, is a copy of *R* where free occurrences of *x* are replaced by *E*. Hence, here, expression *E* is implicitly coerced into a *valid term* of the underlying logic: it is thus a *pure* expression, totally defined, terminating and without side effect.

- version 1:

where |

- version 2:

The first version avoids a potential duplication of *E* in *R*, whereas the second version is simpler when there is at most a single occurrence of *x* in *R*. The first version also reveals a deep duality between weakest-precondition and strongest-postcondition (see below).

An example of a valid calculation of *wp* (using version 2) for assignments with integer valued variable *x* is:

This means that in order for the postcondition *x > 10* to be true after the assignment, the precondition *x > 15* must be true before the assignment. This is also the "weakest precondition", in that it is the "weakest" restriction on the value of *x* which makes *x > 10* true after the assignment.

For example,

As example:

Ignoring termination for a moment, we can define the rule for the *weakest liberal precondition*, denoted *wlp*, using a predicate *I*, called the loop invariant, typically supplied by the programmer:

This simply states that (1) the invariant must hold at the start of the loop; (2) additionally, for any initial state *y*, the invariant and guard taken together be strong enough to establish the weakest precondition necessary for the loop body to be able to re-establish the invariant; (3) finally, if and when the loop terminates in a given state *y*, the fact that the loop guard is false along with the invariant should be able to establish the required postcondition.

To show total correctness, we also have to show that the loop terminates. For this we define a well-founded relation on the state space denoted "<" and called loop variant. Hence, we have:

where |

Informally, in the above conjunction of three formulas:

- the first one means that invariant
*I*must initially hold; - the second one means that the body of the loop (e.g. statement
*S*) must preserve the invariant and decrease the variant: here, variable*y*represents the initial state of the body execution; - the last one means that
*R*must be established at the end of the loop: here, variable*y*represents the final state of the loop.

In predicate transformers semantics, *invariant* and *variant* are built by mimicking the Kleene fixed-point theorem. Below, this construction is sketched in set theory. We assume that *U* is a set denoting the state space. First, we define a family of subsets of *U* denoted by induction over natural number *k*. Informally represents the set of initial states that makes *R* satisfied after less than *k* iterations of the loop:

Then, we define:

- invariant
*I*as the predicate . - variant as the proposition

With these definitions, reduces to formula .

However, in practice, such an abstract construction cannot be handled efficiently by theorem provers. Hence, loop invariants and variants are provided by human users, or are inferred by some abstract interpretation procedure.

Actually, Dijkstra's Guarded Command Language (GCL) is an extension of the simple imperative language given until here with non-deterministic statements. Indeed, GCL aims to be a formal notation to define algorithms. Non-deterministic statements represent choices left to the actual implementation (in an effective programming language): properties proved on non-deterministic statements are ensured for all possible choices of implementation. In other words, weakest-preconditions of non-deterministic statements ensure

- that there exists a terminating execution (e.g. there exists an implementation),
- and, that the final state of all terminating execution satisfies the postcondition.

Notice that the definitions of weakest-precondition given above (in particular for **while-loop**) preserve this property.

Selection is a generalization of **if** statement:

Here, when two guards and are simultaneously true, then execution of this statement can run any of the associated statement or .

Repetition is a generalization of **while** statement in a similar way.

Refinement calculus extends non-deterministic statements with the notion of *specification statement*. Informally, this statement represents a procedure call in black box, where the body of the procedure is not known. Typically, using a syntax close to B-Method, a **specification statement** is written

- @

where

*x*is the global variable modified by the statement,*P*is a predicate representing the precondition,*y*is a fresh logical variable, bound in*Q*, that represents the new value of*x*non-deterministically chosen by the statement,*Q*is a predicate representing a postcondition, or more exactly a guard: in*Q*, variable*x*represents the initial state and*y*denotes the final state.

The weakest-precondition of **specification statement** is given by:

@
where |

Moreover, a statement *S* **implements** such a specification statement if and only if the following predicate is a tautology:

where is a fresh name (denoting the initial state) |

Indeed, in such a case, the following property is ensured for all postcondition *R* (this is a direct consequence of *wp* monotonicity, see below):

- @

Informally, this last property ensures that any proof about some statement involving a specification remains valid when replacing this specification by any of its implementations.

An important variant of the weakest precondition is the **weakest liberal precondition** , which yields the weakest condition under which *S* either does not terminate or establishes *R*. It therefore differs from *wp* in not guaranteeing termination. Hence it corresponds to Hoare logic in partial correctness: for the statement language given above, *wlp* differs with *wp* only on **while-loop**, in not requiring a variant (see above).

Given *S* a statement and *R* a precondition (a predicate on the initial state), then is their **strongest-postcondition**: it implies any postcondition satisfied by the final state of any execution of S, for any initial state statisfying R. In other words, a Hoare triple is provable in Hoare logic if and only if the predicate below hold:

Usually, **strongest-postconditions** are used in partial correctness. Hence, we have the following relation between weakest-liberal-preconditions and strongest-postconditions:

For example, on assignment we have:

where |

Above, the logical variable *y* represents the initial value of variable *x*. Hence,

On sequence, it appears that *sp* runs forward (whereas *wp* runs backward):

Leslie Lamport has suggested *win* and *sin* as *predicate transformers* for concurrent programming.^{[1]}

This section presents some characteristic properties of predicate transformers.^{[2]} Below, *T* denotes a predicate transformer (a function between two predicates on the state space) and *P* a predicate. For instance, *T(P)* may denote *wp(S,P)* or *sp(S,P)*. We keep *x* as the variable of the state space.

Predicate transformers of interest (*wp*, *wlp*, and *sp*) are monotonic. A predicate transformer *T* is **monotonic** if and only if:

This property is related to the consequence rule of Hoare logic.

A predicate transformer *T* is **strict** iff:

For instance, *wp* is strict, whereas *wlp* is generally not. In particular, if statement *S* may not terminate then is satisfiable. We have

Indeed, **true** is a valid invariant of that loop.

A predicate transformer *T* is **terminating** iff:

Actually, this terminology makes sense only for strict predicate transformers: indeed, is the weakest-precondition ensuring termination of *S*.

It seems that naming this property **non-aborting** would be more appropriate: in total correctness, non-termination is abortion, whereas in partial correctness, it is not.

A predicate transformer *T* is **conjunctive** iff:

This is the case for , even if statement *S* is non-deterministic as a selection statement or a specification statement.

A predicate transformer *T* is **disjunctive** iff:

This is generally not the case of when *S* is non-deterministic. Indeed, let us consider a non-deterministic statement *S* choosing an arbitrary boolean. This statement is given here as the following *selection statement*:

Then, reduces to the formula .

Hence, reduces to the *tautology*

Whereas, the formula reduces to the *wrong proposition* .

The same counter-example can be reproduced using a *specification statement* (see above) instead:

- @

- Computations of weakest-preconditions are largely used to statically check assertions in programs using a theorem-prover (like SMT-solvers or proof assistants): see Frama-C or ESC/Java2.
- Unlike many other semantic formalisms, predicate transformer semantics was not designed as an investigation into foundations of computation. Rather, it was intended to provide programmers with a methodology to develop their programs as "correct by construction" in a "calculation style". This "top-down" style was advocated by Dijkstra
^{[3]}and N. Wirth.^{[4]}It has been formalized further by R.-J. Back and others in the refinement calculus. Some tools like B-Method now provide automated reasoning in order to promote this methodology. - In the meta-theory of Hoare logic, weakest-preconditions appear as a key notion in the proof of relative completeness.
^{[5]}

In predicate transformers semantics, expressions are restricted to terms of the logic (see above). However, this restriction seems too strong for most existing programming languages, where expressions may have side effects (call to a function having a side effect), may not terminate or abort (like *division by zero*). There are many proposals to extend weakest-preconditions or strongest-postconditions for imperative expression languages and in particular for monads.

Among them, *Hoare Type Theory* combines Hoare logic for a Haskell-like language, separation logic and type theory.^{[6]} This system is currently implemented as a Coq library called **Ynot**.^{[7]} In this language, evaluation of expressions corresponds to computations of *strongest-postconditions*.

*Probabilistic Predicate Transformers* are an extension of predicate transformers for probabilistic programs. Indeed, such programs have many applications in cryptography (hiding of information using some randomized noise), distributed systems (symmetry breaking). ^{[8]}

- Axiomatic semantics – includes predicate transformer semantics
- Dynamic logic – where predicate transformers appear as modalities
- Formal semantics of programming languages – an overview

**^**Leslie Lamport, "*win*and*sin*: Predicate Transformers for Concurrency".*ACM Transactions on Programming Languages and Systems*, 12(3), July 1990. [1]**^**Ralph-Johan Back and Joakim von Wright,*Refinement Calculus: A Systematic Introduction*, 1st edition, 1998. ISBN 0-387-98417-8.**^**Edsger W. Dijkstra,*A constructive approach to program correctness*, BIT Numerical Mathematics, 1968 - Springer**^**N. Wirth,*Program development by stepwise refinement*, Communications of the ACM, 1971 [2]**^**Tutorial on Hoare Logic: a Coq library, giving a simple but formal proof that Hoare logic is sound and complete with respect to an operational semantics.**^**Aleksandar Nanevski, Greg Morrisett, Lars Birkedal.*Hoare Type Theory, Polymorphism and Separation*, Journal of Functional Programming, 18(5/6), 2008 [3]**^**Ynot a Coq library implementing Hoare Type Theory.**^**Carroll Morgan, Annabelle McIver , Karen Seidel.*Probabilistic Predicate Transformers*, ACM Transactions on Programming Languages and Systems, 1995 [4]

- J. W. de Bakker.
*Mathematical theory of program correctness*. Prentice-Hall, 1980. - Marcello M. Bonsangue and Joost N. Kok,
*The weakest precondition calculus: Recursion and duality*,*Formal Aspects of Computing*,**6**(6):788–800, November 1994. DOI 10.1007/BF01213603. - Edsger W. Dijkstra,
*Guarded commands, nondeterminacy and formal derivation of program*.*Communications of the ACM*, 18(8):453–457, August 1975. [5] - Edsger W. Dijkstra.
*A Discipline of Programming*. ISBN 0-613-92411-8. — A systematic introduction to a version of the guarded command language with many worked examples - Edsger W. Dijkstra and Carel S. Scholten.
*Predicate Calculus and Program Semantics*. Springer-Verlag 1990 ISBN 0-387-96957-8 — A more abstract, formal and definitive treatment - David Gries.
*The Science of Programming*. Springer-Verlag 1981 ISBN 0-387-96480-0

None of the audio/visual content is hosted on this site. All media is embedded from other sites such as GoogleVideo, Wikipedia, YouTube etc. Therefore, this site has no control over the copyright issues of the streaming media.

All issues concerning copyright violations should be aimed at the sites hosting the material. This site does not host any of the streaming media and the owner has not uploaded any of the material to the video hosting servers. Anyone can find the same content on Google Video or YouTube by themselves.

The owner of this site cannot know which documentaries are in public domain, which has been uploaded to e.g. YouTube by the owner and which has been uploaded without permission. The copyright owner must contact the source if he wants his material off the Internet completely.

Wikipedia content is licensed under the GFDL and (CC) license