The Essence of iRRAM Andrej Bauer (University of Ljubljana) Sewon - - PowerPoint PPT Presentation

Command-like Expressions for Real Infinite-precision Calculations

Andrej Bauer (University of Ljubljana) Sewon Park (KAIST) Alex Simpson (University of Ljubljana) Dagstuhl – November 2017

Thank you for giving me the opportunity to speak. I will present some recent work done jointly with Sewon Park and Alex Simpson. The work is still “in progress” but we think it’s worth reporting about. Our work was inspired by the ERC language, as presented by Sewon in the previous talk. But before I go on, I should say that there is a much better title for my talk.

The Essence of iRRAM

Andrej Bauer (University of Ljubljana) Sewon Park (KAIST) Alex Simpson (University of Ljubljana) Dagstuhl – November 2017

This one speaks for itself. But seriously, I am going to present a small language which tries to capture the essence of imperative real-number computation.

Command-like expressions for real infinite-precision calculations

When you see a silly title like this you know there is an even sillier acronym behind it.

Command-líké expŕessíons for reaI infíníte-pŕecísíon calcuIatíons

Clerical

Clerical

• 1. concerned with or relating to work in an office, especially routine

documentation and administrative tasks

• 2. relating to the clergy

And thus we named our language Clerical. It is Alex’s fault. We take the first meaning of the word.

• A simple & expressive language for exact real numbers
• Easy denotational semantics
• Hoare-style correctness rules
• Operational semantics a la iRRAM
• Implement & formalize

What we did

We set out to design a small and expressive programming language for exact real number computation, much like ERC, but perhaps better structured. We want as simple semantics as possible, avoiding technicalities of domain theory as well as representation theory. Based on the semantics we formulate Hoare-style correctness rules with preconditions and postconditions. The language should of course be executable. Here we follow the execution model

• f iRRAM.

The language is implemented in OCaml (3000 lines, of this 1800 for interval arithmetic) and formalized in Coq (work in progress).

Commands & expressions

• Datatypes: boolean, integer, real
• Commands & expressions:
• local mutable variables
• commands – read & write variables, no value
• expressions – read & write variables, return value
• pure expressions – read-only ambient variables,


but still write to its own local variables

Clerical is an imperative language. It has three datatypes: booleans, integers, and (exact) reals. There are commands and expressions. The difference is that commands do not yield any values, but expressions do. An expresssion is pure if it does not modify the ambient variables (it may still modify its own local variables).

x

variable

k

constant

e1 ⊙ e2

• perator

var x := e1 in c2

local mutable variable

x := e

variable assignment

skip

do nothing

c1 ; c2

sequencing

if b then c1 else c2

conditional statement

case b1 ⇒ c1 | b2 ⇒ c2 end

guarded non-determinism

while b do c end

loop

lim n ⇒ en

limit of a sequence

Here is the entirety of Clerical syntax. There are standard commands, such as declaration of local variable, assignment, and control-flow.

x

variable

k

constant

e1 ⊙ e2

• perator

var x := e1 in c2

local mutable variable

x := e

variable assignment

skip

do nothing

c1 ; c2

sequencing

if b then c1 else c2

conditional statement

case b1 ⇒ c1 | b2 ⇒ c2 end

guarded non-determinism

while b do c end

loop

lim n ⇒ en

limit of a sequence

effectful (read & write) pure
 (read only)

Clerical also has typing rules. They are pretty standard and expected, so we do not show them here. But the rules check that certain expressions are pure. Namely, the blue ones must be pure, so that we can give reasonable semantics to the language. The red ones may be efecful, unless they appear as subexpressions in positions where purity is required.

x

variable

k

constant

e1 ⊙ e2

• perator

var x := e1 in c2

local mutable variable

x := e

variable assignment

skip

do nothing

c1 ; c2

sequencing

if b then c1 else c2

conditional statement

case b1 ⇒ c1 | b2 ⇒ c2 end

