#bdd #boolean #behavior #object #symbolic

biodivine-lib-bdd

A simple thread-safe implementation of basic binary decision diagrams

30 releases

0.5.22 Sep 24, 2024
0.5.19 Aug 13, 2024
0.5.17 May 15, 2024
0.5.12 Mar 15, 2024
0.1.0 Feb 7, 2020

#59 in Data structures

Download history 62/week @ 2024-08-05 311/week @ 2024-08-12 48/week @ 2024-08-19 105/week @ 2024-08-26 101/week @ 2024-09-02 125/week @ 2024-09-09 494/week @ 2024-09-16 259/week @ 2024-09-23 80/week @ 2024-09-30 34/week @ 2024-10-07 117/week @ 2024-10-14 224/week @ 2024-10-21 31/week @ 2024-10-28 195/week @ 2024-11-04 178/week @ 2024-11-11 124/week @ 2024-11-18

532 downloads per month
Used in 8 crates (7 directly)

MIT license

350KB
6K SLoC

Crates.io Api Docs Continuous integration Codecov GitHub issues Dev Docs GitHub last commit Crates.io

Biodivine/LibBDD

You can now also access the full functionality of lib-bdd from Python! The library is available as part of the AEON.py package.

This crate provides a basic implementation of binary decision diagrams (BDDs) in Rust — a symbolic data structure for representing Boolean functions or other equivalent objects (such as bit-vector sets).

Compared to other popular implementations, every BDD owns its memory. It is thus trivial to serialise, but also to share between threads. This makes it useful for applications that process high number of BDDs concurrently, but is also generally more idiomatic in Rust.

At the moment, we support many standard operations on BDDs:

  • Any binary logical operation (and, or, iff, ...), and of course negation.
  • Evaluation of Boolean expressions parsed from a string.
  • A bdd! macro for a more idiomatic building of BDDs inside Rust.
  • Methods for CNF/DNF transformations (BDD => CNF/DNF and CNF/DNF => BDD). (We do not guarantee minimality of CNF/DNF)
  • Binary and text serialization/deserialization of BDDs.
  • Valuation/path iterators and other Bdd introspection methods (random_valuation, most_fixed_clause, ...).
  • Export of Bdd back into a Boolean expression.
  • "Relational" operations: projection (existential quantification), selection (restriction) and unique subset picking (see tutorials for more info).
  • Various "advanced" apply algorithms: binary operations "fused" with variable inversion (flip), enforced node limit, and existential/universal projection; ternary operations and ternary operations with variable inversion...
  • Export to .dot graphs.

More detailed description of all features can be found in our tutorial module, and of course in the API documentation.

use biodivine_lib_bdd::*;

fn main() {
    let mut builder = BddVariableSetBuilder::new();
    let [a, b, c] = builder.make(&["a", "b", "c"]);
    let variables: BddVariableSet = builder.build();
    
    // String expressions:
    let x = variables.eval_expression_string("(a <=> !b) | c ^ a");
    // Macro:
    let y = bdd!(variables, (a <=> (!b)) | (c ^ a));
    // Logical operators:
    let z = variables.mk_literal(a, true)
        .iff(&variables.mk_literal(b, false))
        .or(&variables.mk_literal(c, true).xor(&variables.mk_literal(a, true)));

    assert!(!x.is_false());
    assert_eq!(6.0, x.cardinality());
    assert_eq!(x, y);
    assert_eq!(y, z);
    assert_eq!(z, x);

    for valuation in x.sat_valuations() {
        assert!(x.eval_in(&valuation));
    }   
}

Correctness: At the moment, the project has a quite good test coverage (including a simple formula fuzzer) and is used in multiple applications. However, in case of any unexpected behaviour, please submit an issue here. There are many edge cases which we may have not considered.

Completeness: Even though the library can support a wide range of applications, the API is still missing some features provided by other BDD libraries. Furthermore, the performance of some methods could be definitely improved. If you find that something is either missing or unexpectedly slow/impractical to implement, feel free to create an issue with a feature request, or send us a pull request!

Citation

If you are using lib-bdd in academic research, we'd very much appreciate a citation. There isn't a specific lib-bdd publication, however, lib-bdd originated in the tool AEON. As such, you can cite lib-bdd as the "BDD library of the tool AEON".

@inproceedings{aeon,
  title     = {{AEON}: {A}ttractor {B}ifurcation {A}nalysis of {P}arametrised {B}oolean {N}etworks},
  author    = {Bene{\v{s}}, Nikola
           and Brim, Lubo{\v{s}}
           and Kadlecaj, Jakub
           and Pastva, Samuel
           and {\v{S}}afr{\'a}nek, David},
  year      = {2020},
  month     = {07},
  booktitle = {Computer Aided Verification},
  editor    = {Lahiri, Shuvendu K.
           and Wang, Chao},
  pages     = {569 -- 581},
  numPages  = {13},
  publisher = {Springer},
  series    = {Lecture Notes in Computer Science},
  volume    = {12224},
  isbn      = {978-3-030-53288-8},
  doi       = {10.1007/978-3-030-53288-8\_28}
}

Performance

The benchmarks presented here are quite outdated, but still at least somewhat relevant. There is an ongoing effort to provide a better benchmark suite, but this has not been completed yet.

Critical part of every BDD implementation is performance. Currently, the repository contains a benchmark branch with several benchmark problems evaluable using this crate as well as other state-of-the-art BDD libraries (bex, cudd and buddy). In our experience, biodivine-lib-bdd performs comparably to these libraries for complex problem instances:

Performance stats

The benchmarks typically consist of incrementally constructing one large BDD of exponential size. For some applications where node reuse is critically important (very similar formulas appear repeatedly, or very small modifications to a single BDD are performed), lib-bdd would likely be slower. However, in our experience, these types of problems do not appear in verification/formal methods very often.

Also note that even though buddy is winning, the setting of initial cache size was critical when achieving this level of performance (each benchmark has a specifically tuned cache size to avoid garbage collection and overallocation). If the size of the problem is not known beforehand, buddy may perform significantly worse.

Dependencies

~0.7–1MB
~21K SLoC