Truth in the Flip: The First Quantis Source-Entropy Run Is Complete

The first mature Truth in the Flip experiment driven directly by Quantis source entropy is complete.

Quant.tkr stopped at 8,903,400,000,000 flips after producing eighty-nine complete 100-billion-flip segments. The run used direct Quantis source entropy without an additional whitening stage and applied MetaGuess as its anticipation strategy.

The final length was chosen deliberately. It closely matches the established crypto3 tracker, which contains approximately 8.918 trillion flips and the same number of complete default-scale segments.

That gives the project its first clean matched-length comparison between a mature computational random source and a mature physical quantum entropy source.

The Run Said the Same Thing Consistently

The most surprising feature of Quant.tkr was not a dramatic final endpoint.

It was the regularity of the profile.

As the run grew from a few trillion flips to almost nine trillion, its central measurements changed only gradually. Shorter windows continued to produce substantial favorable excursions, while longer windows continued to spend and settle predominantly below baseline.

At the 10-billion-flip rolling scale, the completed record finished with:

segments                  89
median best TrueZ         +1.626320
average best TrueZ        +1.681835
average end TrueZ         -0.665331
median end TrueZ          -0.664580
average mean TrueZ        -0.845842
average time above 50%     49.0576%
best TrueZ >= 1.96         30.3371%
positive settlements       28.0899%

The median best excursion remained near +1.63 through much of the mature run. Roughly three out of every ten completed segments crossed +1.96, while average settlement remained negative.

That is a remarkably stable form:

Favorable local movement appeared regularly, but favorable settlement did not persist with it.

The Default Scale Was More Severe

At the default 100-billion-flip scale, the same distinction became stronger:

segments                  89
median best TrueZ         +0.401426
average best TrueZ        +0.383116
average end TrueZ         -0.920284
median end TrueZ          -0.995049
average mean TrueZ        -0.967614
average time above 50%     41.6180%
positive settlements       23.5955%
positive means             13.4831%

The typical segment still reached a modest positive maximum, but most segments spent much of their histories below baseline and settled close to TrueZ = -1.

This is the clearest mature characterization of the run:

Positive excursion was common enough to be structurally visible.
Positive occupation was less common.
Positive settlement was uncommon.
A durable positive advantage did not emerge.

A Positive Endpoint Inside a Negative Geometry

Quant.tkr happened to stop at a positive current endpoint.

The active 10-billion window ended at anticipation TrueZ = +1.4111, while the active default window ended at +0.7017.

Those values do not overturn the completed-window record.

They illustrate why a lifetime endpoint and a distribution of completed paths must remain separate.

A tracker may stop while its current window is favorable even though most prior windows settled negatively. Likewise, a tracker may stop negative despite having produced many favorable excursions throughout its history.

The final endpoint answers:

Where was the tracker when it stopped?

The segment distribution answers:

How did the tracker behave repeatedly across the run?

For Quant.tkr, the second question carries the stronger result.

The Record Was Not Featureless

Although the aggregate profile remained negative in settlement, the run contained a wide variety of local regimes.

It produced:

• segments that remained negative throughout;
• large positive excursions that disappeared before closing;
• segments that spent almost all of their time above baseline but settled near neutral;
• a complete strongly positive 100-billion-flip segment;
• severe negative settlements;
• later favorable regimes that softened the aggregate without reversing it.

This is an important reminder that randomness need not look flat.

A random record may be locally coherent, dramatically directional, and highly expressive over finite intervals. What it refuses to provide is a dependable promise that the current regime will continue.

Randomness may form a pattern without becoming bound to preserve it.

Matched Against crypto3

The completed Quantis run now stands beside crypto3 at the same eighty-nine-segment horizon.

Both trackers share the same broad geometry:

• positive best excursions;
• negative average settlement;
• stronger movement at shorter windows;
• limited persistence at the default scale.

Their exact measurements differ.

Quantis showed weaker default-scale excursion and less time above baseline, while its 10-billion settlements were somewhat less negative and its positive ending rate was somewhat higher.

Those differences are worth preserving, but they should not yet be called permanent source signatures.

One mature run from each condition cannot separate:

• source behavior;
• strategy behavior;
• run-to-run variation;
• window effects;
• ordinary sampling variation.

The matched records establish a baseline, not a final classification.

The Temptation of AntiMetaGuess

The consistently low default-scale settlement and mean values make AntiMetaGuess an especially tempting next experiment.

MetaGuess expresses a principle of change:

What has just characterized the process may be precisely what fails next.

AntiMetaGuess expresses the complementary principle:

What has just characterized the process may continue to characterize it.

The negative completed-window geometry of Quant.tkr naturally invites the question of whether the complementary strategy will produce a different distribution on fresh source entropy.

But an AntiMetaGuess run would not be an exact reversal of Quant.tkr.

The source bytes are distributed among worker threads nondeterministically, and a new run would receive an entirely new physical entropy stream. The experiment would compare strategies across independent records rather than applying both strategies to the identical sequence.

That comparison is still valuable. It simply answers a different question:

Does the complementary anticipation principle develop a measurably different path geometry on fresh physical entropy?

Why RNG Mode Still Comes Next

The previously announced next experiment uses Quantis RNG mode with MetaGuess.

That sequence remains scientifically clean because it preserves the anticipation strategy while changing the hardware output mode.

The first completed run used direct source entropy.

The next run will use the device’s conditioned RNG output.

By holding the tracker, strategy, window sizes, reporting rules, and target length constant, the experiment can isolate one main contrast:

Does the Quantis conditioning stage change the temporal geometry observed by Truth in the Flip?

This is a cleaner immediate test than switching strategy and source realization at the same time.

AntiMetaGuess remains the more philosophically mischievous experiment. RNG mode remains the more controlled next experiment.

QuantisExtractor and the Next Experimental Path

The practical bridge to that next run is now taking shape.

QuantisExtractor has been brought up successfully on Ubuntu, providing a cross-platform path for extracting and routing Quantis output into the Truth in the Flip source system.

The planned fluent switch is:

-IDQE <rsource>

The intention is to allow another random source to feed QuantisExtractor directly through the existing command structure.

This gives the experiment a reusable way to distinguish:

• direct source entropy;
• conditioned Quantis RNG output;
• optional downstream source handling;
• future alternate transformations or extraction paths.

The switch is more than a command-line convenience.

It creates a clean experimental seam.

Hardware acquisition, output mode, extraction, transformation, and anticipation can remain separate layers rather than becoming entangled inside one specialized test path.

The First Physical Baseline

Quant.tkr is now committed as the first mature direct source-entropy MetaGuess artifact.

Its role is not to prove that MetaGuess succeeds or fails universally.

Its role is to establish a carefully preserved physical baseline:

• 8.9034 trillion flips;
• 89 complete default segments;
• direct Quantis source entropy;
• no additional whitening stage;
• MetaGuess anticipation;
• matched-length comparison with crypto3;
• stable short-scale excursion;
• negative long-scale settlement.

Future experiments can now agree with it, diverge from it, or reveal that its distinctive features belonged only to this particular run.

That is what makes a mature artifact valuable.

It gives the next experiment something more substantial than an expectation to confront.

It gives it a record.

Closing Statement

Across 8.9 trillion direct source-entropy flips, Quant.tkr repeatedly formed favorable local excursions while most completed long-scale windows occupied and settled below baseline. Its final positive endpoint belongs to, rather than overturns, a mature record of excursion without general persistence.

The first Quantis horizon is complete.

The next horizon will ask whether conditioned RNG output travels through randomness in the same way.

