Booleguru, the Propositional Polyglot (Short Paper)

Abstract

Recent approaches on verification and reasoning solve SAT and QBF encodings using state-of-the-art SMT solvers, as it “makes implementation much easier”. The ease-of-use of these solvers make SAT and QBF solvers less visible to users of solvers—who are maybe from different research communities—potentially not exploiting the power of state-of-the-art tools. In this work, we motivate the need to build bridges over the widening solver-gap and introduce Booleguru , a tool to convert between formats for logic formulas. It makes SAT and QBF solvers more accessible by using techniques known from SMT solvers, such as advanced Python interfaces like Z3Py and easily generatable languages like SMT-LIB, integrating them to our conversion tool. We then introduce a language to manipulate and combine multiple formulas, optionally applying transformations for quickly prototyping encodings. Booleguru ’s advanced scripting capabilities form a programming environment specialized for Boolean logic, offering a more efficient way to develop novel problem encodings.

Full text

Booleguru, the Propositional Polyglot
(Short Paper)
Maximilian Heisinger(B
), Simone Heisinger , and Martina Seidl
Johannes Kepler University Linz, Linz 4040, Austria
{maximilian.heisinger,simone.heisinger,martina.seidl}@jku.at
Abstract. Recent approaches on verification and reasoning solve SAT
and QBF encodings using state-of-the-art SMT solvers, as it “makes
implementation much easier”. The ease-of-use of these solvers make SAT
and QBF solvers less visible to users of solvers—who are maybe from
different research communities—potentially not exploiting the power of
state-of-the-art tools. In this work, we motivate the need to build bridges
over the widening solver-gap and introduce Booleguru, a tool to con-
vert between formats for logic formulas. It makes SAT and QBF solvers
more accessible by using techniques known from SMT solvers, such as
advanced Python interfaces like Z3Py and easily generatable languages
like SMT-LIB, integrating them to our conversion tool. We then intro-
duce a language to manipulate and combine multiple formulas, option-
ally applying transformations for quickly prototyping encodings. Boole-
guru’s advanced scripting capabilities form a programming environment
specialized for Boolean logic, offering a more efficient way to develop
novel problem encodings.
Keywords: SAT ·QBF ·SMT ·DIMACS ·QCIR ·SMTLIB2 ·
AIGER
1 Introduction
Numerous recent publications with encodings of problems into SAT and QBF do
not use SAT or QBF solvers directly [6,16,18]. SMT solvers, often the feature-
rich and popular state-of-the-art solver Z3 [8], are used instead, as it “makes
implementation much simpler” [17], although no theory reasoning is involved.
Z3’s programming API or the Common Lisp compatible SMT-LIB standard [3]
are well documented and regarded by many as easy to use. While this ease
of use leads to wide adoption and fast results, adapting encodings to use less
general solving backends that are potentially more efficient for the problem at
hand remains hard, e.g. switching from SMT solving to using a less general SAT
solver. Researchers focus on optimizing their encodings against an SMT solver’s
performance characteristics, instead of testing them against many different (also
This work was supported by the LIT AI Lab funded by the State of Upper Austria.
c
The Author(s) 2024
C. Benzmüller et al. (Eds.): IJCAR 2024, LNAI 14739, pp. 315–324, 2024.
https://doi.org/10.1007/978-3-031-63498-7_19

316 M. Heisinger et al.
Table 1 . Formula formats that are optimized (✓), usable (≈), or unusable (✗)for
encoding the respective problem
Problem DIMACS QDIMACS QCIR AIGER SMTLIB2
SAT Solving ✓≈ ≈ ≈ ≈
QBF Solving ✗ ✓ ✓ ✗ ≈
AIG Solving ✗ ✗ ≈✓ ✓
SMT Solving ✗ ✗ ✗ ✗ ✓
Table 2 . File formats and their capabilities.
Form a t Non-CNF Quantifiers Non-Prenex Structure-Sharing
DIMACS ✗ ✗ ✗ ✗
QDIMACS ✗ ✓ ✗ ✗
AIGER ✓ ✗ ✗ ✓
Limboole ✓ ✓ ✓ ✗
QCIR ✓ ✓ ✓ ✓
SMTLIB ✓ ✓ ✓ ✓
non-SMT) solvers. We consider the transformation of formulas into conjunctive
normal form (CNF) required for SAT and QBF solvers to be non-trivial, espe-
cially for beginners. Seemingly bad intermediary results are discarded, as the
effort required to re-encode the problem to be solvable with SAT or QBF solvers
is too large to be spent during prototyping, effectively forming a solver gap.We
want to bridge over this gap and reduce the friction involved with testing other
solvers outside the SMT world, without extensive modifications to encoding gen-
erators. In this work, we analyze what features are required to build this bridge
and develop Booleguru, a polyglot for (quantified) Boolean logic. Our tool is
available under the permissive MIT license at:
https://github.com/maximaximal/booleguru
1.1 Bridging the Solver Gap with Propositional Logic
In order to build a bridge over the solver gap described above, we first have to
identify it. When encoding problems into logic, one also has to decide which for-
mat to encode into. The encoding itself is then typically accomplished with some
encoder program, which is closely tied to the problem to be encoded. Chang-
ing the output format of an encoder involves considerable effort, as encoders
are typically tailored to the output formats they were designed to support. As
encoders grow in complexity, communities form around them, while still relying
on the original output format. The decision at the beginning of an encoder’s
development then influences the newly formed community, as changing their
encoder to generate a different output format involves considerable effort. We

