One inch is exactly 2.54 centimeters, but that does not make every centimeter-to-inch result an exact decimal. I wanted a small conversion page to make that distinction clear: an exact unit definition, a floating-point calculation, and a rounded display are three different things.

This matters when you build a measurement UI. The usual multiplication or division is easy; deciding how many digits to show, what a reverse conversion means, and whether a tiny measurement should disappear is where the numerical contract actually takes shape.

Use Exact Definitions Without Duplicating Pair Formulas

The conversion page uses the same helper as the site's general length converter. Instead of storing a formula for each direction, the helper gives each supported unit a scale relative to meters.

The relevant entries are cm: 0.01 and inch: 0.0254. The actual conversion function is:

export function convertLength(value, fromKey, toKey) { const meters = (Number(value) || 0) * (lengthUnitMap[fromKey] || 0); return lengthUnitMap[toKey] ? meters / lengthUnitMap[toKey] : 0; }

For centimeters to inches, it multiplies the input by 0.01 and divides by 0.0254. Algebraically, that is the familiar division by 2.54.

The useful design decision is not making the arithmetic shorter. It is having one unit table serve both the general converter and the fixed-pair page. Correcting a scale or adding a supported unit should not require hunting through many slightly different copies of the same formula.

The inch definition itself is exact. A rounded reciprocal such as 0.3937 inches per centimeter is an approximation, so repeatedly using that shortened multiplier introduces an avoidable source of error before display rounding even begins.

The helper does not use a decimal-arithmetic library, however. Its constants and operations are JavaScript Number values, so the exact definition is still evaluated through binary floating-point arithmetic.

An Exact Constant Does Not Mean an Exact Binary Fraction

Most decimal fractions do not have a finite representation in binary. The same issue that makes 0.1 + 0.2 surprising also applies to ordinary measurement constants.

That does not make JavaScript unusable for a household measurement converter. It means the presentation should not confuse a long sequence of digits with certainty, or assume two algebraically equivalent expressions must produce bit-for-bit identical intermediate results.

The shared helper rounds its output as follows:

export function roundLengthResult(v) { if (!isFinite(v)) return 0; return Math.round(v * 1e6) / 1e6; }

For 100 centimeters, the displayed result is 39.370079 inches. For 2.54 centimeters, it is 1 inch. Those are sensible outputs for the page's six-decimal policy.

Notice what the function returns: a number, not a string padded to six decimal places. A result of 1 is displayed as 1, not necessarily 1.000000. “At most six decimal places” is a different promise from “always show six places.”

The limit also concerns decimal places, not significant figures. A value close to zero can lose a much larger proportion of its information than a large value. A single display policy is convenient, but it is not a complete scientific measurement policy.

I would keep input precision, calculation precision, and display precision separate when reviewing a numeric interface. A precise-looking display cannot recover uncertainty in a ruler reading, and rounding output should not be described as increasing the accuracy of the original measurement.

Round Trips Can Lose Information

The fixed-pair page lets the user edit either side. Its left-to-right synchronization writes a rounded output:

toValue.value = categoryConfig.value.round( categoryConfig.value.convert(fromValue.value, pair.value.from, pair.value.to), );

The reverse direction uses the corresponding reverse conversion. A synchronization guard prevents the programmatically written output from immediately rewriting the original input.

That protects the current editing direction, but it does not make rounding invertible. If the user later edits or copies the rounded inch result, that rounded number becomes the next input. Information discarded from the earlier result is no longer available.

A particularly clear boundary is 0.000001 centimeters. Converted to inches, it is about 0.0000003937 before display rounding. The six-decimal helper returns zero. Converting that zero back produces zero centimeters, not the original tiny measurement.

This is quantization, not evidence that the unit factor is wrong. Many different small inputs map to the same displayed number, so no reverse operation can identify which original value produced it.

For tests, I would check representative values with an explicitly chosen tolerance rather than asserting exact equality for every arbitrary round trip. I would also include a tiny input that intentionally rounds to zero. That test documents the actual output contract instead of treating the loss as an unexpected accident.

For ordinary nonnegative values, I can estimate that tolerance from the two rounding steps. Rounding inches to six decimal places contributes at most 0.0000005 inch, or 0.00000127 centimeters. Rounding the reverse result adds at most 0.0000005 centimeters, giving a combined absolute error budget of 0.00000177 centimeters, before allowing for floating-point error. That is a display-rounding budget, not a guarantee about the original measurement's accuracy or extreme numeric inputs.

Unit Conversion Does Not Interpret the Measurement

The page's English content discusses heights and screen sizes. The underlying function only converts a scalar length; it does not know what was measured.

A screen measurement in inches generally describes the diagonal. Converting that diagonal to centimeters does not tell you the display's width or height without an aspect ratio. Similarly, a number of inches is not automatically a feet-and-inches height string.

The rounding helper returns zero when its incoming, unrounded result is nonfinite. That check happens before multiplication by one million: a sufficiently large finite result can still overflow during rounding and return Infinity. For example, converting 1e308 centimeters produces a finite intermediate result, but rounding it overflows. The function does not recheck after scaling.

Input handling is a separate boundary. Both fields use type="number", v-model.number, and min="0". On blur, validateInput checks whether the value converts to a finite, nonnegative number and resets an invalid field to zero. That validation does not run before every conversion. The conversion helper itself also coerces nonnumeric input to zero, so these fallbacks do not establish that every displayed zero represents a genuine zero-length measurement.

For ordinary sizing comparisons, the implementation is useful precisely because its scope is small. For engineering tolerances, explicit error states, locale-aware parsing, or preservation of significant figures, I would define a stricter numeric model rather than silently extending the meaning of this one.

I turned this conversion and its shared rounding policy into a small free tool: CM to Inches Converter.