After that, AntiMetaGuess waits with a beautifully simple challenge:

When continuity performs poorly, does contradiction acquire a different path—or does pure entropy deny them both with equal creativity?

github.com/johnwaynecornell/TruthInTheFlip

Artifacts/Trackers

Truth in the Flip on Pure Entropy: A Positive Island in a Negative Sea

The first direct source-entropy Quantis run has now passed 4.4 trillion flips and completed forty-four 100-billion-flip segments.

The overall character of the run remains predominantly negative at the default window scale. Most completed segments have settled below chance, positive mean behavior has been uncommon, and the accumulated edge profile still favors excursion over persistence.

Then the record produced something new.

It did not merely cross into positive territory for a moment. It produced an entire completed segment in which excursion, duration, mean position, and settlement all aligned positively.

A Segment That Held Together

Segment 35 became the strongest positive default-scale segment observed in the Quantis run so far:

best TrueZ   +3.500148
mean TrueZ   +1.922725
end TrueZ    +3.269991
time > 50%   100.000%

The anticipation remained above chance throughout the complete 100-billion-flip segment.

This distinction matters.

Many earlier segments produced positive excursions but surrendered them before the window closed. Their best observed points were favorable, while their mean positions and settlements remained negative.

Segment 35 was different. Its positive movement was not merely visited. It was occupied, maintained, and carried through completion.

Pure entropy did not merely generate a positive peak. For one complete window, it generated a favorable history that held together from beginning to end—and then declined to make a promise of it.

The Window Before and the Window After

The surrounding record makes the segment more interesting.

Only two completed windows earlier, segment 33 had produced the most severe negative settlement observed in the run:

best TrueZ   -1.090119
mean TrueZ   -3.026320
end TrueZ    -4.908690
time > 50%    0.000%

That segment never entered positive territory at the default scale. It remained negative throughout and finished nearly five standard deviations below the tracker baseline.

The record then moved through segment 34 and into the strongly positive segment 35.

Segment 36 also rose dramatically:

best TrueZ   +3.366188
mean TrueZ   +1.589000
end TrueZ    -0.044797
time > 50%   98.200%

It spent almost the entire window above chance and reached a high positive excursion, yet closed almost exactly at neutral.

This three-part sequence provides a compact demonstration of the distinctions at the heart of Truth in the Flip:

• segment 33 showed sustained negative settlement;
• segment 35 showed sustained positive settlement;
• segment 36 showed strong positive occupation without retained settlement.

The source moved through all three forms without preserving any one of them as a permanent state.

The Larger Record Remains Negative

One exceptional segment does not overturn the wider profile.

Across forty-four completed default windows, the aggregate measurements remained:

median best TrueZ       +0.350330
average end TrueZ       -1.001970
median end TrueZ        -1.009307
average mean TrueZ      -1.002358
average time above 50%   38.6545%

Only about one fifth of the completed segments ended above chance, and only a small minority maintained a positive mean.

The run therefore continues to show a familiar asymmetry:

Positive movement is possible.
Positive excursion is recurring.
Positive settlement is uncommon.
Permanent advantage has not appeared.

Segment 35 is important not because it proves an edge, but because it demonstrates that durable positive local structure is not absent from the physical entropy record.

The Shorter Window View

The same tracker was also examined through a rolling 10-billion-flip window.

At that scale, the run continued to display frequent positive excursions:

median best TrueZ       +1.632050
average end TrueZ       -0.706615
median end TrueZ        -0.651880
best TrueZ >= 1.96       31.8182%
average time above 50%   47.9801%

Shorter windows reveal favorable intervals far more often than the default 100-billion-flip view. But those intervals frequently disappear before the larger segment closes.

This is not a contradiction.

The two window sizes ask different questions.

• The 10-billion-flip view asks how often meaningful local ascent appears.
• The 100-billion-flip view asks whether that ascent survives prolonged accumulation.

The answer so far is that local ascent appears regularly, while durable settlement remains rare.

What Real Randomness May Look Like

Randomness is often imagined as visually flat, uneventful, and immediately balanced.

A physical random process does not owe us that appearance.

It may produce long negative intervals, coherent positive regimes, sharp reversals, extended occupation above chance, and dramatic movements that later disappear.

None of those features alone establishes prediction.

Their presence does show why randomness can be mistaken for intention. A sufficiently rich random record does not avoid structure. It continually produces local structure while refusing to preserve it as a dependable law.

Randomness may be locally coherent without becoming globally committed.

The Quantis source-entropy run has now produced both its strongest negative segment and its strongest positive segment within the same growing record.

That contrast is valuable.

It shows that the experiment is not observing a simple downward tendency, nor has it discovered a stable upward advantage. It is observing a process capable of forming compelling regimes in either direction.

Excursion Is Not Settlement

Truth in the Flip preserves several distinctions that are easily lost when attention is placed only on the final number.

A best observed TrueZ measures excursion.

A mean TrueZ measures the typical position occupied during the segment.

An ending TrueZ measures settlement.

The percentage of observations above chance measures duration.

Segment 36 demonstrates why these measures must remain separate. It was positive for almost the entire window and reached above +3.36, yet finished near neutral.

Segment 35 demonstrates what happens when they align. It rose, remained positive, held a positive mean, and closed strongly above chance.

These two neighboring windows did not behave equivalently, even though they were generated by the same hardware source, processed by the same anticipation method, and measured under the same reporting rules.

That does not violate classical expectation. It reveals the diversity of finite paths contained within it.

The First QRNG Fingerprint

As this run matures, it is beginning to form a useful experimental fingerprint.

At the shorter scale, the fingerprint includes:

• frequent positive excursions;
• a median best TrueZ near +1.63;
• approximately one third of segments crossing +1.96;
• negative average settlement;
• nearly balanced time above and below chance.

At the default scale, the fingerprint includes:

• smaller positive excursions;
• average and median settlement near -1;
• positive endings in roughly one fifth of segments;
• predominantly negative mean behavior;
• rare but substantial coherent positive regimes.

Future Quantis runs can now be compared against this first record.

The next planned contrast is direct RNG mode rather than direct source-entropy mode. The hardware will remain the same, while the device’s internal output mode changes.

The important question will not be whether the next run happens to finish higher or lower.

The deeper question will be whether it produces the same temporal geometry:

• the same excursion distribution;
• the same settlement tendency;
• the same frequency of coherent positive windows;
• the same relationship between short and long scales.

No Promise, but a Record

The strongest positive segment does not promise that another will follow.

The strongest negative segment did not prevent one from appearing.

That may be the clearest lesson of this checkpoint.

The record carries history, but history does not command the next interval.

Each completed segment becomes part of the evidence without becoming a law imposed upon the future.

The path remembers where it has been.
Randomness remains free to go somewhere else.

At 4.42 trillion flips, Truth in the Flip has not discovered a dependable advantage in direct quantum source entropy.

It has discovered a remarkably expressive record: negative seas, positive islands, strong excursions, failed settlements, and one complete favorable window that held together from beginning to end.

Whatever the eventual Truth in the Flip may be, this is a moment worth preserving.

TruthInTheFlip_sample_report3 -print Detailed $NewAgeData/Documents/Trackers/Quant.tkr -window WindowByTotal def -grade all -whole -info > ~/Quant_def.20260720_075853.txt

TruthInTheFlip_sample_report3 -print Detailed $NewAgeData/Documents/Trackers/Quant.tkr -window WindowByTotal 10000000000 -grade all -whole -info > ~/Quant_10B.20260720_075853.txt

github.com/johnwaynecornell/TruthInTheFlip

