Oscar.jl puts GAP, Polymake, Antic and Singular behind one Julia namespace

One namespace over four separate computer algebra systems

OSCAR describes itself as a comprehensive open source computer algebra system for computations in algebra, geometry and number theory, and as a new system that combines the capabilities of four cornerstone systems: GAP, Polymake, Antic and Singular. Each of those is a mature program with its own language, its own data model and its own community. OSCAR does not replace them. It exposes them, and it adds a layer that lets objects from one of them meet objects from another.

The README is explicit that the cornerstones remain available directly, which is the detail that tells you how to think about the project. You are not restricted to the unified interface, and for some tasks the direct route is the right one. The example session shows both styles in a single file, with OSCAR types at first and then raw Polymake calls underneath.

The audience is academic and research. The topics attached to the repository are abstract algebra, computer algebra, mathematics, and Julia packaging, the development documentation has a dedicated introduction for new developers, and the funding section names the German Research Foundation. The version banner in the README even shows a development version, 1.9.0-DEV, which is the clearest signal that this is a project with a release cadence and a moving target rather than a stable service.

Installing is a Pkg call, with caveats on the website

OSCAR requires Julia 1.10 or newer. The README says that in principle it can be installed and used like any other Julia package, and that doing so will take a couple of minutes. The three lines that do it are:

julia> using Pkg
julia> Pkg.add("Oscar")
julia> using Oscar

That is the whole happy path, and it is genuinely short. The caveat is the sentence that follows, which says that some of OSCAR's components have additional requirements, and points to the installation instructions on the project website for more detailed information. Those extra requirements are exactly where a first install can go wrong, since a component that calls out to an external system needs that system present, and the README does not enumerate which components need what.

Two consequences follow for planning. First, a pinned, reproducible environment is not a one line operation, because the dependency requirements of individual components have to be checked against the installation page. Second, the difference between an in principle install and a working one is where the documentation earns its keep, so the installation page is not optional reading for a serious deployment.

The package is registered in the Julia ecosystem, so the usual Julia package workflow applies for adding it to a `Project.toml` as a dependency of your own environment rather than adding it to the default environment.

Number fields in three calls, with the order computed for you

The example session in the README is worth reading as documentation, because it shows the shape of the interface. A quadratic field is created with one call:

julia> k, a = quadratic_field(-5)
(Imaginary quadratic field defined by x^2 + 5, sqrt(-5))

The call returns two values, the field and a generator. The next call, `maximal_order(k)`, returns the maximal order of that field, and the printed result includes the Z-basis, so the structure of the ring of integers is visible without the user computing it. Then the factorisation machinery is applied directly to an element of that order:

julia> factorizations(zk(6))
2-element Vector{Fac{AbsSimpleNumFieldOrderElem}}:
 -1 * -3 * 2
 -1 * (sqrt(-5) + 1) * (sqrt(-5) - 1)

The output shows two factorisations, one trivial and one that splits into elements of the order, which is the kind of result that in a less integrated system requires moving between a number field package and a factorisation package by hand.

The style to notice is that the type names are visible in the output, with `AbsSimpleNumFieldOrderElem` and `Fac` appearing in the vector type, and that the printed results are meant to be read by a person. For a research tool that is a deliberate choice: the returned object carries its type, so downstream code can dispatch on it, while the display stays legible.

Graded rings, modules and homomorphisms in one linear type system

The second half of the example moves from number theory into commutative algebra, and it is the part that shows the type system doing the work.

A multivariate polynomial ring over the rationals is created with `polynomial_ring(QQ, [:x1,:x2])`, returning the ring and its generators, and it is then graded with `grade(Qx, [1,2])[1]`, which produces a ring whose grading is printed as x1 mapping to [1] and x2 to [2]. Elements are then built in that graded ring, and `degree(f)` returns the degree vector [2] for the element x1 squared plus x2.

From there the example builds a free module of rank one over the graded ring with `free_module(R, 1)`, takes a submodule with `sub`, forms a quotient with `quo`, computes a homomorphism with `hom`, and finally evaluates the map on a generator with `mH(H[1])`. The printed result is a full module homomorphism, with source, target and generator, which is exactly the kind of output you would otherwise assemble by hand from basis and coefficient lists.

