Your machine is the apparatus · number

The Rounding Your Browser Was Allowed to Get Wrong

There is a sentence in the JavaScript standard that says nobody has to get this right. It has been there since the first edition, in 1997, it applies to Math.exp and Math.sin and twenty-one other functions, and the consequence is running on your machine now: your browser hands back numbers whose last bit is wrong, and how often depends entirely on which maths library is underneath it. The engines here that use fdlibm, the library the standard itself recommends, miss … of exponentials. JavaScriptCore and glibc miss … of the same list. This page builds the correct answer from scratch, in BigInt, in front of you, and measures your own engine against it. Five engines were measured on one machine at one instant. Yours is the sixth column.

Here is the sentence. It is a Note in clause 21.3.2 of ECMA-262, and this page found it word for word in each of the three editions it fetched, and again in the first edition of 1997, where it sat in clause 15.8.2 and named ten functions instead of the current twenty-three.

…
…

Some latitude is allowed. Not an error bound, not a tolerance, not a maximum. Latitude. One name in that list is worth pointing at before it looks like a typing error: Math.random is on it, where being unspecified is the whole point rather than a concession, and this page measures none of it. The other twenty-two are functions with a right answer. Elsewhere the standard gives the class of thing this is a name, and is candid about what the name buys you:

…
…

Encouraged to strive. That is the whole of your guarantee about the exponential function.

1. Your engine, against the truth

To say an engine is wrong you need something to be wrong against, and the something cannot be another engine. So the page carries its own arbiter: a small binary floating-point arithmetic in BigInt, with the working precision under your control, which computes the true value to a few hundred bits and then rounds it once, correctly. Nothing in it is a stored constant. Pi and the natural logarithm of two are summed on demand to whatever precision you ask for.

Type an argument. The row marked correctly rounded is what the standard would say if the standard said anything.

Instrument 1 · one argument, sixty-four bits

Working bits 160

Drag the precision down and the reference starts refusing to answer. That refusal is section 5.

Press find one and the page walks the argument list until it finds one your engine gets wrong. On the engines measured here it does not have to walk far.

2. The census: how often, and by how much

One argument proves nothing about a rate. The page ships a fixed list of 1,000 arguments per function, generated by a 48-bit linear congruential generator with a seed written down before any measurement was taken, so that every engine that has ever been pointed at this page saw byte-identical inputs. Press the button and your machine computes the correctly-rounded value for all of them and counts how often it disagrees with itself.

Instrument 2 · the census

Nothing measured yet. Your column is empty until you press a button.

Two things in that table are worth stopping on, and neither is the headline.

The first is the row for sqrt, which is 0.0% in every measured column, and will be in yours the moment you press the button. That row is the reason to believe the others. If a measurement apparatus reports a divergence everywhere it looks, it is measuring itself. A row that comes back exactly zero, on the one function of the eight where zero is the right answer, is the thing that says the other seven rows are about the engines and not about the page. Section 3 is about why that row is zero, and it is a better story than it looks.

The second is that the columns fall into camps, the camps are not the ones a reader would guess, and on two of the eight functions they are not camps at all. …

3. The one that got pinned

In the fifteenth edition of ECMA-262, published June 2024, Math.sqrt was on the latitude list with the rest of them, and clause 21.3.2.32 ended like this:

…
…

In the sixteenth edition, published June 2025, the same step reads:

…
…

The blackboard F is the standard's own operator for the Number value for, and the standard is explicit that it means round to nearest, ties to even. In one line, Math.sqrt stopped being approximated and started being specified, and its name was struck out of the list of functions in clause 21.3.2 whose behaviour is not precisely specified. It is the only name that has ever left that list.

The order of events is the other way round, and it matters. The zero row is not the standard's doing. Square root is one of the operations IEEE 754 has required to be correctly rounded since 1985, and on x86-64, the architecture every column here was captured on, it is a single machine instruction; the engines were returning the correctly-rounded double for years before anyone changed a word of ECMA-262. What the pull request titled Normative: fully define Math.sqrt, opened on 6 June 2024 and merged on 17 August 2024, actually did was stop permitting anything else, and its entire stated rationale was that the engines were all doing it already. The difference between the 0.0% row and the 9.96% row above it is not one sentence in a document. It is that one of the two has a hardware guarantee underneath it and the other has a recommendation, and the document has now caught up with exactly one of them.

