AngouriMath: symbolic algebra for C# and F#

A computer algebra system in the .NET ecosystem

AngouriMath is described as an open-source cross-platform symbolic algebra library for C# and F#, and the description adds that it can be used for both production and research purposes.

The subject is computer algebra rather than numerical computing. Where a numeric library answers what is 1 divided by 3 to fifteen decimal places, a symbolic one returns the expression itself, and keeps it as an expression that can be differentiated, integrated, expanded, substituted into and printed. The topics attached to the repository reflect that: algebra, calculus, differentiation, integration, equations, inequality, solver, symbolic-manipulation, parsing, LaTeX, arbitrary-precision and computer-algebra.

The project lives under the ASC-Community organisation, its website is am.angouri.org with a quick start guide and a what is new page, and there is a Discord for questions. The licence is MIT, the primary language is C#, and the last push to the repository was on 2026-10-20.

The release history is busy for a library of this kind. Version 2.5.0 was published on 2026-09-09, 2.4.0 on 2026-08-28 and 2.3.0 on 2026-08-23, so three minor releases landed inside a fortnight and a half. That is worth noticing for a different reason than excitement, because minor releases in a symbolic algebra library can carry behaviour changes in simplification or in how expressions are represented, and the repository carries a file called BREAKING-CHANGES.md precisely for that.

The audience is a .NET developer who needs exact symbolic results, and the F# package exists because the F# community is where a lot of research code lives.

Five NuGet packages, and where the boundaries sit

The versions table in the README lists five NuGet packages, and the split tells you more about the project than a single package description would.

AngouriMath is the kernel, the C# entry point that everything else is built on. AngouriMath.FSharp is the F# binding. AngouriMath.Interactive is the package for use in a notebook or interactive session. AngouriMath.Experimental holds features that are not yet considered stable. And AngouriMath.Terminal is a terminal front end.

The experimental package is the one to look at first if you are evaluating the project, because it is the project's own statement about where the boundary between a supported API and an experimental one lies. Anything you build on AngouriMath.Experimental is a bet that the API will not change, and the fact that it is a separate package rather than a namespace inside the kernel means the maintainers think of that boundary as significant enough to enforce with a package reference.

The Terminal package is the least obvious one and rather useful. A command line front end to a computer algebra system means you can script symbolic work, pipe results into other tools, and use it in a shell pipeline without writing a C# program. For a team that only occasionally needs a factorisation or a limit, that is a much lower barrier than a project reference.

The Interactive package is the Jupyter route, and the README links a Binder environment for the AngouriMathLab repository, along with a .NET Fiddle link. Those two links are a good sign about how the project expects people to try it, in both languages.

The C++ port is marked work in progress in the version table

The C++ row of the versions table is different from every other row, and it is worth reading carefully.

For the kernel, the F# package, the interactive package, the experimental package and the terminal package, the table shows NuGet prerelease versions, stable versions and download counts. For C++, the table shows a GitHub release badge for the latest semantic version including prereleases, and then the words WIP in both the stable and prerelease columns.

So the C++ side is not a released package at all. The header line above the table says the library covers C#, F#, Jupyter and C++ with the last marked as work in progress, and the table confirms it.

That distinction matters for anyone planning around it. The C++ repository the badge points at is AngouriMathLab, which is also the repository behind the Binder environment, so it is a real and active codebase rather than a placeholder. But a WIP column in a version table is a promise that the C++ surface is not stable, and the .NET packages are the ones with a released version you can pin.

The practical reading is that AngouriMath is a .NET library first, with a native port in progress. If your team is a C++ shop, the honest position today is to evaluate the C++ build as a project you would track and possibly patch, rather than as a package you can depend on today.

Four build pipelines, three operating systems

The status board in the README is unusually detailed for a library README, and it is the best evidence of how the project is maintained.

There is a build and a test workflow for each of four targets: Kernel and C#, F#, Interactive, and C++. That is eight separate CI workflows, and the README states that all tests and builds are tested for three operating systems, Windows, Ubuntu and Mac OS.

The reason for four targets rather than one is the packaging story from the previous section. The kernel, the F# binding, the interactive front end and the native port are separate deliverables with separate surfaces, and each gets its own build and test run. A change to the kernel can break the F# binding without touching it, and the per target workflows make that visible in the status board rather than in a bug report.

The multi platform testing is the other thing worth noting. A symbolic algebra library touches floating point behaviour, arbitrary precision arithmetic and file encoding, and all three of those differ between platforms. Building the same three operating systems in the matrix is the minimum for a library that people run on a developer laptop and in a Linux CI container.

The status board is embedded in the README itself, which means the badges are the current state rather than a snapshot from a release announcement, and you can check the project at the moment you read it rather than trusting a claim in a blog post.