Truth in the Flip Meets Quantum Randomness: First Light from a Quantis QRNG

After years of working with software-generated and cryptographic random sources…
TruthInTheFlip has crossed a new experimental threshold. The project is now receiving its bits from a physical quantum random number generator.

This is not an announcement that quantum randomness has revealed a predictive edge. It is the story of bringing a new instrument online, integrating it into the existing framework, and examining the first substantial record with the same caution that has guided the project’s recent development.

The instrument is an ID Quantique Quantis PCIe New Generation quantum random number generator. Its first serious TruthInTheFlip run reached more than 557 billion flips while sustaining approximately 11.13 million flips per second.

The result did not settle into a dramatic statistical victory. That is important. It produced excursions, including a lifetime rise beyond Z = +2, but ultimately returned close to equilibrium. In doing so, the run gave the project something more foundational than a headline result: a stable physical baseline and a new field for comparison.

From Software Randomness to a Physical Source

TruthInTheFlip began with a simple question:

Can an anticipation strategy perform better than chance over a sufficiently large record of random bits?

Over time, that question became more nuanced. Long tracker runs showed that a temporary statistical peak is not the same thing as a persistent edge. A process may rise impressively, remain above chance for a time, and then settle back toward equilibrium as the record continues to grow.

This led to a broader interpretive vocabulary:

• Excursion describes how strongly a result can rise locally.
• Settlement describes where it tends to finish.
• Persistence describes how durably it remains above or below its baseline.

The next natural step was to change the source of uncertainty itself.

Previous runs used pseudorandom and cryptographic random-number generators. A Quantis device introduces a physical source whose randomness originates in quantum processes measured by dedicated hardware. The tracker, anticipation system, segmentation, and reporting remain the same. The constraint changes.

This makes the Quantis run valuable whether it rises, falls, or remains neutral. It allows TruthInTheFlip to ask whether a physical quantum source produces a coherence profile that differs from software-based sources under the same analytical framework.

Getting the Hardware Online

The installation was not entirely ceremonial.

The card arrived at a pickup location, and I brought it home by Lyft. During installation, I unknowingly displaced some motherboard jumpers and initially received no power from the workstation. Once that was corrected, the hardware came online successfully under Windows.

Windows introduced its own compatibility constraint. The available Quantis Windows driver and library were from version 20.2.4 and provided only a 32-bit native interface, requiring TruthInTheFlip to run through the 32-bit .NET loader on that platform.

Ubuntu presented a different challenge. ID Quantique’s automated Debian packages installed the user library, headers, DKMS source, and device rules, but the kernel driver had not actually been registered and built for the active kernel.

The package appeared installed:

pcie-chip-unix-dkms 24.4-2
quantis-rng-libs-bundle 24.4-2

Yet modinfo could not locate the module, lsmod showed nothing, and the native QuantisCount function reported zero devices.

The missing step was to register and build the supplied source through DKMS. Once the module was added, built, installed, and loaded, the driver announced itself:

quantis_chip_pcie v24.4.2
Firmware version: 19.1.1
Serial number: ###########
RNG MODE (qrng_mode:0)

The device node appeared as:

/dev/qrandom0

At that point, the managed test advanced all the way into the native read path. The hardware, kernel module, native library, and .NET interop layer were finally connected.

The Stable Quantis API Beneath Changing Drivers

The software history initially looked confusing.

The current Linux package was version 24.4.2, while the Windows package was still based on the older 20.2.x line. Online searches often emphasized newer-looking Qrng* APIs and suggested that the older Quantis* entry points represented a legacy product.

A comparison of archived Quantis.h headers showed a more useful reality: the core handle API has remained stable across the available releases.

The common operations are:

QuantisOpen
QuantisReadHandled
QuantisClose

The simpler QuantisRead function opens the device, performs a read, and closes it again for every request. That is convenient for occasional calls, but TruthInTheFlip is a continuous consumer. A persistent handle is a better match.

The final architecture therefore uses one maintained path:

Open the Quantis device once
    ↓
Read repeatedly through QuantisReadHandled
    ↓
Close the handle during shutdown

This provides one lifecycle model across both Windows and Linux and avoids maintaining a second fallback implementation that would need its own testing and failure behavior.

What the Handle Benchmark Revealed

The difference between repeated open-and-close reads and handled reads was measurable.

Using the original non-handled QuantisRead path, small buffers performed as follows:

1 KiB: 0.62 MiB/s
2 KiB: 0.89 MiB/s
4 KiB: 1.34 MiB/s

At 4 KiB and above, throughput remained almost perfectly flat at approximately 1.34 MiB/s. This appeared to be the sustained generation rate of the hardware and driver rather than a limitation of PCIe transport or managed code.

After moving to QuantisReadHandled:

1 KiB: 0.97 MiB/s
2 KiB: 1.49 MiB/s
4 KiB: 1.34 MiB/s

The 1 KiB case improved by approximately 56 percent, and the 2 KiB case improved by approximately 67 percent. Larger reads remained at the same physical throughput ceiling.

This was exactly the expected pattern. Persistent handles do not make the quantum source generate entropy faster, but they remove a significant fixed cost from smaller calls.

The benchmark therefore validated the architectural decision for two reasons:

• Handled reads are measurably better for low-latency and small-buffer use.
• They provide the cleaner long-lived resource model even when larger reads already saturate the device.

When Whitening Became a Random Source

During the integration, I initially expected the Quantis API to provide separate native calls for raw and conditioned output. The installed library did not export the anticipated QuantisReadRaw entry point, and ID Quantique’s extraction layer appeared to be implemented in another library or statically linked component.

That led to a useful simplification.

If the experimental goal is to compare the native stream with a bias-reduced stream, the whitening algorithm does not need to belong inside the Quantis device abstraction. It can be applied to any random source.

The first implemented transform is a classic von Neumann extractor:

00 → discard
11 → discard
01 → 0
10 → 1

For an independent source with a stable bit bias, the unequal pairs 01 and 10 occur with equal probability. The retained output therefore removes simple first-order bias, although it does not claim to eliminate arbitrary serial correlation or certify randomness.

The important architectural move was to make whitening a composed random source rather than a Boolean device setting.

The resulting command-line form is:

TruthInTheFlip -rsource Whiten Quantis PCI 0

This means:

Whiten(
    Quantis("PCI", 0)
)

The command is not interpreted through a custom composite identifier. Instead, the registry parser recognizes that the Whiten function accepts another BitFactory and recursively parses the next source expression as its parameter.

The same mechanism allows:

-rsource Whiten NET1
-rsource Whiten NET2
-rsource Whiten Quantis PCI 0

This fits the framework better than a Quantis-specific whitening switch. Quantis remains an entropy source. Whitening becomes a general transformation over sources. The command line becomes a small reflected composition language whose structure corresponds directly to function parameters.

One Device, Multiple Entropy Modules

The Quantis card reports one PCIe device but contains two entropy modules. Its installed-module mask is:

0x3

In binary, that is 0011, indicating that modules zero and one are present.

During early testing, the functional status sometimes appeared as 0x1 or 0x2 rather than 0x3. The original managed readiness check interpreted this as a fatal condition because it required every installed module to be simultaneously reported as functional.

A review of ID Quantique’s own read logic showed that the vendor library uses a less restrictive condition. It proceeds whenever the functional status is greater than zero—that is, whenever at least one entropy module is available.

The managed check was therefore stricter than the native read contract.

After a complete power cycle, both modules returned online. This also suggested that the device could retain configuration or initialization state across a warm transition between operating systems. A shutdown that does not fully remove PCIe power is not always equivalent to a cold boot.