Instrument 3 · the latitude list, three editions

Every function named in the Note to clause 21.3.2 as not precisely specified, in each of the three most recent editions of ECMA-262. Clause numbers are read out of the published document by 00-spec-quotes.mjs, because they move: sqrt is 21.3.2.32 in the 15th edition and 21.3.2.33 in the 16th and 17th, since a clause was inserted above it.
function	ES2024 · 15th	ES2025 · 16th	ES2026 · 17th	your engine, measured

4. Your number, and the published number

The GNU C library publishes a table of the largest error it knows of in each of its maths functions, per architecture, in units of the last place. It is the closest thing to a published accuracy figure that any of the libraries under this page has, and one of the five engines measured here is that library, reached through python3 rather than through a browser, on the same machine in the same minute. So the comparison is available directly.

Six of the eight functions carry a published number. On every one of those six the measured maximum is inside the published bound. Two carry no published number at all, and one of those two is not zero, which is the interesting row.

Instrument 4 · measured against published

The glibc manual's known maximum error for x86_64, against what a thousand and then twenty thousand random arguments actually found in the copy of glibc installed on the capture machine. The two columns are in different units and the mismatch is deliberate: see below.
function	published, ulps	measured, wrong on	measured, whole doubles	real error implied

The units are not the same, and pretending otherwise would be the easiest lie on this page. The published figure is a real number of ulps: an error of 0.9 ulp is reported as 1. What this page measures is how many representable doubles apart two answers are, which is an integer. An integer distance of 1 means the real error lay somewhere in the half-open range above half an ulp and up to one and a half. So a measured 1 and a published 1 are consistent, and a measured 3 against a published 4 is consistent, and neither is a coincidence to be celebrated.

…

The manual says the rest itself, and it is worth reading as a sentence about how published error bounds are made rather than as an excuse:

…
…

That is the honest shape of the gap between your number and the published number, everywhere on this page. The published number is what somebody's test suite found. Yours is what a thousand arguments drawn from a seed found in your browser, thirty seconds ago. Neither is the maximum. The maximum is not known for any of these functions, which is section 5.

5. The arguments nobody can round

The reference on this page rounds a few hundred bits of the true value down to fifty-three. That works because the bits it discards almost always decide the matter: the true value sits clearly nearer one double than the other. Almost always.

Sometimes the true value sits so close to the exact midpoint between two doubles that a few hundred bits cannot tell which side it is on. There is no clever fix. You compute more bits, and either that settles it or it does not, and nobody can tell you in advance how many will be enough. This is the Table Maker's Dilemma, and it is why correctly rounded is a hard property to ship rather than an obvious one.

It is also measurable, and the measurement has a shape you can predict before you take it. For a random argument, the bits of the true value past the point where the double stops behave like a fair coin. The chance that the first k of them are all the same, which is what it takes to sit within 2^-k of the midpoint, halves with every extra bit. So the count of arguments at each margin should fall by half, step after step, and the reference's refusal rate at a given working precision is the tail of that same fall.

Instrument 5 · the dilemma, and the refusal

Nothing measured yet.

Gold is what your browser counted. Blue is N / 2^(k-1), the prediction, which was not fitted to anything.

At low working precision the reference declines to name a value. This measures how often, at each precision.

How often the reference refuses, against its working precision, in your browser. A refusal is not an error and is never counted as agreement: those arguments are removed from the census denominator and reported separately.
working bits	refused	rate	expected from the halving law

…

6. One bit becomes the whole trajectory

A wrong last bit is a relative error of about one part in nine quadrillion, and for most purposes that is the end of the discussion. Not for all of them. Feed the two answers into a system that amplifies differences and the difference stops being small on a schedule you can compute in advance.

The map used here is x → 4x(1-x), chosen because its rate of amplification is not a fitted number but an exactly known one. Substituting x = sin²(πt/2) turns it into t → 2t mod 1, whose derivative is 2 wherever it exists; a change of variable cannot change a Lyapunov exponent; so the exponent is ln 2, exactly. One bit of separation is lost per step. Two trajectories that begin one double apart should therefore be visibly different after about 48.7 steps, and that number is arithmetic, not a fit.

The seeds below are not hypothetical. They are the values two real browsers actually returned for Math.exp, captured on one machine, at the arguments where they disagreed.

