blas

The blas crate provides thin, code-generated Rust wrappers around BLAS (Basic Linear Algebra Subprograms), the decades-old Fortran interface for vector, matrix-vector, and matrix-matrix operations that underlies most of the numerical computing ecosystem. Rather than reimplementing the routines, it links against whichever BLAS implementation is configured through its blas-sys dependency — OpenBLAS, Netlib, Intel MKL, or a platform’s Accelerate framework — and exposes each Fortran routine (sgemm, dgemv, ddot, and roughly 140 others) as an unsafe fn with idiomatic Rust slice and scalar arguments in place of raw pointers.

It is a building-block crate: applications rarely depend on it directly, and instead reach it transitively through higher-level linear algebra libraries such as ndarray-linalg or nalgebra-lapack that need a real BLAS backend for performance-critical numerical code. The wrapper functions themselves add no error handling or bounds checking beyond what the underlying Fortran library provides, since the point of the crate is a faithful, low-overhead mapping onto the existing BLAS API rather than a new abstraction.

What You Get

• Full BLAS coverage - all three BLAS levels (roughly 146 routines) across single/double precision and real/complex types (s/d/c/z prefixes).
• Idiomatic argument types - Rust slices and scalars in place of the raw pointers and Fortran calling conventions the underlying C ABI expects.
• Complex number support - c32/c64 type aliases built on num-complex::Complex, matching Fortran’s complex-number memory layout.
• Backend-agnostic linking - works with any BLAS implementation exposed through blas-sys (OpenBLAS, Netlib reference BLAS, Intel MKL, Accelerate).

Common Use Cases

• Backend for higher-level linear algebra crates - libraries like ndarray-linalg use blas as the low-level compute layer under a safer, typed API.
• Performance-critical numerical code - calling dgemm/sgemm directly for matrix multiplication when hand-tuning avoids the overhead of a heavier abstraction.
• Porting Fortran/C numerical code to Rust - a near 1:1 mapping onto familiar BLAS routine names eases translation of existing scientific code.
• Scientific computing prototypes - quick vector/matrix operations in Rust without hand-writing FFI bindings to a system BLAS library.

Under The Hood

Architecture The crate is a single flat module (src/lib.rs, ~2,800 lines) containing roughly 146 thin unsafe wrapper functions, each translating idiomatic Rust slice and scalar arguments into raw pointers passed straight through to the blas-sys FFI crate’s extern "C" declarations for the underlying BLAS implementation. There is no internal layering beyond type translation — the file itself is generated by a small Python toolchain (bin/generate.py, bin/function.py, bin/documentation.py) that reads BLAS routine metadata and emits the Rust source, so in practice the crate is maintained by editing the generator and regenerating lib.rs rather than hand-editing individual wrappers.

Tech Stack A small, stable Rust dependency chain: blas-sys 0.8 supplies the raw FFI declarations and links against whichever system BLAS implementation is configured, libc 0.2 provides C ABI primitive types, and num-complex 0.4 supplies the complex-number types used for the c32/c64 aliases. CI (.github/workflows/build.yml) runs cargo clippy -- -D warnings and cargo fmt --check alongside cargo test on every push and pull request.

Code Quality There is no dedicated test suite — the only executable check tied to correctness is a single no_run doctest embedded in the crate-level doc comment, meaning it is compiled but never actually executed against a real BLAS backend. Every public function is unsafe fn with no bounds or validity checking, which mirrors the underlying C/Fortran ABI’s own lack of error propagation; the crate explicitly allows clippy::missing_safety_doc, waiving the usual requirement to document each function’s safety invariants. Naming follows canonical BLAS routine names (sgemm, dgemv) rather than idiomatic Rust conventions, which is intentional given the crate’s purpose as a faithful low-level mapping.

API Design The public surface is deliberately minimal and mechanical: one function per BLAS routine, parameter order and semantics matching the Fortran originals, with slices standing in for pointer+length pairs. This keeps the mapping predictable for anyone already familiar with BLAS, but it also means callers get none of Rust’s usual safety guarantees or ergonomic conveniences (no Result types, no dimension validation) — the crate is intended as infrastructure for other libraries to build a friendlier API on top of, not as an end-user-facing interface.