The revised policy treats zero functional modules as fatal while preserving partial-module status as diagnostic information. For scientific runs, the installed, functional, and power masks can be recorded with the tracker metadata rather than silently ignored.

First Light: 557.2 Billion Quantum-Backed Flips

The first substantial Quantis-backed run reached:

557,200,000,000 flips
wallclock: 13:54:12
throughput: 11,132,363 flips per second

The heads distribution remained close to equilibrium:

heads: 50 + 5.8e-05%
ZHeads: +0.3690

The anticipation result also finished near neutral:

anticipated: 50 + 2.8e-05%
Z: approximately +0.18

This is reassuring from an instrumentation perspective. The new physical source ran continuously, the handled interop path remained stable, the tracker maintained its expected throughput, and no obvious gross bias appeared in the heads distribution.

The lifetime path was more interesting than the endpoint.

During the run, the anticipated result reached a maximum Z above +2:

lifetime maxZ: +2.094914
TrueZ near the strongest excursion: +2.028129

But the excursion did not persist. The lifetime report ultimately settled almost exactly at equilibrium:

final z: -0.025006
time above 50%: 52.8356%

The initial segmented report contained only six segments, so its metrics remain preliminary. Even so, they described the early profile clearly:

Edge Excursion Score:   +0.280187
Edge Settlement Score:  -0.708360
Edge Persistence Index: -0.366052

In plain language, the run was capable of positive local movement, but those movements generally did not survive to the segment endpoints.

This is not evidence of a persistent predictive edge. It is a useful example of why TruthInTheFlip distinguishes excursion from settlement.

Why the Z = 2 Excursion Is Not the Conclusion

A Z value above 1.96 is conventionally notable when it is the outcome of a single precommitted test. A long tracker run is observed repeatedly across many intermediate points. Under repeated observation, eventually crossing a familiar threshold is less surprising than crossing it once at a predetermined endpoint.

This is why a peak cannot carry the interpretation by itself.

TruthInTheFlip now asks several different questions:

• How high did the process rise?
• How often did similar excursions occur?
• Where did the segments settle?
• How much time did the process spend above chance?
• Did the apparent edge become more coherent or less coherent as the record expanded?

The first Quantis record produced an interesting excursion and a neutral settlement. Both facts belong in the interpretation.

The excursion says that local statistical structure appeared.

The settlement says that the larger record did not preserve it.

Neither observation needs to erase the other.

Constraint, Record, and a New Physical Baseline

Within the language of Constraint-Record Coherence, the Quantis integration changes one major term while preserving the others.

• Constraint: uncertainty is now supplied by a dedicated quantum physical source.
• Record: the tracker still preserves every cumulative and segmented result.
• Coherence: excursion, settlement, and persistence still ask what apparent order survives as the record grows.

The project has therefore not changed its interpretive standards to flatter the new instrument. The Quantis run is read through the same discipline applied to cryptographic and software-generated sources.

A physical source does not make every excursion profound. It makes the comparison deeper.

The first Quantis record now serves as a baseline against which several future experiments can be compared:

Quantis PCI 0
Whiten Quantis PCI 0
NET2
Whiten NET2

The comparison need not be limited to final Z values. Different sources may exhibit different profiles of local excursion, segment settlement, persistence, conditional bias, or variance even when all of them ultimately remain consistent with chance.

That comparative profile may become one of the most valuable products of the experiment.

What This Does Not Claim

This first Quantis run does not prove that quantum randomness can be predicted.

It does not establish a durable advantage over chance.

It does not show that cryptographic or quantum random-number generation is broken.

It does not treat a temporary Z = 2 excursion as a final result.

It also does not assume that native Quantis output is completely unprocessed physical entropy. The card and firmware may perform health checking, conditioning, or other internal operations before bytes reach the public API. For that reason, the project currently uses the careful description native Quantis output rather than claiming access to a preconditioned raw quantum signal.

What the run does establish is more modest and more durable:

• The Quantis PCIe hardware is functioning under both Windows and Linux.
• The managed interop layer can consume it through a stable historical handle API.
• The tracker can sustain more than 11 million flips per second from the physical source.
• Random sources can now be recursively composed through the command-line registry.
• Von Neumann extraction is available as a general source transformation.
• The first large Quantis record provides a neutral and technically stable physical baseline.

The Instrument Is Online

TruthInTheFlip had reached a horizon where the next question required new instrumentation.

The instrument is now online.

Its first substantial record did not announce a victory. It showed a balanced heads stream, a stable hardware and software path, an interesting local excursion, and a settlement near equilibrium.

That is not a disappointing first result. It is a disciplined one.

The project now has a physical quantum source, a reusable whitening transform, a recursively composable source registry, and a new baseline from which longer comparisons can grow.

The first light from the Quantis did not reveal a final answer. It illuminated the next field of questions.

The code and continuing experiment are available in the public TruthInTheFlip repository:

github.com/johnwaynecornell/TruthInTheFlip

The Multiplicative Mirror: Squaring, Roots, and the Geometry of Halving

Before we can dive into arbitrary exponentiation and dynamic logarithms, we have to formally cross the boundary into the highest foundational level of the Mercury engine: The Power Tier.

To understand exactly where that boundary lies, we need to look at how we scale numbers by a constant of $2$.

In the Multiplicative Tier, if you want to scale a number by $2$, you use Double ($A + A$) or Half ($A / 2$). Notice the mechanics: you are relying on the Additive Tier’s operations to achieve a Multiplicative result.

But what happens when you need to scale a number by an exponent of $2$? You use Square ($A \cdot A$) and Square Root ($A^{0.5}$). These functions rely on the Multiplicative Tier’s mechanics to achieve a Power result.

Squaring and square roots are not the end of the Multiplicative Tier. They are the absolute foundational constants of the Power Tier. They are the base-2 geometric primitives that the rest of the tier (mercuryPow and mercuryLog) must rely on to survive. Let’s look at how the engine optimizes these foundational operations.

The Geometry of Self-Scaling (mercurySqr)

Squaring is simply multiplication looking in a mirror.

In our earlier post on geometric scaling, we established that multiplying two places physically adds their exponents:

$$B^i \cdot B^j = B^{i+j}$$

When a number is squared, the factors are identical. The spatial footprint perfectly doubles:

$$B^i \cdot B^i = B^{2i}$$

Because of this rigid geometric rule, mercurySqr acts as a highly streamlined version of our standard multiplication engine. Because the factors are identical, the engine only needs to read from one input array (a). The underlying geometric expansion—the nested loops combining places and the 64-bit register capturing the native hardware carry—remains exactly the same. It is the Multiplicative Tier operating at maximum efficiency to serve the Power Tier.

Halving the Footprint (The highbit Payoff)

If squaring a number doubles its spatial footprint, then reversing the operation must cut that footprint in half, with the final boundary landing according to the highest occupied bit.

This geometric certainty unlocks a brilliant hardware optimization. When mercurySqrt initializes, it does not need to execute a complex search loop to figure out where its starting bit should be. It mathematically knows exactly where the highest possible bit of the root must live.

Look at the first three active lines of mercurySqrt:

// Extract the highest 32-bit place of our target number
int h = (int)a[1]; 

// Calculate the absolute highest possible bit of the root
int highbit = ((int) ((h + 1) * 32)) / 2 - 1; 
int lowbit = highbit - Precision * 32 + 1;

By taking the highest base-$2^{32}$ place (h), translating the end of that place into bit-space with (h + 1) * 32, dividing by 2, and then subtracting 1, the engine instantly pinpoints the highest possible bit of the square root.

