Centimeters to Inches: Exactness vs. Rounding

DEV Community

Converting Centimeters to Inches Without Pretending Rounded Results Are Exact

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 prote...

Powered by Readybot.io