Unit-Scale
UNIT CONVERTER
Technical Transparency

Unit Conversion Methodology

This document explains how conversion factors are structured, how calculations are executed, how precision is managed, and how regional unit variants are differentiated within this platform.

1How Conversion Factors Are Stored

Rather than hardcoding separate pairwise formulas for every possible combination of units (which would require over N(N-1) formulas and increase error probability), our architecture establishes a canonical Base Unit for each physical dimension:

  • Length: Meter (m)
  • Weight & Mass: Kilogram (kg)
  • Temperature: Kelvin (K)
  • Area: Square Meter (m²)
  • Volume: Liter (L)
  • Speed: Meter per Second (m/s)
  • Time: Second (s)

Every unit in our database stores an exact conversion factor representing its ratio to the dimension's base unit. For example, in the length category:

1 yard = 0.9144 meters (exact by 1959 international agreement)
1 inch = 0.0254 meters (exact)
1 foot = 0.3048 meters (exact)

2How Calculations Are Performed

For linear dimensions, any conversion from unit A to unit B is evaluated via a two-step transformation through the base unit:

BaseValue = InputValue × Factor(A)
TargetValue = BaseValue ÷ Factor(B)

For example, converting 5 yards to inches:

  1. BaseValue = 5 × 0.9144 m = 4.572 m
  2. TargetValue = 4.572 m ÷ 0.0254 m/in = 180 inches

3Decimal Arithmetic & Floating-Point Handling

Standard JavaScript numbers are stored as 64-bit binary floating-point values (IEEE 754). In binary representation, simple decimal fractions like 0.1 or 0.2 cannot be represented with finite binary bits, which produces well-known artifacts like 0.1 + 0.2 = 0.30000000000000004.

To mitigate this, Unit-Scale executes calculations using the decimal.js library set to 28 digits of internal precision. Operations are carried out in decimal base, allowing exact multiplications and divisions.

Note: While arbitrary-precision decimal arithmetic removes binary conversion artifacts, irrational conversion factors (such as conversions involving π) or repeating fractions (such as 1/3) still require standard rounding to a reasonable display limit.

4Rounding and Display Precision

Our interface provides users with an explicit precision control (from 2 up to 10 decimal places, defaulting to 6).

  • Exact Integers: Results that evaluate to integers are displayed without artificial decimal points or trailing zeros (e.g. 5 yards = 180 inches, not 180.000000).
  • Trailing Zeros: For non-integer numbers, trailing zeros beyond significant figures are trimmed.
  • Scientific Notation: Values with absolute magnitude greater than 1012 or smaller than 10-6 (except zero) are rendered in scientific exponential notation (e.g. 1.23e-8) for clarity.

5Temperature Scales (Affine vs. Linear Transformations)

Temperature scales cannot be converted purely by multiplication because their zero points do not correspond:

  • 0 °C corresponds to 273.15 K (the approximate freezing point of water).
  • 0 °F corresponds to approximately -17.78 °C.
  • The Celsius and Fahrenheit scales share only one numerical equivalence point: -40 °C = -40 °F.

Therefore, our engine handles temperature conversions via explicit affine transformation formulas:

Celsius to Fahrenheit: °F = (°C × 9/5) + 32
Fahrenheit to Celsius: °C = (°F − 32) × 5/9
Celsius to Kelvin: K = °C + 273.15

6Differentiating US Customary and Imperial Units

A common source of errors in conversion tools is conflating US Customary and British Imperial units that share the same name but describe different physical quantities:

Unit NameUS Customary DefinitionBritish Imperial DefinitionVariance
Gallon3.785411784 L (231 cu in)4.54609 LImperial is ~20% larger
Fluid Ounce29.5735295625 mL28.4130625 mLUS is ~4% larger
Ton907.18474 kg (2,000 lb, Short Ton)1,016.0469 kg (2,240 lb, Long Ton)Long ton is ~12% heavier

Unit-Scale maintains distinct records for these units with explicit regional labels in selectors, headers, and metadata to prevent accidental confusion.

7Validation & Error Correction Procedures

Before any conversion relationship is approved for indexing, our automated build pipeline validates:

  • Unit Existence: Source and target units exist in the registry with documented citations.
  • Category Compatibility: Source and target share identical physical dimensions.
  • Mathematical Reciprocity: Converting value V from A → B and then B → A returns V within tolerance.
  • No Placeholders: Content contains no boilerplate placeholder tokens or empty fields.

If you encounter any discrepancy in our conversion factors, please report it via our Contact & Feedback page. Reported issues are reviewed against primary standards and corrected immediately in code.