The subtraction matters because (h + 1) * 32 names the boundary just beyond the highest bit of place h. The actual highest bit is one step lower. Since square root halves the footprint, the root’s highest possible bit is the halved boundary minus one.

Because the loop includes both endpoints, the lowest bit is calculated with a + 1. This makes the scan cover exactly Precision * 32 candidate bits: from the highest possible root bit down through the final retained bit of the requested precision.

This is a zero-cost optimization. It requires no loops, no comparisons, and no trial-and-error. It is an instant jump to the correct binary location, and it only works because the engine strictly respects the spatial geometry established in the tiers below it.

The Constructive Binary Search

Once the ceiling is found, mercurySqrt must construct the rest of the root. It does this through a highly optimized, automated binary search.

Starting from highbit and working down to lowbit, the engine tests each possible binary place to see if it belongs in the final answer:

for (int i = highbit; i >= lowbit; i--) {
    // Generate the test bit
    mercury_2Pow(stack, Precision+1, i, mark); 
    
    // Add the test bit to our running guess
    mercuryAdd(stack, Precision+1, m, mark, q); 
    
    // Square the new guess
    mercurySqr(stack, Precision+1, q, x);       
    
    // Compare the squared guess against our original target
    int s = mercuryCmp(Precision+1, x, A);      

    if (s <= 0) {
        // It fits! Keep the bit in our running root.
        mercuryLoadMercury(stack, Precision+1, q, m); 
        
        // If it is a perfect match, exit early.
        if (s == 0)
            break; 
    }
}

This loop is the definition of a constructive algorithm. It tests a single bit, geometrically expands it (mercurySqr), and compares it to the target (mercuryCmp). If it overshoots the target, the bit is discarded. If it fits, the bit is permanently locked into the running root (m).

It is a flawlessly automated descent that relies entirely on the established geometry of the Multiplicative Tier to dynamically construct its inverse.

Up Next: The Exponentiation Engine

With the base-$2$ constants of the Power Tier firmly established, we are now ready to unleash them.

Next time, we will explore mercuryPow, and see exactly how the engine uses these squaring mechanics to skip millions of redundant multiplications and rapidly calculate massive, arbitrary geometric growth.

JWCEssentials on GitHub

JWCEssentials/C/Mercury/Mercury.c

The Power Tier Inverses: Roots, Logarithms, and Dynamic Convergence

In our last post, we explored how mercuryPow uses a binary squaring shortcut to rapidly calculate massive exponents, and how it relies on the square root operation to navigate fractional powers.

Because exponential growth is asymmetrical (the base and the exponent play completely different roles), deconstructing an exponent requires two completely different inverse operations:

In Mercury’s API terms, mercuryLog(a, b, val) computes val = log_b(a). In tier notation, this is the inverse route that solves for the exponent.

$$C = A^B \implies A = \sqrt[B]{C} \quad \text{and} \quad B = \log_A(C)$$

Today, we are going to look at how Mercury solves for both. We will start with the elegant simplicity of the Root, and then dive into the most complex convergence loop in the entire engine: the Logarithm.

The Root: The Elegant Inversion

When solving for a missing base, the strategy remains identical to how we handle division in the lower tiers.

In the Multiplicative Tier, division can always be rewritten as multiplication by a fractional inverse:

$$\frac{A}{B} = A \cdot \left(\frac{1}{B}\right)$$

In the Power Tier, finding a root can always be rewritten as exponentiation by a fractional inverse:

$$\sqrt[B]{A} = A^{\left(\frac{1}{B}\right)}$$

Because we already built mercuryPow to gracefully handle negative fractional bits, Mercury gets the highly complex root function almost for free. We don’t need a massive new algorithm to calculate a root; we simply flip the exponent into a fraction and route it right back through the engine we already built.

Here is the entirety of the mercuryRoot function. It is exactly eight lines of active math:

void mercuryRoot(void *stack, int Precision, uint *a, uint *b, uint *val) {
    uint *p = (uint *) mercuryStackAlloc(stack, (Precision+2)*4);
    uint *one = (uint *) mercuryStackAlloc(stack, (Precision+2)*4);
    mercuryLoadUint(stack, Precision, one, 1);
    
    // Step 1: Calculate the fractional inverse (1 / B)
    mercuryDiv(stack, Precision, one, b, p); 
    mercuryStackFree(stack, (Precision+2)*4);
    
    // Step 2: Pass the fractional inverse back into the positive variant
    mercuryPow(stack, Precision, a, p, val); 
    
    mercuryStackFree(stack, (Precision+2)*4);
}

The Logarithm: Hunting for the Exponent

Solving for a missing base is straightforward. Solving for a missing exponent, however, is a completely different beast.

To compute $B = \log_A(C)$, we are asking the CPU: “To what power must I raise A to get C?” There is no simple fractional inversion for this. The engine must actively construct the exponent bit-by-bit. Mercury handles this through a highly optimized, automated two-phase search.

Phase 1: Finding the Ceiling

Before Mercury can test bits, it needs to know where to start. It does this by actively hunting for the highest necessary bit using two do-while loops.

It first checks if our target is larger or smaller than our base.

• If the target is larger: The engine starts at bit 0 and steps upward (bit++), squaring the base (mercurySqr) until it overshoots the target. This efficiently finds the highest whole-number bit.

• If the target is smaller: The engine starts at bit 0 and steps downward (bit--), taking the square root of the base (mercurySqrt) until it drops below the target. This efficiently finds the highest fractional bit.

Once the overshoot happens, Mercury knows exactly where the ceiling is, and it proceeds to the convergence loop.

Phase 2: The Unified Descent

This is where the mathematical purity of the Power Tier shines. Once Mercury finds that starting bit, it iterates downward linearly across the specified precision.

It no longer cares if it is looking at a whole number or a fraction. Because the combinator of this tier is multiplicative, moving down one binary place always means halving the geometric magnitude of the step.

This unified descent is the absolute pinnacle of the Constructive Tiers working in harmony. Whether stepping from bit $2$ to $1$, or from bit $-1$ to $-2$, the engine simply calls mercurySqrt at the bottom of the loop to geometrically halve the step size for the next bit.

To find a logarithm, the engine must compare magnitudes (mercuryCmp), add candidate bits (mercuryAdd), combine running totals (mercuryMul), and dynamically halve its geometric steps (mercurySqrt). Every single operation we have built from the Additive Tier upward converges in this one loop to solve the hardest arbitrary-precision calculation in the library.

Why No Multi-Bit Stride?

If you read our previous post on Division, you might remember that Mercury used a 4-bit “nibble stride” to speed up calculations, pre-computing a table of chunks to subtract all at once.

You might wonder: Why not use a multi-bit stride for Logarithms?

The answer lies in the combinator. In division, scaling is linear—shifting our pre-computed table across the dividend only required cheap bit-shifts. But in the Power Tier, the combinator is multiplicative, and the scaling is geometric.

Every single fractional bit in an exponent represents a completely different geometric magnitude (e.g., $A^{1/2}$, then $A^{1/4}$, then $A^{1/8}$). You cannot mathematically bit-shift a square root. To discover the exact size of the next fractional bit’s contribution, the engine must actively execute a new square root on the previous step. Because every bit’s magnitude is geometrically dependent on the one before it, the clean nibble-table optimization used by division does not transfer directly. The log engine is naturally forced toward sequential refinement, evaluating and combining the candidate contributions one by one.

The Convergence Engine (mercuryLog)

