an orbit in whole numbers, and the same bytes after a hundred million steps

Harriett Little. Published 2026-10-06.
The program links on this page load into the one Run box. Edit it and run it again.

Two simulations that propagate the same orbit from the same state with the same integrator should arrive at the same place, and in floating point they do not, quite. The arithmetic is specified to the bit, but what a compiler makes of an expression is not: one fuses a multiply and an add into a single rounding and another does not, one library's square root differs from another's in the last place, and after enough steps the two trajectories are different numbers. In a distributed simulation, where federates on different machines may each carry a copy of a state, that is a disagreement nobody chose. This page propagates an orbit in checked integer arithmetic, where there is only one answer, and shows the same bytes from four compilers on three machines after a hundred million steps, beside the same integrator in double from the same compilers, which do not agree. It also shows what that costs: the integer program is twenty-five to forty-four times slower than the double one.

two kinds of error

They are easy to run together and this page keeps them apart. Truncation error is the integrator's: a fixed step of one second with a first-order method puts the vessel a few kilometers from where the exact solution would, and it does so identically on every machine, because it is a property of the method and not of the hardware. Reproducibility is the other thing: whether two machines running the same method get the same bits. Floating point fails the second even when both machines pass the first by the same margin. Integer arithmetic has only the first. The orbit below is not more accurate than its floating-point twin, and the page does not say it is. It is the same everywhere.

the program

Earth, a circular orbit at 6,778.137 km, one second per step, semi-implicit Euler: kick the velocity by gravity, then drift the position by the new velocity. Position is in centimeters, velocity in micrometers per second, and the part of a step that is less than a centimeter is carried in a remainder of its own, so nothing is dropped and the position is exact to the micrometer. Gravity is GM / r², with the square root an integer square root and the two divisions a muldiv each, which keeps the product wide and rounds once, by name. The radius squared in centimeters is about 4.6 x 10¹⁷, inside I64 with room to spare, and that is the whole reason for the units: they were chosen so that every intermediate fits, and if one did not the program would stop and say which. A digest of every state is folded along the way; it wraps on purpose, marked with the wrapping operators, because it is a fingerprint and not a quantity.

orbit.ci   Run   the first Run loads Python, about 12 MB, once

what the output shows

One period, 5,554 steps. The vessel comes back to within 2.85 kilometers of its start, which is the truncation error of a one-second first-order step and the fact that 5,554 seconds is not quite the period, and the radius stays within 3.9 kilometers of its starting value through the whole orbit, the small oscillation this integrator is known for. Then the digest. Run it twice and the digest is the same. Run it in the compiler and the digest is the same. Change the step or the starting speed and it changes, as it should.

a hundred million steps

The same program with the step count raised to 100,000,000, about 18,000 orbits, emitted to C by cintc once and built with four compilers on three machines, an x86-64 Linux host, an x86-64 Windows host and an arm64 Mac, each at -O2 (/O2 for MSVC):

Every byte of output is identical between the four builds, the four lines and their SHA-256 alike, 68d2475161b0946c69e0373f6dbd50768ac17848e30c848ed6aa16df96608a7a. The radius stayed between 6,774.295 and 6,781.985 kilometers for the whole three years of simulated time. How long each build took, beside the same loop in double, is in what the checking costs, below.

the same integrator in double

Thirty lines of C, the same state, the same step, the same kick and drift, in meters and meters per second, with the same digest folded over the bit patterns of the state. Built four ways on the same machine, the same hundred million steps:

Three of the four agree and the fourth does not. gcc, at its default contraction setting with fused multiply-add available, puts the vessel 93 centimeters from where the other three put it, after the same hundred million steps of the same source on the same processor, and its digest shares nothing with theirs. Nothing is wrong with any of the four. Each is a correct compilation of a program whose result the language leaves to the compiler. That is the disagreement the integer version does not have.

The same thirty lines on the other two machines, and clang on the first once more with its vectorizer off:

