I defined a sigma algebra datatype in Dafny, as shown below:
datatype Alg = Empty | Complement(a: Alg) | Union(b: Alg, c: Alg) | Set(s: set<int>)
class test {
var S : set<int>
function eval(X: Alg) : set<int> // evaluates an algebra
reads this;
decreases X;
{
match X
case Empty => {}
case Complement(a) => S - eval(X.a)
case Union(b,c) => eval(X.b) + eval(X.c)
case Set(s) => X.s
}
}
I want to state properties that quantify over the inductive datatype. Is it possible to express properties like this?
Here is an example of what I have tried:
lemma algebra()
ensures exists x :: x in Alg ==> eval(x) == {};
ensures forall x :: x in Alg ==> eval(x) <= S;
ensures forall x :: x in Alg ==> exists y :: y in Alg && eval(y) == S - eval(x);
ensures forall b,c :: b in Alg && c in Alg ==> exists d :: d in Alg && eval(d) == eval(b) + eval(c);
But I get the error message:
second argument to "in" must be a set, multiset, or sequence with
elements of type Alg, or a map with domain Alg
I want to state properties like: "there exists an algebra such that ...", or "for all algebras ...".
A type is not the same as a set in Dafny. You want to express the quantifiers in your lemmas as follows:
lemma algebra()
ensures exists x: Alg :: eval(x) == {}
ensures forall x: Alg :: eval(x) <= S
ensures forall x: Alg :: exists y: Alg :: eval(y) == S - eval(x)
ensures forall b: Alg, c: Alg :: exists d: Alg :: eval(d) == eval(b) + eval(c)
In the same way, you can declare a variable x to have type int, but you don't write x in int.
Because of type inference, you don't have to write : Alg explicitly. You can just write:
lemma algebra()
ensures exists x :: eval(x) == {}
ensures forall x :: eval(x) <= S
ensures forall x :: exists y :: eval(y) == S - eval(x)
ensures forall b, c :: exists d :: eval(d) == eval(b) + eval(c)
Another comment on the example: You're defining mathematics here. When you do, it's usually a good idea to stay away from the imperative features like classes, methods, and mutable fields. You don't need such features and they just complicate the mathematics. Instead, I suggest removing the class, changing the declaration of S to be a const, and removing the reads clause. That gives you:
datatype Alg = Empty | Complement(a: Alg) | Union(b: Alg, c: Alg) | Set(s: set<int>)
const S: set<int>
function eval(X: Alg): set<int> // evaluates an algebra
decreases X
{
match X
case Empty => {}
case Complement(a) => S - eval(X.a)
case Union(b,c) => eval(X.b) + eval(X.c)
case Set(s) => X.s
}
lemma algebra()
ensures exists x :: eval(x) == {}
ensures forall x :: eval(x) <= S
ensures forall x :: exists y :: eval(y) == S - eval(x)
ensures forall b, c :: exists d :: eval(d) == eval(b) + eval(c)
Rustan
Related
I am new to Coq and was wondering what is the difference between the following things:
Class test (f g: nat -> nat) := {
init: f 0 = 0 /\ g 0 = 0;
output: ...another proposition about f and g...;
}.
and
Class test := {
f: nat -> nat;
g: nat -> nat;
init: f 0 = 0 /\ g 0 = 0;
output: ...another proposition about f and g...;
}.
Could anyone provide an explanation ?
The difference between them is referred to as bundling.
Class test (f g: nat -> nat) := {
init: f 0 = 0 /\ g 0 = 0;
output: ...another proposition about f and g...;
}.
is unbundled, and
Class test := {
f: nat -> nat;
g: nat -> nat;
init: f 0 = 0 /\ g 0 = 0;
output: ...another proposition about f and g...;
}.
is bundled.
The advantage of bundling is that you don't need to always provide f and g. The advantage of unbundling is that you can have different instances of the same class sharing the same f and g. If you bundle them, Coq will not be easily convinced that different instances share parameters.
You can read more about this in Type Classes for Mathematics in Type Theory.
To complement Ana’s excellent answer, here is a practical difference:
the unbundled version (call it utest) allows you to write the logical statement utest f g about a specific pair of functions f and g,
whereas the bundled version (call it btest) allows you to state that there exists a pair of functions which satisfies the properties; you can later refer to these functions by the projection names f and g.
So, roughly speaking:
btest is “equivalent” to ∃ f g, utest f g;
utest f' g' is “equivalent” to btest ∧ “the f (resp. g) in the aforementioned proof of btest is equal to f' (resp. g')”.
More formally, here are the equivalences for a minimal example
(in this code, the notation { x : A | B } is a dependent pair type,
i.e. the type of (x, y) where x : A and y : B
and the type B depends on the value x):
(* unbundled: *)
Class utest (x : nat) : Prop := {
uprop : x = 0;
}.
(* bundled: *)
Class btest : Type := {
bx : nat;
bprop : bx = 0;
}.
(* [btest] is equivalent to: *)
Goal { x : nat | utest x } -> btest.
Proof.
intros [x u]. econstructor. exact (#uprop x u).
Qed.
Goal btest -> { x : nat | utest x }.
Proof.
intros b. exists (#bx b). constructor. exact (#bprop b).
Qed.
(* [utest x] is equivalent to: *)
Goal forall x, { b : btest | #bx b = x } -> utest x.
Proof.
intros x [b <-]. constructor. exact (#bprop b).
Qed.
Goal forall x, utest x -> { b : btest | #bx b = x }.
Proof.
intros x u. exists {| bx := x ; bprop := #uprop x u |}. reflexivity.
Qed.
(* NOTE: Here I’ve explicited all implicit arguments; in fact, you
can let Coq infer them, and write just [bx], [bprop], [uprop]
instead of [#bx b], [#bprop b], [#uprop x u]. *)
In this example, we can also observe a difference with respect to computational relevance: utest can live in Prop, because its only member, uprop, is a proposition. On the other hand, I cannot really put btest in Prop, because that would mean that both bx and bprop would live in Prop but bf is computationally relevant. In other words, Coq gives you this warning:
Class btest : Prop := {
bx : nat;
bprop : bx = 0;
}.
(* WARNING:
bx cannot be defined because it is informative and btest is not.
bprop cannot be defined because the projection bx was not defined.
*)
In the book Concrete Semantics, exercise 2.11 writes:
Define arithmetic expressions in one variable over integers
(type int) as a data type:
datatype exp = Var | Const int | Add exp exp | Mult exp exp
Define a function eval :: exp ⇒ int ⇒ int such that eval e x evaluates e at the value x. A polynomial can be represented as a list of coefficients, starting with the constant. For example, [4, 2, − 1, 3] represents the polynomial 4+2x−x 2 +3x 3 . Define a function evalp :: int list ⇒ int ⇒ int that evaluates a polynomial at the given value. Define a function coeffs :: exp ⇒ int list that transforms an
expression into a polynomial. This may require auxiliary functions. Prove that coeffs preserves the value of the expression: evalp (coeffs e) x = eval e x. Hint: consider the hint in Exercise 2.10.
As a first try, and because former exercises encouraged to write iterative versions of functions, I wrote the following:
datatype exp = Var | Const int | Add exp exp | Mult exp exp
fun eval :: "exp ⇒ int ⇒ int" where
"eval Var x = x"
| "eval (Const n) _ = n"
| "eval (Add e1 e2) x = (eval e1 x) + (eval e2 x)"
| "eval (Mult e1 e2) x = (eval e1 x) * (eval e2 x)"
fun evalp_it :: "int list ⇒ int ⇒ int ⇒ int ⇒ int" where
"evalp_it [] x xpwr acc = acc"
| "evalp_it (c # cs) x xpwr acc = evalp_it cs x (xpwr*x) (acc + c*xpwr)"
fun evalp :: "int list ⇒ int ⇒ int" where
"evalp coeffs x = evalp_it coeffs x 1 0"
fun add_coeffs :: "int list ⇒ int list ⇒ int list" where
"add_coeffs [] [] = []"
| "add_coeffs (a # as) (b# bs) = (a+b) # (add_coeffs as bs)"
| "add_coeffs as [] = as"
| "add_coeffs [] bs = bs"
(there might be some zip function to do this)
fun mult_coeffs_it :: "int list ⇒ int list ⇒ int list ⇒ int list ⇒ int list" where
"mult_coeffs_it [] bs accs zeros = accs"
| "mult_coeffs_it (a#as) bs accs zeros =
mult_coeffs_it as bs (add_coeffs accs zeros#bs) (0#zeros)"
fun mult_coeffs :: "int list ⇒ int list ⇒ int list" where
"mult_coeffs as bs = mult_coeffs_it as bs [] []"
fun coeffs :: "exp ⇒ int list" where
"coeffs (Var) = [0,1]"
| "coeffs (Const n) = [n]"
| "coeffs (Add e1 e2) = add_coeffs (coeffs e1) (coeffs e2)"
| "coeffs (Mult e1 e2) = mult_coeffs (coeffs e1) (coeffs e2)"
I tried to verify the sought theorem
lemma evalp_coeffs_eval: "evalp (coeffs e) x = eval e x"
but could not. Once I got an advice that writing good definitions is very important in theorem proving, though the adviser did not give details.
So, what is the problem with my definitions, conceptually? Please do not write the good definitions but point out the conceptual problems with my definitions.
UPDATE: upon advice I started to use
fun evalp2 :: "int list ⇒ int ⇒ int" where
"evalp2 [] v = 0"|
"evalp2 (p#ps) v = p + v * (evalp2 ps v) "
and looking into src/HOL/Algebra/Polynomials.thy I formulated
fun add_cffs :: "int list ⇒ int list ⇒ int list" where
"add_cffs as bs =
( if length as ≥ length bs
then map2 (+) as (replicate (length as - length bs) 0) # bs
else add_cffs bs as)"
but that did not help much, simp add: algebra_simps or arith did not solve the corresponding subgoal.
Some hints:
Try running quickcheck and nitpick on the Lemma until no more counter example is found. For the Lemma in your question I get the following counter example:
Quickcheck found a counterexample:
e = Mult Var Var
x = - 2
Evaluated terms:
evalp (coeffs e) x = - 10
eval e x = 4
Try to prove some useful Lemmas about your auxiliary functions first. For example:
lemma "evalp (mult_coeffs A B) x = evalp A x * evalp B x"
Read about calculating with polynomials (e.g. https://en.wikipedia.org/wiki/Polynomial_ring) and choose definitions close to what mathematicians do. Although this one might spoil the fun of coming up with a definition on your own.
Let's say we have a function merge that, well, just merges two lists:
Order : Type -> Type
Order a = a -> a -> Bool
merge : (f : Order a) -> (xs : List a) -> (ys : List a) -> List a
merge f xs [] = xs
merge f [] ys = ys
merge f (x :: xs) (y :: ys) = case x `f` y of
True => x :: merge f xs (y :: ys)
False => y :: merge f (x :: xs) ys
and we'd like to prove something clever about it, for instance, that merging two non-empty lists produces a non-empty list:
mergePreservesNonEmpty : (f : Order a) ->
(xs : List a) -> (ys : List a) ->
{auto xsok : NonEmpty xs} -> {auto ysok : NonEmpty ys} ->
NonEmpty (merge f xs ys)
mergePreservesNonEmpty f (x :: xs) (y :: ys) = ?wut
Inspecting the type of the hole wut gives us
wut : NonEmpty (case f x y of True => x :: merge f xs (y :: ys) False => y :: merge f (x :: xs) ys)
Makes sense so far! So let's proceed and case-split as this type suggests:
mergePreservesNonEmpty f (x :: xs) (y :: ys) = case x `f` y of
True => ?wut_1
False => ?wut_2
It seems reasonable to hope that the types of wut_1 and wut_2 would match the corresponding branches of merge's case expression (so wut_1 would be something like NonEmpty (x :: merge f xs (y :: ys)), which can be instantly satisfied), but our hopes fail: the types are the same as for the original wut.
Indeed, the only way seems to be to use a with-clause:
mergePreservesNonEmpty f (x :: xs) (y :: ys) with (x `f` y)
mergePreservesNonEmpty f (x :: xs) (y :: ys) | True = ?wut_1
mergePreservesNonEmpty f (x :: xs) (y :: ys) | False = ?wut_2
In this case the types would be as expected, but this leads to repeating the function arguments for every with branch (and things get worse once with gets nested), plus with doesn't seem to play nice with implicit arguments (but that's probably worth a question on its own).
So, why doesn't case help here, are there any reasons besides purely implementation-wise behind not matching its behaviour with that of with, and are there any other ways to write this proof?
The stuff to the left of the | is only necessary if the new information somehow propagates backwards to the arguments.
mergePreservesNonEmpty : (f : Order a) ->
(xs : List a) -> (ys : List a) ->
{auto xsok : NonEmpty xs} -> {auto ysok : NonEmpty ys} ->
NonEmpty (merge f xs ys)
mergePreservesNonEmpty f (x :: xs) (y :: ys) with (x `f` y)
| True = IsNonEmpty
| False = IsNonEmpty
-- for contrast
sym' : (() -> x = y) -> y = x
sym' {x} {y} prf with (prf ())
-- matching against Refl needs x and y to be the same
-- now we need to write out the full form
sym' {x} {y=x} prf | Refl = Refl
As for why this is the case, I do believe it's just the implementation, but someone who knows better may dispute that.
There's an issue about proving things with case: https://github.com/idris-lang/Idris-dev/issues/4001
Because of this, in idris-bi we ultimately had to remove all cases in such functions and define separate top-level helpers that match on the case condition, e.g., like here.
Is there a provision in any programming language such that we can write (a==b || a==c) as a==(b||c)?
In other words, is == distributive over logical OR in any programming language? (can we write (a==b || a==c) as a==(b||c)).
There are similar constructs in several languages. IN in SQL, in in python, etc, most evaluating lists or arrays. Closest one I know is Haskell's or which has the type [Bool] -> Bool.
As Anton Gogolev said, it's hard to find a good type for b || c, but not entirely impossible.
You may have to define the higher order function (|||) :: forall a . a -> a -> ((a -> Bool) -> Bool) implemented as a (|||) b = \f -> (f x) || (f y) (here \ means the lambda expression).
Now you can use this (b ||| c) (== 42).
Alternatively you could do :
(|||) :: forall a b . a -> a -> (a -> b -> Bool) -> b -> Bool
(|||) x y f b = (f x b) || (f y b)
and now you can do ( a ||| b ) (==) 42
Of course none of the above will work in languages lacking higher order functions. Moreover, Equality (==) must be function and not language construct. (You can get similar effect with Promises, however).
Maybe the above lines give hints why this approach is not commonly used in the wild. :) a in [b,c] is much simpler to use.
EDIT: (for fun sake)
You can use wrapper type to achieve the goal (in Haskell):
data F a = (Eq a) => Fn (a -> (a->a->Bool) -> Bool) | N a
(===) :: Eq a => F a -> F a -> Bool
(Fn f) === (N n) = f n (==)
(N n) === (Fn f) = f n (==)
(N a) === (N b) = a == b
(Fn a) === (Fn b) = error "not implemented"
(|||) :: Eq a => F a -> F a -> F a
N a ||| N b = Fn $ \c f -> (a `f` c) || (b `f` c)
Fn a ||| N b = Fn $ \c f -> a c f || ( b `f` c )
N a ||| Fn b = Fn $ \c f -> b c f || ( a `f` c )
Fn a ||| Fn b = Fn $ \c f -> (a c f) || (b c f)
Now our new (===) is distributive over (|||). Some efforts has been made to keep associative and commutative properties. Now we can have all of the following:
N 1 === N 2
N 3 === ( N 3 ||| N 8 ||| N 5 )
( N 3 ||| N 8 ||| N 5 ) === N 0
N "bob" === ( N "pete" ||| N "cecil" ||| N "max")
N a === ( N 9 ||| N b ||| N c)
Everything will work smoothly. We could replace standard operators and type N with basic types and write 3 == (3 || 8 || 5). What you ask for is not impossible.
The construct is generic, you can easily extend it with something like (>=) :: F a -> F a -> Bool and now you can use ( 100 || 3 || a || b ) >= c. (Please notice that no lists or arrays are used.)
I try to solve with spin the task about the farmer, wolf, goat and cabbage.
So, I found the folowing promela description:
#define fin (all_right_side == true)
#define wg (g_and_w == false)
#define gc (g_and_c == false)
ltl ltl_0 { <> fin && [] ( wg && gc ) }
bool all_right_side, g_and_w, g_and_c;
active proctype river()
{
bit f = 0,
w = 0,
g = 0,
c = 0;
all_right_side = false;
g_and_w = false;
g_and_c = false;
printf("MSC: f %c w %c g %c c %c \n", f, w, g, c);
do
:: (f==1) && (f == w) && (f ==g) && (f == c) ->
all_right_side = true;
break;
:: else ->
if
:: (f == w) ->
f = 1 - f;
w = 1 - w;
:: (f == c) ->
f = 1 - f;
w = 1 - c;
:: (f == g) ->
f = 1 - f;
w = 1 - g;
:: (true) ->
f = 1 - f;
fi;
printf("M f %c w %c g %c c %c \n", f, w, g, c);
if
:: (f != g && g == c) ->
g_and_c = true;
:: (f != g && g == w) ->
g_and_w = true;
::else ->
skip
fi
od;
printf ("MSC: OK!\n")
}
I add there an LTL-formula: ltl ltl_0 { <> fin && [] ( wg && gc ) }
to verify, than the wolf wouldn't eat a goat, and the goat wouldn't eat the cabbage. I want to get an example, how the farmer can transport all his needs (w-g-c) without loss.
When I run verification, I get the following result:
State-vector 20 byte, depth reached 59, errors: 1
64 states, stored
23 states, matched
87 transitions (= stored+matched)
0 atomic steps
hash conflicts: 0 (resolved)
This means that the program has generated an example for me. But I cannot interpret it.
The content of *.pml.trial file is:enter image description here
Please, help me to interpret.
There are a few ways you can go about interpreting the trace.
Use iSpin:
go to Simulate/Play
in Mode, select Guided and enter the name of your trail file
Run
This will show, step by step, the actions taken by each of the processes, including info such as process number, proctype name, line number of instruction executed, code of instruction executed.
Do the same with spin:
Use the command
spin -t -p xyz.pml
Understand the trail file syntax:
each line on the file is one step taken by the simulator.
the first column is just serial numbers.
The second column is process numbers (pids). (eg init will be 0, the first process it starts/runs will be 1 and so on.)
The third column is transition number. If you want to get just an idea of what is happening, you can look at the pids and go over the instructions
In order to "interpret" it, you could modify your source code so that each time an action is taken something intellegibile is printed on stdout.
e.g.:
:: (f == w) ->
if
:: f == 0 -> printf("LEFT ---[farmer, wolf]--> RIGHT\n");
:: f == 1 -> printf("LEFT <--[farmer, wolf]--- RIGHT\n");
:: else -> skip;
fi;
f = 1 - f;
w = 1 - w;
+ something similar for the cases (f == c), (f == g) and (true).
Note: your source code already provides printf("M f %c w %c g %c c %c \n", f, w, g, c);, which can be used to interpret the counter-example if you keep in mind that 0 means left and 1 means right. I would prefer a more verbose tracing, though.
After you have done this for each possible transition, you can see what happens within your counter-example by running spin in the following way
~$ spin -t file_name.pml
The option -t replays the latest trail found by spin upon the violation of some assertion/property.