Here is the core convergence loop where Mercury hunts down the bits:

// Step downward from our discovered ceiling
for (int i = 0; i <= bits; i++) {
    
    // Test the current bit: Add it to our running exponent register
    mercury_2Pow(stack, InnerPrecision, bit, _bit);
    mercuryAdd(stack, InnerPrecision, reg, _bit, reg);

    // Calculate the new power using our running root 'r' and 'p'
    mercuryMul(stack, PowerPrecision, r, p, r);

    // Compare our test power 'x' against our target 'A'
    s = mercuryCmp(InnerPrecision, x, A) * c;

    if (s > 0) {
        // We overshot! Reject the bit and restore the previous state
        mercuryLoadMercury(stack, InnerPrecision, last, reg);
        mercuryLoadMercury(stack, PowerPrecision, lastR, r);
    } else if (s == 0) {
        // Perfect match! Clean exit.
        mercuryLoadExtendMercury(stack, InnerPrecision, Precision, reg, val);
        goto stackCleanup;
    }
    
    bit--; // Move down to the next smallest bit

    if (i != bits - 1) {
        // The Engine Drive: Halve the exponent step by taking the square root
        mercurySqrt(stack, PowerPrecision, p, p);
    }
}

This is the absolute pinnacle of the Constructive Tiers working in harmony. To find a logarithm, the engine must compare magnitudes (mercuryCmp), add candidate bits (mercuryAdd), combine running totals (mercuryMul), and dynamically halve its geometric steps (mercurySqrt).

Every single operation we have built from the Additive Tier upward converges in this one loop to solve the hardest arbitrary-precision calculation in the library.

Closing the Ladder

This completes the foundational Mercury arithmetic ladder. Addition taught us carry and borrow. Multiplication showed how places combine through additive geometry. Division reversed that geometry with pre-computed nibble tables. Power introduced binary squaring and the mirror of fractional exponents. Root revealed how an inverse can collapse into a call back through pow. Finally, logarithm brought the entire structure together as a constructive search for the missing exponent.

The lesson is that Mercury’s functions are not isolated tricks. They are a tiered family of operations. Each tier introduces a new kind of combination, and each inverse operation reveals what it means to solve for the missing relationship at that tier.

JWCEssentials on GitHub

JWCEssentials/C/Mercury/Mercury.c

The Power Tier: Binary Squaring and the Symmetry of Fractional Exponents

With the linear and geometric foundations of the Mercury engine established, we now step into the highest foundational level of mathematics: The Power Tier.

Unlike addition or multiplication, exponential growth is completely asymmetrical. The base and the exponent play entirely different physical roles. Because of this asymmetry, the inverse operations required to deconstruct an exponent split into two distinct, specialized functions: roots and logarithms.

$$C = A^B \implies A = \sqrt[B]{C} \quad \text{and} \quad B = \log_A(C)$$

In Sigma Language notation, this structural relationship looks like this:

• C = A pow B; (Exponential combination)

• A = C root B; (Solving for the Base)

• B = C log A; (Solving for the Exponent)

In the lower tiers, the inverse operation could often be visualized as a direct reversal: subtraction reverses addition, and division reverses multiplication. In the Power Tier, the reversal splits because the two inputs have different meanings. Solving for the base requires root; solving for the exponent requires log.

Before we can look at how Mercury solves for missing bases and exponents, we first need to look at the forward operation: mercuryPow.

The Binary Shortcut: Exponentiation by Squaring

If you need to calculate $A^{100}$, the naive mathematical approach is to multiply $A \cdot A \cdot A \dots$ one hundred times. For arbitrary-precision numbers scaling across thousands of base-$2^{32}$ places, executing that many massive multiplications would bring a CPU to its knees.

Instead, Mercury uses an algorithmic shortcut called “exponentiation by squaring.” Because Mercury stores the exponent (B) in a native binary format, the engine can read the bits of B to determine exactly which prepared powers of A need to be multiplied into the result.

For example, raising A to the power of 3 normally looks like:

A * A * A

But 3 in binary is 11, meaning:

3 = 2 + 1

So the same expression can be rewritten as:

A^3 = A^2 * A^1

Mercury prepares those powers by repeatedly squaring the running base:

A^1 → A^2 → A^4 → A^8 → ...

Then, whenever the corresponding exponent bit is 1, that prepared power is multiplied into the result. The exponent’s binary digits become instructions for which powers of A participate in the final product.

This same bit-selection principle also appears one tier below in binary multiplication. To multiply by 3, we can write:

A * 3 = A + A + A = (A * 2) + A

Since 3 is binary 11, the multiplication engine can prepare A, A * 2, A * 4, and so on, then add the prepared values whose multiplier bits are set.

The Power Tier follows the same pattern at a higher order. Instead of preparing values with doubling and combining them with addition, it prepares powers with squaring and combines them with multiplication. The key is to use the correct construction and combination operations for the tier.

Here is the exact loop inside mercuryPow that handles the whole-number portion of the exponent:

// Process the integer bits (from bit 0 up to the highest bit)
for (int bit = 0; bit <= highBit; bit++) {
    
    // If the bit is 1, multiply our running base 'p' into our result 'r'
    if (mercuryGetBit(stack, Precision, bit, b) == 1) {
        mercuryMul(stack, Precision + 1, r, p, r);
    }

    // Always square the running base 'p' to prepare for the next bit
    if (bit != highBit) mercurySqr(stack, Precision + 1, p, p);
}

By reading the binary places and squaring the base at every step (e.g., $A^1 \to A^2 \to A^4 \to A^8$), Mercury geometrically skips over the redundant math. To calculate $A^{100}$, the engine does not need 100 multiplications—it only needs a handful of squares and strategic multiplies, dynamically arriving at the answer in a fraction of the time.

The Mirror: Fractional Exponents and Tier Symmetry

What happens if the exponent is not a whole integer? What if we need to calculate $A^{2.5}$?

This is where the true symmetry of the Power Tier reveals itself in the silicon. The identity position (bit $0$) acts as a mirror. When moving left into positive bits ($1, 2, 3 \dots$), Mercury scales the base by squaring it. But when moving right into the fractional bits ($-1, -2, -3 \dots$), Mercury must scale the base in the exact opposite direction.

To do this, it is mathematically forced to call upon its tier sibling: the square root.

// Process the fractional bits (from bit -1 down to the lowest bit)
for (int bit = -1; bit >= lowBit; bit--) {
    
    // Always square root the running base 'p' to prepare for the next fractional bit
    mercurySqrt(stack, Precision + 1, p, p);

    // If the bit is 1, multiply our running base 'p' into our result 'r'
    if (mercuryGetBit(stack, Precision, bit, b) == 1) {
        mercuryMul(stack, Precision + 1, r, p, r);
    }
}

Bit $-1$ represents $A^{0.5}$, which is exactly $\sqrt{A}$. Bit $-2$ represents $A^{0.25}$, which is the square root of the square root.

By simply swapping mercurySqr for mercurySqrt as it crosses the binary point, the engine seamlessly handles massive fractional powers. It proves that within the Power Tier, these operations are not isolated functions—they are fundamentally dependent on one another. You literally cannot build a comprehensive pow engine without a sqrt engine.

Implementation Note: The Guard Place

If you look closely at the C loops above, you will notice that the math functions are called with Precision + 1 rather than the standard Precision.

When you square massive numbers repeatedly, minor rounding errors at the absolute lowest bits can cascade upwards and corrupt the final answer. By temporarily computing the entire exponentiation sequence with one extra 32-bit “guard place,” Mercury insulates the working precision from cumulative geometric error. Once the calculation is completely finished, the guard place is cleanly truncated, leaving a pristine result.