guarded non-determinism

while b do c end

loop

lim n ⇒ en

limit of a sequence

+ – × ÷ < > ≤ ≥ = ≠ but only < > ≠ on reals

We support the usual arithmetical operators and comparisons. On reals we support those that make computational sense, namely the strict ones. (The comparison x < x does not terminate.)

x

variable

k

constant

e1 ⊙ e2

• perator

var x := e1 in c2

local mutable variable

x := e

variable assignment

skip

do nothing

c1 ; c2

sequencing

if b then c1 else c2

conditional statement

case b1 ⇒ c1 | b2 ⇒ c2 end

guarded non-determinism

while b do c end

loop

lim n ⇒ en

limit of a sequence

can be simulated with case

The conditional statement is not necessary because we can simulate it with the guarded non-deterministic case.

x

variable

k

constant

e1 ⊙ e2

• perator

var x := e1 in c2

local mutable variable

x := e

variable assignment

skip

do nothing

c1 ; c2

sequencing

if b then c1 else c2

conditional statement

case b1 ⇒ c1 | b2 ⇒ c2 end

guarded non-determinism

while b do c end

loop

lim n ⇒ en

limit of a sequence

multi-valued results

We include non-deterministic guarded case. This is a source of multi-valued

• results. We will discuss it shortly.

x

variable

k

constant

e1 ⊙ e2

• perator

var x := e1 in c2

local mutable variable

x := e

variable assignment

skip

do nothing

c1 ; c2

sequencing

if b then c1 else c2

conditional statement

case b1 ⇒ c1 | b2 ⇒ c2 end

guarded non-determinism

while b do c end

loop

lim n ⇒ en

limit of a sequence

non-termination

The while loops are a source of non-termination, and they make the language Turing-complete. In fact, every computable real is expressible in the language.

case
 | b1 ⇒ c1
 | b2 ⇒ c2
 end

If bi is true then evaluate ci. Evaluate either if b1 and b2 are true.

Let us take a closer look at the non-deterministic case. These are Dijsktra’s guarded commands. The case evaluates one of the commands ci whose corresponding boolean test bi evaluates to true (even if other tests diverge). If several branches are available any one may be chosen (but only one).

case
 | x < x ⇒ c1
 | true ⇒ c2
 end

x < x diverges, execute c2

For example, a real-valued comparison x < x is non-terminating, so execution must proceed with the second branch.

case
 | x < ε ⇒ c1
 | -ε < x ⇒ c2
 end

zero-test with tolerance ε

The case statements are used to perform comparison tests with tolerance. On the

• verlapping areas any one of the branches may be executed. It is the responsibility
• f the programmer to take care of such cases.

lim n ⇒ en

Compute the limit x, provided |x – en| ≤ 2–n.

It ain’t reals without limits

In Clerical real numbers are constructed as limits of rapidly converging sequences. It is important the en be pure. It may be multi-valued, in which case

lim n ⇒
 case
 | x < 2-n-1 ⇒ -x
 | x > -2-n-1 ⇒ x
 end

compute |x|

Here is an example that combines limits and case. It computes the absolute value

• f x. (In reality we would expect a primitive operations abs(x) that works directly

with intervals.)

x1:τ1, …, xn:τn ; xn+1:τn+1, …, xn+m:τn+m

Context of variables

read-only variables read-write variables

Γ Δ

τi ∈ { bool, int, real }

Clerical has a very simple type system. The only datatypes are booleans, integers and reals. An expression is always considered in a context of variables. This is a sequence of variables xi with corresponding types τi. The context has two parts, the read-write variables and the read-only variables. When a new local variable is introduced, it is placed on top of the read-write part, following a stack discipline. When a pure expression is evaluated the read-write variables are moved over to the read-only part.

Typed expressions

Γ ; Δ ⊢ e : τ

“In context Γ ; Δ expression e has type τ “

We may express the fact that an expression has a given type in the given context.

Typed expressions

