We got almost where we needed to be on Monday with respect to our invariant proof. Remember that we are going backwards from:

{X! * Y =n! /\ X>=0 /\ X > 0} Y:=Y*X; X:=X-1; {X! * Y = n! /\ X>=0}

Note that the loop condition is included with I in the precondition on the sequence. This is required by the while rule.

The only rule we can apply is the sequence rule. Thus, we have to find A, B and C from {A}c0{C} and {C}c1{B}. We know that B is the invariant and can thus find C by working backwards over c1. Thus, the first thing to deal with is the assignment rule and X:=X-1:

{X! * Y = n! /\ X>=0}[X-1/X]

Replacing X by X-1 gives us C:

{(X-1)! * Y = n! /\ X-1>=0}

Now we can push C backwards through c0 again using the assignment rule to get A:

{(X-1)! * Y = n! /\ X-1>=0}[X*Y/Y]

Replacing Y with X*Y gives us A:

{(X-1)! * X * Y = n! /\ X-1>=0}

Unfortunately, this is not what we want. But if we can show that:

X! * Y = n! /\ X >=0 /\ X > 0 => (X-1)! * X * Y = n! /\ X-1 >= 0

we're in business because of the consequence rule. This is just a bit of mathematical manipulation:

X! * Y = n! /\ X >= 0 /\ X > 0
=> X! * Y = n! /\ X >= 1 (By X>0 and X>=0)
=> X! * Y = n! /\ (X-1) >= 0 (By subtracting 1 from each side of the inequality)
=> X * (X-1)! * Y = n! (X-1) >= 0 (By unrolling the factorial once)

Since A => A' and {A'}c{B} and B=>B the consequence rule gives us {A}c{B} which is exactly what we want if A = X! * Y = n! /\ X >= 0 /\ X > 0

Q.E.D.

Cool, but we still have some work to do in class Wednesday to show that the factorial calculation really is a factorial. All we've done here is show that our invariant is an invariant over the body of the loop.

A quick word about partial vs total correctness in our axiomatic specifications. Remember that we are talking about partial correctness in class. For the command c:

{A}c{B}

When dealing with everything but loops, the distinction between this and total correctness has little impact on our work. However, it is important to remember that the notation:

{A}while b do c{B}

says that B is true if c terminates. Thus, partial correctness. Total correctness is harder to deal with and our book chooses not to do so.

Remember to look at the last rule from class for Monday:

|=(A=>A') {A'}c{B'} |=(B=>B')------------------------------------- {A}c{B}

I've just moved the blog from being hosted by the ITTC web server to blogger.com.  You can still access the blog through the web page as always.  However, you can now access the blog via the address:

http://ku-eecs762.blogspot.com

Should be easier for me to administer and you to follow.  Let me know if you have any difficulties.

Today in class we defined what is called a Hoare triple, {A}c{B}, where A is a precondition, B is a postcondition and c is a command from IMP. Intuitively, the meaning of the Hoare triple is if A is true in sigma before c is evaluated, then B will be true in sigma’ after c is evaluated. We have that a formal definition using the concept of models or satisfies using the new semantic turnstyle. We started to give the assertion language used to write A and B a semantics towards the end of class. We were providing a semantics that was simply an extension of the semantics for a and b from IMP with the addition of integer variables. We don’t really know what those are quite yet, but we will shortly. We also defined the concept of an interpretation, denoted I, that is in effect a mapping from integer variables to values.

What’s going on here will be much clearer after Monday’s lecture, but Winskel’s description of this is excellent if you want to read it. I’m guessing that will happen after the project, which of course is perfectly fine.

Project 2 due date is set for November 17

As promised, I’ve written up the IMP operational and denotational semantics verification for the sequence operation. Attached are the PDF and LaTeX source. The LaTeX file uses the semantic package (semantic.sty) that can be found on any of the LaTeX module sites.

I will add the proof case for while that we’re doing in class sometime soon.

Project 2 is available should you want to get started.

More than one of you has asked about the fixed point of phi and why we found it. We are not using it at this point. In fact, we generally use the form of C[[while b do c]] that we found the fixed point from.

The answer is that the equation:

C[[w]] = {(sigma,sigma’) | B[[b]]sigma=true and (sigma,sigma’) in C[[w]] . C[[c]]} U {...}

does not give us a definition of the denotation. Specifically, C[[w]] appears in its own definition. This is not a well-founded function definition because, in affect, C[[w]] contains itself. So, we needed a value for C[[w]] that does not have this property.

If you look at the definition of R on page 59 of the text, notice that phi does not appear on the right-hand side of the equation. Thus, when we find the fixed point of R to give us R-hat, the definition is well founded. Once we have the value, we can in effect file it away for further use.

We have been going through a structural induction proof in class that is based on the induction scheme we set out earlier. Basically, if we can show something is true for every form in our language, then that something is true for the entire language. No big deal there.

What seems to be causing folks a bit of trouble is how the proof is set up. Basically, we have to definitions of our language. The operational semantic function for arithmetic expressions has the form:

<a,sigma> -> n

while the denotational semantic function has the form:

A[[a]]sigma = n

Somehow, we have to show that these are equivalent. The first thing we do is get both descriptions in the same form. In this case, sets that share the form of the denotational definition. So, we can define a function that returns the value for an expression as specified by the operational definition like this:

{(sigma,n) | <a,sigma> -> n}

This set defines a function that given a sigma, will return the n that the operational semantics definition says it should.

So why reformulate the definition and write this odd set definition? Quite simply, it formulates a denotational definition from the operational definition. That is quite helpful because now all we need to do is prove that these two denotational definitions are the same:

P(a) == A[[a]] = {(sigma,n) | <a,sigma;> -> n}

after expanding A[[a]]:

P(a) == {(sigma,n) | D(sigma,a,n)} = {(sigma,n) | <a,sigma> -> n}

where D is the denotational definition we developed a week ago.

Now you should see where we are headed. If we can show that:

D(sigma,a,n) <=> <a,sigma> -> n

then we know that if a pair is in A[[a]] it is also in the denotation function defined using the operational semantics. That is what we have been up to.

More later on where the preconditions come from and how they are used.

If you are looking for classes in the spring, Andy Gill is offering a new course on functional programming:

EECS 700 – Advanced Functional Programming – 3 credit hours – Prof. Andrew Gill
1:00pm – 1:50pm Monday/Wednesday/Friday
2111 Learned Hall
Prerequisite: EECS 368 or equivalent course.
An advanced introduction to functional programming. For additional course information contact Dr. Gill (andygill [at] ku [dot] edu)

We also have a couple of language-related courses on the books that will be offered:

EECS 843 - Programng Language Foundatn II - 3 credit hours - Prof. Perry Alexander
11:00am - 12:15pm Monday/Wednesday
1131 Learned Hall
Prerequsite: EECS 762 or EECS 662, or permission from the instructor
A follow-on to EECS 762 that covers static semantics including type systems and some static analysis. For additional course information, contact me. I’ll likely talk about this in class.

EECS 700 - Virtual Machines - 3 credit hours - Prof. Prasad Kulkarni
11:00am - 12:15pm Tuesday/Thursday
2111 Learned Hall
Prerequisite: permission from the instructor
A graduate introduction to virtual machines. For additional course information contact Dr. Kulkarni (kulkarn [at] eecs [dot] ku [dot] edu)