Instrument 6 · fifty steps

Two trajectories from two engines' answers to the same question. They are drawn on top of each other and stay that way, until they do not.

…

And sometimes the opposite happens, which is the half of this that a demonstration would leave out. The map contracts wherever the absolute value of 4 - 8x is below one, which is a quarter of the interval, and a difference of a single double can be rounded out of existence there. When that happens the two engines agree from that step onward, forever, and there is no divergence time to print. … The page prints which of the two happened rather than a number in both cases.

7. What your engine tells a stranger

If the answers differ by engine, the answers are a name badge. This is not a hypothetical: it is the stated reason Firefox changed its arithmetic. In July 2021 Tom Ritter posted an intent to implement to mozilla.dev.platform under the subject Intent to Implement: Use fdlibm for Math.cos, Math.sin, and Math.tan to prevent math-based fingerprinting, and the bug it closed, 531915, Floating point differences between platforms, had been open since 30 November 2009. It was resolved fixed on 13 August 2021, against milestone 93.

Here is what your engine discloses through this door, and here is the honest accounting of how much that is.

Instrument 7 · your signature

The row worth looking at is the first one. Math.pow(Math.PI, -100) returns one of exactly two doubles, and both of them are written out by name in a comment in Firefox's own source, in js/src/builtin/Math.cpp, where a function called pow_libm_or_fdlibm decides which library to call:

…
…

…

So the honest version of the fingerprinting claim, in 2026, is narrow and specific: a Firefox on Windows still computes sine with whatever Microsoft ships, and a Firefox anywhere else does not. The capture machine here runs Linux, so every trace on this page is from the fdlibm side of that switch and this page cannot show you the Windows side. If you are reading this on Firefox for Windows, your sin column is the one measurement on this page that nobody else here has.

What the check panel checks

Every number above that came from the thousand-argument sample is recomputed below, in your browser, from the reference engine and the committed traces. The traces are not shipped raw: the page carries the reference table and the 1,812 places where the five engines depart from it, in place of 40,000 doubles, and rebuilds each engine's full run from those departures. The check panel hashes each rebuilt run and compares it against a digest taken from the raw captured file, so a lossy or drifted encoding cannot pass quietly.

The figures marked OFFLINE are the exception, and it is worth being exact about what the mark means. The twenty-thousand-argument census is half a minute of BigInt and no browser is going to redo it while you wait, so the page reads its counts from a file. A file is not a measurement. What travels with that file is the list of every argument at which each engine departed from the reference, and the panel below requires all forty counts to equal the length of the list behind them, which is the check that was missing when an audit forged two of those counts and every green light on this page stayed green. The lists themselves are re-derived offline, against a reference recomputed from scratch, by research/the-rounding-you-were-allowed/verify.mjs, which also re-runs glibc over all twenty thousand arguments and requires the departures to come back identical.

Three of the checks are controls that must come back dirty, and they matter more than the ones that come back clean. A reduction that cannot fail a deliberately corrupted trace has not proved anything by passing a real one.

Show the check

Running…

Apparatus

What is being run

The arbiter is reference.mjs, a binary floating-point arithmetic carried in BigInt: a value is a signed BigInt significand of exactly W bits times a power of two, every operation rounds to W bits, and a running budget of half-ulps decides whether the final rounding to a double is determined or must be refused. Pi is summed by Machin's formula and the natural logarithm of two by an inverse hyperbolic tangent series, both to whatever precision the caller asked for, so raising the working precision cannot silently reuse a constant good to 53 bits. Exponential is argument-reduced against ln 2 and then halved before a Taylor sum; logarithm is Newton's method on the exponential from a double-precision seed; sine and cosine are reduced against pi over two and halved; tangent is their quotient; arctangent is Newton on the tangent. Square root and cube root use exact integer roots and no series at all, which is deliberate, because square root is this layer's control and a control computed by the same approximate machinery as the thing it controls is not a control.

The page, the lab scripts and verify-the-rounding-you-were-allowed.mjs all import that one file, and ulp.mjs beside it, and chaos.mjs beside that. There is no second copy of any of them. That is the only reason the verifier is able to disagree with the page: a verifier holding its own copy of the page's rule cannot catch a mistake in the rule.