⋅ ; Δ ⊢ e : τ

“In context ⋅ ; Δ pure expression e has type τ “

We may state that an expression is pure by making the read-write part of the context empty.

Typed expressions

Γ ; Δ ⊢ c cmd

“c is a command in in context Γ ; Δ“

There is also the judgment that we have a command. This one does not have a type because it does not return anything. An alternative would be to introduce a unit type and commands return unit. (The unit type is misnamed “void” in many languages.)

⟦bool⟧ = 𝔺 ⟦int⟧ = ℤ ⟦real⟧ = ℝ

⟦x1:τ1,…,xn:τn⟧ = ⟦τ1⟧ × ⋯ × ⟦τn⟧

Meaning of types

Let me touch briefly on the semantics of the language. The datatypes are interpreted in the most naive way, as sets. Because “reals are reals” this makes it easier to reason about programs, as one does not have to worry about intervals, representations, or anything like that. (How intervals are actually used to execute programs is a matter for operational semantics.) The meaning of a typing context is just the product of the meaning of types.

Meaning of expressions

⟦Γ ; Δ ⊢ e : τ⟧ : ⟦Γ⟧ × ⟦Δ⟧ ⇀ P*((⟦Γ⟧ × ⟦τ⟧)⊥)

well-typed expression e values of variables non-empty set of possible results non-termination partial semantics

We only assign meaning to well-typed expressions. So suppose we have an expression e of type τ in a context Γ, Δ. Such an expression is a map which takes as input the values of variables. It outputs a set of possible results. Each result is a pair: the new values of the read-write variables, and a return value. One possible value is ⊥, indicating that e is non-terminating. The semantics is partial because we only assign a meaning to the limit operator when its result is uniquely determined.

Meaning of lim

x ∈ ⟦Γ ; Δ ⊢ lim n ⇒ en⟧
 ⇔ ∀n, ⟦en⟧ defined and ∀n ∀y ∈ ⟦en⟧ , | x – y | ≤ 2–n 


We assign a meaning to the limit operator only when it has a unique limit x. In particular, all possible results must converge to it.

Proof rules

{ φ } e { x | ψ(x) } { φ } c { ψ }

If φ holds then e evaluates to a value x satisfying ψ(x). If φ holds then c terminates and ψ holds.

proof rules, correctness & comleteness

φ ⇒ ∀n∈ℕ.Θ { θ(n) } en { y | ξ(n,y) } φ ⇒ ∀n∈ℕ.∀y,z∈ℝ. (ξ(n,y) ∧ ψ(z) ⇒ |z – y| ≤ 2–n) { φ } lim n ⇒ en { z | ψ(z) }

Most rules of correctness are standard. Let us look just at the rule for limits. Suppose want to show that under precondition φ the limit is some number z satisfying ψ(z). Then we have to check three things, as shown.

Operational semantics

• A simple stack machine
• Reals are evaluated as intervals
• Upon loss of precision, increase

precision and restart computation.

• Implemented in OCaml

We implemented the language in the style of iRRAM. We have not yet proved that the implemented operational semantics is correct. Correctness here means: the program evaluates to one of the possible meanings.

Conclusion

• A “laboratory language” suitable for experiments
• Basis for formalization and proofs of correctness
• Use it as an embedded domain-specific language

In conclusion let me explain how such a language (or one of the other ones presented here, Michal Konencny has one too) can be used. It is small enough so that we can experiment with it, formalize and implement it. The language semantics provides a framework for correctness: what does it mean to correctly implement a language? What does it mean for proof rules to be sound (and complete)? We can answer these questions. Finally, there is an intrigiung practical possibility. In real-number computation we

• ften have to control the overall execution of the program (for instance by

restarting upon loss of precision). Real languages do not let us do this (iRRAM resorts to a hack), but we can have an embedded language with full control over it. For example, in Clerical we do know precisely what variables are alive at any moment, which may computation (think of Taylor models). Thank you.