Nikolaj Bjørner and Leonardo de Moura: The Z3 Constraint Solver

In this episode of The Verification Corner, Rustan Leino talks about Loop Invariants. He gives a brief summary of the theoretical foundations and shows how a program can sometimes be systematically constructed from its specifications. Rustan Leino is a Principal Researcher in the Research in Software Engineering (RiSE) group at Microsoft Research.
The Verification Corner is a show on Software Verification Techniques and Tools. The show is produced by the Research in Software Engineering team (RiSE) coordinates Microsoft's research in Software Engineering in Redmond, USA.
Very interesting video, thx
I agree, I'd like to see a lot more videos in this series. Also, that is a way cool digital whiteboard - I've always wanted a whiteboard I could print from. It does make me wonder what other "toys" MSR use as part of their working day.
More videos are coming, The Verification Corner will cover all the aspects of software verification. At MSR, we usually rely on regular whiteboards like everyone else In the movie, we've used an eBeam system to capture the pen to give a better video experience.
Very nice.
I only wish there was an invariant of having the video released closer to the creation.
> video released closer to the creation
Note sure I get it. Do you mean the video should be on the Spec# web site?
Very good explanation of the subject! And the tools show to really help in the process.
Could the same thing be accomplished with CodeContracts? Or is Spec# further in its evolution? I was wondering because CodeContracts is what most people will be using (I guess) so it would make more sense to show the example in CodeContract instead of Spec#.
Thanks!
CodeContracts could in principle be used to do the same thing. However, we have more engineering to do for CodeContracts to support this particular example. While CodeContracts does support pre- and postconditions, it has no direct support for writing loop invariants, which play a central role in this episode of Verification Corner. As a more technical point, the static-checking tools for CodeContracts don't have the support for non-linear arithmetic (that is, multiplication of a variable with itself or with another variable) that is required to reason about the computation of cubes.
For now, the best you can do in CodeContracts is to use an Assert just inside the loop body to express the loop invariant and then rely on run-time checking. Still, you may find that doing that improves your ability to reason about what's going on in the loop.
I suppose you're referring to the mention of "it is December" in the video, while it was actually released here in January. But you can make wishes any time of year.
Hi all, I have a rather basic question. Why Hoare's triple is written as {P}S{Q}, instead of P{S}Q? Is there any special reason behind it?
In Tony Hoare's classic 1969 paper, the triples were written P{S}Q. Sometime later (I'm not sure when), the common notation switched to {P}S{Q}. I think (but I'm not certain) that the reason for the switch was to make the assertions P and Q look as if they were comments, like in the syntax of the Pascal programming language.
Can the system handle overflow (e.g. if the array of cubes is so large that the cubes of higher indices exceed the maximum integer value)?
No, the Spec# verifier ignores issues of overflow. Checks for arithmetic overflow can be added to the verifier, at the cost of additional specification overhead for users. In some other languages we use for verification, like Dafny, the integers are unbounded, so there will never be any overflows.