The reference was checked against a second opinion that shares no code with it. 03-cross-check-python.mjs recomputes exponential, logarithm, sine, cosine, tangent and arctangent in CPython at 70 significant decimal digits using the Decimal type, and settles square root and cube root exactly, with no series anywhere, by cubing or squaring the midpoint between the two candidate doubles as an exact rational and comparing it with the argument. 8,000 comparisons (…), 0 disagreements, and the offline mirror re-runs all eight thousand rather than reading the count out of a file. For exponential, logarithm, arctangent and the two roots that is an independent algorithm as well as an independent arithmetic: the arctangent here is argument halving and a Taylor sum where the reference runs Newton's method on its own tangent. For sine, cosine and tangent the reduction-plus-Taylor idea is shared but no line of code is. Arctangent was added to this list after an audit found it was the one function of the eight the page called checked twice and was not.

The machines

…

The five columns of the census, and what produced each one. The user-agent strings are what the build reports about itself, read out of the trace files; the host column is where the process actually ran, and where the two disagree the host is the one to believe. The census table in section 2 points at this date.
column	what it is	as it identifies itself	host	captured

Sources

The rule fixed before measuring

The argument list is a 48-bit linear congruential generator, multiplier 25214903917, increment 11, seed 20260807, mapped onto a domain declared per function in ulp.mjs before any engine was run. Every engine on this page, and yours, sees byte-identical arguments.
An engine is wrong at an argument when the double it returned is not the double the reference names. Not "nearly", not "within tolerance". The comparison is on all sixty-four bits.
Where the reference refuses, the argument is struck from the denominator and reported separately. It is never counted as agreement. Across the committed 1,000-argument and 20,000-argument runs at 160 working bits, the refusal count is zero, so no rate on this page has been affected by this rule; it exists so that the rule was fixed before it was needed rather than after.
The functions measured are the eight where a correctly-rounded reference could be built and checked twice, which now means all eight and did not when this page was first written. Seven are on ECMA-262's latitude list. The eighth, square root, is the control, and was chosen as the control before it was discovered that the standard had changed underneath it.

What this page does not claim

That the rates here are each engine's worst case. They are not. A thousand random arguments finds what a thousand random arguments finds; the true maximum error of any of these functions is unknown, which is the subject of section 5.
That any engine is correctly rounded. A zero cell means no disagreement was seen in that many draws. Square root at 0 of 20,000 is a strong statement and still not a proof; the guarantee for square root is IEEE 754, which has required correct rounding for it since 1985, and since the 16th edition ECMA-262 requires it too. Neither of those is something this measurement establishes.
That the two camps are two libraries everywhere. They are exactly two answers on most of these functions and more than two on sine and cosine, and section 2 prints the counts rather than asserting the picture. Naming one camp fdlibm is a label on three engines, and on those two functions the label has come apart: whatever the newest V8 here computes them with, it is not what the older V8 in Node computes them with.
That these are the engines you are running. Every captured column is a headless browser on one Linux desktop on one afternoon. A Safari on a Mac, a Chrome on Windows and a Firefox on Windows are all absent, and the last of those is named in section 7 as the specific gap.
That the two-camp split generalises beyond this machine. JavaScriptCore agreeing with glibc on all 8,000 committed values is a fact about a Linux build; on macOS the system library is a different one.
That glibc is right. glibc is one of the five subjects. The arbiter is the BigInt reference, and where they disagree the reference is the one with a second opinion behind it.
That the fingerprinting vector is open or closed. It is open on one named configuration, closed on the others measured, and this page measured none of the Windows ones.

Predictions, and how they did

Written down in research/the-rounding-you-were-allowed/PREDICTIONS.md before the traces were captured.