Booleguru, the Propositional Polyglot (Short Paper) 317
Fig. 1. Booleguru Architecture, Transformers may be arbitrarily combined.
therefore identify gaps in the solving landscape opening between the different
input formats of different solvers for different problems. Table1lists a selection
of different problems with their associated dominant file formats. Table 2lists
features offered by each format. All of them offer ways to encode propositional
logic in CNF, with some of them extending it with quantifiers over variables
(∀,∃). More advanced formats also allow encoding formulas in Non-CNF, i.e.,
formulas built from expressions and more complex logical operators. If a format
supports quantifiers, they may always be added as a prefix to the formula. While
every formula with embedded quantifiers can be prenexed to be in such a prenex
form, some formats also allow encoding formulas in non-prenex form, extending
a format’s expressiveness. Some formats also allow structure-sharing, which lets
problems reference sub-expressions multiple times, without repeating them. The
overlapping capabilities of different formats suggest that a conversion tool has to
be able to process all of them, and to serialize complex features into less complex
formats, where supported.
1.2 Related Work
Other communities already went through this bridge-building effort in order to
reduce duplicated work and advance their fields. One of the biggest examples are
the researchers of the machine learning community, who commonly use libraries
like PyTorch [15], SciPy [21], and Pandas [20]. This allows others to use new
innovations in these libraries, such as newly added learning algorithms or prop-
erties in PyTorch, or better storage formats in Pandas.
Multiple conversion tools already exist for QBF [9,13,19]. While all of these
tools convert between specific formats, no tool tries to encompass multiple con-
version or combination capabilities. Some SMT solvers are able to read multiple
input formats [2,7,8], with all supporting SMT-LIB2, the format favored by the
SMT-Competition [22]. SMT solvers do not offer to combine multiple formulas
seamlessly. Booleguru fills this niche and provides such a convert & combine
capability, while also enabling a unique development environment to create new
formulas. It enables previously tedious comparisons between different solvers
solving similar problems, like SMT and QBF solvers, as shown in Fig. 2.
2 Booleguru, the Propositional Multitool
After introducing the overlaps between file formats and solving communities,
we now introduce our conversion tool: Booleguru. As shown in the architec-
ture diagram in Fig. 1, it consists of readers, transformers, and serializers for

