sklears-core
The foundational crate for sklears, providing core traits, types, and utilities that power the entire machine learning ecosystem. Actively evolving (Partial) — core traits and error handling are stable, while some advanced modules are still maturing; see Status.
Latest release:
0.2.0(July 14, 2026). See the workspace release notes for highlights and upgrade guidance.
Overview
sklears-core provides the fundamental building blocks for all sklears algorithms:
- Core Traits: Comprehensive ML abstractions with type-safe state management
- Advanced Type System: Compile-time validation, phantom types, const generics
- Performance Infrastructure: SIMD, an oxicuda-backed GPU backend (
gpu::{GpuBackend, GpuArray, GpuMatrixOps}) that gracefully reports "no GPU" instead of faking a CPU fallback, memory pooling, parallel processing - Error Handling: Rich error types with context propagation and recovery
- Integration: scikit-learn compatibility, format I/O, cross-framework support
- Trait Explorer Tooling: Graph-based analysis of the crate's own trait relationships (hub/bridge/bottleneck node detection, Newman modularity, small-world coefficient), plus API reference generation. Also includes
trait_explorer::security_analysis, an internal dev-tooling module (not part of the public ML API) for compliance/security-metrics assessment of trait usage, with data-backed constructors for common regulatory frameworks (GDPR, HIPAA, CCPA, SOX, FERPA, ISO 27001, NIST CSF, COBIT, ITIL, CIS Controls).
Status
- Implementation: 0.2.0 ships with >99% of the planned v0.1 APIs implemented (141 stubs remaining). Status: Partial — actively evolving, not yet claiming full stability.
- Validation: Covered by 863 passing crate tests (
cargo nextest run -p sklears-core --all-features). - Performance: Pure Rust implementation with ongoing performance optimization via SIMD, threading, and cache-friendly layouts. An oxicuda-backed GPU backend (
gpu::GpuBackend/GpuArray/GpuMatrixOps) is available behind thegpu_supportfeature, wired directly tooxicuda-driver/oxicuda-blas;GpuBackend::detect()gracefully returnsOk(None)on machines without a usable GPU rather than silently substituting a fake backend. - API Stability: Minor breaking changes possible in pre-1.0 releases; stabilization roadmap tracked in the root
TODO.md.
Core Trait System
Base Traits
Estimator<State>
The foundational trait for all ML models with compile-time state tracking:
Learning Traits
// Supervised learning
// Incremental/online learning
// Unsupervised learning
Prediction Traits
// Standard predictions
// Probabilistic predictions
// Decision scores
Advanced Features
Async Trait Support
GPU Acceleration
Behind the gpu_support feature, backed by real oxicuda-driver / oxicuda-blas calls (no CPU-fallback stub):
use ;
// `detect()` gracefully returns `Ok(None)` when no GPU/driver is present,
// instead of silently substituting a fake backend.
if let Some = detect?
Type-Safe State Management
Prevent common ML errors at compile time:
use ;
// Model starts untrained
// Only untrained models can be fitted
// Only trained models can predict
This prevents:
- Calling
predict()on untrained models - Accessing parameters before fitting
- Double-fitting models
- All caught at compile time!
Advanced Type System
Compile-Time Validation
use ;
// `ValidatedConfig<T, S>` tracks validated/unvalidated state via a phantom type parameter;
// `.validate()` moves an `Unvalidated` config into a `ValidatedState` one, or returns an error.
let config = new;
let validated = config.validate?;
// Const-generic range validators, e.g. RangeValidator::<0, 1>, implement `ParameterValidator`
// for `i32`/`f64` parameters.
Phantom Types for Safety
The Untrained/Trained-style phantom-type pattern shown above for Estimator<State> is used
throughout the crate (and downstream estimator crates) to encode task/state distinctions at
compile time. There is no separate sklears_core::phantom module — the pattern is applied
directly via each type's own state parameter (as in the Model<State> example above), not via a
shared Classification/Regression marker-type module.
Performance Features
SIMD Optimizations
use SimdOps;
// Automatic SIMD acceleration
let distances = euclidean_distances_simd?;
Memory Efficiency
use MemoryPool;
// Reusable-buffer pool (max_buffers, buffer_size)
let pool: = new;
let mut buffer = pool.get_buffer;
Error Handling
Rich error types with context:
use ;
Macro System
Powerful macros for boilerplate reduction:
use quick_dataset;
use ;
// Quick dataset creation (field names are `data`/`target`, not `features`/`feature_names`)
let dataset = quick_dataset!;
// ML-specific trait-bound alias (takes a single trait name; the bound list itself is fixed)
define_ml_float_bounds!;
// Automatic test generation (takes only the estimator type name)
estimator_test_suite!;
Integration & Compatibility
sklears_core::compatibility provides metadata-level interop helpers (not full zero-copy tensor
exchange):
use CrossPlatformModel;
use NumpyArray;
use ndarray_to_pytorch_tensor;
use DataFrame;
// scikit-learn metadata round-trip (parameters/weights/version, not a live estimator)
let model = from_sklearn_metadata?;
// NumPy-compatible array wrapper (shape/strides/dtype), built from an owned ndarray
let np_array = from_ndarray?;
// PyTorch-compatible tensor bytes + metadata (shape/dtype/device)
let = ndarray_to_pytorch_tensor?;
// Pandas-compatible DataFrame built from an ndarray
let df = from_ndarray?;
Note: there is no SklearnEstimator::from_sklearn(...) drop-in estimator conversion, and no
array.to_numpy()/array.to_torch_tensor()/Dataset::from_polars() methods — the real surface is
the module-level metadata/tensor-descriptor helpers shown above.
Format I/O
sklears_core::format_io::DataFormat covers:
- CSV, JSON, Parquet
- HDF5, NPY/NPZ
- Arrow, Feather, Binary, MessagePack
(ONNX/PMML/MLflow are mentioned in module docs as aspirational targets but are not yet implemented formats in DataFormat.)
Builder Pattern
Consistent API across all estimators:
let model = builder
.learning_rate
.max_iter
.early_stopping
.validation_fraction
.n_jobs
.random_state
.build?;
Testing Infrastructure
Contract Testing
sklears_core::contract_testing provides infrastructure for verifying estimator contracts
(shape/state invariants) hold across implementations.
Mock Objects
use ;
// Simulates fit/predict timing and failure behavior for testing error-handling code,
// rather than returning a caller-supplied canned prediction.
let mock = builder
.with_behavior
.with_fit_failure_probability
.build;
There is no sklears_core::testing module or proptest-based properties::assert_* helper
module — property-based testing in this crate is done ad hoc per-module with proptest! directly,
not through a shared assertion-helper API.
Contributing
We welcome contributions! See CONTRIBUTING.md.
License
Licensed under the Apache License, Version 2.0.
Citation