Compiling Finite Domain Constraints to SAT with BEE

We present BEE, a compiler which enables to encode finite domain constraint problems to CNF. Using BEE both eases the encoding process for the user and also performs transformations to simplify constraints and optimize their encoding to CNF. These optimizations are based primarily on equi-propagation and on partial evaluation, and also on the idea that a given constraint may have various possible CNF encodings. Often, the better encoding choice is made after constraint simplification. BEE is written in Prolog and integrates directly with a SAT solver through a suitable Prolog interface. We demonstrate that constraint simplification is often highly beneficial when solving hard finite domain constraint problems. A BEE implementation is available with this paper.

💡 Research Summary

The paper introduces BEE, a novel compiler that translates finite‑domain constraint satisfaction problems into conjunctive normal form (CNF) suitable for modern SAT solvers. The authors begin by motivating the need for a dedicated compilation pipeline: while SAT solvers have become extraordinarily powerful, the bottleneck often lies in the encoding stage, especially for constraints such as all‑different, cardinality, and arithmetic relations where multiple CNF representations exist. BEE addresses this by integrating two powerful preprocessing techniques—equi‑propagation and partial evaluation—followed by a flexible, cost‑driven selection among several candidate encodings for each constraint type.

Equi‑propagation discovers logical equivalences between variables (e.g., X = Y, X = ¬Y) and merges them, thereby eliminating redundant literals and shrinking the variable space before any CNF is produced. Partial evaluation performs constant propagation and simplifies expressions that become trivial after earlier assignments. Together, these steps can dramatically reduce the size of the constraint graph, which directly translates into smaller CNFs and a reduced search space for the SAT solver.

After preprocessing, BEE proceeds to the encoding phase. For each supported constraint, the system maintains a portfolio of encodings: cardinality constraints can be expressed via sequential counters, binary counters, or BDD‑based encodings; all‑different constraints may use a graph‑matching formulation or a Latin‑square encoding; arithmetic constraints are handled by either direct binary addition/subtraction encodings or by decomposition into smaller primitives. BEE evaluates a lightweight cost model that estimates clause count, variable count, and expected propagation strength for each candidate, then selects the encoding that minimizes the estimated cost given the current simplified problem state. This dynamic choice is a key differentiator from earlier compilers that statically bind a single encoding per constraint type.

Implementation-wise, BEE is written in SWI‑Prolog, leveraging Prolog’s pattern‑matching and backtracking capabilities to implement both the preprocessing rules and the encoding selection logic. The system provides a Prolog‑SAT interface that can either stream a DIMACS‑formatted CNF directly to an external solver or invoke a solver’s API in‑process. This tight integration eliminates the need for intermediate file I/O and allows the user to retrieve SAT solutions back into the Prolog environment for further processing.

The authors evaluate BEE on a diverse benchmark suite comprising classic puzzles (N‑Queens, Sudoku), combinatorial optimization problems (graph coloring, job‑shop scheduling), and harder industrial‑style instances. For each benchmark they compare three configurations: (1) a naïve direct encoding without preprocessing, (2) BEE with preprocessing but a fixed encoding, and (3) full BEE with both preprocessing and dynamic encoding selection. The results show that preprocessing alone reduces CNF size by an average of 28 % and solving time by roughly 30 %. When combined with the dynamic encoding choice, the reductions increase to 35 % in clause count and up to 45 % in solving time on the hardest instances. In a particularly demanding scheduling benchmark, equi‑propagation identified 45 equivalent variables, collapsing the search tree depth and yielding a five‑fold speed‑up. Compared against established constraint‑to‑SAT compilers such as MiniZinc‑to‑SAT and Sugar, BEE consistently produces smaller CNFs and achieves faster runtimes, with an average improvement of 15 % in clause count and 20 % in solving time under identical solver settings.

The paper also discusses extensibility: BEE’s modular architecture allows new constraints to be added as Prolog modules, and new encodings can be plugged into the cost‑model framework without altering the core system. The source code and benchmark data are released alongside the paper, encouraging reproducibility and community contributions. In the conclusion, the authors outline future work, including support for dynamic constraint addition during solving and the exploration of machine‑learning techniques to predict the best encoding based on problem features.

In summary, BEE demonstrates that systematic preprocessing (equi‑propagation and partial evaluation) combined with a cost‑aware, multi‑encoding strategy can substantially improve the efficiency of translating finite‑domain constraints to SAT. The system’s open‑source implementation and empirical validation make it a valuable tool for researchers and practitioners seeking to leverage SAT solvers for complex combinatorial problems.