318 M. Heisinger et al.
propositional logic and extensions. Inputs in arbitrary formats may be read,
modified, and then serialized in the same or a different file format. This section
first describes how Booleguru stores propositional formulas in memory, so that
all capabilities described in Table 2can be provided. We then introduce features
intended for working with formulas.
2.1 Representing Propositional Formulas in Memory
In order to be accepted as an efficient tool to work with propositional formulas,
they have to be both fast to create and to traverse. While this is true for a tool in
any problem domain, the lower expressiveness of propositional logic compared to
bit-vectors or more complex theories leads to large formulas with many nodes,
relying on tools with especially high throughput. For this, they are stored in
a directed-acyclic-graph (DAG), enabling structure-sharing. Each node in the
DAG is either a variable, a unary (negation), or a binary operation (and, or, etc.).
A node is stored in a struct of 16B, which (on most architectures) exactly fits
into a single cache-line. The remaining bits to fill the cache line are occupied by
structural information of the expression and user-writable extra data to be stored
within the DAG, which speeds up transformers that need to store temporary data
on nodes. Beside the user writable data, nodes stay constant over the whole
execution.
References between nodes are stored as 32bit unsigned integers, which are
evaluated relatively to the nodes of a whole formula. When creating a formula, a
hash table is used to check if a given node already exists, and if it does not, a new
node is appended at the back of the node array. References to previous nodes are
immutable, which enables cheaply appending new expressions that are composed
of others. Expressions may only reference other expressions with IDs smaller
than themselves, cycles imply a malstructured formula. Traversing this DAG
does not involve hash lookups or pointer indirections, as every reference can be
resolved directly through the child’s index in the array. Information about a sub-
expression is collected during insertion of a new node, removing the requirement
to scan the DAG in order to check for commonly required structural information.
The 32bit references make traversal very efficient, but limits formula sizes to
232 −1nodes. We will provide a compile-time switch to increase reference sizes
in a future version.
2.2 Parsing Formulas
We already implemented several parsers:
– (Q)DIMACS
–QCIR[13]
–AAG(AIGER[5])
– SMT-LIB [3]
– Z3Py
–CLI
– generic infix logic
using &,|,<->,etc.
(Limboole)
The readers are mostly implemented using the ANTLR parser generator [14].
While slower than hand-written parsers, the library allowed us to iterate faster

Booleguru, the Propositional Polyglot (Short Paper) 319
during development and add more input languages with a shared base. Some
parsers are hand-written, and performance critical ones are incrementally opti-
mized to a specialized implementation. Each parser produces a reference to an
expression inside a shared expression manager. Multiple expressions can then be
combined into new ones, disregarding their source format. The command-line
parsing is also fully done using an ANTLR parser producing an expression, in
order to provide a language for composing formulas from multiple files or scripts.
2.3 Transforming Formulas
Transformers are the umbrella term for functions that work on one or more
expressions passed to them. They may return new expressions built from their
inputs and may be chained together. They are either implemented in native
C++, Lua [12], or Fennel1, with Lua and Fennel possibly supplied at run-
time by a user without re-compiling Booleguru. Several transformations are
already implemented, with more being added in future releases. The list below
uses the Colon Operator (:op) notation, which is transformed into Fennel func-
tion calls during CLI parsing. Each such transformation can be supplied to the
Booleguru CLI, where they strongly bind (stronger than binary operators)
to the expression preceding them. Generating transformers without expressions
as inputs have to be written without an expression preceding them, akin to
variables.
:eliminate-implication
Converts a⇒bto ¬a∨b.
:eliminate-equivalence
Converts a⇔bto (a∨¬b)∧(b∨¬a)
:eliminate-xor
Converts a⊕bto ¬a∧b∨a∧¬b
:distribute-ors
Distributes ∨into the formula and
remove them from the outermost
context.
:distribute-nots
Distributes ¬into the formula and
remove them from the outermost
context or from applying to sub-
expressions.
:distribute-to-cnf
Distributes operations in the for-
mula until it is in Conjunctive Nor-
mal Form (CNF). This often entails
exponential size increase.
:tseitin
Tseitin-encode a (sub-) expres-
sion into CNF, without the expo-
nential blowup involved with
:distribute-to-cnf.
:rename
Rename one or more variables in a
(sub-) expression. Can take multiple
arguments.
:solve
Solve a (sub-) expression in CNF.
Returns a conjunction of variables.
:quanttree
Draw a formula’s quantifiers.
:unquantified
Print all variables that are not quan-
tified by some quantifier.
:prefixtract
Extract statistics from a formula’s
quantifier prefix (if it is in prenex
form).
1https://fennel-lang.org.

