I dont understand the format of wp printed by wp plugin in frama-c.
An example:
Goal Assertion 'P402926' (file gzip-1.5/deflate.c, line 479):
Let x_0 = Mint_0[(shift match_8 1)].
Let x_1 = Mint_0[(shift scan_16 1)].
Let x_2 = Mint_0[(shift scan_17 1)].
Let a_0 = (global G_window_2513).
Let x_3 = Mint_0[(shift a_0 (1+cur_match_1))].
Let x_4 = Mint_0[scan_17].
Let x_5 = Mint_0[(shift a_0 cur_match_1)].
Assume {
(* Domain *)
Type: (is_sint32 best_len_1) /\ (is_sint32 len_0)
/\ (is_uint32 cur_match_1) /\ (is_uint8 Mint_0[match_0])
/\ (is_uint8 Mint_0[match_1]) /\ (is_uint8 Mint_0[match_2])
/\ (is_uint8 Mint_0[match_3]) /\ (is_uint8 Mint_0[match_4])
/\ (is_uint8 Mint_0[match_5]) /\ (is_uint8 Mint_0[match_6])
/\ (is_uint8 Mint_0[scan_1]) /\ (is_uint8 Mint_0[scan_3])
/\ (is_uint8 Mint_0[scan_5]) /\ (is_uint8 Mint_0[scan_7])
/\ (is_uint8 Mint_0[scan_9]) /\ (is_uint8 Mint_0[scan_11])
/\ (is_uint8 Mint_0[scan_13]) /\ (is_uint8 x_4) /\ (is_uint8 x_0)
/\ (is_uint8 x_1) /\ (is_uint8 x_2) /\ (is_uint8 x_5)
/\ (is_uint16
(* gzip-1.5/deflate.c:453: Else *)
Have: x_4=x_5.
(* gzip-1.5/deflate.c:454: Else *)
Have: x_2=x_3.
(* gzip-1.5/deflate.c:468: Conditional *)
If: x_0=x_1
Then {
(* gzip-1.5/deflate.c:468: Conditional *)
If: Mint_0[(shift match_8 2)]=Mint_0[(shift scan_16 2)]
Then {
(* gzip-1.5/deflate.c:469: Conditional *)
If: Mint_0[(shift match_8 3)]=Mint_0[(shift scan_16 3)]
Then { .....
Many extra variables have been introduced which i dont understand like shift, global,etc, which are not in the program..
Can some one explain?
You can find a brief description of the internal language used by WP for building proof obligations in chapters 3 and 4 of the WP manual. Additionally, the built-in functions and predicates that appear in the formula are defined in the various .why files in $(frama-c -print-share-path)/wp/why3, especially Memory.why which axiomatize all memory-related operations.
To answer your main interrogations:
if-else is here to avoid an exponential blow-up in the number of proof obligations with respect to the number of branches of each function (at the expense of a slightly more complicated formula)
global takes the address of a global. You can see here that a0 is then used as an index in the Mint_0 map (which maps addresses of the form base + offset to values).
shift moves the offset of an address: shift a_0 cur_match_1 refers to the corresponding cell of the window array.
Related
I have a problem with proving assigns after calling other function that assigns until strlen. Below is a simple example with a call to a function from standard library. The function contract is basically a copy from strcpy requirements.
#include <string.h>
/*#
requires valid_string_src: valid_read_string(src);
requires room_string: \valid(dest+(0..strlen(src)));
requires separation:
\separated(dest+(0..strlen(src)), src+(0..strlen(src)));
assigns dest[0..(strlen(src))];
*/
void mycpy(char *dest, const char *src) {
strcpy(dest, src);
}
Frama-c fails to prove assigns for mycpy even though it matches assigns of the strcpy:
Goal Assigns ... (exit):
Let a_0 = « dest#L1 + 0 ».
Let x_0 = L_strlen(µ:Mchar#L1, src#L1).
Let x_1 = 1 + x_0.
Let x_2 = L_strlen(Mchar_0, src#L1).
Assume {
Have: 0 <= x_2.
Type: is_sint8_chunk(µ:Mchar#L1).
(* Heap *)
Type: (region(dest#L1.base) <= 0) /\ (region(src#L1.base) <= 0) /\
linked(µ:Malloc#L1) /\ sconst(µ:Mchar#L1).
(* Goal *)
When: !invalid(µ:Malloc#L1, a_0, 1 + x_2).
Stmt { L1: }
(* Pre-condition *)
Have: P_valid_read_string(µ:Malloc#L1, µ:Mchar#L1, src#L1) /\
valid_rw(µ:Malloc#L1, a_0, x_1) /\
separated(a_0, x_1, « src#L1 + 0 », x_1).
}
Prove: x_2 <= x_0.
--------------------------------------------------------------------------------
Prover Alt-Ergo 2.3.3: Timeout (Qed:6ms) (10s) (cached).
The full context of the goal shows that it tries to prove: L_strlen(Mchar_0, src#L1) <= L_strlen(µ:Mchar#L1, src#L1). However, there is no information about Mchar_0.
What is this µ:Mchar#L1 and Mchar_0? How do I prove this assigns?
Frama-c version: 22.0 (Titanium).
Haskell replaces for loops over iteratable objects with map :: (a -> b) -> [a] -> [b] or
fmap :: (a -> b) -> f a -> f b. (This question isn't limited to Haskell, I'm just using the syntax here.)
Is there something similar that replaces a while loop, like
wmap :: ([a] -> b) -> [a] -> ([b] -> Bool) -> [b]?
This function returns a list of b.
The first argument is a function that takes a list and computes a value that will end up in the list returned by wmap (so it's a very specific kind of while loop).
The second argument is the list that we use as our starting point.
The third argument is a function that evaluates the stoping criteria.
And as a functor,
wfmap :: (f a -> b) -> f a -> (f b -> Bool) -> f b
For example, a Jacobi solver would look like this (with b now the same type as a):
jacobi :: ([a] -> [a]) -> [a] -> ([a] -> Bool) -> [a]
What I'm looking for isn't really pure. wmap could have values that mutate internally, but only exist inside the function. It also has nondeterministic runtime, if it terminates at all.
In the case of a Gauss-Seidel solver, there would be no return value, since the [a] would be modified in place.
Something like this:
gs :: ([a] -> [a]) -> [a] -> ([a] -> Bool) -> ???
Does wmap or wfmap exist as part of any language by default, and what is it called?
Answer 1 (thanks to Bergi): Instead of the silly wmap/wfmap signature, we already have until.
Does an in place version of until exist for things like gs?
There is a proverb in engineering which states "Don't generalize before you have at least 3 implementations". There is some truth to it - especially when looking for new functional iteration concepts before doing it by foot a few times.
"Doing it by foot" here means, you should - if there is no friendly helper function you know of - resort to recursion. Write your "special cases" recursively. Preferably in a tail recursive form. Then, if you start to see recurring patterns, you might come up with a way to refactor into some recurring iteration scheme and its "kernel".
Let's for the sake of clarification of the above, assume you never heard of foldl and you want accumulate a result from iteration over a list... Then, you would write something like:
myAvg values =
total / (length values)
where
mySum acc [] = acc
mySum acc (x:xs) = mySum (acc + x) xs
total = mySum 0 values
And after doing this a couple of times, the pattern might show, that the recursions in those where clauses always look darn similar. You might then come up with a name like "fold" or "reduce" for that inner recursion snippet and end up with:
myAvg values = (foldl (+) 0.0 values) / fromIntegral (length values) :: Float
So, if you are looking for helper functions which help with your use-cases, my advice is you first write a few instances as recursive functions and then look for patterns.
So, with all that said, let's get our fingers wet and see how the Jacobi algorithm could translate to Haskell. Just so we have something to talk about. Now - usually I do not use Haskell for anything requiring arrays (containers with O(1) element access), because there are at least 5 array packages I know of and I would have to read for 2 days to decide which one is suitable for my application. TL;DR;). So I stick with lists and NO package dependencies beyond prelude in the code below. But that is - given the size of the example equations we try to solve is tiny - not a bad thing at all. Plus, the code demonstrates, that list comprehensions in lazy Haskell allow for un-imperative and yet performant operations on sets of cells (e.g. in the matrix), without any need for explicit looping.
type Matrix = [[Double]]
-- sorry - my mind went blank while looking for a better name for this...
-- but it is useful nonetheless
idefix nr nc =
[ [(r,c) | c <- [0..nc-1]] | r <- [0..nr-1]]
matElem m (r,c) = (m !! r) !! c
transpose (r,c) = (c,r)
matrixDim m = (length m, length . head $ m)
-- constructs a Matrix by enumerating the indices and querying
-- 'unfolder' for a value.
-- try "unfoldMatrix 3 3 id" and you see how indices relate to
-- cells in the matrix.
unfoldMatrix nr nc unfolder =
fmap (\row -> fmap (\cell -> unfolder cell) row) $ idefix nr nc
-- Not really needed for Jacobi problem but good
-- training to get our fingers wet with unfoldMatrix.
transposeMatrix m =
let (nr,nc) = matrixDim m in
unfoldMatrix nc nr (matElem m . transpose)
addMatrix m1 m2
| (matrixDim m1) == (matrixDim m2) =
let (nr,nc) = matrixDim m1 in
unfoldMatrix nr nc (\idx -> matElem m1 idx + matElem m2 idx)
subMatrix m1 m2
| (matrixDim m1) == (matrixDim m2) =
let (nr,nc) = matrixDim m1 in
unfoldMatrix nr nc (\idx -> matElem m1 idx - matElem m2 idx)
dluMatrix :: Matrix -> (Matrix,Matrix,Matrix)
dluMatrix m
| (fst . matrixDim $ m) == (snd . matrixDim $ m) =
let n = fst . matrixDim $ m in
(unfoldMatrix n n (\(r,c) -> if r == c then matElem m (r,c) else 0.0)
,unfoldMatrix n n (\(r,c) -> if r > c then matElem m (r,c) else 0.0)
,unfoldMatrix n n (\(r,c) -> if c > r then matElem m (r,c) else 0.0)
)
mulMatrix m1 m2
| (snd . matrixDim $ m1) == (fst . matrixDim $ m2) =
let (nr, nc) = ((fst . matrixDim $ m1),(snd . matrixDim $ m2)) in
unfoldMatrix nr nc
(\(ro,co) ->
sum [ matElem m1 (ro,i) * matElem m2 (i,co) | i <- [0..nr-1]]
)
isSquareMatrix m = let (nr,nc) = matrixDim m in nr == nc
jacobi :: Double -> Matrix -> Matrix -> Matrix -> Matrix
jacobi errMax a b x0
| isSquareMatrix a && (snd . matrixDim $ a) == (fst . matrixDim $ b) =
approximate x0
-- We could possibly avoid our hand rolled recursion
-- with the help of 'loop' from Control.Monad.Extra
-- according to hoogle. But it would not look better at all.
-- loop (\x -> let x' = jacobiStep x in if converged x' then Right x' else Left x') x0
where
(nra, nca) = matrixDim a
(d,l,u) = dluMatrix a
dinv = unfoldMatrix nra nca (\(r,c) ->
if r == c
then 1.0 / matElem d (r,c)
else 0.0)
lu = addMatrix l u
converged x =
let delta = (subMatrix (mulMatrix a x) b) in
let (nrd,ncd) = matrixDim delta in
let err = sum (fmap (\idx -> let v = matElem delta idx in v * v)
(concat (idefix nrd ncd))) in
err < errMax
jacobiStep x =
(mulMatrix dinv (subMatrix b (mulMatrix lu x)))
approximate x =
let x' = jacobiStep x in
if converged x' then x' else approximate x'
wikiExample errMax =
let a = [[ 2.0, 1.0],[5.0,7.0]] in
let b = [[11], [13]] in
jacobi errMax a b [[1.0],[1.0]]
Function idefix, despite it's silly name, IMHO is an eye opener for people coming from non-lazy languages. Their first reflex is to get scared: "What - he creates a list with the indices instead of writing loops? What a waste!" But a waste, it is not in lazy languages. What you see in this function (the list comprehension) produces a lazy list. It is not really created. What happens behind the scene is similar in spirit to what LINQ does in C# - IEnumerator<T> juggling.
We use idefix a second time when we want to sum all elements in our delta. There, we do not care about the concrete structure of the matrix. And so we use the standard prelude function concat to flatten the Matrix into a linear list. Lazy as well, of course. That is the beauty.
The next notable difference to the imperative wikipedia pseudo code is, that using matrix notation is much less complicated compared to nested looping and operating on single cells. Fortunately, the wikipedia article shows both. So, instead of a while loop with 2 nested loops, we only need an equivalent of the outermost while loop. Which is covered by our 2 liner recursive function approximate.
Lessons learned:
Lists and list comprehensions can help simplify code otherwise requiring nested loops. (In lazy languages).
Ocaml and Common Lisp have mutability and built in arrays and loops. That makes a package, very convenient when translating algorithms from imperative languages or imperative pseudo code.
Haskell has immutability and no built in arrays and no loops, but instead it has a similarly powerful set of tools, namely Laziness, tail call optimization and a terse syntax. That combination requires more planning (and writing some usually short helper functions) instead of the classical C approach of "Let's write it all in main()."
Sometimes it is easier to write a 2 line long recursive function than to think about how to abstract it.
In FP, you don't usually try to fit everything "inside the loop." You do one step and pass it on to the next function. There are lots of combinations that are useful in different situations. A common replacement for a while loop is a map followed by a takeWhile or a dropWhile, but there are many other possibilities, up to just plain recursion.
As an exercise to understand recursion by a well-founded relation I decided to implement the extended euclidean algorithm.
The extended euclidean algorithm works on integers, so I need some
well-founded relation on integers. I tried to use the relations in Zwf, but things didn't worked (I need to see more examples). I decided that would easier to map Z to nat with the Z.abs_nat function and then just use Nat.lt as relation. Our friend wf_inverse_image comes to help me. So here what I did:
Require Import ZArith Coq.ZArith.Znumtheory.
Require Import Wellfounded.
Definition fabs := (fun x => Z.abs_nat (Z.abs x)). (* (Z.abs x) is a involutive nice guy to help me in the future *)
Definition myR (x y : Z) := (fabs x < fabs y)%nat.
Definition lt_wf_on_Z := (wf_inverse_image Z nat lt fabs) lt_wf.
The extended euclidean algorithm goes like this:
Definition euclids_type (a : Z) := forall b : Z, Z * Z * Z.
Definition euclids_rec : (forall x : Z, (forall y : Z,(myR y x) -> euclids_type y) -> euclids_type x).
unfold myR, fabs.
refine (fun a rec b => if (Z_eq_dec a 0) then (b, 0, 1)
else let '(g, s, t) := rec (b mod a ) _ a
in (g, t - (b / a) * s, s)
).
apply Zabs_nat_lt. split. apply Z.abs_nonneg. apply Z.mod_bound_abs. assumption.
Defined.
Definition euclids := Fix lt_wf_on_Z _ euclids_rec.
Now let's see if it works:
Compute (euclids 240 46). (* Computation takes a long time and results in a huge term *)
I know that can happen if some definition is opaque, however all my definitions end with Defined.. Okey, something else is opaque, but what?
If is a library definition, then I don't think that would cool to just redefine it in my code.
It seems that my problem is related with this, this other and this too.
I decided to give Program Fixpoint a try, since I never used it. I was surprised to see that I could just copy and paste my program.
Program Fixpoint euclids' (a b: Z) {measure (Z.abs_nat (Z.abs a))} : Z * Z * Z :=
if Z.eq_dec a 0 then (b, 0, 1)
else let '(g, s, t) := euclids' (b mod a) a in
(g, t - (b / a) * s, s).
Next Obligation.
apply Zabs_nat_lt. split. apply Z.abs_nonneg. apply Z.mod_bound_abs. assumption.
Defined.
And even more surprise to see that works just fine:
Compute (euclids' 240 46). (* fast computation gives me (2, -9, 47): Z * Z * Z *)
What is opaque in euclids that is not in euclids' ?
And how to make euclids work?
Okey, something else is opaque, but what?
wf_inverse_image is opaque and so are the lemmas it relies on: Acc_lemma and Acc_inverse_image. If you make these three transparent euclids will compute.
The evidence of well-foundness is basically your parameter you do structural recursion on, so it must be transparent.
And how to make euclids work?
Fortunately, you don't have to roll your own transparent versions of the aforementioned standard definitions as there is well_founded_ltof lemma in Coq.Arith.Wf_nat which is already transparent so we can reuse it:
Lemma lt_wf_on_Z : well_founded myR.
Proof. exact (well_founded_ltof Z fabs). Defined.
That's it! After fixing lt_wf_on_Z the rest of your code just works.
I am doing some exercises on F#, i have this function that calculate the alternate sum:
let rec altsum = function
| [] -> 0
| [x] -> x
| x0::x1::xs -> x0 - x1 + altsum xs;;
val altsum : int list -> int
The exercise consist in declare the same function with only two clauses...but how to do this?
The answer of mydogisbox is correct and work!
But after some attempts I found a smallest and readable solution of the problem.
let rec altsum2 = function
| [] -> 0
| x0::xs -> x0 - altsum2 xs
Example
altsum2 [1;2;3] essentially do this:
1 - (2 - (3 - 0)
it's is a bit tricky but work!
OFF TOPIC:
Another elegant way to solve the problem, using F# List library is:
let altsum3 list = List.foldBack (fun x acc -> x - acc) list 0;;
After the comment of phoog I started trying to solve the problem with a tail recursive function:
let tail_altsum4 list =
let pl l = List.length l % 2 = 0
let rec rt = function
| ([],acc) -> if pl list then -acc else acc
| (x0::xs,acc) -> rt (xs, x0 - acc)
rt (list,0)
This is also a bit tricky...substraction is not commutative and it's impossible think to revers with List.rev a long list...but I found a workaround! :)
To reduce the number of cases, you need to move your algorithm back closer to the original problem. The problem says to negate alternating values, so that's what your solution should do.
let altsum lst =
let rec altsumRec lst negateNext =
match lst with
| [] -> 0
| head::tail -> (if negateNext then -head else head) + altsumRec tail (not negateNext)
altsumRec lst false
I have the following implementation for a binary tree and a depth function to calculate its depth:
type 'a btree =
| Empty
| Node of 'a * 'a btree * 'a btree;;
let rec depth t = match t with
| Empty -> 0
| Node (_, t1, t2) -> 1 + Int.max (depth t1) (depth t2)
The problem here is that "depth" is recursive and can cause a stack overflow when the tree is too big.
I read about tail recursion and how it can be optimised into a while loop by the compiler to remove the stack call.
How would you make this function tail recursive or make it use a while/for loop instead?
type 'a btree =
| Empty
| Node of 'a * 'a btree * 'a btree;;
let max x y = if x > y then x else y
let depth t =
let rec dep m = function (* d records current level, m records max depth so far *)
| [] -> m
| (Empty,d)::tl -> dep (max m d) tl
| (Node (_,l,r),d)::tl -> dep (max m d) ((l,d+1)::(r,d+1)::tl)
in
dep 0 [(t,0)]
Basically, you need 3 things:
a list (stack) to store nodes along the paths
a indicator to record the current depth
the current max depth so far
Whenever we face a problem that needs to remove the possible stackoverflow problem, we should think two things: tail-recursive and explicit stack.
For tail-recursive, you have to find a way to explicitly store the temporary data generated through each recursion step.
For explicit stack, remember the reason that recursion can work is because internally it uses a stack with a limited size. If we analyse the logic and make that stack explicit, we then don't need that internal stack any more.
In pragmatic cases the solution is to use a balanced tree, which limits the depth to some multiple of log(n). Even for very large n, log(n) is small enough that you won't run out of stack space.
Otherwise see the SO page linked by Kadaku. It has ridiculously good answers to the question.
I already answered similar question once. Reposting the solution:
There's a neat and generic solution using fold_tree and CPS - continuous passing style:
let fold_tree tree f acc =
let loop t cont =
match tree with
| Leaf -> cont acc
| Node (x, left, right) ->
loop left (fun lacc ->
loop right (fun racc ->
cont ## f x lacc racc))
in loop tree (fun x -> x)
let depth tree = fold_tree tree (fun x dl dr -> 1 + (max dl dr)) 0