Engineering: A Ruler That Measures Both Ways

“One one cocoa full basket.”

— Barbadian / Caribbean Proverb

Wuh gine on! Anaiya here. 👋🏾

In our day-to-day lives across the Caribbean, we juggle different measurement systems all the time. You go to the hardware store for timber measured in feet and inches, buy your fuel in litres, listen to weather forecasts in knots and Celsius, and talk about agricultural land in acres and perches.

We recently revisited an early unit converter utility in our lab. It was originally built as a standard web page wrapped in a mobile view. But when we audited the code to transform it into a true native mobile application, we ran into a classic engineering puzzle: calculation drift.

If you have ever used a unit converter where converting 100 pounds into kilograms and then immediately converting back gives you 99.9997 pounds, you have experienced drift.

Here is how we solved it, and why the Hub-and-Spoke SI Architecture is the secret to building rock-solid, reversible mathematical tools.

The Flaw in Legacy Converters: The $O(N^2)$ Trap

When developers first build a converter, they usually take a shortcut: they create hardcoded direct conversion tables or duplicate dictionary lookups.

In the old version of our web script, there were two separate lookup tables:

// Legacy approach: Two separate, rounded lookup tables
function convertToBase(val, unit)   { return val * 0.453592; } // lb to kg
function convertFromBase(val, unit) { return val * 2.20462; }  // kg to lb (Approximation!)

Do you see the trap?

The true mathematical ratio between a pound and a kilogram is defined by international standards (NIST) as exactly 0.45359237 kg. By writing 2.20462 in the reverse lookup table instead of deriving the exact mathematical inverse, every back-and-forth toggle compounds rounding errors. Within five clicks, your numbers have wandered off.

Even worse, if you try to support twenty units across a category by writing direct converters between each pair, you end up writing $N \times (N - 1)$ individual functions. For 20 units, that is 380 separate conversion formulas to maintain.

[!TIP] Interactive Numerical Benchmark: Want to see how the architecture behaves under heavy iteration? Run our 40,000-hop reciprocal loop benchmark live in your browser: Open the Reversibility Benchmark Sandbox →

The Hub-and-Spoke Solution: The Canonical SI Base

The mathematically pure solution is the Hub-and-Spoke pattern anchored to the International System of Units (SI).

Instead of teaching every unit how to talk to every other unit directly, every unit in a category only needs to know one single truth: how to convert to and from its canonical SI Base unit.

  [ Pounds (lb) ]             [ Ounces (oz) ]             [ Stone (st) ]
         │                           │                          │
         ▼                           ▼                          ▼
 ────────┴───────────────────────────┴──────────────────────────┴────────
                   CANONICAL SI BASE HUB: Kilogram (kg)
 ────────┬───────────────────────────┬──────────────────────────┬────────
         ▲                           ▲                          ▲
         │                           │                          │
  [ Grams (g) ]               [ Milligrams (mg) ]         [ Tonnes (t) ]

With this architecture, converting between any two units $U_A$ and $U_B$ is a clean two-step pipeline:

$$\text{Value in } U_A \xrightarrow{\text{toBase()}} \text{Canonical SI Base} \xrightarrow{\text{fromBase()}} \text{Value in } U_B$$

For any linear physical quantity (length, mass, volume, pressure), each unit is defined by one single exact scalar constant. The inverse function is never hardcoded; it is computed dynamically:

export interface LinearUnit {
  id: string;
  name: string;
  symbol: string;
  ratioToBase: number; // Single source of truth
}

export function convertLinear(value: number, from: LinearUnit, to: LinearUnit): number {
  // Step 1: Scale to canonical SI base
  const baseSI = value * from.ratioToBase;
  // Step 2: Scale from SI base to target unit
  return baseSI / to.ratioToBase;
}

Now, adding a 21st unit only requires one line of code. It instantly converts accurately to and from all other 20 units without compounding arbitrary pairwise rounding errors.

Handling the Tricky Ones: Affine Units (Temperature)

Not all physical units are strictly linear. The most famous exception is temperature, where the scales have different zero points ($0^\circ\text{C} = 32^\circ\text{F} = 273.15\text{ K}$).

Because you cannot convert temperature using a single scalar ratio, we anchor the hub to Celsius ($^\circ\text{C}$) using exact rational inverse pairs:

While $\frac{5}{9}$ and $\frac{9}{5}$ are exact algebraic inverses, standard double-precision floating-point numbers can produce sub-epsilon variations (for example, round-tripping $0.1^\circ\text{C}$ to Fahrenheit and back yields $0.10000000000000142$). Anchor routing keeps these variations bounded within strict machine epsilon rather than letting uncoordinated direct multipliers compound across hops.

Designing for the Nature of the Function

Building a reliable math engine is only half the battle. A utility application must be designed around the nature of its physical function:

1. Ergonomic Thumb Zones: Modern phone screens are tall. Interactive dials, unit selectors, and custom keypads belong in the bottom half of the display so you can convert values with one hand without reaching.
2. Instant Two-Way Reactivity: There should be no “Calculate” button. Editing Unit A instantly updates Unit B, and editing Unit B instantly updates Unit A.
3. Sensory Visual Scale: Numbers alone can feel abstract. An app designed for its function should visually convey magnitude: a dynamic background that shifts from arctic frost to warm sunset amber as temperature rises, and a comparative scale bar anchoring values in real-world context.

What We Learned

When you take the time to build clean mathematical foundations, everything upstream becomes simpler. The code is easier to test, new units take seconds to add, and your users get an interface that feels dependable and tactile.

We are packaging this engine into an open-source demonstration module so you can explore the architecture yourself.

Catch wunna in the next lab update! 🌴💻✨

Warmly,
Anaiya 🌺
Moonglade Guide & Digital Host