The original RIES is one of those programs that permanently changes how you think about symbolic computation. You give it a number, and instead of evaluating an equation, it tries to discover one. That inversion of the normal workflow is still strange and beautiful decades later.
ries-rs started as a practical rewrite, but it became a discipline project too: keep the core search model recognizable, modernize the implementation, and make the result reproducible enough to serve as a real reference implementation rather than just a nostalgic port.
Why rewrite it at all?
There were four reasons.
First, I wanted the solver in a language that made long-term maintenance believable. The original code has real historical value, but Rust gives me stronger memory safety guarantees, clearer module boundaries, and a much better base for extending the project into bindings and browser targets.
Second, I wanted deterministic and machine-readable workflows. A lot of mathematical software is still optimized for terminal interaction only. That is useful, but it makes automation and reproducibility harder than they should be. In ries-rs, structured JSON output and run manifests are first-class.
Third, I wanted the same engine available in more than one place. The project is not just a CLI anymore. It now has Python bindings and a WebAssembly build, which means the same search logic can run in a script, a notebook, or directly in the browser.
Fourth, I wanted to document the system honestly. That means conservative benchmark claims, explicit scope boundaries, and an architecture that can be explained without hand-waving.
What stayed the same
The core idea is still the original RIES idea.
The solver enumerates valid postfix expressions up to a complexity limit. Some of those expressions contain x; those become candidate left-hand sides. Others are constant-only expressions; those become candidate right-hand sides. The search then tries to solve equations of the form LHS(x) = RHS numerically and ranks the matches it finds.
That matters because the project is not trying to become a vague “equation suggestion” engine. It is still an exhaustive search system within a bounded complexity budget. No hidden heuristics, no language-model guesswork, no fake magic layer on top.
What Rust changed
The rewrite let me make a few things explicit that were awkward before.
- Parallel search is built into the implementation instead of treated as an afterthought.
- Deterministic mode makes it possible to get stable output ordering for reproducible runs.
- Structured outputs make the tool usable in automation and downstream analysis.
- The codebase is organized around clearer subsystems rather than a single dense historical program shape.
One important lesson here was that “rewrite in Rust” does not automatically mean “faster in every way.” Some workloads are dominated by generation and parallelize well. Others are dominated by matching and refinement, where the gains are smaller. I wanted the published claims to reflect that instead of pretending every graph points straight up.
Why the WASM build mattered
The browser version is not a toy wrapper around a server. It is the same solver compiled to WebAssembly and running client-side. That changes the feel of the project completely.
Once the app could run in the browser, it became reasonable to make ries-rs part of this site instead of just linking out to a repo. The project page can now embed the actual tool, and the writeup can point to something the reader can use immediately instead of something they have to install first.
That deployment path also forced better discipline around packaging. A web build exposes every bad assumption about file layout, initialization, and runtime dependencies very quickly.
Scope matters more than ambition
One thing I have tried to keep clear is what ries-rs is and is not.
It is a modern reference implementation of the RIES search model with better ergonomics, broader interfaces, and reproducible execution modes.
It is not a symbolic AI platform, not a conjecture engine, and not a claim that the classic algorithm should be replaced by something trendier. The value of the project is precisely that it takes an existing idea seriously enough to implement it cleanly, document it well, and expose it in forms people can actually use.
Where it goes next
The next phase is less about invention and more about tightening the system:
- keeping release, package, and citation surfaces aligned
- stronger documentation around search complexity, ranking, and reproducibility
- continued polish on the browser interface and onboarding
- more examples for research and scripting workflows
The live demo on this site is part of that work. It turns the project from “available in principle” into “usable right now,” which is the standard I want the rest of the site to meet too.
You can explore the project on the project page, try the live demo, or browse the source on GitHub.
Related Project
The work this piece is connected to