XSat: A Fast FloatingPoint Satisfiability Solver
 9 Citations
 1.4k Downloads
Abstract
The Satisfiability Modulo Theory (SMT) problem over floatingpoint arithmetic is a major hurdle in applying SMT techniques to realworld floatingpoint code. Solving floatingpoint constraints is challenging in part because floatingpoint semantics is difficult to specify or abstract. Stateoftheart SMT solvers still often run into difficulties when solving complex, nonlinear floatingpoint constraints.
This paper proposes a new approach to SMT solving that does not need to directly reason about the floatingpoint semantics. Our insight is to establish the equivalence between floatingpoint satisfiability and a class of mathematical optimization (MO) problems known as unconstrained MO. Our approach (1) systematically reduces floatingpoint satisfiability to MO, and (2) solves the latter via the Monte Carlo Markov Chain (MCMC) method.
We have compared our implementation, XSat, with MathSat, Z3 and Coral, stateoftheart solvers that support floatingpoint arithmetic. Evaluated on 34 representative benchmarks from the SMTCompetition 2015, XSat significantly outperforms these solvers. In particular, it provides both 100 % consistent satisfiability results as MathSat and Z3, and an average speedup of more than 700X over MathSat and Z3, while Coral provides inconsistent results on 16 of the benchmarks.
Keywords
Monte Carlo Markov Chain Minimum Point Mathematical Optimization Symbolic Execution Satisfiability Modulo Theory1 Introduction
Floatingpoint constraint solving has received much recent attention to support the testing and verification of programs that involve floatingpoint computation. Existing decision procedures, or Satisfiability Modulo Theory (SMT) solvers, are usually based on the DPLL(T) framework [19, 33], which combines a Boolean satisfiability solver (SAT) for the propositional structure of constraints and a specialized theory solver. These decision procedures can cope with logical constraints over many theories, but since they are bitlevel satisfiability solvers (SAT), their theoryspecific SMT components can run into difficulties when dealing with complex, nonlinear floatingpoint constraints.
This work proposes a new approach for solving floatingpoint satisfiability. Our approach does not need to directly reason about floatingpoint semantics. Instead, it transforms a floatingpoint constraint to a floatingpoint function that represents the models of the constraint as its minimum points. This “representing function” is similar to fitness functions used in searchbased testing in the sense both reduce a search problem to a function minimization problem [30]. However, unlike searchbased testing, which uses fitness functions as heuristics, our approach uses the representing function as an essential element in developing precise, systematic methods for solving floatingpoint satisfiability.
It is a common need to minimize/maximize scalar functions in science and engineering. The research field dedicated to the subject is known as mathematical optimization (MO) [17]. MO works by iteratively evaluating its objective function, i.e., the function that MO attempts to minimize. In other words, the representing function allows the transformation of an SMT problem to an MO problem, which enables floatingpoint constraint solving by only executing its representing function, without the need to directly reason about floatingpoint semantics—a key benefit of such an SMTMO problem reduction.
Note, however, that an MO formulation of the SMT problem does not, by itself, provide a panacea to SMT solving, since many MO problems are themselves intractable. However, efficient algorithms have been successfully applied to difficult MO problems. A classic example is the traveling salesman problem. The problem is NPhard, but has been nicely handled by simulated annealing [26], a stochastic MO technique. Another example is the Monte Carlo Markov Chain method (MCMC) [9], which has been successfully applied in testing and verification [12, 18, 38].
The insight of this work is that, if we carefully design the representing functions so that certain rules are respected, we can reduce floatingpoint constraint solving to a category of MO problems known as unconstrained MO that can be efficiently solved. Thus, our highlevel approach is: (1) systematically transform a floatingpoint constraint in conjunctive normal format (CNF) to its representing function, and (2) adapt MCMC to minimize the representing function to output a model of the constraint or report unsat.
We have compared our implementation, XSat, with Z3 [16], MathSat [14], and Coral [39], three solvers that can handle floatingpoint arithmetic. Our evaluation results on 34 representative benchmarks from the SMTCompetition 2015 show that XSat significantly outperforms these solvers in both correctness and efficiency. In particular, XSat provides 100 % consistent satisfiability results as MathSat and Z3, and an average speedup of more than 700X over MathSat and Z3, while Coral provides inconsistent results on 16 of the 34 benchmarks.

We show, via the use of representing functions, how to systematically reduce floatingpoint constraint solving to a class of MO problems known as unconstrained MO;

We establish a theoretical guarantee for the equivalence between the original floatingpoint satisfiability problem and the class of MO problems.

