Sock loss index calculator

Use it free in the browser for a quick drawer audit, or call the API at $0.002 per successful request when you need the same reproducible index in a household log, a dorm inventory, or a teaching demo.

What the sock loss index means and what the response contains

The sock loss index is the share of the original sock inventory that disappeared, expressed as a percentage, then divided by the months of ownership so households can compare a six-month laundry stretch with a two-year drawer. Ten pairs and fourteen remaining socks after a year is six lost of twenty, thirty percent gone, two point five percent per month. Count every pair you purchased as two socks, subtract the individual socks still in the house, and you have socks_lost. Divide socks_lost by socks_bought to get the lost fraction; multiply by one hundred for a total loss percent; divide that percent by months_owned to obtain socks_loss_index, the monthly percentage. The response echoes the three inputs, reports socks_bought as twice the pair count, socks_lost, the unit lost_fraction between zero and one, loss_percent_total, the primary socks_loss_index, a formula string, a method tag, and the rounding precision. There is no hidden dryer model, no seasonal weather factor, and no assumed washer brand: the engine either evaluates the closed form or rejects the input with invalid_input. Rejected cases include a missing pairs_bought, socks_remaining, or months_owned field, non-finite values, magnitudes above the documented ceiling, a negative pair count or remaining count, remaining socks that exceed twice the pairs bought, a non-positive ownership horizon, and — the case this page is explicit about — pairs_bought equal to zero, because dividing by an empty original inventory is undefined.

How pairs, remaining socks, and months are read and how the rate stays reproducible

Optional leading plus signs and scientific notation on numeric strings are allowed when they parse as finite decimals; embedded spaces, hex prefixes, and non-numeric tokens are rejected with a clear message so a bad cell does not become a wrong monthly rate. Remaining socks cannot be negative and cannot exceed twice the pairs bought. The preferred fields are pairs_bought for how many pairs entered the household, socks_remaining for how many individual socks are still on hand, and months_owned for the ownership horizon in months. Aliases pairs, bought, n_pairs, and pair_count for the pair count; remaining, remaining_socks, socks, and socks_left for the leftover singles; and months, month, owned_months, and ownership_months for the horizon are accepted so spreadsheets, query strings, and typed forms can reuse the same contract. Zero for remaining socks is valid and simply means the entire inventory is gone, so the total loss percent is one hundred and the index is one hundred divided by months_owned. pairs_bought must be strictly positive: if it is zero or at or below a tiny epsilon, the request fails with invalid_input because the original sock count would be zero and the fraction is undefined. months_owned must also be strictly positive, because the monthly index divides by that horizon. An optional precision field, with aliases decimals and dp, chooses how many decimal places to expose, defaulting to ten and capped at fifteen so JSON goldens stay stable. Pair the free browser run on this page with the priced API when you need the identical mathematical result inside an automated pipeline without re-implementing the inventory arithmetic yourself.

Where sock-loss thinking fits in households, laundry rooms, and software

Households can log pairs_bought, count the singles left, and see whether the monthly loss is a trickle or a leak worth changing how laundry is folded and stored. Developers call the same contract from scripts to seed deterministic test vectors for wardrobe widgets, to normalize user-entered pair counts before a household-budget demo, or to satisfy product statements that demand a socks_loss_index field rather than a joke about missing mates. On this page the work runs entirely in your browser; through the API each successful lookup costs $0.002, failed validation is not charged, and nothing is stored after the response returns. That split — free interactive exploration and a priced, identical API — lets you move from a personal drawer check to an automated pipeline without changing the mathematical result.