CS195Y Lecture 32
4/24/17
SMT (2)
Debugging in Rosette
(define anint integer?)
(current-bitwidth #f)
(define (f x)
(cond
[(< x 0) (-x 5)]
[(>= x 0) (* X -1)]))
(verify (assert(< (f anint)2 )))
(verify (assert(< (f anint)2 )))
Wouldn't it be cool if we had a way to see right away what the bug in this model is? Figuring out
where we went wrong can be a lot of work and we want get there faster! But how?
We can use the debugger!
(define anint integer?)
(current-bitwidth #f)
(define/debug (f x)
(cond
[(< x 0) (-x 5)]
[(>= x 0) (* X -1)]))
(verify (assert(< (f anint)2 )))
(verify (assert(< (f anint)2 )))
(define c (debug [integer?] (assert (> (f-1) 2))))
render(c)
And now when we run we get the definition of f with the issues highlighted. Now we know exactly where we need to look!
Remember the day that Tim was a little bit off with that really big constant? What if we could fix that problem using the debugger?
Let's add in a debug line:
(define c (debug [integer?] (assert (= (mypolynomial -32320) (factored -32320)))))
Here we get a core. It shows a bunch of different issues. Would it be possible for it to pinpoint the constant issue? Unfortunatly, no.
The takeaway: you can get a lot out of cores if they are integerated with your programming languages but you can't get everything.
Could we synthesize the value that goes there?
(define (almostpoly x) (+ (* X X) (* -198 x) (??)))
(current-bitwidth 32)
(synthesize #: forall (list anint)
#: guarantee (assert (= (almostpoly anint) (factored anint))))
It gives us -39483 right away!
Measure and Binary Search
bsearch(A, x):
ans = -1
l = 0
r = len(A) -1
while l <= r and ans == -1:
m = (l + r) /2
if A[m] == x:
ans = m
elif A[m] < x:
l = m+1
elif A[m] > x:
r = m - 1
return ans
Loop invariant: something that stays the same for each iteration of a loop
Loop variant: something that changes (hopefully in a controlled manner) for each iteration of a loop
On the board:
for x: 1 to N
print "Hi!"
Measure = N-x
Measure is just a loop variant that lets you argue about termination.