We realize our approach in the XSat solver and show empirically that XSat significantly outperforms the stateoftheart solvers.
The rest of the paper is organized as follows. Section 2 gives an overview of our approach, and Sect. 3 presents its theoretical underpinning. Section 4 presents the algorithm design of the XSat solver, while Sect. 5 describes its overall implementation and our evaluation of XSat. Finally, Sect. 6 surveys related work, and Sect. 7 concludes.
2 Approach Overview
This section presents a highlevel overview of our approach. Its main goal is to illustrate, via examples, that (1) it is possible to reduce a floatingpoint satisfiability problem to a class of mathematical optimization (MO) problems, and (2) efficient solutions exist for solving those MO problems.
2.1 Preliminaries on Mathematical Optimization
MO techniques can be divided into two categories. One focuses on how functions are shaped at local regions and where a local minimum can be found near the given inputs. This local optimization is classic, involving techniques dated back to the 17th century (e.g., Newton’s approach or gradientbased search). Local optimization not only provides the minimum value of a function within a neighborhood of the given input points, but also aids global optimization, another, more active body of research, which determines the minimum value of a function over an entire search space.
Let f be a function over a metric space with d as its distance. We call \(x^*\) a local minimum point if there exists a neighborhood of \(x^*\), namely \(\{x \mid d(x,x^*) < \delta \}\) for some \(\delta >0\), so that all x in the neighborhood satisfy \(f(x)\ge f(x^*)\). The value of \(f(x^*)\) is called the local minimum of the function f. If \(f(x^*)\le f(x)\) for all \(x\in S\), we call \(f(x^*)\) the global minimum of the function f, and \(x^*\) a global minimum point.
In this presentation, if we say minimum (resp. minimum point), we mean global minimum (resp. global minimum point). It should be clear that a function may have more than one minimum point but only one minimum.
2.2 From SMT to Unconstrained Mathematical Optimization
2.3 Efficiently Solve MO Problems via MCMC
In this paper, we use a Monte Carlo Markov Chain (MCMC) method [9] as a general approach for unconstrained MO problems. MCMC is a random sampling technique used to simulate a target distribution. Consider, for example, the target distribution of coin tossing, with 0.5 probability for having the head or tail. An MCMC sampling is a sequence of random variables \(x_1\),..., \(x_n\), such that the probability of \(x_n\) being “head”, denoted by \(P_n\), converges to 0.5, i.e., \(\lim _{n\rightarrow \infty }P_n=0.5\). The fundamental fact regarding MCMC sampling can be summarized as the lemma below [9]. For simplicity, we only show the result with discretevalued probabilities here.
Lemma 1
Why do we adopt MCMC? There are multiple advantages. First, the search space in our problem setting involves floatingpoint values. Even in the onedimensional case, a very small interval contains a large number of floatingpoint numbers. MCMC is known as an effective technique to deal with large search spaces. Because MCMC samples follow the distribution asymptotically, it can be configured so that the sampling process has more chance to attain the minimum points than the others (by sampling for a target distribution based on \(\lambda x: \exp ^{f(x)}\) for example, where f is the function to minimize). Second, MCMC has many mature techniques and implementations that integrate well with classic local search techniques. These implementations have proven efficient for realworld problems with a large number of local minimum points, and can even handle functions beyond classic MO, e.g., discontinuous objective functions. Other MO techniques, e.g., genetic programming, may also be used for our problem setting, which we leave for future investigation.
3 Technical Formulation
This section presents the theoretical underpinning of our approach. We write \(\mathbbm {F}\) for the set of floatingpoint numbers. Given a function f, we call x a zero of f if \(f(x)=0\).
Let \(\pi \in FP \) be a constraint with variables \(X_1,\cdots , X_N\). We write \(\mathsf {dom}(\pi ) \) for the value domain of its variables. Usually, \(\mathsf {dom}(\pi ) =\mathbbm {F}^N\). We say a vector of floatingpoint numbers \((x_1,\cdots ,x_N)\) is a model of \(\pi \), denoted by \((x_1,\cdots ,x_N)~\models \pi \), if \(\pi \) becomes a tautology by substituting \(X_i\) with the corresponding \(x_i\) for all \(i\in [1,N]\). In the following, we shall use a metavariable x for a vector of floatingpoint numbers \((x_1,\cdots , x_N)\).
As mentioned in Sect. 1, our idea is to derive from \(\pi \) a floatingpoint program that represents how far a floatingpoint input, i.e., \((x_1,\cdots , x_N)\), is from being a model of \(\pi \). We specify this program as below:
Definition 1

R1. \(\mathtt {R}(x)\ge 0\) for all \(x\in \mathsf {dom}(\pi ) \),