P1 held. About one argument in ten would show a one-bit disagreement on the exponential. The three fdlibm engines came in at … over 20,000 arguments, and the two system libraries at …, which is P2.
P2 died, and took the page's framing with it. I predicted that the two browsers using fdlibm, the library the standard itself recommends, would be the accurate ones, and that whatever else was out there would be the outlier. It is the reverse. On … of the … functions the fdlibm engines are the less accurate ones, by factors running from …, because fdlibm dates from 1993 and the system libraries have been rewritten since. The standard's recommendation is a recommendation to be less accurate. It ties on … and loses on …, which is P3. This item said "seven of eight" and "twenty to a hundred and fifty" until an audit counted six; and it said six until the margin was looked at. Two of that six were carried by … out of twenty thousand, which is not a difference. The rule now requires three standard deviations of the difference between two counts before a function is assigned to a camp at all, and … are where the camps do not separate, for the reason section 2 gives: the three engines carrying the fdlibm label do not agree with each other there.
P3 died. I predicted cube root would behave like the others. It is the one function where the direction reverses: the system library is wrong on … of arguments by up to … whole doubles, and fdlibm is wrong on … by ….
P4 held. Square root would be identical everywhere. It is, on all 20,000, in all five engines.
P5 was not a prediction and is recorded because it should have been. I did not predict that the standard had changed underneath the control. The zero itself is IEEE 754's doing and was never in doubt; what turned up while checking the section numbers, not while looking for it, is that ECMA-262 had stopped permitting anything else between the 15th edition and the 16th.

Errors this page made, and kept

The cube root that was not a cube root. The first version of this study compared JavaScript's Math.cbrt against Python's abs(x) ** (1/3) and reported a divergence of 24.2%. Those are different functions: one third is not representable as a double, so the exponent is already wrong before any library is reached. The real figure for Math.cbrt against the same reference is 9.1%. The wrong number is kept in 05-negative-controls.mjs as control C5, which requires the substitution to diverge measurably more than the real function, so that the mistake is now a thing the check panel would notice if it were made again.

The zero that was not a zero. On the committed 1,000-argument sample, Chromium's Math.sin was wrong on 0. The sentence I nearly wrote was that Chrome's sine is correctly rounded. At 20,000 arguments it is wrong on 36. A rate near 0.18% has better than a one in six chance of showing nothing at all in a thousand draws, and it showed nothing at all. The 0 of 1,000 is still in the census table, because it is what a thousand arguments found and the reader will run a thousand too. The 20,000-argument count is not in that table: it is in the check panel, on the line marked OFFLINE that prints both numbers together, and this is what that mark is for.

The seeds that were all in the same place. The first version of section 6 mapped each engine's answer into the interval from 0.25 to 0.75, which put every seed within a quarter of the map's critical point, where the map contracts. Half the pairs had their one-bit difference rounded away on the first step and the demonstration was measuring the seeding rather than the arithmetic. The mapping now spans the whole interval and annihilation is reported as its own outcome rather than as a failure to diverge.

A committed field that quotes the wrong comment, and is not printed. The pref block in firefox-source.json carries a comment field whose first sentence belongs to the pref above it in the file: a fixed-length lookback walked back through the blank line between two entries. Nothing on this page renders that field (section 7 describes the pref in its own words and reads only the two default values), so no misquotation reached a reader, and both verifiers now assert that it stays unrendered. The extraction in 11-firefox-source.mjs is fixed, but the committed artifact is left as it was captured rather than edited by hand, because a fetched file that gets corrected by hand afterwards is no longer a fetched file.

A size labelled bytes that was a character count. The files entries in the same artifact, and in spec-quotes.json, recorded a JavaScript string length: 35,515 for Math.cpp against 35,553 actual bytes, because a string length counts UTF-16 code units. The sha256 beside it, which is the field that actually identifies the file, was right. The label now says chars.

What the checks were tested with

A check panel that has never failed is a claim about the panel, not about the page, so five deliberate defects were introduced one at a time and the verifiers were run against each. Three were caught immediately: a single hex digit flipped inside a committed trace, a reduction that stopped counting engines that round down, and a page-wide layout regression on a narrow screen. Two were not, and both gaps are now closed.

Ties changed from round-to-even to round-away, and every check passed. The branch is unreachable from any function measured here: the true value of a transcendental is irrational, so it never lands exactly on the boundary between two doubles, and the two roots take a different code path. It was code nothing tested. The offline mirror now drives it directly on nine constructed exact ties, and the same mutation now fails.
A digit was changed inside a quoted source comment, and every check passed. The page printed the quotation from hand-typed HTML while printing the two values it names from data, so nothing ever compared the quotation with the thing it quotes. The comment is now a committed artifact fetched by 11-firefox-source.mjs, the page writes the blockquote from that file at runtime, and both verifiers re-extract the numbers from the quoted text rather than trusting the list beside it.