The API is functional and the operations compose. `sub(...)[1]`, `quo(F, s)[1]` and `grade(...)[1]` all use the same indexing convention, where a function returns a tuple and the first element is the object of interest, with the rest carrying extra data. The consistency is worth noting because it means the mental model transfers from one family of objects to the next instead of changing shape at every step.

The cornerstones are one call away when the unified layer is in the way

The README shows that the underlying systems stay reachable, and the example is a polymake session rather than an OSCAR one:

julia> C = Polymake.polytope.cube(3);

julia> C.F_VECTOR
pm::Vector<pm::Integer>
8 12 6

julia> RP2 = Polymake.topaz.real_projective_plane();

The f-vector of the three dimensional cube comes back as three numbers, and the last call constructs the real projective plane through polymake's `topaz` interface. The results are polymake's own types, printed with polymake's own type annotations, not wrapped in OSCAR types.

This is the actual difference in approach between OSCAR and using the four systems separately. Each system alone is a complete environment with its own syntax, its own object conventions and its own conventions for output. OSCAR offers a common surface for the operations it has unified, and it deliberately leaves the rest alone, so a problem that is natively polymake's can be solved natively in polymake without translating the question into OSCAR's vocabulary first.

The trade is that a workflow crossing the boundary has to decide where to cross it. Objects that OSCAR has unified can be passed between components, but a raw polymake object has to be converted before it can be used in an OSCAR operation. How smooth those conversions are for a given problem is not described in the README, and for a project evaluating the system that is the question to test with a real workload.

The repository layout shows four systems' worth of integration work

The top level of the repository is where the scale of the integration becomes visible. There is `src/` for the Julia code, `gap/` for the GAP side, `system/` for what appears to be the external system components, `ext/` for Julia extension packages, and `experimental/` for work that is not yet stable. There are also `data/`, `docs/`, `etc/`, `test/`, `examples/`, `Artifacts.toml` and a `regression_candidates/` directory.

That last directory name is telling. A computer algebra system that wraps other systems accumulates a long tail of cases where the layers disagree, and keeping those cases in the repository is what lets the project notice when a change re-breaks one. The `test/` directory alongside it, plus the coverage and CI configuration in `.github/` and `.codecov.yml`, describe a project that treats correctness as a tracked property.

The examples are named rather than generic. `examples/BlockSys.jl` and `examples/PerfectPowers.jl` are two self-contained programs, which suggests the intended way to learn the system is to read a worked example in full rather than to work through a tutorial of fragments. The repository also carries `AGENTS.md` and `CLAUDE.md`, so the project has been set up for contributors working with coding assistants, and the development documentation linked from the README has an introduction for new developers, which is where the architecture notes live.

Research funding, a custom licence, and a version that moves often

The funding section states that development is supported by the German Research Foundation within the Collaborative Research Center TRR 195. That is the key fact about the project's character. The support is for research rather than for a company maintaining a product, which tells you what to expect from the release notes and what to expect from issue triage.

The releases are frequent and small. v1.8.0 came on 2026-07-14, v1.8.1 on 2026-08-10 and v1.8.2 on 2026-09-02, with the development version in the README banner at 1.9.0-DEV. The last push to the repository was on 2026-10-20 and the project is not archived, so work is landing. A patch release every few weeks is good news for bug fixes and a warning for reproducibility, since a project on that cadence is not promising a frozen API.

The licence needs attention. The repository ships `LICENSE.md` rather than a standard licence file, and GitHub's own classifier lists the licence as a custom one that it cannot categorise. There is no summary of the terms in the README, so the file itself is the only source. If you intend to use OSCAR in published work, in a commercial pipeline or inside a larger product, that text has to be read and interpreted, and a licence checker in your compliance tooling will not resolve it for you.

For attribution, the README points to a citing page on the project website, and the repository carries `CITATION.cff` and a `.bibtoolrsc` file, so a paper that used OSCAR has a defined way to cite it.

Editorial conclusion

Oscar.jl suits a researcher in abstract algebra, number theory or algebraic geometry who wants the four cornerstone systems in one place with a shared object model, and it does not suit a production service that needs a stable, semver-friendly API or a permissive licence that a compliance tool can read. Before you build on it, read the installation page linked from the README, because some components need extra requirements, and check `LICENSE.md` in the repository root, since the project ships a licence GitHub cannot classify automatically.

Frequently asked questions

Official sources

1. Issues
2. oscar-system/Oscar.jl on GitHub
3. Project website
4. README
5. Releases