Up Next: The Convergence

Now that we have seen how mercuryPow utilizes mercurySqrt to navigate fractional exponents, we are perfectly positioned to tackle the most complex function in the library.

In our next post, we will look at mercuryLog, and explore how Mercury dynamically hunts for a missing exponent by using roots and powers to converge on the answer bit by bit.

JWCEssentials on GitHub

JWCEssentials/C/Mercury/Mercury.c

The Execution Engine: Sliding Windows and Triple-Nested Loops in Mercury Division

In our last post, “The Division Stage-Setter,” we explored how Mercury outsmarts the CPU division limit. Instead of blindly guessing and subtracting to find a quotient, mercuryAbsDiv builds a multi-dimensional Table[8][16] array in its scratch memory—effectively memorizing its own times tables for the divisor across every possible 4-bit nibble shift.

But a pre-computed table is only useful if you have an engine built to navigate it. Today, we are looking at the execution phase: a triple-nested loop that dynamically slides our pre-computed grid across the dividend, turning a massive arbitrary-precision division problem into a lightning-fast sequence of pure lookups and subtractions.

To understand how the engine works without getting lost in the syntax, we are going to build it piece by piece.

Phase 1: Navigating the Places (The Outer Loop)

Division requires us to start at the most significant parts of our number and work our way down. The outermost loop of our execution engine handles this macro-level movement.

It starts at the highest 32-bit place of the dividend and slowly steps down to the identity place (the ones place).

// Step down through the 32-bit places of the dividend
for (int i = Precision - 1; i >= 0; i--) {
    
    // ... nibble and subtraction logic goes here ...
    
    dividend[1]++; // Shift the dividend window for the next place
}

The crucial piece of logic here is dividend[1]++. In Mercury’s architecture, index [1] holds the exponent. By incrementing it at the end of every loop, we physically shift our working frame of reference down the array. We are systematically sliding the divisor’s window across the dividend.

Phase 2: Slicing into Nibbles (The Middle Loop)

Once our window is locked onto a specific 32-bit place, we need to zoom in.

As we established in the previous post, our pre-computed table is based on 4-bit nibbles. Since there are exactly 8 nibbles in a 32-bit word, our middle loop slices the current place into 8 discrete steps, starting from the highest nibble ($7$) down to the lowest ($0$).

for (int i = Precision - 1; i >= 0; i--) {
    
    // Step down through the 8 nibbles of the current place
    for (int p = 7; p >= 0; p--) {
        
        // ... lookup and strike logic goes here ...
        
    }

    dividend[1]++;
}

The variable p here maps exactly to the q dimension of our Table[8][16]. It tells the engine exactly which layer of our shifted, pre-multiplied grid we need to look at for this specific spatial position.

Phase 3: The Lookup and Strike (The Inner Loop)

Now we drop the hammer. Inside the innermost loop, the engine tests the pre-computed multiples of our divisor, checking the largest possible value ($15$, or 0xF in hex) down to $0$.

for (int i = Precision - 1; i >= 0; i--) {
    for (int p = 7; p >= 0; p--) {
        
        // Test the pre-computed multiples from 15 down to 0
        for (int d = 0xF; d >= 0; d--) {
            uint *x = Table[p][d]; // Grab the pre-computed chunk

            // Does it fit?
            if (mercuryAbsCmp(Precision, dividend, x) >= 0) {
                
                // Strike: Subtract it from the dividend
                mercurySub(stack, Precision, dividend, x, dividend);

                // Log the quotient piece in its exact spatial position
                reg[i] += ((uint) d) << (p * 4);

                // ... exit logic ...
                d = -1; // Break the inner loop, move to the next nibble
            }
        }
    }
    dividend[1]++;
}

This is the ultimate payoff of our preparation. There is no guesswork. The engine simply checks if the pre-computed chunk fits (mercuryAbsCmp). If it does, it executes a single subtraction (mercurySub) and instantly logs the quotient piece directly into the result array (reg[i] += ((uint) d) << (p * 4)), perfectly aligning it using the exact same bit-shift math we used to generate the table.

Once a fit is found and subtracted, it forces d = -1 to break the inner loop and instantly move on to the next nibble.

The Clean Exit: A Surgical Optimization

If you look closely at the full mercuryAbsDiv source code, there is one final optimization nestled inside that innermost strike loop.

Every time Mercury performs a successful subtraction, it checks if the dividend has reached absolute zero. If it has, there is no reason to continue shifting the window or testing lower places. The math is completely finished. To immediately halt the engine, Mercury uses a direct goto ret; jump.

                    if (mercuryIsZero(Precision, dividend)) {
                        goto ret; // Break out of all three loops instantly
                    }

While the goto statement is often treated as taboo in modern, high-level application development, in bare-metal C engine architecture, it is a surgical tool. It allows the processor to instantly break out of a triple-nested loop the exact millisecond the work is done, without having to cascade through multiple break conditions or evaluate a chain of boolean flags. It saves precious clock cycles and guarantees a perfectly clean exit.

Up Next: Entering the Power Tier

With addition, subtraction, multiplication, and division firmly established, we have conquered the linear and geometric foundations of the Mercury engine.

Next time, we step into the highest foundational level of mathematics: The Power Tier. We will explore how exponential growth forces our inverse operations to split into roots and logarithms, and how Mercury relies on those exact structural relationships to dynamically converge on the hardest calculations in silicon.

JWCEssentials on GitHub

JWCEssentials/C/Mercury/Mercury.c

The Division Stage-Setter: Pre-computed Tables and Reversing Spatial Geometry

In our previous look at the Multiplicative Tier, we established that multiplication is fundamentally a spatial expansion. When multiplying two numbers, the resulting memory footprint respects an $(X+Y) – 1 + 1$ relationship. The baseline width expands outward from the overlapping identity places, with a final potential carry determining the absolute maximum width.

Division must respect this exact same spatial geometry—but in reverse. Instead of expanding outward, division requires aligning a fixed-width window (the divisor) with the most significant places of the dividend, and systematically sliding it down toward the identity place.

The Grade-School Analogy: Why Division is Hard for a CPU

When we perform long division on paper—for example, $7450 \div 25$—we do not repeatedly subtract 25 from 7450. We align the 25 under the 74 and ask, “How many times does this fit?” We immediately know the answer is roughly 2 or 3 because we have a memorized 1-9 multiplication table in our heads.

A CPU does not have a memorized multiplication table for arbitrary, multi-place base-$2^{32}$ numbers. If we force the computer to blindly guess and repeatedly subtract to find the ratio, division becomes incredibly slow and computationally expensive.

The Mercury Solution: The Pre-computed Table

To solve this, mercuryAbsDiv executes a brilliant algorithmic shortcut: it builds its own “memorized” multiplication table inside the scratch memory before it ever starts dividing.

Creating a full base-$2^{32}$ table would require 4.2 billion entries, which is physically impossible. Instead, Mercury slices the 32-bit places down into 4-bit “nibbles.” This reduces the required search space to just 16 entries ($0$ through $15$).

Here is the exact C code where Mercury learns its “times tables” by repeatedly adding the divisor to populate the base nibble level:

// Setup the base level (q=0) for the first nibble
mercuryLoadZero(stack, Precision, Table[0][0]);
mercuryLoadMercury(stack, Precision, divisor, Table[0][1]);

// Build 2 through 15 by repeatedly adding the divisor
for (int i = 2; i < 16; i++) {
    mercuryAdd(stack, Precision, Table[0][i-1], divisor, Table[0][i]);
}

