If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/mathnet/mathnet-numerics shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 1y ago

• 10 active contributors
• Distributed ownership (top contributor 45% of recent commits)
• MIT licensed
• Tests present
• ⚠ Stale — last commit 1y ago
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live mathnet/mathnet-numerics repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/mathnet/mathnet-numerics.

What it runs against: a local clone of mathnet/mathnet-numerics — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in mathnet/mathnet-numerics | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 462 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of mathnet/mathnet-numerics. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/mathnet/mathnet-numerics.git
#   cd mathnet-numerics
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of mathnet/mathnet-numerics and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "mathnet/mathnet-numerics(\\.git)?\\b" \\
  && ok "origin remote is mathnet/mathnet-numerics" \\
  || miss "origin remote is not mathnet/mathnet-numerics (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "MathNet.Numerics.sln" \\
  && ok "MathNet.Numerics.sln" \\
  || miss "missing critical file: MathNet.Numerics.sln"
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f "build/build.fs" \\
  && ok "build/build.fs" \\
  || miss "missing critical file: build/build.fs"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f ".github/dependabot.yml" \\
  && ok ".github/dependabot.yml" \\
  || miss "missing critical file: .github/dependabot.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 462 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~432d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/mathnet/mathnet-numerics"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Math.NET Numerics is a comprehensive numerical computing library for .NET and Mono, providing optimized implementations of linear algebra, FFT, statistics, special functions, probability distributions, interpolation, and curve fitting. It supports both managed C# code and optional native providers (Intel MKL, OpenBLAS, ATLAS, CUDA) for performance-critical linear algebra operations, making it the numerical foundation for scientific computing in the .NET ecosystem. Multi-faceted monorepo structure with: core algorithms in src/Numerics (C#), F# idiomatic wrappers in src/FSharp, platform-specific native providers in src/Providers/{MKL,OpenBLAS,ATLAS,CUDA}, data import extensions in src/Data/{Matlab,Text}, and build orchestration via FAKE scripts (build/Building.fs, build/Packaging.fs, build/Publishing.fs). Separate .sln files exist for each provider variant (MathNet.Numerics.MKL.sln, MathNet.Numerics.CUDA.sln, etc.) to manage conditional compilation and dependencies.

.NET and F# developers building scientific, engineering, and data analysis applications who need production-grade numerical algorithms without implementing them from scratch. Data scientists using .NET, quantitative analysts, and researchers needing high-performance matrix operations with optional native backend acceleration.

