The Verification Venue · pointed at the most retold wrong answer in numerical computing
The Region Where the Double Is Wrong
Every retelling of Rump's expression evaluates one famous point, prints a table of wrong answers, and leaves the impression of a curiosity: a single coordinate crafted by an adversary, safely far from anything anyone would compute. This page asks how far the damage reaches, by censusing the 16,785,409 lattice points around it and computing the exact rational value at every one in big integers, rather than quoting anyone's table. The answer is a genuine surprise, and it is not the one this page was built expecting.
Drag the probe over the map below, or focus it and use the arrow keys. Under the finger you get the exact value, computed in big integers, next to what double, single and double-double precision return, and next to an interval that is guaranteed to contain the truth. Then, when you are satisfied the small picture is honest, launch the full census of 16,785,409 lattice points across every core you have.
Census window halfwidth
The map is computed by the slow JavaScript reference, point by point, in your browser: it is the small case, shown before anything heavy runs. ↓
Exact value, f = g / 4y, big integers
·
Double precision (pinned arrangement)
·
Single precision
·
Double-double
·
Interval (guaranteed to contain the truth)
·
Error of the point estimate vs width of the honesty
·
| arrangement | value at probe | sign vs exact |
|---|---|---|
| move the probe | ||
The shading is the exact log₁₀|f| from the big-integer value, stretched across the range this window actually contains: brighter means closer to the two ±8×10³⁶ terms annihilating each other. The faint diagonal thread is the line x/y ≈ 77617/33096, along which the cancellation is deepest, and the famous point sits on it. In every window offered here exactly one point carries a wrong-sign colour, that point, and the precision that is wrong there is the double-double.
The mechanism is catastrophic cancellation, and the honest claim is about cancellation, not about arithmetic being unreliable. Clear the fractions once, exactly: multiply the expression by 4y and every coefficient becomes an integer,
Near the famous point, the term 5.5y⁸ and the term x²(11x²y² − y⁶ − 121y⁴ − 2) are both near ±8×10³⁶ and cancel almost completely: the exact remainder is less than 1. A double has about 16 digits, so subtracting two numbers of size 10³⁶ to get an answer of size 10⁰ throws away everything the format has. The expression is due to S. M. Rump, who constructed it to make that cancellation visible.
What the pinned arrangement actually does at the famous point is computed live in the panel above, not quoted from any retelling: it returns about -1.18×10²¹, an enormous negative number. The exact value is negative too (-54767/66192 ≈ -0.827), so for this arrangement the celebrated sign flip does not happen: the double answer is wrong by twenty-one orders of magnitude while accidentally keeping the sign. Whether any grouping flips the sign is decided by rounding debris a dozen orders of magnitude below the operands, so the arrangements table computes several named groupings live, at the probe point, and marks the ones whose sign disagrees with the exact value. No retelling's table is quoted anywhere on this page.
What the census found, and it is not what this page set out to find. Over all 16,785,409 lattice points, the number where the pinned double arrangement has the wrong SIGN is 0. Not a band: nothing. Single precision gets the sign wrong at 5 of them, and the double-double at exactly 1, which is the famous point itself, where it returns about +1.1726 against an exact -0.827. The panel below recomputes all three counts live, and the map above marks whichever of them fall in the window you are looking at. The reason is visible in the numbers rather than in the story: one lattice step away from the famous point the exact value is already at least 2×10³², while the double's debris is only about 10²¹, so the double is right about the sign with eleven orders of magnitude to spare. Cancellation this total needs sixteen digits of coincidence, which is why the point had to be constructed. Seven digits of coincidence are cheap by comparison, and that is why single precision is caught five times over the same window.
The full census
Runs the compiled C engine (WebAssembly, one worker per core) over every lattice point within ±2048 of the famous point: 16,785,409 points, each getting an exact big-integer evaluation, four floating evaluations, an interval, and an exact signed containment comparison. Then it runs the whole thing AGAIN under a different decomposition and requires the two answers to be identical.
waiting
Points where double has the wrong sign
·
Points where single has the wrong sign
·
Points where double-double has the wrong sign
·
Single right while double wrong
·
Interval containment failures (must be 0)
·
Horner vs expansion mismatches (must be 0)
·
The check · run in front of you, not described to you
Before any headline number is shown, the compiled engine and the slow JavaScript reference are run over a battery of small instances and their fingerprints compared. The reference is written from the contract by direct expansion over BigInt; the engine uses Horner over 256-bit limbs. Different formulations, one polynomial.
| battery row | engine fingerprint | reference fingerprint | agree |
|---|---|---|---|
| loading… | |||
The planted inputs are doctored data, not a separate code path: at (0,2), (4,2), (8,2) and (12,2) the exact value is a small integer by construction (22768, 2001, 74866 and 646867, each derived from the cleared rule above), and the unmodified engine must land its double evaluation exactly on each of them. The narrowed-rounding control reuses the same doctored points under inward rounding: their exact values are exactly representable and every operation on them is exact, so the inward interval inverts and the engine's own containment test must reject it, while the outward run on the same points is accepted, which is what proves that test can fail and is not a constant rejector. At census points the same inward nudge cannot bite: the interval there is held open by rounding debris of order 10²¹ produced at the ±8×10³⁶ sites, and flipping the nudge direction retracts only the deliberate one-ulp pads, not that debris, so no inward census interval can exclude a value of size O(1). The offline gate records that window explicitly.
The control moves coefficient 121 to 122 in the reference's polynomial. A check that has never failed is a claim about the code, not evidence about it: press the button and watch this panel go red, then say so.
Full-size decomposition check: waiting for the run.
Engine hash: waiting for fetch.
Planted-input control: waiting.
Narrowed-rounding control: waiting. It runs the four planted points under inward rounding and requires the engine's containment test to reject them.
What none of this rules out: two decompositions agreeing rules out a boundary error in the strip partitioning and very little else. Nor can the engine-versus-reference battery see a misreading of the ALGEBRA of an arrangement, because both implementations are transcriptions of the same written arrangement by the same hand and will agree on the same wrong polynomial. That is not hypothetical here: the Horner-in-y² arrangement shipped in an earlier build with 11x⁴ and −121x² in one Horner stage, which evaluates 11x⁴z² in place of 11x⁴z, and the battery agreed with itself all the way. What caught it was the planted points, where every named arrangement must land exactly on a known integer, and that check now runs on every arrangement in the offline gate. The containment decision is an exact signed integer comparison performed by both implementations at every single point, but the interval METHOD itself is the same method in both, so a conceptual flaw in the method would be shared; the mitigation is that the method is conservative by construction and its judgement is compared against exact arithmetic at every point. The reproducible-build check is offline: it is research/the-region-where-the-double-is-wrong/verify-the-region-where-the-double-is-wrong.mjs, which rebuilds the C and compares bytes.
Operations performed (engine's own counter)
·
Wall time
·
Workers, and why that number
·
vs main-thread JavaScript
·
What's exactly true here, and what's pinned
Exactly true. The integer evaluation of the cleared polynomial, in two different formulations (Horner in C, direct expansion in JavaScript), the sign of the exact value at every point, the containment comparison of the exact rational against the interval endpoints (an exact signed integer comparison: lo·4y ≤ g ≤ hi·4y), and every count printed. The planted points are exact by construction: at y = 2 with x a multiple of 4, every term of f is an integer, giving 22768, 2001, 74866 and 646867 at the four planted points.
Pinned, not universal. The double, single and double-double digits belong to one stated evaluation arrangement, written identically in both implementations and quoted in the source of each. Change the arrangement, the compiler, or the use of fused multiply-add and the wrong digits change. That fragility is the subject, not a defect of this page, and it bit this page: WebAssembly has no fused multiply-add instruction, so the compiled engine cannot fuse anything at run time, but clang fuses while CONSTANT FOLDING, and the engine's record for the famous point (whose coordinates are literals) came back one ulp away from what the same function returns on run-time arguments. The engine is now compiled with contraction switched off, and the offline gate compares the two paths. At the famous point the pinned arrangement returns a huge negative value, about -1.18×10²¹, where the exact value is -54767/66192: the sign agrees by accident and the value is wrong by twenty-one orders of magnitude. Which named groupings flip the sign is computed live in the arrangements table; it is a property of the grouping, not of the expression. The interval arithmetic nudges each result one ulp outward after every operation, which is conservative directed rounding rebuilt by hand because this target has no rounding-mode control.
Every named arrangement is checked against arithmetic, not only against its twin: at the four planted points each of them must return the planted integer exactly, since every intermediate there is exactly representable and every operation on it is exact.
Measured, not asserted. The extent of the wrong-sign band, the count of points where single precision is accidentally right while double is wrong, and the behaviour of double-double are measurements of this census window. The page reports what it finds; it does not claim the picture repeats everywhere.