How This Calculator Is Tested

Three automated suites run against the real calculation engine - not against mocks or copies - and all of them must pass before the site is built. Together they make just over eleven hundred assertions.

What the engine suite checks

• Arithmetic and precedence - that the documented order of operations is what actually happens, including the awkward cases: −5², right-associative exponents, and left-to-right division.
• Every function on the keypad against known reference values - the exact trigonometric values, logarithms in several bases, roots, factorials, permutations and combinations.
• Both angle modes, since a function that is right in radians and wrong in degrees is a whole class of bug.
• Error handling - that each invalid input produces the specific error code documented in the error message guide, not merely "an error". A test that only checked "this fails" would not catch an input failing for the wrong reason.
• Formatting - that rounding, thousands grouping, scientific-notation thresholds and localized digits all behave as documented.

What the content suite checks

This is the unusual one, and the reason it exists is simple: published numbers drift. Someone edits an example, or a library changes a rounding behaviour, and a page quietly starts claiming something false.

• Every worked-example result is recomputed by the engine and compared to the published figure.
• Every reference-table value - the factorials from 0! to 20!, powers of two, logarithm tables, degree-to-radian conversions, fraction equivalents - is verified the same way.
• Every error-message claim is checked by actually triggering that error and confirming the code.
• Every tool on a calculator page is evaluated on its shipped default values, so no page can ship with a broken widget.
• Structural checks: unique slugs, meta descriptions within the length budget, rectangular tables, and no internal link pointing at a page that does not exist.

Known limits

Being specific about what a tool cannot do is more useful than claiming it does everything.

• About 15–17 significant digits of underlying precision, displayed as 12. This is standard double-precision floating point. See why 0.1 + 0.2 is not 0.3.
• Integers are exact only up to 9,007,199,254,740,991 (2⁵³ − 1). Above that the display switches to scientific notation rather than printing digits that are not reliable.
• Real numbers only. There is no complex-number support, so √(−4) returns an undefined result rather than 2i.
• Values near a trigonometric asymptote are approximations. tan(90°) returns a very large finite number rather than an error, because 90° cannot be converted to exactly π/2 in binary.
• Factorials overflow above 170!, which exceeds the largest representable double.
• No symbolic algebra. This is a numeric calculator; it does not simplify expressions or solve equations.
• A pasted or hand-edited expression can defeat thousands-grouping detection. The editor tells a grouping comma ("12,345") from a function-argument comma ("nPr(5, 2)") by whether a space follows it - typing and the on-screen keypad always insert the space, so this never comes up in normal use. But backspacing that space back out, or pasting in an already-unspaced call, reads as a grouped number instead: for a function like nPr or nCr that always needs two arguments, the result is a clean error. For log or nthRoot, whose second argument is optional, the same edit is silently accepted as one merged number and returns a different, wrong answer with no error at all - log(1024,2) with no space evaluates as log₁₀(10242), not log₂(1024). Keep the space after a function-argument comma.

Why math.js

The expression parser is math.js, a mature open-source library with its own extensive test suite and a large user base. Writing a parser from scratch would have meant reproducing years of edge-case handling with far fewer eyes on it.

A thin layer sits on top of it, and that layer is where the deliberate divergences live: log is redefined as base 10 to match scientific-calculator convention, trigonometric functions honour the degree/radian toggle, mod by zero returns undefined instead of math.js's dividend, and nPr and nCr are restricted to whole numbers rather than generalising through the gamma function. Each of those overrides is covered by its own tests, because an override is exactly the kind of code that silently regresses.

• What each error message means
• Why floating-point results drift
• About the author

Frequently Asked Questions