DEV Community: Leene Casella

Edge Cases in a Waist-to-Height Ratio Calculator: Units, Rounding, and Boundaries

Leene Casella — Sun, 01 Nov 2026 22:05:31 +0000

Waist-to-height ratio (WHtR) looks like the easiest calculator you could write: divide one number by another. It's also a good example of how a "trivial" calculator goes wrong in production. Users type centimeters into an inches box. Floating point makes a value that should sit exactly on a limit land a hair above it. A display rounded to two decimals disagrees with the pass/fail check underneath it.

This post walks through a small, dependency-free JavaScript module for WHtR and the tests that keep it honest. The limit in the examples (0.5) is only an illustration for the code. If you build a calculator for a real standard, take the threshold from the governing document and cite it on the page.

The core: one unit internally

The first decision is to convert everything to one unit as soon as input arrives, then do all comparisons in that unit. Mixing units in the middle of the logic is where most bugs start.

const IN_PER_CM = 1 / 2.54;

function toInches(value, unit) {
  if (!Number.isFinite(value) || value <= 0) throw new RangeError("measurement must be a positive number");
  if (unit === "in") return value;
  if (unit === "cm") return value * IN_PER_CM;
  throw new TypeError(`unknown unit: ${unit}`);
}

function whtr({ waist, height, waistUnit = "in", heightUnit = "in" }) {
  const w = toInches(waist, waistUnit);
  const h = toInches(height, heightUnit);
  return w / h;
}

// Compare against a limit without letting float noise or display rounding flip the answer.
function withinLimit(ratio, limit) {
  const EPS = 1e-9;
  return ratio <= limit + EPS;
}

// Largest waist (inches) allowed for a given height and limit, rounded DOWN to the tape's resolution.
function maxWaist(heightIn, limit, step = 0.5) {
  const raw = heightIn * limit;
  return Math.floor((raw + 1e-9) / step) * step;
}

module.exports = { whtr, withinLimit, maxWaist, toInches };

if (require.main === module) {
  const assert = require("assert");
  // Same person, two unit systems: the ratio must agree.
  const a = whtr({ waist: 34, height: 70 });
  const b = whtr({ waist: 86.36, waistUnit: "cm", height: 177.8, heightUnit: "cm" });
  assert(Math.abs(a - b) < 1e-9);
  // Boundary: exactly on the (illustrative) limit passes, a hair over does not.
  assert(withinLimit(35 / 70, 0.5));
  assert(!withinLimit(35.1 / 70, 0.5));
  // Mixed units
  const c = whtr({ waist: 34, height: 177.8, heightUnit: "cm" });
  assert(Math.abs(c - a) < 1e-9);
  // maxWaist rounds down
  assert.strictEqual(maxWaist(69, 0.5), 34.5);
  assert.strictEqual(maxWaist(69.9, 0.5), 34.5);
  assert.strictEqual(maxWaist(70, 0.5), 35);
  // Bad input
  assert.throws(() => whtr({ waist: 0, height: 70 }), RangeError);
  assert.throws(() => whtr({ waist: 34, height: 70, waistUnit: "ft" }), TypeError);
  console.log("all tests passed", a.toFixed(4));
}

A few things worth noticing in that module.

Validation happens at the boundary. toInches rejects zero, negative numbers, NaN, and unknown units. A calculator that quietly returns Infinity or NaN teaches users to distrust the whole page. Throwing a specific error lets the UI show a specific message.

Units are explicit. Waist and height each carry their own unit, so a person can enter a waist in inches and a height in centimeters and still get the right ratio. People do this more often than you would guess, because tape measures and doctor's-office height charts don't always agree on units.

The comparison uses a small epsilon. Floating point means 35 / 70 is fine, but a value derived from a centimeter conversion might come out as 0.5000000000000001. If the rule says "at or below the limit," a person exactly on the limit must pass. The epsilon (1e-9) is far smaller than any real measurement resolution, so it only removes noise.