The second of those is the one worth stating plainly: for as long as that quotation was typed rather than fetched, this page could have been misquoting its source and every green check would have said so.

Adversarial passes over the finished page then found three more. The first and the last are the same species, and it is the species this whole layer is about: a setting in which the check cannot fail.

A setting where the central comparison was true by construction. The working-bits slider in section 1 goes down to 54, and below about 60 bits the reference refuses nearly every argument. The hunt walked past each refusal, ran out of list, and announced in the green class that your engine had got all thousand right, beside the sentence that this is what the sqrt row looks like. It was a thousand refusals reported as a thousand agreements, which is this page's own stated rule inverted. The verdict is now written by a pure function that counts refusals, the panel drives that function at 54 bits and requires it to refuse, and the browser pass drives the real slider to the real minimum and requires the same.
A second setting where the comparison could not fail, and this one needs no slider. Type 0 into the argument box, or an argument big enough to overflow, or a perfect square, and instrument 1 printed your engine is exactly right here in the green class. It had no choice. Those are the arguments ECMA-262 pins with a normative return step, or where the true value leaves the range of a double, or where the root is exact, and no conforming implementation is permitted to differ at any of them. The instrument names them now and declines to score them. The panel drives all three classes, and an ordinary argument that must still be scored, and the browser pass types them into the real box; no argument in the pre-registered list is one of them, which the panel checks by requiring every reference value to be finite and non-zero.
An OFFLINE figure with nothing behind it. The 20,000-argument census shipped as a summary: no raw run, no digest, no departure list. Two of its counts were forged, both verifiers and this panel were re-run, and everything stayed green, because the only numeric guard on the page's most striking record correction was that it be greater than zero. The departure lists now travel with the summary, all forty counts must equal the length of the list behind them, and the offline mirror recomputes the whole deep reference from scratch, rebuilds every engine's twenty thousand values from those lists, checks a digest of each, and re-runs glibc through python3 over the same twenty thousand arguments to require the departures back identical.

Four figures went the same way in the same pass. The real errors quoted in section 4 (the tangent departures adjudicated at 110 decimal digits) existed only inside the sentence that printed them: no script produced them, no file held them, and a changed digit would have passed everything. They are an artifact now, recomputed in front of you at 380 working bits and independently in CPython's Decimal. They were, as it happens, correct.

Then a third pass, by a re-derivation of the central claims from the primary documents, carried out without sight of this page, of its data or of its scripts. It is where three more corrections came from, and not one of them was a wrong number. The first is the sentence section 3 now opens with: the order of events behind the sqrt row was told backwards, and the standard was being credited with a guarantee that IEEE 754 had already made. The second is that two of the functions counted in prediction P2 were carried by a difference of one count in twenty thousand, printed as a factor of about one and read as though it meant something. The third is the second vacuous setting above. It also reproduced independently, on its own arguments and its own instrument, the two results this page leans on hardest: that WebKit's engine and glibc are one arithmetic on this machine, and that on cube root it is the system library that is inaccurate, by up to three whole doubles.

Reproducing

The lab is research/the-rounding-you-were-allowed/. In order: 00-spec-quotes.mjs pulls the quoted sentences and clause numbers out of three editions of ECMA-262 (needs network); 01-capture-traces.mjs drives Chromium, Firefox and WebKit through Playwright and reaches glibc through python3, writing the golden traces; 02-reference-table.mjs computes the correctly-rounded answers; 03-cross-check-python.mjs checks those answers against CPython and against exact rational arithmetic; 04-census.mjs prints the headline table; 05-negative-controls.mjs runs the six controls; 06-hard-to-round.mjs measures the dilemma; 07-one-bit-becomes-everything.mjs runs the trajectories; 08-build-page-data.mjs writes what this page ships; 09-glibc-table.mjs fetches the published bounds (needs network); 10-deep-census.mjs is the 20,000-argument run behind every OFFLINE figure; 11-firefox-source.mjs commits the quoted source comment and the pref defaults (needs network); 12-tan-real-ulp.mjs adjudicates the glibc tangent departures in two arithmetics; 13-first-edition.mjs fetches the 1997 first edition and extracts the sentence from it (needs network and pdftotext). The offline mirror is research/the-rounding-you-were-allowed/verify.mjs and the browser pass is verify-the-rounding-you-were-allowed.mjs at the repository root.