大浮点数库,Fabrice Bellard 的 libbf 的 Rust 移植版本。
Beeg float library, a Rust port of Fabrice Bellard's libbf

原始链接: https://github.com/lifthrasiir/libbeef

**libbeef** 是 Fabrice Bellard 的 `libbf` 的纯 Rust、零依赖移植版本,提供具备完整 IEEE 754 语义的任意精度浮点算术。 主要特性包括: * **功能全面:** 支持带符号零、NaN、无穷大、可配置指数位宽、次正规数以及五种舍入模式。包含一套完整的超越函数(exp、log、sin、cos 等)及十进制算术。 * **高性能:** 实现了诸如基于 NTT 的乘法和牛顿迭代等最优算法,性能表现与 C 语言原版相当。在大多数运算中,其性能显著优于 `num-bigint`,并可与 GMP/MPFR 相媲美。 * **可移植性与体积:** 兼容 `no_std`(仅需 `alloc`)且无系统依赖,在 WASM 和嵌入式平台上具有极高的可移植性。其二进制体积小巧,优于那些依赖 GMP/MPFR 等庞大 C 库的解决方案。 * **许可协议:** 在宽松的 MIT 协议下发布,作为受 LGPL 约束的 GMP 等库的理想替代方案,对许可环境非常友好。 尽管 GMP/MPFR 在极高精度(超过 1 万位)的原始吞吐量上依然占据优势,但对于需要独立、准确且轻量级任意精度浮点解决方案的项目而言,`libbeef` 是首选。

```Hacker News最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 投稿登录Beeg float 库,Fabrice Bellard 的 libbf 的 Rust 移植版 (github.com/lifthrasiir)10 点,由 serialx 发布于 1 小时前 | 隐藏 | 过往 | 收藏 | 讨论 帮助 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系 搜索: ```
相关文章

原文

docs.rs

A Rust translation of Fabrice Bellard's libbf — a tiny arbitrary-precision floating-point library. The name stands for "Beeg Float".

  • Full IEEE 754 semantics: signed zeros, NaN, infinities, configurable exponent width, subnormals, all five rounding modes, all five status flags.
  • Transcendental functions: exp, log, pow, sin, cos, tan, atan, atan2, asin, acos.
  • Decimal floating point (BigDecimal) with independent base-10 arithmetic.
  • no_std compatible (requires alloc).
  • Pure Rust with zero dependencies.
use libbeef::format::formats;
use libbeef::Float;

type Quad = Float<formats::Binary128>;

fn main() {
    let a: Quad = "3.14159265358979323846".parse().unwrap();
    let b: Quad = "2.71828182845904523536".parse().unwrap();
    let result = (a * b).sin();
    println!("{result}");
    // 0.773942685266708278263054855332479932...
}

Float<F> pairs a value with a compile-time format, so * and .sin() use 128-bit precision and round-to-nearest-even automatically — no format argument at every call site.

libbeef implements the same algorithms as the C libbf: NTT-based multiplication, Newton iteration for division/sqrt, and AGM/binary-splitting for transcendentals. The asymptotic complexity is optimal for each operation class:

Operation class Complexity Algorithm
add, sub, cmp O(n) Linear scan
mul O(n log n) Number-theoretic transform
div, sqrt O(M(n)) Newton iteration over NTT mul
exp, log, sin, … O(M(n) · log n) AGM / binary splitting

Empirically (full data in docs/benchmark-report.md), libbeef tracks the C libbf's throughput with constant-factor overhead from Rust's bounds checking and allocation model:

op 256 bits 30 000 bits 300 000 bits vs libbf vs rug (GMP/MPFR)
mul 6.7 84 100 ns/limb 1.3–2.0× 0.9–1.3×
div 17.3 515 659 ns/limb 1.1–1.4× 2.6–3.5×
sqrt 38.3 384 597 ns/limb 1.2–1.3× 3.2–4.3×
sin 1051 — ns/limb 0.7× (faster) 3.6×

The mul row is the most informative: a quadratic algorithm would show ~10× growth per decade of operand size (47 → 469 → 4688 limbs), but libbeef grows 4.2× then 1.2× — the O(n log n) NTT envelope, the same shape as the C original. At 300k bits libbeef is ~2× libbf and 1.3× GMP, while being 4× faster than num-bigint's schoolbook/Toom multiplication.

For transcendentals, libbeef matches or beats the C libbf on sin/cos/tan/pow and is within 15% on log/atan. The uniform 3–5× gap to MPFR is algorithmic (MPFR uses different, better algorithms for these functions; the C libbf shows the same gap).

Division and sqrt show a larger constant-factor gap to GMP/MPFR (~3×). This is an inherent property of libbf's Newton-reciprocal approach vs. GMP's tuned divide-and-conquer — the same ratio appears in the C original.

1. Pure Rust, no system dependencies. rug/GMP requires a C compiler, system GMP/MPFR libraries, and a build script that probes the host. libbeef is a single cargo add with no build.rs, -lm, nor pkg-config. It builds on any target rustc supports — including WASM, embedded, and cross-compilation — with zero configuration.

2. Small binary footprint. With GMP/MPFR statically linked, a trivial program that multiplies two numbers and computes sin produces:

Library Binary size (stripped)
libbeef 482 KiB
num-bigint (integers only, no trig) 448 KiB
malachite (integers only, no trig) 658 KiB
rug (GMP + MPFR statically linked) 680 KiB

libbeef delivers full floating-point arithmetic and transcendentals in less space than malachite or rug need for integers alone. The num-bigint binary is smaller only because it cannot compute sin at all — it has no floating-point layer.

3. Correct and complete. libbeef passes libbf's own verification suite across every operation, precision, and rounding mode. It is not a "good enough" approximation library — it implements IEEE 754 correctly-rounded arithmetic with configurable exponent width and subnormals.

4. no_std ready. Only requires alloc. No file I/O, no threads, no system calls beyond allocation.

5. More permissive license. libbeef is MIT-licensed, while GMP/MPFR are LGPL. This makes libbeef a better choice for license-sensitive projects where additional legal review for LGPL is undesirable.

When to use something else

  • Maximum throughput at large precisions (>10k bits): GMP/MPFR (via rug) has a heavily tuned FFT and Toom-Cook stack with ~2–3× better constants for multiplication and ~3× for division. If raw ns/op at million-bit precision is the bottleneck, use rug.
  • Integer-only workloads: If you never need floating point, rounding, or transcendentals, num-bigint or malachite give you a simpler API focused purely on integers.
  • Decimal arithmetic at scale: libbeef's decimal path is functional but not yet performance-tuned (it routes through binary conversion rather than native base-10⁹ kernels).
cargo build                    # build (default features: std)
cargo test                     # run all tests
cargo test --test bftest       # libbf verification suite (quick, single-seed)
cargo doc --open               # generate and view API docs
Feature Description
std (default) Enables std support
num-traits Trait impls for the num ecosystem
num-integer Additional num integer traits
serde Serialization support

MIT (same as in libbf).

联系我们 contact @ memedata.com