Highly mature and production-ready. The codebase is substantial (~12.9M lines of C#, ~246K F#), well-organized across multiple NuGet packages with multiple native provider bindings (MKL, OpenBLAS, ATLAS, CUDA), and maintains separate release notes per provider. Has comprehensive CI/CD setup (appveyor.yml, dependabot.yml) and multiple solution files for different configurations, indicating long-term active maintenance and broad enterprise adoption.

Low risk for core functionality but moderate complexity in native provider integration. The library maintains 4+ separate native provider packages (MKL, OpenBLAS, ATLAS, CUDA) requiring platform-specific binaries and configuration, increasing deployment complexity. The signed assemblies approach (MathNet.Numerics.Signed.nuspec) and multi-platform targeting add maintenance burden. No visible major breaking changes in recent release notes, but the native provider ecosystem introduces version coupling risks.

Active maintenance with dependabot monitoring (.github/dependabot.yml), recent Paket package management updates (.paket/Paket.Restore.targets), and multiple provider package variants under active release management (separate RELEASENOTES files for CUDA, MKL, OpenBLAS, Data packages). The presence of fresh build scripts and CI configuration indicates ongoing development, though specific recent commits are not visible in the provided file list.

git clone https://github.com/mathnet/mathnet-numerics.git
cd mathnet-numerics
# Restore dependencies via Paket (configured in .paket/)
./build.sh              # On Linux/macOS
build.cmd               # On Windows

The FAKE build system is configured in build/build.fs and handles compilation, testing, and packaging across all provider variants.

Daily commands: Build system: ./build.sh (Linux/macOS) or build.cmd (Windows) executes FAKE scripts in build/build.fs. For core library: targets .NET Standard/Framework via project files in solution. For native providers: build.cmd/sh handles conditional compilation per provider variant (see build/NativeProvider.targets). Testing invoked via build system configuration in build/Testing.fs.

• MathNet.Numerics.sln — Primary solution file that orchestrates all core and provider-specific projects; essential for understanding project structure and dependencies.
• Directory.Build.props — Centralized build configuration file that defines version, metadata, and common build settings across all projects.
• build/build.fs — FAKE build script that defines the complete build, test, and packaging pipeline for all supported platforms and providers.
• README.md — Project overview and architecture rationale; establishes the vision for numerical computing across .NET/Mono and provider integration strategy.
• .github/dependabot.yml — Dependency management configuration; ensures security updates for the library and its build toolchain are tracked.
• NuGet.config — NuGet feed configuration that resolves internal and external package dependencies for the build system.
• build/NativeProvider.targets — MSBuild targets file that conditionally includes native provider bindings (MKL, OpenBLAS, CUDA, ATLAS) based on platform and configuration.

• Core Numerics (C#) (C#, .NET Standard) — Implements all algorithms in pure managed code: linear algebra (decompositions, solvers), statistics (distributions, estimation), special functions, interpolation, FFT, integration, root-finding.
  • Failure mode: Algorithm bugs propagate to all users; mitigation via extensive NIST/Matlab reference dataset testing
• F# Extensions — Wraps C# APIs with idiomatic F# operators, modules, and

Add a new numerical algorithm to the core library

1. Implement the algorithm in C# in an appropriate namespace under src/Numerics/ (e.g., src/Numerics/LinearAlgebra/ for linear algebra, src/Numerics/Statistics/ for statistics) (src/Numerics/[Algorithm].cs)
2. Add corresponding F# wrapper module in src/FSharp/ to expose idiomatic F# API (src/FSharp/[Algorithm].fs)
3. Create unit tests in tests/ directory mirroring the source structure (tests/Numerics.Tests/[Algorithm]Tests.cs)
4. Add F# tests if applicable (tests/FSharp/[Algorithm]Tests.fs)
5. Update build/build.fs to ensure new tests are included in the test target (build/build.fs)

Add support for a new native provider (e.g., MKL, OpenBLAS, CUDA)

1. Create a new .sln file for the provider variant (e.g., MathNet.Numerics.NewProvider.sln) (MathNet.Numerics.NewProvider.sln)
2. Create a provider-specific project wrapping native bindings under src/Providers/ (src/Providers/MathNet.Numerics.NewProvider/NativeInterop.cs)
3. Create MSBuild targets file to conditionally link provider binaries (build/NewProvider.targets)
4. Add NuSpec packaging template for the provider package (build/MathNet.Numerics.NewProvider.nuspec)
5. Update build/Packaging.fs and build/Publishing.fs to include the new provider in automated packaging (build/Packaging.fs)

Create a data format reader/writer (e.g., new matrix serialization)

1. Implement reader/writer in src/Numerics/Data/ following the pattern of existing TextData, MatlabData formats (src/Numerics/Data/[FormatName]/[FormatName]Reader.cs)
2. Add integration extension methods or factory methods to Matrix/Vector classes (src/Numerics/LinearAlgebra/Matrix.cs)
3. Create test fixtures in data/[FormatName]/ with sample test files (data/[FormatName]/sample.ext)
4. Add unit tests covering read/write round-trip and edge cases (tests/Numerics.Tests/Data/[FormatName]ReaderTests.cs)

• C# — Core portable implementation across .NET Framework and .NET Core; enables broad platform support and IDE integration.
• F# — Provides idiomatic functional API and maintains numerical types (e.g., BigRational) that originated in F# PowerPack for scientific computing.
• P/Invoke & Native Providers (MKL, OpenBLAS, CUDA, ATLAS) — Pluggable native backends for 10–100× performance gains on linear algebra and FFT; allows users to swap managed code for optimized libraries at deployment time.
• FAKE (F# Make) — Cross-platform build automation in F# enabling complex conditional logic for multi-variant packaging (core, provider-specific, platform-specific).

• Pluggable native providers vs. single optimized backend

  • Why: Numerics must work everywhere (no native deps required) but also accelerate where possible; conditional linking allows users to trade size/complexity for speed.
  • Consequence: Requires maintaining parallel code paths and extensive testing across all combinations; build complexity increases significantly.

• Both C# and F# libraries instead of single language

  • Why: C# reaches maximum .NET audience; F# provides mathematical expressiveness and type safety that users expect in scientific computing.
  • Consequence: Code duplication and double maintenance burden; must keep APIs synchronized and test both paths.

• MIT license + acceptance of contributions

  • Why: Maximizes adoption and community contributions for a foundational numerics library.
  • Consequence: Requires strong governance and review discipline to maintain code quality as external contributions scale.

• Real-time computing (optimized for throughput, not latency guarantees)
• Symbolic/algebraic manipulation (numerical only; not a CAS)
• GPU-first design (CUDA is optional provider, not primary path)
• Cross-language bindings beyond .NET ecosystem (C# and F# only)
• Deep learning or automatic differentiation (out of scope; focus on classical numerical methods)

Native provider complexity: Building with MKL/OpenBLAS/CUDA requires corresponding native libraries installed; managed-only builds work without them. Solution file selection: Multiple .sln files exist (MathNet.Numerics.sln is core; MathNet.Numerics.MKL.sln, etc. for providers)—opening the wrong one omits provider code. Paket restore: Must run Paket restore before normal NuGet; .paket/Paket.Restore.targets handles this but watch for locked dependency versions. Signed assemblies: MathNet.Numerics.Signed.nuspec exists separately; requires build/MathNet.Numerics.snk for signing. Platform-specific binaries: Native providers are x86/x64/platform-specific; nuspec files in build/ have Windows vs Linux variants. F# PowerPack migration: BigRational is maintained here post-F# discontinuation; code assumes F# knowledge in src/FSharp/.

• LU Decomposition & Solving Linear Systems — Core to numerical linear algebra; Math.NET implements multiple factorization types (LU, QR, SVD, Cholesky) used throughout the library for system solving and matrix inversion—understanding these is essential to using the linear algebra module correctly
• FFT (Fast Fourier Transform) — Math.NET provides highly optimized FFT implementations (via managed code and native providers); critical for signal processing, filtering, and spectral analysis applications in scientific computing
• Sparse Matrix Formats (CSR, CSC) — Large-scale linear systems in scientific computing use sparse matrices; Math.NET supports compressed row/column storage formats for memory efficiency and performance on large, mostly-zero matrices
• Probability Distributions & Random Number Generation — Math.NET implements 50+ continuous and discrete distributions with fast sampling; essential for Monte Carlo simulations, Bayesian inference, and statistical modeling—must understand seeding and thread-safety for reproducibility
• Cubic Spline Interpolation — Math.NET provides multiple interpolation schemes (cubic spline, linear, Akima); used extensively in data fitting and curve smoothing where exact function values between data points are needed
• Numeric Integration (Quadrature Rules) — Math.NET implements Gauss-Legendre, adaptive quadrature, and other integration schemes; essential for approximating definite integrals in scientific computing where closed-form solutions don't exist
• Provider Pattern / Pluggable Backends — Math.NET's architecture allows swapping managed .NET implementations with optimized native providers (MKL, OpenBLAS) at runtime; understanding the provider interface in src/Providers/ is critical for maintaining and extending the library

• MicrosoftDocs/dotnet-api-docs — Official .NET API documentation source; Math.NET Numerics implementation examples often reference .NET Framework classes and should align with canonical documentation patterns
• Intel-HPC/mkl-dnn — Intel MKL deep learning components; Math.NET's MKL provider bindings wrap MKL kernels, so understanding MKL API evolution is critical for provider maintenance
• xunit/xunit — Unit testing framework likely used in test projects; important for understanding test infrastructure in src/UnitTests/
• fsprojects/FSharp.Data — Companion F# data access library; Math.NET's F# extensions and data import modules (src/Data/) often work alongside FSharp.Data for scientific pipelines
• numpy/numpy — Spiritual predecessor in Python ecosystem; many algorithms and decompositions in Math.NET are ported from or parallel NumPy/SciPy, useful for algorithmic understanding

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for native provider platform detection and fallback logic

The repo supports multiple native backends (MKL, OpenBLAS, ATLAS, CUDA) with platform-specific nuspec files (build/MathNet.Numerics.MKL.Linux-x64.nuspec, .Win-x64.nuspec, etc.) and a NativeProvider.targets file. There's likely insufficient test coverage for the provider selection logic across different OS/architecture combinations. A new contributor could add integration tests to verify correct native provider loading and graceful fallback behavior when providers are unavailable.

• [ ] Examine build/NativeProvider.targets to understand current provider detection logic
• [ ] Review existing test structure in the repo to identify where native provider tests belong
• [ ] Create unit tests covering: Linux x64/x86 provider detection, Windows x64/x86 detection, CUDA availability checking, fallback to managed implementation
• [ ] Add parameterized tests for each supported native provider configuration
• [ ] Document the testing approach in CONTRIBUTING.md if it's a new testing pattern

Add missing GitHub Actions workflows for multi-target framework validation

The repo has appveyor.yml for Windows CI but .github/dependabot.yml shows it uses GitHub. There's no visible GitHub Actions workflow file (.github/workflows/*.yml) for running tests across the multiple supported solution files (MathNet.Numerics.sln, MathNet.Numerics.MKL.sln, MathNet.Numerics.OpenBLAS.sln, MathNet.Numerics.CUDA.sln, MathNet.Numerics.ATLAS.sln). A contributor could create a comprehensive matrix-based workflow that validates each solution configuration.

• [ ] Create .github/workflows/test-matrix.yml with matrix strategy for: [MathNet.Numerics.sln, MathNet.Numerics.MKL.sln, MathNet.Numerics.OpenBLAS.sln]
• [ ] Add matrix dimensions for: os (ubuntu-latest, windows-latest), dotnet-version (from Directory.Build.props or .csproj files)
• [ ] Configure workflow to call existing build.sh/build.cmd scripts (referencing CONTRIBUTING.md for build instructions)
• [ ] Add workflow badges to README.md
• [ ] Document workflow maintenance requirements in CONTRIBUTING.md

Create data validation and format documentation for Matlab and MatrixMarket test data

The repo contains test data in data/Matlab/ and data/MatrixMarket/ directories with multiple file formats (.mat, .mtx, .csv, .txt). There's no documentation explaining the purpose of each file, their generation methodology, or validation checksums. This makes it difficult for contributors to understand or modify test data appropriately.

• [ ] Create data/README.md documenting each test data file with: purpose, format description, size, generation method
• [ ] Add checksums (SHA256) for each file to data/README.md for integrity validation
• [ ] Create a data/VALIDATE.md script (e.g., PowerShell/Bash) that verifies checksums and loads sample data to ensure integrity
• [ ] Document which tests use which data files by searching test project files for file path references
• [ ] Add note to CONTRIBUTING.md about data file modification requirements (regenerating checksums, updating documentation)

• Add missing unit tests for special functions in src/Numerics/SpecialFunctions/—many advanced functions (polylogarithm, Chebyshev polynomials) lack comprehensive test coverage; start by writing tests for one family of functions in src/UnitTests/SpecialFunctionsTests.cs.
• Expand F# API documentation examples in src/FSharp/ with concrete runnable samples in examples/ directory—currently many F# extension modules have XML doc comments but no worked examples showing when/why to use them vs C# equivalents.
• Add native provider auto-detection helper to simplify fallback configuration—src/Numerics/Providers/Control.cs currently requires manual provider registration; add heuristic detection of available native libraries (MKL, OpenBLAS) to reduce boilerplate for users.

The Math.NET Numerics codebase demonstrates generally good security practices as a numerical library focused on algorithms rather than web services or data handling. The main security concern is the committed strong name key file (build/MathNet.Numerics.snk), which poses a supply chain risk and should be moved to a secrets management system. Secondary concerns include test data management practices and documentation of multiple solution file purposes. No injection vulnerabilities, exposed credentials in filenames, or obvious misconfigurations were detected. The project appears well-maintained with appropriate use of .gitignore and standard C# project structure.

• Medium · Hardcoded Strong Name Key File — build/MathNet.Numerics.snk. The file 'build/MathNet.Numerics.snk' is a strong name key file that is committed to the repository. Strong name keys should not be stored in version control as they can be used to sign assemblies and potentially compromise the supply chain. Fix: Move the SNK file outside of version control. Store it securely in a secrets management system (e.g., Azure Key Vault). Use environment variables or build-time injection to provide the key during the build process. Add .snk files to .gitignore.
• Low · Multiple Solution Files Without Clear Separation — MathNet.Numerics.*.sln files. Multiple .sln files exist (ATLAS, CUDA, MKL, OpenBLAS, standard), which could lead to confusion about which build artifacts are produced and complicate dependency management across variants. This increases risk of accidental inclusion of wrong provider implementations. Fix: Maintain clear documentation about which solution file is used for which purpose. Implement CI/CD checks to ensure only the correct solution is built for each configuration. Consider using a single solution with conditional compilation or project dependencies.
• Low · Test Data Files in Repository — data/ directory (data/NIST, data/Matlab, data/MatrixMarket). The 'data/' directory contains multiple test and sample data files (CSV, MAT, MTX files). While these appear to be legitimate test data, storing large datasets in version control can inflate repository size and create supply chain risks if data provenance isn't tracked. Fix: Consider moving large test data files to an external storage system (e.g., AWS S3, Azure Blob Storage) and downloading them during test execution. Maintain a manifest of data files with checksums/hashes to verify integrity. Document the source and license of all test data.
• Low · Vagrant Configuration File Present — Vagrantfile. A Vagrantfile is present in the repository, which may contain environment-specific configurations. While Vagrant files are typically safe, they should be reviewed to ensure no hardcoded credentials or sensitive paths are included. Fix: Review the Vagrantfile contents to ensure no credentials, API keys, or sensitive paths are hardcoded. Use environment variables for any configuration that varies by environment. Document the Vagrant setup requirements clearly.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.