R2. Every zero of \(\mathtt {R}\) is a model of \(\pi \): \(\forall x\in \mathsf {dom}(\pi ), \mathtt {R}(x)=0\implies x\models \pi \), and

R3. The zeros of \(\mathtt {R}\) include all models of \(\pi \): \(\forall x\in \mathsf {dom}(\pi ), x\models \pi \implies \mathtt {R}(x)=0\).
The concept of representing functions allows us to establish an equivalence between the floatingpoint satisfiability problem and an MO problem. This is shown in the theorem below:
Theorem 1
Proof
Let \(x^*\) be an arbitrary global minimum point of \(\mathtt {R}\). If \(\pi \) is satisfiable with x being one of its models, then we have \(\mathtt {R}(x)=0\) by R3. By R1, x is also a global minimum point of \(\mathtt {R}\). Thus \(\mathtt {R}(x^*)=\mathtt {R}(x)=0\) since at most one global minimum exists. The proof for the “\(\Leftarrow \)” part follows directly from R2.
Lemma 2
Let \(\pi \) be a floatingpoint constraint of \( FP \). Procedure P has the following two properties: (1) Soundness: If procedure P reports sat, \(\pi \) is necessarily satisfiable, and (2) Incompleteness: Procedure P may incorrectly report unsat when \(\pi \) is actually satisfiable. This case happens if the MO tool at step P2 calculates a wrong global minimum point.
In the next section, we present XSat, a solver that realizes procedure P. As we will show in Sect. 5, by carefully designing the representing function, the incompleteness in theory can be largely mitigated in practice.
4 The XSat Solver
This section presents the algorithmic design of XSat, an SMT solver to handle quantifierfree floatingpoint constraints. XSat is an instance of Procedure P (Sect. 3).
Notation. Given a set A, we write A to denote its cardinality. We adopt C’s ternary operator “\(p\ ?\ a\ :\ b\)” to denote a code fragment that evaluates to a if p holds, or b otherwise. As in the previous section, we use \(\mathbbm {F}\) for the set of floatingpoint numbers, and \( FP \) for the language of quantifierfree floatingpoint constraints that we have defined.
Lemma 3
Given \(\pi ,\pi ' \in FP \) such that \(\pi \Leftrightarrow \pi '\) (logical equivalence), any representing function of \(\pi \) is also a representing function of \(\pi '\).
Now, we can define \(\mathtt {R}_{x\ge y}\) as \(\mathtt {R}_{y\le x}\), \(\mathtt {R}_{x==y}\) as \(\mathtt {R}_{x\ge y \wedge x\le y}\). For the strict inequalities, we use the notation \(x^\) for the largest floating point that is strictly smaller than x, and reduce \(\mathtt {R}_{x<y}\) to \(\mathtt {R}_{x\le y^}\), \(\mathtt {R}_{x>y}\) to \(\mathtt {R}_{y<x}\), and \(\mathtt {R}_{x\ne y}\) to \(\mathtt {R}_{x<y\vee x>y}\). We summarize the representing function used in XSat in the theorem below:
Theorem 2
Discussion. The example above illustrates that XSat is executionbased—XSat executes the function (22) (so to minimize it) rather than analyzing the semantics of the logic formula (21). While this feature allows XSat to handle floatingpoint formulas that are difficult for traditional solvers, it also implies that XSat may be affected by floatingpoint inaccuracy: Let \(\mathtt {R}\) be the representing function and \(x^{*}\) be its minimal point. Imagine that \(\mathtt {R}(x^*) > 0\) but the calculating \(\mathtt {R}(x^{*})\) incorrectly gives 0 due to a truncation error. Then, XSat reports sat for an unsatisfiable formula. To overcome this issue, we test the original constraint to confirm the satisfiability (Sect. 5.1). Also, we have designed XSat’s representing function using \( \theta \) to sense small perturbations when calculating \(\mathtt {R}\). In the literature of searchbased algorithms [28, 30], fitness functions have been proposed based on an absolutevalue norm or Euclidean distance. They are valid representing functions in the sense of R1–3, but may trigger floatingpoint inaccuracies.
5 Experiments
5.1 Implementation
As a proofofconcept demonstration, we have implemented XSat as a research prototype. Our implementation is written in Python and C. It is composed of two building blocks.
(B1). The frontend uses Z3’s parser_smt_file API [8] to parse an SMT2Lib file to its syntax tree representation, which is then transformed to a representing function following Lines 7–15 and Line 1 of Algorithm 1. The transformed program is compiled by Clang with optimization level O2 and invoked via Python’s C extension.
(B2). The backend uses an implementation of a variant of MCMC, known as Basinhopping, taken from the scipy.optimize library of Python [6]. This MCMC tool has multiple options, including notably (1) the number of MonteCarlo iterations and (2) the local optimization algorithm. These options are used in Algorithm 1 as the input parameters \(\mathtt {iter} \) and \({\mathtt {LM}}\) respectively. In the experiment, we set \(\mathtt {iter} = 100\) and \({\mathtt {LM}} =\) “Powell” (which refers to Powell’s algorithm [36]). To ensure that XSat does not returns sat yet the formula is unsatisfiable, we have used Z3’s frontend to check XSat’s calculated model.
The XSat solver does not yet support all floatingpoint operations that are specified in the SMTLIB 2 standard [37]. The floatingpoint operators currently supported by XSat mainly include the common arithmetic operations: fp.leq, fp.lt, fp.geq, fp.gt, fp.eq, fp.neg, fp.add, fp.mult, fp.sub and fp.div. To extend XSat with other operators such as fp.min, fp.max, fp.abs and fp.sqrt, etc. should be straightforward since they can be directly translated into arithmetic expressions. XSat currently only accepts the rounding mode RNE (round to nearest). Other rounding modes can be easily supported in the frontend by setting appropriate floatingpoint flags in the C program. For example, the rounding mode RTZ (round toward zero) can be realized by introducing Open image in new window in the representing function. The unsupported features listed above do not occur in the tested floatingpoint benchmarks (see below).
It is worth noting that, as mentioned in Sect. 4, XSat has the potential to handle floatingpoint constraints beyond the current SMT2LIB’s specification, because interpreted functions, such as trigonometric functions or any userdefined functions, can be readily implemented by translating them to their corresponding C implementations. An illustrative example of dealing with the sine function is given in Sect. 4.
5.2 Experimental Setup
 (1)
<=10K in file size: 131 SMT2 files
 (2)
11K – 20K in size: 34 SMT2 files
 (3)
>20K in size: 49 SMT2 files
We have run XSat on all these benchmarks. This section presents our experiments on (2). We include our experimental results on (1) and (3) in Appendices A and B.
Compared FloatingPoint Solvers. We have compared XSat with MathSat, Z3 and Coral, stateoftheart solvers that are freely available online. MathSat and Z3 competed in the QF_FP (quantifierfree floatingpoint) track of the 2015 SMT Competition (SMTCOMP) [7]. The Coral solver was initially used in symbolic execution. It uses a search based approach to solve path constraints [25]. Unlike MathSat or Z3, Coral does not directly support the SMT2 language. Thus, we have transformed the benchmarks in the SMT2 language to the input language of Coral [3].
For each solver, we use its default setting for running the benchmarks. All experiments were performed on a laptop with a 2.6 GHz Intel Core i7 and 16 GB RAM running MacOS 10.10.

Correctness testing: For each benchmark, we run all solvers and check the consistency of their satisfiability results. MathSat’s result is used as the reference because the selected benchmarks are initially used and provided by the MathSat developers.

Efficiency testing: For each benchmark, we run all solvers with 48 h as the timeout limit. The time is wall time measured by the standard Unix command “time”.
5.3 Quantitative Results
Comparison of MathSat, Z3, Coral and XSat on the SMTCompetition 2015 benchmarks proposed by Griggio, of file sizes 11K20K.
Benchmark  Satisfiability  Time (seconds)  

SMT2LIB program  size(byte)  #var  MathSat  Z3  Coral  XSat  MathSat  Z3  Coral  XSat 
div2.c.30  11430  32  sat  sat  sat  131.73  14633.28  2.43  7.41  
mult1.c.30  11478  33  sat  sat  sat  293.28  14.55  1.37  0.80  
div3.c.30  11497  33  sat  sat  sat  139.30  212.68  1.37  0.76  
div.c.30  11527  33  sat  sat  sat  90.75  140.09  1.37  0.75  
mult2.c.30  11567  34  sat  sat  sat  358.77  12.87  1.39  0.77  
test_v7_r7_vr10_c1_s24535  14928  7  sat  sat  sat  sat  35.27  85.56  0.78  0.77 
test_v5_r10_vr5_c1_s13195  15013  5  sat  sat  sat  sat  160.30  260.32  0.54  0.76 
div2.c.40  15060  42  sat  sat  sat  419.57  6011.65  3.38  11.90  
mult1.c.40  15088  43  sat  sat  sat  726.95  31.88  1.57  0.83  
test_v7_r7_vr1_c1_s24449  15090  7  unsat  unsat  unsat  unsat  359.42  669.88  1.34  3.93 
div3.c.40  15117  43  sat  sat  sat  sat  301.53  226.78  0.92  0.80 
div.c.40  15157  43  sat  sat  sat  290.41  375.42  1.57  0.79  
mult2.c.40  15177  44  sat  sat  sat  1680.93  30.03  1.59  0.77  
test_v7_r7_vr5_c1_s3582  15184  7  sat  sat  sat  sat  101.78  78.10  0.55  0.83 
test_v7_r7_vr1_c1_s22845  15273  7  sat  sat  sat  sat  138.76  2619.23  0.72  0.78 
test_v7_r7_vr5_c1_s19694  15275  7  sat  sat  sat  sat  705.91  20862.74  0.64  0.86 
test_v7_r7_vr5_c1_s14675  15277  7  sat  sat  sat  sat  66.90  227.70  0.53  0.76 
test_v7_r7_vr10_c1_s32506  15277  7  sat  sat  sat  sat  291.32  1401.88  0.74  0.96 
test_v7_r7_vr10_c1_s10625  15277  7  sat  sat  sat  sat  2971.82  1335.51  0.53  0.76 
test_v7_r7_vr1_c1_s4574  15279  7  sat  sat  sat  sat  90.80  2381.56  0.80  0.77 
test_v5_r10_vr5_c1_s8690  15393  5  unsat  unsat  unsat  unsat  264.36  563.48  1.37  1.58 
test_v5_r10_vr1_c1_s32538  15393  5  unsat  unsat  unsat  unsat  38.88  153.65  1.35  2.22 
test_v5_r10_vr5_c1_s13679  15395  5  sat  sat  sat  256.88  1748.58  1.36  0.76  
test_v5_r10_vr10_c1_s15708  15395  5  unsat  unsat  unsat  unsat  3586.89  9099.97  1.35  1.89 
test_v5_r10_vr10_c1_s7608  15400  5  unsat  unsat  unsat  unsat  2098.50  4941.08  1.36  1.89 
test_v5_r10_vr1_c1_s19145  15486  5  sat  sat  sat  sat  125.61  190.75  0.88  0.76 
test_v5_r10_vr1_c1_s13516  15488  5  sat  sat  sat  sat  107.16  89.15  0.89  0.76 
test_v5_r10_vr10_c1_s21502  15488  5  unsat  unsat  unsat  unsat  1810.06  4174.55  1.35  2.00 
sin2.c.10  17520  37  sat  >48h  crash  sat  43438.34  timeout  crash  26.64 
div2.c.50  18755  52  sat  sat  sat  972.07  1803.04  4.57  15.81  
mult1.c.50  18757  53  sat  sat  sat  2742.47  61.49  1.71  1.32  
div3.c.50  18798  53  sat  sat  sat  350.13  473.64  1.72  0.99  
mult2.c.50  18848  54  sat  sat  sat  2890.08  106.22  1.71  0.96  
div.c.50  18849  53  sat  sat  sat  464.64  554.38  1.70  0.97  
SUMMARY    100.0 %  54.6 %  100.0 %  2014.75  2290.05  1.38  2.80 
Correctness. We sort the 34 benchmark programs by size in Table 1 (Col. 12), show each benchmark’s number of variables (Col. 3) and report its satisfiability result (Col. 4–7). As mentioned above, MathSat’s satisfiability results (Col. 4) are used as the reference. It shows that Z3 provides consistent results except for the benchmark sin.2.c.10, for which it times out after 48 h. Coral cannot solve 15 of the benchmarks with the wrong results marked by a framed box. For the benchmark sin2.c.10, Coral crashes due to an internal error (java.lang.NullPointerException).^{5} Col. 7 shows the results of XSat, which is 100 % consistent compared with MathSat. We have summarized the correctness ratio for each solver on the last row of the table: 100 % for Z3,^{6} 54.6 % for Coral,^{7} and 100 % for XSat.
Efficiency. Table 1 also reports the time used by the solvers (the last four columns). Both Z3 and Mathsat show large performance variances over different benchmarks. Some of the benchmarks take very long time, such as sin.2.c.10 for MathSat, which takes 43438.34 s (> 12 h) or test_v7_r7_vr5_c1_s19694 for Z3, which takes 20862.74 s. On average, both MathSat and Z3 need more than 2,000 s (shown in the last row of the table).^{8} By contrast, Coral and XSat (the last two columns) perform significantly better than MathSat or Z3. Both can finish most benchmarks within seconds. On average, Coral requires 1.38 s, which is less than XSat (2.80 s). Note that Coral only obtains accurate satisfiability results on 54.6 % of the benchmarks.
Appendices A and B list our experimental results of XSat versus Z3 and Mathsat on the rest of Griggio’s benchmarks. Similar to Table 1, the results in Tables 2 and 3 show an important performance improvement of XSat over MathSat and Z3. Note that on five of the listed benchmarks, XSat reports unsat while MathSat and Z3 report sat. We have recognized such incompleteness in Lemma 2. Thus, although XSat has achieved significantly better results than the other evaluated solvers, it is generally unable to prove unsat, while Z3 and MathSat can. Therefore, XSat does not compete, but rather complements these solvers.
6 Related Work
The study on floatingpoint theory is relatively sparse compared to other theories. Eager approaches encode floatingpoint constraints as propositional formulas [15, 35], relying on a SAT solver as the backend; the lazy approaches, on the other hand, use a propositional CDCL solver [24] to reason about the Boolean structure and an adhoc floatingpoint procedures for theory reasoning. The issues of these decision procedures are wellknown: The eager approaches may produce large propositional encoding, which can be a considerable time burden for the worstcase exponential SAT solvers, while the lazy approaches may have difficulties to deal with nontrivial numerical (e.g., nonlinear) operations that are frequent in realworld floatingpoint code. Although, we have seen active development and enhancement for these solutions, such as the mixed abstractions [11], theorybased heuristics [22], or the natural domain SMT [23], stateoftheart floatingpoint decision procedures still face performance challenges.
The idea of using numerical methods in program reasoning has been explored. As an example, the SMTsolver dReal [20] combines numerical search with logical techniques for solving problems that can be encoded as firstorder logic formulas over the real numbers. There is also a body of work on symbolic and numerical methods [28, 31, 32] for test generation in scientific programs.
Perhaps the closely related work to XSat is the Coral solver [10, 39]. It involves mostly heuristicbased fitness functions integrated in symbolic execution [25], which has been successfully integrated in Java Pathfinder [5]. However, to the best of our knowledge, it has not seen much adoption. Compared to XSat, Coral does not provide a precise and systematic solution for using mathematical optimization in solving floatingpoint constraints.
7 Conclusion
We have introduced XSat, a floatingpoint satisfiability solver that is grounded on the concept of representing functions. Given constraint \(\pi \) and program \(\mathtt {R}\) such that R13 hold, the theoretical guarantee of Theorem 1 stipulates that the problem of deciding \(\pi \) can be equivalently solved via minimizing \(\mathtt {R}\) and checking whether \(\mathtt {R}(x^*) = 0\) where \(x^*\) is a global minimum point of \(\mathtt {R}\).
The key challenge of such an approach lies in minimizing the representing function \(\mathtt {R}\), which involves an unconstrained mathematical optimization problem. While many MO problems are intractable, our sight is that carefully designed representing functions can lead to MO problems efficiently solvable in practice. We have implemented the XSat solver to empirically validate our theory. XSat systematically transforms quantifierfree floatingpoint formulas into representing functions, and minimizes them via MCMC methods. We have compared XSat with the stateoftheart floatingpoint solvers, MathSat, Z3 and Coral. Evaluated on benchmarks taken from the SMTCompetition 2015, XSat is shown to significantly outperform these solvers.
Footnotes
 1.
The term “representing function” in English should first appear in Kleene’s book [27], where the author used it to define recursive functions. “Representing function” is also called “characteristic function” or “indicator function” in the literature.
 2.
For example, it is common practice to transform a constrained MO problem by replacing its constraints with penalized terms in the objective function and to solve the problem as an unconstrained MO [34].
 3.
In a general MetropolisHasting algorithm, in the case of \(f(x^*)>f(x)\), \(x^*\) is to be accepted with the probability of \(\exp ( \frac{f(x^*)f(x)}{T})\), where T is the “annealing temperature” [26]. Our algorithm sets \(T=1\) for simplicity.
 4.
Griggio initially used these benchmarks for comparing MathSat and Z3 [23].
 5.
More precisely, our JVM reports errors at coral. util. visitors. adaptors. TypedVisitorAdaptor. visitSymBoolOperations (TypedVisitorAdaptor.java: 94). We are unsure whether this is due to bugs in Coral or our misusing it.
 6.
The benchmark that Z3 times out on, sin2.c.10, is not included in calculating Z3’s correctness.
 7.
The one that Coral crashes on, sin2.c.10, is not included when calculating Coral’s correctness.
 8.
The one that Z3 times out on, sin2.c.10, is omitted in calculating Z3’s performance.
 9.
The benchmarks that Z3 or MathSat timeouts are not included when measuring their mean times (the last row of Table 2).
Notes
Acknowledgments
We thank the anonymous reviewers for their useful comments on earlier versions of this paper. Our special thanks go to Viktor Kuncak for his thoughtful feedback. This work was supported in part by NSF Grant No. 1349528. The information presented here does not necessarily reflect the position or the policy of the Government and no official endorsement should be inferred.
References
 1.Benchmarks of the QF_FP track in SMTCOMP (2015). http://www.cs.nyu.edu/~barrett/smtlib/QF_FP_Hierarchy.zip. Accessed 29 Jan 2016
 2.Boost c++ libraries. www.boost.org/. Accessed 27 Jan 2016
 3.Coral input language. http://pan.cin.ufpe.br/coral/InputLanguage.html. Accessed 24 Jan 2016
 4.The GNU C library (glibc). https://www.gnu.org/software/libc/. Accessed 28 Jan 2016
 5.The main page for Java Pathfinder. http://babelfish.arc.nasa.gov/trac/jpf. Accessed 29 Jan 2016
 6.Scipy optimization package. http://docs.scipy.org/doc/scipydev/reference/optimize.html#modulescipy.optimize. Accessed 29 Jan 2016
 7.SMTCOMP (2015). http://smtcomp.sourceforge.net/2015/. Accessed 24 Jan 2016
 8.Z3py API. http://z3prover.github.io/api/html/namespacez3py.html. Accessed 29 Jan 2016
 9.Andrieu, C., de Freitas, N., Doucet, A., Jordan, M.I.: An introduction to MCMC for machine learning. Mach. Learn. 50, 5–43 (2003)CrossRefzbMATHGoogle Scholar
 10.Borges, M., d’Amorim, M., Anand, S., Bushnell, D., Pasareanu, C.S.: Symbolic execution with interval solving and metaheuristic search. In: Proceedings of the 2012 IEEE Fifth International Conference on Software Testing, Verification and Validation, ICST 2012, Washington, DC, USA, pp. 111–120. IEEE Computer Society (2012)Google Scholar
 11.Brillout, A., Kroening, D., Wahl, T.: Mixed abstractions for floatingpoint arithmetic. In: FMCAD, pp. 69–76 (2009)Google Scholar
 12.Chen, Y., Zhendong, S.: Guided differential testing of certificate validation in SSL/TLS implementations. In: Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering, ESEC/FSE 2015, Bergamo, Italy, 30 August–4 September 2015, pp. 793–804 (2015)Google Scholar
 13.Chib, S., Greenberg, E.: Understanding the metropolishastings algorithm. Am. Stat. 49(4), 327–335 (1995)Google Scholar
 14.Cimatti, A., Griggio, A., Schaafsma, B.J., Sebastiani, R.: The mathSAT5 SMT solver. In: Piterman, N., Smolka, S.A. (eds.) TACAS 2013 (ETAPS 2013). LNCS, vol. 7795, pp. 93–107. Springer, Heidelberg (2013)CrossRefGoogle Scholar
 15.Clarke, E., Kroning, D., Lerda, F.: A tool for checking ANSIC programs. In: Jensen, K., Podelski, A. (eds.) TACAS 2004. LNCS, vol. 2988, pp. 168–176. Springer, Heidelberg (2004)CrossRefGoogle Scholar
 16.de Moura, L., Bjørner, N.S.: Z3: an efficient SMT solver. In: Ramakrishnan, C.R., Rehof, J. (eds.) TACAS 2008. LNCS, vol. 4963, pp. 337–340. Springer, Heidelberg (2008)CrossRefGoogle Scholar
 17.EspíritoSanto, I.A., Costa, L.A., Rocha, A.M.A.C., Azad, M.A.K., Fernandes, E.M.G.P.: On Challenging Techniques for Constrained Global Optimization. Springer, Heidelberg (2013)CrossRefGoogle Scholar
 18.Zhoulai, F., Bai, Z., Zhendong, S.: Automated backward error analysis for numerical code. In: OOPSLA, pp. 639–654 (2015)Google Scholar
 19.Ganzinger, H., Hagen, G., Nieuwenhuis, R., Oliveras, A., Tinelli, C.: DPLL(T): fast decision procedures. In: Alur, R., Peled, D.A. (eds.) CAV 2004. LNCS, vol. 3114, pp. 175–188. Springer, Heidelberg (2004)CrossRefGoogle Scholar
 20.Gao, S., Kong, S., Clarke, E.M.: \({\sf dReal}\): an SMT solver for nonlinear theories over the reals. In: Bonacina, M.P. (ed.) CADE 2013. LNCS, vol. 7898, pp. 208–214. Springer, Heidelberg (2013)CrossRefGoogle Scholar
 21.Goldberg, D.: What every computer scientist should know about floating point arithmetic. ACM Comput. Surv. 23(1), 5–48 (1991)CrossRefGoogle Scholar
 22.Goldwasser, D., Strichman, O., Fine, S.: A theorybased decision heuristic for DPLL(T). In: FMCAD, pp. 1–8 (2008)Google Scholar
 23.Haller, L., Griggio, A., Brain, M., Kroening, D.: Deciding floatingpoint logic with systematic abstraction. In: FMCAD, pp. 131–140 (2012)Google Scholar
 24.Bayardo Jr., R.J., Schrag, R.: Using CSP lookback techniques to solve realworld SAT instances. In: Proceedings of the Fourteenth National Conference on Artificial Intelligence and Ninth Innovative Applications of Artificial Intelligence Conference, AAAI 1997, IAAI 1997, 27–31 July 1997, pp. 203–208. Providence, Rhode Island (1997)Google Scholar
 25.King, J.C.: Symbolic execution and program testing. Commun. ACM 19(7), 385–394 (1976)MathSciNetCrossRefzbMATHGoogle Scholar
 26.Kirkpatrick, S., Gelatt, C.D., Vecchi, M.P.: Optimization by simulated annealing. Science 220(4598), 671–680 (1983)MathSciNetCrossRefzbMATHGoogle Scholar
 27.Kleene, S.C.: Introduction to Metamathematics. NorthHolland, Amsterdam (1962)zbMATHGoogle Scholar
 28.Lakhotia, K., Tillmann, N., Harman, M., de Halleux, J.: Flopsysearchbased floating point constraint solving for symbolic execution. In: Petrenko, A., Simão, A., Maldonado, J.C. (eds.) ICTSS 2010. LNCS, vol. 6435, pp. 142–157. Springer, Heidelberg (2010)CrossRefGoogle Scholar
 29.Li, Z., Scheraga, H.A.: Monte Carlominimization approach to the multipleminima problem in protein folding. In: Proceedings of the National Academy of Sciences of the United States of America, vol. 84, No. 19, pp. 6611–6615 (1987)Google Scholar
 30.McMinn, P.: Searchbased software test data generation: a survey: research articles. Softw. Test. Verif. Reliab. 14(2), 105–156 (2004)CrossRefGoogle Scholar
 31.Meinke, K., Niu, F.: A learningbased approach to unit testing of numerical software. In: Petrenko, A., Simão, A., Maldonado, J.C. (eds.) ICTSS 2010. LNCS, vol. 6435, pp. 221–235. Springer, Heidelberg (2010)CrossRefGoogle Scholar
 32.Miller, W., Spooner, D.L.: Automatic generation of floatingpoint test data. IEEE Trans. Softw. Eng. 2(3), 223–226 (1976)MathSciNetCrossRefGoogle Scholar
 33.Nieuwenhuis, R., Oliveras, A., Tinelli, C.: Solving SAT and SAT modulo theories: from an abstract DavisPutnamLogemannLoveland procedure to DPLL(T). J. ACM 53(6), 937–977 (2006)MathSciNetCrossRefzbMATHGoogle Scholar
 34.Nocedal, J., Wright, S.J.: Numerical Optimization. Springer, Berlin (2006)zbMATHGoogle Scholar
 35.Peleska, J., Vorobev, E., Lapschies, F.: Automated test case generation with SMTsolving and abstract interpretation. In: Bobaru, M., Havelund, K., Holzmann, G.J., Joshi, R. (eds.) NFM 2011. LNCS, vol. 6617, pp. 298–312. Springer, Heidelberg (2011)CrossRefGoogle Scholar
 36.Press, W.H., Teukolsky, S.A., Vetterling, W.T., Flannery, B.P.: Numerical Recipes: The Art of Scientific Computing, 3rd edn. Cambridge University Press, New York (2007)zbMATHGoogle Scholar
 37.Rümmer, P., Wahl, T.: An SMTLIB theory of binary floatingpoint arithmetic. In: Informal proceedings of 8th International Workshop on Satisfiability Modulo Theories (SMT) at FLoC, Edinburgh, Scotland (2010)Google Scholar
 38.Schkufza, E., Sharma, R., Aiken, A.: Stochastic optimization of floatingpoint programs with tunable precision. In: PLDI, pp. 53–64 (2014)Google Scholar
 39.Souza, M., Borges, M., d’Amorim, M., Păsăreanu, C.S.: CORAL: solving complex constraints for symbolic pathfinder. In: Bobaru, M., Havelund, K., Holzmann, G.J., Joshi, R. (eds.) NFM 2011. LNCS, vol. 6617, pp. 359–374. Springer, Heidelberg (2011)CrossRefGoogle Scholar