Rounding: decide what the user sees and what the code decides

There are two numbers in play: the exact ratio and the number you display. If you display 0.50 but the check used 0.5004, the page contradicts itself, and you will get a support email.

Two rules help:

Decide pass/fail from the unrounded ratio, with the epsilon above.
If the source document specifies how to round, implement that exactly and test it. If it doesn't, display more digits than you think you need, or say "rounded for display."

The maxWaist function shows the same idea in reverse. When a user asks "what is the largest waist I can have at my height," the answer should be rounded down to the resolution of a tape measure. Rounding to the nearest value could tell someone 34.75 inches is fine when 34.5 is the real limit.

Tests that catch real bugs

The assert block at the bottom of the file is short but covers the failures I have seen most:

Same person, different units. 34 inches at 70 inches tall must equal 86.36 cm at 177.8 cm. If this fails, your conversion constant or your order of operations is wrong.
Exactly on the line. The boundary case should pass, and a tenth of an inch over should not.
Mixed units. One input in inches and one in centimeters gives the same ratio.
Rounding direction. The maximum-waist helper must never round up.
Garbage in. Zero and unknown units throw typed errors.

If you want to go further, add a property test: for a fixed height, the ratio should never decrease as waist increases. And add a handful of cells copied by hand from the source document, so the tests don't only prove the code agrees with itself.

Presentation matters as much as math

A few UI details prevent most user mistakes:

Put the unit toggle next to each field, not in a settings menu.
Show the interpreted values back to the user ("34 in waist, 70 in height") so a typo is obvious.
Write the source and effective date of any threshold next to the result, and say clearly that the page is an independent tool, not an authority on the standard.

I put these ideas into a free tool, AFTPTCalc, which has a WHtR calculator alongside military fitness-test calculators. The code above is a simplified teaching version, not the production code.

Takeaways

Normalize units once, early, and validate hard.
Compare with a tiny tolerance and decide from unrounded values.
Round the "maximum allowed" direction deliberately.
Test the boundary, the unit conversions, and the garbage inputs.

If you have run into other edge cases in measurement calculators, I'd like to hear about them in the comments.

Disclosure: I used an AI writing assistant to help draft and edit this post. I ran the code and its tests before publishing. The 0.5 limit is an illustration only.

Building a Fitness Test Calculator: Why Lookup Tables Beat Formulas

Leene Casella — Sat, 31 Oct 2026 22:11:37 +0000

Fitness test calculators look like simple math problems, but most of them are not formulas at all. Military fitness tests, school fitness programs, and many sports assessments publish score tables: a grid of raw performances (repetitions, seconds, pounds) mapped to points, split by age band and sex. If you try to replace the grid with a curve fit, you will be wrong in a handful of cells, and "a handful of cells" is exactly where a user's promotion points or pass/fail result lives.

This post is about how I approach building one of these calculators: model the data as tables, keep the scoring function pure, and test against the source documents. The numbers in the code below are made up for illustration and are not real standards.

Start from the published table, not a formula

A typical scoring table for a repetition event looks like this: for an age band and sex, there are rows where "at least N reps earns P points." Between those rows, the score does not change. It's a step function. Real tables also have quirks:

Some point values are skipped in the middle of the scale (gaps).
Different age bands have different row counts.
Sex-specific scales may exist for some events and not others.
Timed events work in the opposite direction: lower is better.
A newer edition of a table can change only a few cells.

Interpolating between rows invents scores that the publisher never issued. A lookup keeps every answer traceable to a cell in the original document.

A small, pure scoring function

Here is a minimal version for a "more is better" event. Notice that the function takes the table as an argument, so it has no hidden state and is trivial to test.

// ILLUSTRATIVE numbers only - not real military standards.
const PUSHUP_TABLE = {
  // ageBand -> sex -> array of [minReps, points], sorted high to low
  "17-21": {
    M: [[60, 100], [50, 90], [40, 80], [30, 70], [20, 60]],
    F: [[50, 100], [40, 90], [30, 80], [20, 70], [10, 60]],
  },
};