Coverage is published for the C# kernel and unknown for the rest

The coverage table has three columns, Kernel/C#, F# and C++, and only the first is filled in.

The C# kernel column links to a codecov graph for the repository branch, which is the standard continuous coverage report and lets you see which lines are exercised. The F# and C++ columns both contain three question marks.

It would be easy to read those question marks as a criticism, and it would be wrong to. The most likely reading is that coverage reporting is wired up for the C# kernel and simply has not been enabled for the other two targets, which is a common state of affairs in a project where the C# kernel is where nearly all the code and nearly all the users are. The question mark is an honest absence rather than a claim of zero coverage.

Still, it is the piece of information to weigh when you pick a binding. The F# binding is a layer over the kernel rather than an independent implementation, so the kernel's coverage is evidence about the code that does the work, and the F# package's own surface is smaller. For the C++ port, however, the port is a reimplementation in a different language, and the repository layout shows the C++ side is in a separate repository, AngouriMathLab, which means the C# coverage number tells you nothing about it.

So the coverage table gives you a clear answer to one question and a clear silence on another, and the silence is about the part of the project that is least ready.

A changelog, a breaking changes file and two agent instruction files

The repository root is short, and each entry is a signal about how the project is worked on.

There is CHANGELOG.md, which is the ordinary release history. There is BREAKING-CHANGES.md, which is the one to read before upgrading, for the reason given earlier, that a symbolic algebra library can change how expressions are represented or simplified between minor versions without that being a bug. There is CONTRIBUTING.md and CODE_OF_CONDUCT.md, which is the standard pairing for a community project.

Then there are AGENTS.md and CLAUDE.md, and these are recent enough to be worth a note. They are instruction files for automated coding agents, and their presence tells you that the project expects contributions to be prepared with an AI assistant in the loop. For a project whose contributors are largely students and researchers in mathematics and computer science, that is a deliberate bet on how the next generation of contributors will work.

The code itself lives entirely under Sources, so the repository root holds documentation and metadata rather than a mixed tree. The actual project structure, with its projects for the kernel, the F# binding, the interactive front end, the terminal front end and the native side, is inside that directory.

There is also a Discord badge and a link to the awesome-dotnet list, which tells you the project has a place in the wider .NET ecosystem rather than being an isolated tool.

Where it fits, and where a numeric library fits better

The honest way to place AngouriMath is against the alternatives rather than against nothing.

If what you need is symbolic manipulation, differentiation, integration, equation solving, inequality handling, LaTeX output and parsing, and you want to stay inside the .NET ecosystem, there is not a long list of options, and AngouriMath is the one with a published, stable, well versioned package set and a CI matrix across Windows, Ubuntu and Mac OS.

If what you need is fast numeric work, matrix algebra, statistics, linear solvers or optimisation, then AngouriMath is the wrong category of tool. Numeric libraries in .NET are mature, tuned and well understood, and a symbolic library will not replace them, because they answer different questions. A good rule is that a symbolic system is what you reach for when the answer is supposed to be an expression, and a numeric library is what you reach for when the answer is supposed to be a number in a specific format.

The comparison against Mathematica or a commercial computer algebra system is also a matter of scope rather than of quality, and the practical difference is licence cost, deployment, and how much of a .NET application you want to keep in one language.

What to check first, then, is narrow. Pin a version and re-run your expressions against it, because 2.3.0, 2.4.0 and 2.5.0 landed in quick succession. Read BREAKING-CHANGES.md for the range you are crossing. Check whether the feature you need sits in the main package or only in AngouriMath.Experimental, because that is the difference between a stable dependency and a moving one. And if you need the C++ port, plan to track it rather than to consume it, since the version table marks it WIP in both columns.

Editorial conclusion

AngouriMath suits a .NET team that needs exact symbolic answers, such as deriving an expression, solving an equation in closed form, or emitting LaTeX for a document, because the C# kernel is a real computer algebra system rather than a wrapper around a numeric one, and the F# and interactive packages let the same code be used from a notebook. It does not suit a project that mainly wants fast numeric linear algebra, matrix work or statistics, because that is a different class of library, and it does not suit a team that needs the C++ port today. Before you adopt it, pin the exact version you tested, since 2.3.0, 2.4.0 and 2.5.0 all landed within a few weeks of each other, read BREAKING-CHANGES.md rather than relying on the changelog alone, and check the codecov badge for the C# kernel, because the F# and C++ coverage columns in the README are marked as unknown.

Frequently asked questions

Official sources

1. ASC-Community/AngouriMath on GitHub
2. License: MIT
3. Project website
4. README
5. Releases