@@ -782,7 +782,7 @@ as a vector of 64 propositional variables, say `fac`<sub>0</sub> to
782
782
` fac ` <sub >63</sub >, where
783
783
` fac ` = 2<sup >63</sup > ` fac ` <sub >63</sub > + ... + 2<sup >0</sup > ` fac ` <sub >0</sub >.
784
784
We can then assert that ` fac ` =1 using
785
- the propsitional formula
785
+ the propositional formula
786
786
` fac ` <sub >63</sub > = 0 and ... and ` fac ` <sub >1</sub > = 0 and ` fac ` <sub >0</sub > = 1,
787
787
where we define the formula A = B as ''(A and B) or ((not A) and (not B))''.
788
788
@@ -855,7 +855,7 @@ abbreviation for a moderately complex formula on bit vectors!
855
855
From the semantics of the `return` instruction, we know that this program will
856
856
return the value `a+b`, so we can describe its behavior as return = A+B.
857
857
858
- Let us consider a slighly more complex program.
858
+ Let us consider a slightly more complex program.
859
859
```C
860
860
int calculate(int x)
861
861
{
@@ -991,7 +991,7 @@ their behavior using a finite propositional formula in the way we have
991
991
done above.
992
992
993
993
There are multiple approaches to deal with this problem, all with different
994
- trade-offs. CPROVER chooeses bounded model checking as the underlying approach.
994
+ trade-offs. CPROVER chooses bounded model checking as the underlying approach.
995
995
The idea is that we only consider program
996
996
executions that are, in some measure, ''shorter'' than a given bound. This bound
997
997
then implies an upper bound on the size of the required formulas, which makes
0 commit comments