On arm64 the fused multiply-add is always there, and Apple Clang's default build uses it: it lands on gcc's answer from the table above, to the bit. Allowed to fuse wherever it likes, it gives a third answer, and MSVC's fast mode a fourth. The clang build above that was allowed to fuse and still agreed with the unfused builds did so because clang packed x and y into one vector register and fused nothing there; with the vectorizer off it fuses, and gives the third answer too. Four answers from one source, every one a correct compilation, and the integer program gave one answer on all four compilers.

what the checking costs

The hundred-million-step program against the thirty lines of double, each built at -O2 (/O2 for MSVC) and run once, one after the other on the same machine, with the double built unfused (-ffp-contract=off, or /fp:precise for MSVC):

The double version is twenty-five to forty-four times faster, depending on the compiler. A step of the integer loop takes an integer square root and three multiply-divides with a wide product, and every plain operator in it is checked; a step of the double loop takes one hardware square root and three divisions. How the time splits between the square root, the wide products and the checks has not been measured, so the ratio is the price of the whole program, with the compiler that emitted the C on this site, and not of checking alone. Each time is a single run, so the double times here differ by a few tenths of a second from the first machine's times in the double table above, which came from other runs. It is stated here rather than left out.

same bytes from the reference and the compiler

The box below is the C that cintc emitted for the one-period program as shipped, 536 lines for 50 lines of cint. The compiled program and the reference write the same four lines, with stdout SHA-256 d2b4d07efa7dda4019e55138d3da0d41c0155233af360da18aeceafa3d0c76b1, and the test passes under both.

128 bits

orbit_wide.ci is the same orbit with the state in I128: position in micrometers in one number, no remainder to carry, and squares of about 4.6 x 10²⁵ with about forty bits to spare. It is the shape the state would take in a simulator that wanted femtometer remainders and planetary distances in the same word. The reference runs it; the compiler does not accept I128 yet, so the lower box will say so when it is loaded, and the hundred-million-step result for this version waits on that.

what is not claimed

An earlier simulator by the same author, written in a different language, carried an orbit in integers with explicit units and rounding rules and recorded bit-identical state on x86-64 and AArch64 machines across 1.5 million per-tick digests, and published its state through the SpaceFOM. That work is cited below; this page is the same idea in cint, in fifty lines, with the arithmetic checked by the language rather than by the program.

The machines are one x86-64 Linux host, one x86-64 Windows host and one arm64 Mac, so the identity shown is across four compilers and two architectures, not a survey of hardware. Nothing here exchanged state over HLA or spoke to a federation; the paper's argument about distributed simulation is that two federates computing the same thing would agree, and it is made with three machines standing in for federates. The integrator is first-order with a one-second step and is not offered as an accurate propagator. There is no drag, no oblateness and no third body.

limits

The units were chosen for this orbit. A different radius or a different step moves the intermediates, and the first thing to do with the program is to check that they still fit, which the program itself will do by faulting if they do not. The floating-point comparison is one program on three machines with four compilers; it shows that the result depends on compilation choices, which is all it is asked to show, and the size of the difference, under a meter after three years, is not a measure of anything general. The digest is a fingerprint for comparing runs and is not a cryptographic hash.

references

• E. Hairer, C. Lubich and G. Wanner. Geometric Numerical Integration. Springer, second edition, 2006. Chapter I, the symplectic Euler method.
• D. Goldberg. What Every Computer Scientist Should Know About Floating-Point Arithmetic. ACM Computing Surveys, 1991.
• IEEE Std 754-2019, IEEE Standard for Floating-Point Arithmetic. Section 10, expression evaluation and the fused multiply-add.
• GNU Compiler Collection, Optimize Options: -ffp-contract, whose default in GNU C mode is fast.
• SISO-STD-018-2020, Standard for Space Reference Federation Object Model (SpaceFOM): the setting in which federates carry state for one another.
• H. Little. spaceFOM-integer: a SpaceFOM federate publishing an integer-state orbital simulator over HLA, with a replay verifier for bit-identical results across platforms. github.com/pennyleans/spaceFOM-integer, 2026.

cite as

Harriett Little. An orbit in whole numbers, and the same bytes after a hundred million steps. integerc.dev, 2026. https://integerc.dev/papers/orbit/

Harriett Little
October 2026