TOOL NOTES

How many decimals should a computed price carry

A fair price computed from two-digit inputs deserves two or three decimals, not six. Why false precision misleads, and the display rule that fixes it.

A margin-removal function will happily return 1.90909090 forever. The inputs it ran on, two prices read off a board, carried maybe three significant digits. Printing more digits than the inputs earned is not accuracy; it is decoration, and on a computed fair price it actively misleads.

The inputs set the ceiling

Pinnacle prices arrive as decimal odds with two places: 1.91, 2.50, 4.75. Every figure you compute from them, implied probabilities, fair prices, expected values, inherits their precision and adds none. A fair price of 1.613 from inputs of two places is honest; 1.61290 claims a certainty the inputs never contained.

The converter on this site displays decimal odds to four places and probabilities to two, as its page states, checked 2026-10-08, and that is display formatting for exact conversions, not a claim about the precision of a computed estimate. Converting 2.50 to +150 is exact; removing a margin is not.

What false precision costs

Two fair prices that differ in the fourth decimal invite a comparison that means nothing, because the method choice between proportional and power removal moves the second decimal, and the market's own margin estimate moves more. Readers learn to distrust the digits, or worse, to trust them.

False precision also hides model differences. Two fair prices of 1.6129 and 1.6087 look different and are, for practical purposes, the same number. The display should not pretend otherwise.

The display rule that works

Keep full precision in storage and in any arithmetic, and round only at the display. Two decimals for prices in the usual betting range, since boards quote two, and a probability to one decimal of a percent. That matches the converter's display conventions of four places for exact decimal display and two for probabilities, while acknowledging that computed fair values carry less certainty than exact conversions.

The odds converter warns that rounding a displayed price and converting it back can change the last digits, which is the reason for the storage rule: never compute from a rounded display value. The no-vig calculator shows the same posture from the other side: its percentages are rounded to two places and may not sum to exactly 100%, and it says so instead of faking the sum.

The one place precision matters

The exception is regression testing. When you check that a pipeline still computes what it computed last week, compare unrounded values with an explicit tolerance, because display rounding hides real drift. Precision is a debugging tool, not a user interface.

Store long, show short, test exact. A computed price should carry as many decimals as its inputs earned, and no more.