320 M. Heisinger et al.
Fig. 2. Z3 and selected QBF solvers solving the QCIR track of QBFGallery 2023
:quantlist
Print the quantifier prefix (if avail-
able), merging multiple quantifiers
of same type into sorted blocks.
:counterfactuals
Generate a counterfactual (parame-
terized).
:eqkbkf
Generate a KBKF combined with
an equality formula (parameter-
ized).
:dotter
Outputs the in-memory DAG of the
formula as a .dot file that can be
processed using GraphViz.
:assignment-tree
Expands the quantifier prefix into a
tree over all possible variable assign-
ments and solves each leaf assign-
ment using SAT solver. Outputs a
.dot file.
2.4 Serializing Formulas
After reading, combining, and transforming input formulas, they can be printed
in different output formats. For this, several serializers have been developed,
which are listed below. (Q)DIMACS relies on the provided Tseitin encoding by
default, but one may use other methods that arrive on an expression which is
tagged to be in CNF. This made Booleguru a helpful tool in the QBFGallery
20232.
– (Q)DIMACS
–QCIR
– SMTLIB
–Limboole
3 Booleguru, the Programming Environment
During development of new problem encodings or crafted formulas, there is usu-
ally a step where an encoding tool or a formula generator is written [1,4,11]. In
our experience, these tools often rely on similar primitives:
– Create a new variable.
– Compose an expression based on sub-expressions.
– Read from an external source or draw random data.
2https://qbf23.pages.sai.jku.at/gallery/.

Booleguru, the Propositional Polyglot (Short Paper) 321
– Write the formula in the desired output format.
The Lua, Fennel, and Python APIs offered by Booleguru abstract over multi-
ple output formats and the concept of writing formulas into files. When writing
a generator for a new formula, the Booleguru primitives offer the user to work
directly with the formula’s AST, instead of having to generate syntax describing
the AST in the target language. This makes generators more suited to change, as
they are always composed of (nested) functions, each generating sub-expressions.
In addition to using Booleguru as a first-class execution environment for
formula generators, it may be used to reduce SMT encodings developed using
Z3Py to a SAT or QBF solving problem. Booleguru optionally generates a
Python module that emulates the popular interface of Z3.
Lua and Fennel Interface. The Lua and Fennel interfaces are both accessible
through an embedded interpreter. Lua and Fennel scripts that are already dis-
tributed as a part of Booleguru are compiled ahead of time by LuaJIT3.This
makes both initialization and execution of scripts as efficient as possible in the
Release build of Booleguru. User-supplied scripts are compiled at runtime
using LuaJIT.
Python Interface. Additionally to the specialized Lua and Fennel interfaces,
Booleguru provides the pybooleguru interface which is directly modelled after
the widely used Z3Py Python library. We observed that when using Z3Py during
development of a new encoding, the jump from the SMT solver Z3 to more
fundamental SAT or QBF solving becomes harder. This interface is intended
to be a drop-in replacement to Z3Py, enabling the conversion of a complex
Z3-specific encoder written in Python into an encoder capable of producing
additional output of a different format. Python scripts may be read as inputs or
a script may import pybooleguru instead of z3py.
C++ Interface. Additionally to the scripting interfaces, the C++ interface itself
may also be used. Functions are provided to easily build expressions using C++,
which can be useful when developing new tools in systems languages.
3.1 Command-Line Interactive Interface
The command-line interface of Booleguru is also considered a programming
environment, as it seamlessly merges a grammar for propositional logic in infix
notation with the Scheme-based Fennel, a programming language written in
prefix-notation. Each Fennel expression has to return a logical expression, which
it builds using the provided primitives. By combining transformations and work-
ing with expressions, new functionality can be implemented using the CLI alone.
For example, for the formula (a∧b)∨(a∧¬b), both solutions can be extracted
using the CLI:
3https://luajit.org/luajit.html.

