SciRS2: a pure-Rust SciPy port with AI/ML modules

SciRS2 is the kind of project that reads like an argument for Rust in scientific computing. It reimplements the breadth of SciPy — linear algebra, statistics, optimization, integration, FFT, signal processing, sparse matrices, spatial algorithms — and then keeps going into machine learning: automatic differentiation, neural networks, graph algorithms, computer vision, time series. The whole thing is a Cargo workspace of 29 crates under Apache-2.0, maintained by COOLJAPAN OU (Team KitaSan). Version 0.6.5 was released July 31, 2026.

The defining constraint runs through the whole project: 100% Pure Rust by default. No OpenBLAS, no MKL, no LAPACK, no FFTW, no C/Fortran compilers to install. BLAS/LAPACK come from OxiBLAS, FFT from OxiFFT, HDF5 from oxih5, compression from the oxiarc family — all pure-Rust crates in the same COOLJAPAN ecosystem. The pitch is that cargo add scirs2 and a release build are all you need.

What's inside

The workspace splits into three tiers of crates:

• Core scientific computing: scirs2-linalg, scirs2-stats, scirs2-optimize, scirs2-integrate, scirs2-interpolate, scirs2-special, scirs2-signal, scirs2-sparse, scirs2-spatial
• Advanced modules: scirs2-fft, scirs2-cluster, scirs2-ndimage (N-dimensional image processing), scirs2-io, scirs2-datasets, scirs2-validation
• AI/ML: scirs2-autograd, scirs2-neural, scirs2-graph, scirs2-transform, scirs2-metrics, scirs2-text, scirs2-vision, scirs2-series

A meta-crate, also named scirs2, re-exports everything so a user can pull in the whole stack with one dependency or pick individual crates. The array foundation is ndarray 0.17.2 plus a forked scirs2-numpy crate that keeps ndarray-0.17 support alive.

There are also two binding layers: scirs2-python, PyO3 bindings across 15+ modules (feature-gated, off by default), and scirs2-wasm, WebAssembly/TypeScript bindings for browser and Node.js with SIMD and Web Worker support. A Julia interface lives under julia/.

The layered architecture

A usage policy governs how the crates relate to each other. Every module is expected to route shared functionality through scirs2-core — validation via scirs2-core::validation, errors based on CoreError, numerics through scirs2_core::numeric, and performance work through core's SIMD, parallel and memory modules:

// Expected in non-core crates per the usage policy
use scirs2_core::validation;   // parameter checking
use scirs2_core::error::CoreError;  // base error type

The intent is consistent APIs, centralized version control and a single place to optimize. scirs2-core carries the shared infrastructure: a work-stealing scheduler and NUMA-aware par_map_chunks, SIMD operations, buffer pools, GPU backends (GpuContext, GpuBackend), memory metrics and profiling.

Getting started

Installation is deliberately boring:

cargo add scirs2
cargo build --release

Optional performance features are additive rather than required: oxifft for the high-performance FFT, mpsgraph for Apple Metal on macOS, a per-crate cuda feature (added in 0.6.0) for NVIDIA GPUs across ten crates via pure-Rust oxicuda-*, and arbitrary-precision for GMP/MPFR.

A minimal program uses the integration crate's prelude:

use scirs2::prelude::*;

let a = Array2::from_shape_vec((3, 3), vec![1.0, 2.0, 3.0,
                                            4.0, 5.0, 6.0,
                                            7.0, 8.0, 9.0])?;
let (u, s, vt) = scirs2::linalg::decomposition::svd(&a)?;

Neural-network code follows a familiar Sequential model with layers, activations, losses and optimizers, plus fit/predict.

How the work flows

The project runs on unusually strict quality gates. The README claims zero compilation errors, zero clippy warnings and zero rustdoc warnings across the workspace, enforced by lints in Cargo.toml — including a rule that new code use expect() with descriptive messages rather than bare unwrap(). Tests run through cargo nextest, not plain cargo test.

The 0.6.5 release notes describe a full audit of every #[ignore]-tagged test: each one was actually executed and root-caused, then re-tagged with an explicit reason (requires-gpu: / requires-env: / slow: / bench: / not-implemented:). A new tool, cargo-scirs2-policy, enforces that taxonomy going forward so ignored tests can't silently accumulate without justification.

The release notes also read like a running list of "it worked by accident" bugs being made real. The headline fix in 0.6.5 is the autograd backward pass: a ~670-line dispatch chain keyed on op-name strings only covered 58 of 281 differentiable ops, silently returning identity gradients for everything else. Dispatch now consults each op's own Op::grad() first, converting roughly 223 wrong-or-absent gradients into correct ones — including every elementary math function and activation like softplus, gelu and mish. The public custom-gradient API (custom_op, scale_gradient) had been a no-op; it now works.

Similar honesty fixes landed across the workspace: a real convergence-checked eigenvalue/Schur engine in scirs2-linalg, corrected one-sided Kolmogorov-Smirnov p-values and F-test values in scirs2-stats, a spectral clustering that computes actual linear algebra instead of random stand-ins, and 83 orphaned-but-real signal-processing files wired back into scirs2-signal.

Platform story

The README claims identical behavior across Linux, macOS, Windows and WebAssembly. That cross-platform promise has been tested by hard bugs: v0.6.3 fixed a cluster of platform-specific crashes — heap corruption from an alloc/dealloc layout mismatch in scirs2-spatial, a stack overflow from recursive Drop glue in scirs2-symbolic, and a process abort from eager pre-allocation in scirs2-transform. The 0.6.4 release fixed a wasm32 threading compile error that had blocked publishing the scirs2-wasm and meta crates.

Should you use it?

If your project needs SciPy-style numerics in Rust without wrangling system BLAS/LAPACK, or if you want autograd and neural-network primitives on top of a pure-Rust stack, this is a serious candidate — the workspace claims 38,768 tests across all features plus 5,136 doc-tests. If you're already happy with ndarray plus C-backed BLAS bindings, the main tradeoff to weigh is that SciRS2 buys portability and zero-dependency installs at the cost of adopting a large, fast-moving ecosystem where some modules (notably scirs2-optimize, scirs2-stats, scirs2-special) still carry in-progress compilation fixes.

A ROADMAP.md sits at the top level of the repository; the README's stated goal is a comprehensive pure-Rust scientific-computing and AI/ML ecosystem with SciPy-compatible APIs. For now it stands as a large pure-Rust scientific-computing effort: ~3.87M SLoC across 8,134 Rust files in 29 workspace crates, with a policy that keeps the stack C/Fortran-free by default.