Expanding the Grid and Sliding the Window

Once Mercury knows how the divisor scales from $1$ to $15$, it leverages our spatial alignment rules to expand that knowledge across the entire 32-bit place.

Because a 32-bit place consists of 8 discrete 4-bit nibbles, Mercury simply takes that first 16-entry table and shifts it across the remaining 7 levels.

// Shift the base table across the remaining 7 nibble positions
for (int q = 1; q < 8; q++) {
    mercuryLoadZero(stack, Precision, Table[q][0]);

    for (int i = 1; i < 16; i++) {
        // Shift each pre-multiplied value left by 4 bits (q * 4)
        mercuryShift(stack, Precision, Table[0][i], q * 4, Table[q][i]);
    }
}

The bit-shift math here is elegantly simple. The variable q represents the nibble index (from $1$ to $7$). Since each nibble is exactly 4 bits wide, shifting the base table by $q \cdot 4$ perfectly aligns the pre-multiplied values with the 4th, 8th, 12th, and eventually the 28th bit of the 32-bit word.

By generating this Table[8][16] grid, Mercury turns guessing into a bounded lookup: at each nibble position, there are only sixteen possible candidates to test. It looks at a nibble of the dividend, checks its custom table, grabs the largest pre-multiplied value that fits, and subtracts it. Because the table was built relative to the divisor, the engine can flawlessly slide these pre-calculated chunks across the dividend until it reaches the end.

A massive, highly complex arbitrary-precision division problem is elegantly reduced to a highly efficient lookup-and-subtract loop.

q * 4 is not arbitrary code. It is the direct mechanical translation of eight 4-bit nibbles inside one 32-bit place.

Ready to Strike We now have a fully populated Table[8][16] sitting safely in our scratch memory. By shifting the base nibble values across the 32-bit geometry, Mercury has effectively memorized its times tables for this specific divisor.

But having the knowledge is only half the battle.

In our next post, we will unleash the execution engine. We will look at the triple-nested loop that puts this table to work, dynamically sliding our pre-computed grid across the dividend to turn a massive arbitrary-precision division problem into a lightning-fast sequence of pure lookups and subtractions.

JWCEssentials on GitHub

JWCEssentials/C/Mercury/Mercury.c

The Multiplicative Tier: Geometric Scaling and 64-bit Synergy in Mercury

In our last post, we explored the Additive Tier, establishing how Mercury handles direct linear steps. Today, we step up to the second level of the mathematical architecture: The Multiplicative Tier.

At this tier, we move away from simple counting and enter the realm of geometric scaling.

The Theory of Geometric Scaling

It is common to teach multiplication simply as “fast addition”—and while that is functionally true for small integers, it is the wrong mental model for arbitrary-precision engines. Multiplication applies one value as a scale to the entire magnitude of another.

Because multiplication is symmetrical (the order of factors does not change the product), its inverse operation is used to solve for either of the original variables:

$$C = A \cdot B \implies B = \frac{C}{A} \quad \text{and} \quad A = \frac{C}{B}$$

In our Sigma Language notation, we express this structural relationship linearly:

• C = A * B; (Multiplicative combination)
• B = C / A; (Solving for the right ratio)
• A = C / B; (Solving for the left ratio)

Just as subtraction was the tool to find a missing additive difference, division is strictly the tool to find the missing scale. Before we can look at division, however, we need to look at how Mercury handles that massive geometric expansion in silicon.

32-bit Places in a 64-bit World

When Mercury hands a scaling operation off to mercuryAbsMul, the elegance of using a base-$2^{32}$ positional format shines through.

If we multiply two full 32-bit places together, the largest possible product is still less than 2^64, so a 64-bit register can hold the entire intermediate product. Because modern processors feature 64-bit Arithmetic Logic Units (ALUs), we can multiply two base-$2^{32}$ “places” together and capture the entire result natively, without overflowing the hardware register.

Here is the inner engine of mercuryAbsMul that performs this feat:

// Iterate through the places of variable 'b'
for (int bi = bs; bi <= br; bi++) {
    uint bx = b[2 + bi + bq]; // Load the current place of 'b'
    
    int ai;
    ulong reg = 0; // The 64-bit accumulator register

    // Multiply against the places of variable 'a'
    for (ai = as; ai <= ar; ai++) {
        int place = ai + bi - adj;

        if (place >= 0) {
            uint ax = a[2 + ai + aq]; // Load the current place of 'a'

            // Multiply the two 32-bit places, add the carry, and add the existing scratch value
            reg += (ulong) bx * (ulong) ax + scratch[place];

            // Store the bottom 32 bits as the answer for this place
            scratch[place] = (uint) reg;
            
            // Shift the register right to push the top 32 bits forward as the carry
            reg >>= 32;
        } else {
            reg = 0;
        }
    }
    
    // Process any remaining carry for this row
    int place = ai + bi - adj;
    if (place >= 0) {
        reg += scratch[place];
        scratch[place] = (uint) reg;
    }
}

The Accumulator and Scratch Staging

The magic happens inside that innermost for loop. We are not just multiplying bx and ax. We are accumulating three distinct values into our 64-bit reg:

1. The product of the two current 32-bit places.
2. The carry over from the previous place.
3. The value already sitting in the scratch array from earlier multiplication passes.

Once those are added together, the logic mirrors our Additive Tier perfectly. The bottom 32 bits are saved to the scratch array (scratch[place] = (uint) reg;), and the top 32 bits are shifted forward for the next loop (reg >>= 32;).

Once again, by staging all of this geometric expansion safely inside the scratch stack, Mercury ensures that the output variable (val) is never corrupted mid-calculation.

Why Two 32-bit Places Need 64 Bits

There is a deeper reason that Mercury uses a 64-bit register for multiplication. It is not only because the hardware happens to provide one. It is because multiplication combines magnitudes, and the size of the result is measured by adding the places of the factors.

In a positional number system, a digit does not stand alone. A digit at place i represents:

aᵢ × B^i

and a digit at place j represents:

bⱼ × B^j

When those two places are multiplied, their coefficients multiply, but their places add:

(aᵢ × B^i) × (bⱼ × B^j)
= (aᵢ × bⱼ) × B^(i + j)

That addition in the exponent is not a coincidence. The Multiplicative Tier is built on top of the Additive Tier. Multiplication scales magnitudes, but the placement of the resulting product is still governed by additive displacement.

For Mercury, the base is B = 2^32. Each place can hold any value from 0 to 2^32 - 1. The largest possible single-place product is therefore:

(2^32 - 1) × (2^32 - 1)
= 2^64 - 2^33 + 1

That value is smaller than 2^64, so it fits completely inside an unsigned 64-bit register. Mercury can multiply two full 32-bit places without losing a single bit of the product.

Once the product is staged in the 64-bit register, Mercury follows the same carry discipline introduced in the Additive Tier: the low 32 bits become the current output place, and the high 32 bits move forward as carry.

The Bridge to Division

If multiplication is scaling up by multiplying 32-bit places natively, division is the process of scaling down.

However, division is notoriously expensive for a CPU. Instead of guessing factors and repeatedly subtracting (which would take an eternity for arbitrary-precision numbers), Mercury uses a brilliant algorithmic shortcut to solve the inverse ratio: the nibble-sized precomputed table.

In the next post, we will look at how mercuryAbsDiv pre-computes the entire search space of the dividend, turning massive division problems into highly efficient lookup-and-subtract loops.

 

JWCEssentials on GitHub

JWCEssentials/C/Mercury/Mercury.c