function ageBand(age) {
  if (age < 17) throw new RangeError(`age ${age} is below the table range`);
  if (age <= 21) return "17-21";
  throw new RangeError(`no band for age ${age} in this demo`);
}

function scoreReps(table, age, sex, reps) {
  if (!Number.isInteger(reps) || reps < 0) {
    throw new TypeError("reps must be a whole number >= 0");
  }
  const rows = table[ageBand(age)]?.[sex];
  if (!rows) throw new Error(`no scale for ${sex}`);
  for (const [minReps, points] of rows) {
    if (reps >= minReps) return points;
  }
  return 0; // below the lowest published row
}

// tests
const assert = require("node:assert");
assert.equal(scoreReps(PUSHUP_TABLE, 19, "M", 60), 100);
assert.equal(scoreReps(PUSHUP_TABLE, 19, "M", 59), 90);
assert.equal(scoreReps(PUSHUP_TABLE, 19, "M", 19), 0);
assert.throws(() => scoreReps(PUSHUP_TABLE, 19, "M", 12.5), TypeError);
console.log("all demo tests passed");

A few design choices worth copying:

Rows sorted from highest to lowest threshold. The first row you meet where reps >= minReps wins.
Explicit errors for out-of-range input. A calculator that quietly returns zero for a bad age is worse than one that throws.
Whole-number validation. Repetition events have integer inputs. Timed events need their own parsing, for example converting "15:30" to seconds before comparing.
Data separate from logic. The table lives in data, not in if statements, so a new edition of the standard is a data change.

Timed events flip the comparison

For a run or a plank hold, you write the same function with the comparison reversed for runs (seconds <= maxSeconds) and the same direction for planks (seconds >= minSeconds). Do not try to share one function with a boolean flag unless the tests make the direction obvious. Two tiny functions are easier to review than one clever one.

Rounding and truncation are part of the standard

Raw measurements are not always whole numbers. A body measurement, a time recorded to a tenth of a second, or a distance may be rounded or truncated before the lookup, and the rule is usually written in the governing document. Put the rule in one function, name it after what it does (roundDownToHalfInch, for example), and write tests that show both sides of the boundary.

Make the same code run everywhere

If you generate pages statically and also calculate in the browser, use the same pure functions in both places. Then the number on the pre-rendered example and the number after the user presses a button cannot drift apart. On the site I work on, the AFTPTCalc methodology page describes this approach: every enabled score is a table lookup rather than an interpolated estimate, the original source files are archived with SHA-256 hashes, and the same pure calculation functions run during static generation and in the browser.

Test against the document, not against your own code

Tests that re-derive the answer with the same logic only prove your code agrees with itself. Better:

Transcribe a sample of cells by hand from the source document into test cases.
Test every boundary: the exact threshold, one below it, and one above it.
Test the top and bottom of every age band, where off-by-one errors in band edges show up.
Keep a record of what is not covered. A statement like "sample coverage, not every cell" is honest and helps the next person decide where to look.

A calculator that is right for the tested cells and says so is more trustworthy than one that claims to be perfect.

Handling a data import

When tables arrive as PDFs, the import step is where mistakes sneak in. A few practical habits:

Keep the original file and note its effective date.
Write an import script instead of copying by hand, so a second run gives the same output.
Fail the import loudly when a row is missing or a value is out of order.
Spot-check imported rows against the PDF visually, especially near age band boundaries.

What I would do differently next time

A useful property test to add: for any table, points should never decrease as reps increase. That one invariant catches many transcription errors where two digits were swapped.

If you have built something similar, I'd like to hear how you handle editions of a standard that change over time.

Disclosure: I used an AI writing assistant to help draft and edit this post, and ran the code sample before publishing. The table values are invented for illustration.