322 M. Heisinger et al.
$ booleguru test.boole :solve
a&!b
$ booleguru test.boole ":(b-and ** (b-not (solve **)))" :solve
a&b
It can also be used to combine formulas while renaming e.g. ato aa:
$ booleguru "test.boole :rename@a@aa <-> test.boole"
(#aa ?b (aa & b)) <-> (#a ?b (a & b))
The CLI can also invoke parameterized custom binary operators. The #comment
below is the file my-bin.fnl in the current working directory.
# (lambda my-bin [m] ((. _G m) (b-and *l* *r*) (b-or *l* *r*)))
$ ./booleguru a ::my-bin@equi b
a&b<->a|b
3.2 Developing Booleguru
Our tool is implemented in C++, with some helpers provided to ease devel-
opment. The build system is realized using CMake, which makes Booleguru
easily embeddable into other projects. All modules have test suites to be run
during development. They test basic features like the expression tree, but also
transformers and serializers. Defining new tests is easy and running all tests is
quick and parallelizable. The build system offers a fast Release build, a slower
Debug build without optimization options, and a Sanitized build with enabled
address- and undefined behavior sanitizers. If available, LuaJIT is used for exe-
cuting Lua and Fennel scripts, otherwise the regular Lua distribution is provided
as a fallback. Booleguru also natively supports to be built as a WebAssembly
executable, making it runnable in browsers, including Lua and Fennel scripts.
Embedded Fuzzer. Transformers that process operations may also be fuzzed using
the LLVM libFuzzer integration. Booleguru has to be built in the fuzzing
mode, which creates the specialized booleguru-fuzzer binary. The command-
line has to be provided via the environment variable BOOLEGURU_ARGS,witha
fuzz file that serves as the injection point for fuzzed inputs. Arbitrary trans-
formations may then be performed on the expressions, which are called with
every iteration of the fuzzer. Booleguru’s embedded mutator (inspired by the
mutator of Google Protocol Buffers) randomly creates arbitrary many input
structures until unexpected stops are encountered. The fuzzing capability was
used extensively during development of the transformers. The resulting inputs
can be displayed in Limboole format using the booleguru-print-corpus tool.
4 Conclusion
We developed the propositional polyglot Booleguru,whichcanbeusedtocon-
vert between several widely used logic formats, to transform or combine formulas,

Booleguru, the Propositional Polyglot (Short Paper) 323
and to develop new encodings more efficiently. We discussed the requirements
our tool has to fulfill and introduced the implementation based on these require-
ments. Finally, we explained how Booleguru is used to generate new encodings,
using the embedded Lua, Fennel, and Python scripting support. Booleguru
already proved itself as a valuable tool during the QBFGallery 2023, for revisit-
ing quantifier shifting in QBF [10], and other projects.
References
1. Amendola, G., Ricca, F., Truszczynski, M.: A generator of hard 2QBF formulas and
ASP programs. In: Sixteenth International Conference on Principles of Knowledge
Representation and Reasoning (2018)
2. Barbosa, H., et al.: cvc5: a versatile and industrial-strength SMT solver. In: TACAS
2022. LNCS, vol. 13243, pp. 415–442. Springer, Cham (2022). https://doi.org/10.
1007/978-3-030-99524-9_24
3. Barret, C., Fontaine, P., Tinelli, C.: The SMT-LIB Standard: Version 2.6, May
2021. www.SMT-LIB.org
4. Beyersdorff, O., Pulina, L., Seidl, M., Shukla, A.: QBFFam: a tool for generating
QBF families from proof complexity. In: Li, C.-M., Manyà, F. (eds.) SAT 2021.
LNCS, vol. 12831, pp. 21–29. Springer, Cham (2021). https://doi.org/10.1007/978-
3-030-80223-3_3
5. Biere, A., Heljanko, K., Wieringa, S.: AIGER 1.9 and beyond. Technical
report 11/2, Institute for Formal Models and Verification, Johannes Kepler Uni-
versity, Altenbergerstr. 69, 4040 Linz, Austria (2011)
6. Bonnah, E., Nguyen, L., Hoque, K.A.: Motion planning using hyperproperties for
time window temporal logic. IEEE Robot. Autom. Lett. 8, 1–8 (2023)
7. Brummayer, R., Biere, A.: Boolector: an efficient SMT solver for bit-vectors and
arrays. In: Kowalewski, S., Philippou, A. (eds.) TACAS 2009. LNCS, vol. 5505, pp.
174–177. Springer, Heidelberg (2009). https://doi.org/10.1007/978-3-642-00768-
2_16
8. de Moura, L., Bjørner, N.: Z3: an efficient SMT solver. In: Ramakrishnan, C.R.,
Rehof, J. (eds.) TACAS 2008. LNCS, vol. 4963, pp. 337–340. Springer, Heidelberg
(2008). https://doi.org/10.1007/978-3-540- 78800-3_24
9. Hecking-Harbusch, J., Tentrup, L.: Solving QBF by abstraction. In: Electronic Pro-
ceedings in Theoretical Computer Science (2018). https://doi.org/10.4204/eptcs.
277.7
10. Heisinger, S., Heisinger, M., Rebola-Pardo, A., Seidl, M.: Quantifier shifting for
quantified boolean formulas revisited. In: Benzmüller, C., Heule, M., Schmidt,
R. (eds.) Automated Reasoning - 12th International Joint Conference, IJCAR
2024, Nancy, France, July 3-6, 2024, Proceedings. LNCS, vol. 14739, pp. 325–343,
Springer, Cham (2024). https://doi.org/10.1007/978-3-031-63498-7_20
11. Heisinger, S., Seidl, M.: True crafted formula families for benchmarking quantified
satisfiability solvers. In: Dubois, C., Kerber, M. (eds.) CICM 2023. LNCS, vol.
14101p, pp. 291–296. Springer-Verlag, Berlin, Heidelberg (2023). https://doi.org/
10.1007/978-3-031-42753-4_20
12. Ierusalimschy, R.: Programming in Lua. Roberto Ierusalimschy (2006)
13. Jordan, C., Klieber, W., Seidl, M.: Non-CNF QBF solving with QCIR. In: AAAI
Workshop: Beyond NP. AAAI Technical report, vol. WS-16-05. AAAI Press (2016)

324 M. Heisinger et al.
14. Parr, T.: The definitive ANTLR 4 reference. The Definitive ANTLR 4 Reference,
pp. 1–326 (2013)
15. Paszke, A., et al.: Pytorch: an imperative style, high-performance deep learning
library. In: Advances in Neural Information Processing Systems, vol. 32, pp. 8024–
8035. Curran Associates, Inc. (2019)
16. Peham, T., Brandl, N., Kueng, R., Wille, R., Burgholzer, L.: Depth-optimal syn-
thesis of Clifford circuits with SAT solvers (2023)
17. Saaltink, C., Nicoletti, S.M., Volk, M., Hahn, E.M., Stoelinga, M.: Solving queries
for Boolean fault tree logic via quantified sat. In: Proceedings of the 9th ACM SIG-
PLAN International Workshop on Formal Techniques for Safety-Critical Systems,
pp. 48–59. FTSCS 2023, Association for Computing Machinery (2023). https://
doi.org/10.1145/3623503.3623535
18. Schwarzová, T., Strejcek, J., Major, J.: Reducing acceptance marks in Emerson-
lei automata by QBF solving. In: 26th International Conference on Theory and
Applications of Satisfiability Testing, SAT 2023, July 4-8, Alghero, Italy. LIPIcs,
vol. 271, pp. 23:1–23:20 (2023). https://doi.org/10.4230/LIPICS.SAT.2023.23
19. Seidl, M., Lonsing, F., Biere, A.: qbf2epr: a tool for generating EPR formulas from
QBF. In: Third Workshop on Practical Aspects of Automated Reasoning, PAAR-
2012, Manchester, UK, June 30–July 1, 2012. EPiC Series in Computing, vol. 21,
pp. 139–148. EasyChair (2012). https://doi.org/10.29007/2B5D
20. The pandas development team: pandas-dev/pandas: Pandas, February 2020.
https://doi.org/10.5281/zenodo.3509134
21. Virtanen, P., et al.: SciPy 1.0 Contributors: SciPy 1.0: Fundamental Algorithms
for Scientific Computing in Python. Nature Methods, pp. 261–272 (2020). https://
doi.org/10.1038/s41592-019-0686-2
22. Weber, T., Conchon, S., Déharbe, D., Heizmann, M., Niemetz, A., Reger, G.: The
SMT competition 2015–2018. J. Satisf. Boolean Model. Comput. 11(1), 221–259
(2019). https://doi.org/10.3233/SAT190123
Open Access This chapter is licensed under the terms of the Creative Commons
Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/),
which permits use, sharing, adaptation, distribution and reproduction in any medium
or format, as long as you give appropriate credit to the original author(s) and the
source, provide a link to the Creative Commons license and indicate if changes were
made.
The images or other third party material in this chapter are included in the
chapter’s Creative Commons license, unless indicated otherwise in a credit line to the
material. If material is not included in the chapter’s Creative Commons license and
your intended use is not permitted by statutory regulation or exceeds the permitted
use, you will need to obtain permission directly from the copyright holder.