How Sumvia rounds and displays numbers

Every Sumvia calculator follows a single rounding policy, and this guide shows it working. The policy exists to answer one awkward question: when a result on screen reads 33.333333% or 0.3, what exactly is being shown — the number the engine computed, or a tidied-up version of it? The short answer is that the two are deliberately different, and the difference is documented rather than hidden. What follows explains the three layers a figure passes through on its way from the arithmetic to the screen, why each layer exists, where it stops, and the misreadings it is designed to prevent.

Three layers between the math and the screen

A Sumvia result is not formatted in one step. It passes through three, and keeping them distinct is what lets the site be both precise and readable at once:

• Internally, calculations keep the full precision of IEEE-754 double-precision arithmetic — nothing is rounded between steps. The engines themselves perform no rounding at all; each one is documented as leaving display rounding to the formatting layer.
• Before display, a value is normalized to twelve significant digits. This strips the binary floating-point artifacts that make a naive calculator read oddly, while preserving far more precision than is ever shown.
• On screen, the normalized value is rounded to at most six decimal places — with one exception, covered below, that keeps very small results visible.

The three layers map onto one claim: what you see is a cleanly rounded presentation of a more precise internal value. The sections below walk a number through each layer so the claim is something you can check rather than take on trust.

Why 0.1 + 0.2 is not 0.3 until it is

Start with the arithmetic every programmer meets eventually. Neither 0.1 nor 0.2 can be stored exactly in binary floating point, so their sum carries a trailing error: computed directly, 0.1 + 0.2 evaluates to 0.30000000000000004, not 0.3. That long tail is not a Sumvia bug — it is how double-precision arithmetic represents those particular fractions, and a calculator that printed the raw sum would be reporting the representation rather than the answer.

The normalization layer removes it. Rounding 0.30000000000000004 to twelve significant digits collapses the tail, and the formatter shows 0.3. The error lived in the sixteenth or seventeenth digit; twelve significant digits is precise enough to keep every figure this site computes while being well short of where the binary noise begins. Normalization is a scalpel aimed at that noise, not a rounding of the result itself.

One third, and what six decimal places really caps

Floating-point artifacts are one reason a displayed figure differs from the internal one; genuine non-terminating decimals are the other. Ask the percentage engine the plain question "1 is what percent of 3?" and it returns a value that, carried to the engine's own precision, reads 33.33333333333333. One third has no finite decimal expansion, so there is no exact figure to print — only a choice of where to stop.

Watch the same value cross each layer. The engine holds 33.33333333333333. Normalization to twelve significant digits gives 33.3333333333. The six-decimal display cap then rounds that to 33.333333% on screen. This is the distinction the methodology page draws between displayed rounding and internal precision: the six decimal places you read are a window onto a value the engine still holds in full. It also explains why two correct calculators can disagree in their last digit — if their display caps differ, both can be right and still print different strings.

The same sale, a repeating markup

The policy is not an abstraction reserved for thirds; it governs the business figures these pages exist for. Take one fictional sale: a cost of 60 sold for 100. The profit-margin engine reports the margin as a share of the selling price and the markup as a share of cost — the distinction that runs through the whole business module. Here the margin is exact at 40%, while the markup, dividing the same 40 of profit by the smaller cost, lands on 66.66666666666666 before display.

That markup is a repeating decimal, and it travels the same three layers as one third did: the engine holds 66.66666666666666, normalization yields 66.6666666667, and the screen shows 66.666667%. The lesson is that the display policy is content-blind. It does not know a markup from a margin from a churn rate; it rounds whatever finite value the engine hands it by the same rule, which is precisely why a single documented policy can stand behind every calculator on the site.

Tiny results are shown, never swallowed

A flat "six decimal places" rule has a failure mode: a real result smaller than the smallest representable six-decimal figure would round to 0, and a calculator that answers a genuine question with zero is worse than one that admits it cannot show the number. Sumvia avoids this with a single exception to the display cap. When a nonzero value would round to zero at six decimal places, the formatter switches to six significant digits instead.

The worked example makes the switch visible. Asking the percentage engine for 0.00004% of 1 returns 0.0000004. Six decimal places alone would have shown that as zero; the significant-digits fallback keeps the leading digit on screen. The rule is narrow and precise — a tiny nonzero result is never displayed as "0" — and it never lengthens an ordinary figure, because it engages only when the plain six-decimal format would otherwise erase a real answer.

The supported input range

Rounding governs what leaves the calculator; a second limit governs what may enter it. Inputs are accepted up to a magnitude of 1,000,000,000,000,000 — the documented range of -1,000,000,000,000,000 to 1,000,000,000,000,000. The ceiling is not arbitrary: it keeps every calculation inside the territory where double-precision arithmetic represents integers and products exactly enough for a general-purpose calculator. A value beyond the range is reported as out of range rather than accepted and quietly computed with eroding accuracy.

The same honesty applies to operations with no conventional answer. As the methodology page puts it, undefined operations are reported as such rather than answered: "a percentage of a zero whole, or a percentage change from a zero baseline, has no conventional value, and the calculator says so explicitly instead of showing an infinity or an error code." The display policy formats only genuine finite results; it is never asked to render an infinity, because the engine never produces one.

Reading a result into further work

The one practical consequence worth internalizing follows from the gap between the displayed and internal values. A figure you copy off the screen is the rounded one, not the full-precision value the engine kept. For a single answer that is exactly what you want. For a chain of calculations, rounding at each hand-off accumulates: feeding 33.333333% back in as though it were the exact third introduces a small error that the next step compounds. The methodology page's guidance is direct — "for chained work, prefer doing the whole calculation in one pass" — which is why many Sumvia calculators report several related figures from one set of inputs rather than making you carry a rounded result between tools.

Frequently asked questions

This guide describes how figures are rounded and displayed, not which calculation is right for your situation: the calculator implements the general definition; your jurisdiction's or contract's conventions may differ. The full implementation and testing details are on the methodology page, and the rest of the series is listed on the guides hub.