Mercury Has Landed: Arbitrary-Precision Math for JWCEssentials
I am happy to announce that Mercury has now joined the JWCEssentials family.
Mercury is a native C library for arbitrary-precision floating-point arithmetic. It is designed around a simple but powerful idea: instead of forcing large numbers through decimal-first thinking, Mercury stores them in a machine-native base-232 positional format.
That means each “digit” of the number is a 32-bit unsigned integer. On modern hardware, this is a very natural way to build large-number arithmetic, because two 32-bit words can be multiplied with room for the result and carry inside a 64-bit operation. It is not base 10 dressed up for the machine. It is the machine’s own kind of arithmetic brought closer to the surface.
Why Mercury?
One of the most interesting lessons from writing big-number software is that representation matters. Decimal is excellent for people. Binary and hexadecimal are excellent for machines. Mercury leans into that distinction.
A Mercury number is stored as a sign flag, an exponent, and a sequence of 32-bit mantissa words. The number can then be viewed cleanly through hexadecimal, where each 32-bit word maps perfectly to eight hex digits. This gives hexadecimal a special role: it becomes a transparent window into the native representation, rather than a lossy-looking conversion layer.
That makes Mercury especially useful for the kinds of topics I want to write more about: arbitrary precision, numerical representation, computation, multiplication, division, square roots, powers, logs, and eventually the bridge between numerical engines and computer algebra systems.
The Native Core and the Managed Wrapper
Mercury itself lives as a native C library under:
JWCEssentials/C/MercuryThe managed wrapper lives in:
JWCEssentials/Project/JWCEssentials.netThe wrapper assembly is named Mercury.net. I chose that name intentionally. Mercury should be able to stand on its own as a numerical engine without being over-branded. JWCEssentials can host it, document it, and build around it, but the library itself deserves a clean identity.
On the .NET side, the wrapper exposes the native engine through UltraNumber, giving C# code a much friendlier surface: operator overloads, parsing, string conversion, precision management, and thread-local stack handling.
The Scratch Stack Model
One of Mercury’s design choices that I especially like is that arithmetic functions do not casually allocate temporary memory from the heap. Instead, Mercury uses a caller-supplied scratch stack.
That design keeps temporary allocation explicit, deterministic, and fast. A function asks the stack for temporary space, performs the calculation, and then releases that space in reverse order. This makes the native engine easier to reason about and keeps the door open for GPU-minded execution models, where memory discipline matters.
In other words, Mercury is not just a big-number library. It is also an experiment in making the “nuts and bolts” of arbitrary-precision computation visible and teachable.
A Base-232 View of Math
Most of us are trained to think in base 10. That is natural, cultural, and useful. But the machine does not owe base 10 any special loyalty.
When Mercury prints a number in hexadecimal, it is not merely choosing a programmer-friendly display format. It is showing the number in a form that lines up directly with the internal representation. Eight hex digits correspond exactly to one 32-bit word.
That makes hexadecimal a kind of inspection window. It lets us look at a large computed value without immediately paying the cost, complexity, and conceptual distraction of decimal conversion.
For example, π begins in hexadecimal as:
3.243F6A8885A308D313198A2E03707344A4093822...That may look unusual if decimal is the only familiar lens, but it is not less mathematical. It is simply a different coordinate system for the same value.
Where This Is Going
Mercury gives me a stable base for a series of articles I have wanted to write for a long time.
I want to talk about multiplication at the limb level. I want to show how large-number division works. I want to explore square roots, powers, logarithms, and constants such as π and e. I also want to connect those topics to the larger question of computer algebra systems: where symbolic mathematics ends, where numerical computation begins, and how the two can support one another.
I am also looking forward to making some of this visual. CrystalCatalyst gives me a way to draw the behavior of algorithms, not just describe them. A geometric sine and cosine solver, arbitrary-precision constants, and native hexadecimal output all belong to the same larger story: math is not only something we calculate. It is something we can watch unfold.
Status
Mercury is now building on both Ubuntu and Windows, with the native library and managed wrapper in place. The project is young, but the foundation is real.
This is the beginning of a new numerical-computation thread inside JWCEssentials. Mercury is the native body. Mercury.net is the managed bridge. UltraNumber is the friendly C# face.
And for the blog, this opens the door to something I am very excited about: showing big-number math not as a black box, but as a living set of understandable operations.
Mercury has landed.