Cricket Overs Are Not Decimals: A Data Modelling Guide

Cricket over notation is not ordinary decimal notation. In a six-ball-over format, 12.4 means twelve completed overs and four valid balls, not twelve and four-tenths overs. Treating it as a decimal creates incorrect rates, progress bars and comparisons.

The robust approach is to store the count of valid deliveries as an integer and derive the display notation from it. Keep actual delivery events separately because not every delivered ball advances the valid-ball count.

Convert through balls

For a six-ball over, the valid-ball count at 12.4 is 12 × 6 + 4 = 76. Converting back uses integer division and remainder: 76 divided by 6 gives twelve completed overs with four balls remaining in the partial over.

Do not calculate the next displayed ball by adding 0.1 to a floating-point number. After 12.5, the next completed valid delivery is 13.0, not 12.6.

See the effect on a rate

In a hypothetical innings, 100 runs have been scored after 76 valid balls. The rate per six-ball over is 100 × 6 ÷ 76, approximately 7.89.

Dividing 100 by the decimal number 12.4 instead gives about 8.06. The difference comes entirely from the representation error, not from any ambiguity in the score.

At zero valid balls, avoid dividing by zero. Display an unavailable rate or another explicitly defined presentation until the denominator is meaningful.

Keep deliveries and valid balls distinct

A delivery record can describe a wide or no-ball. Such events can change the score without advancing the valid-ball count in the usual six-ball-over model. Use the provider's documented validity field rather than guessing from the displayed label.

Also avoid assuming that every competition uses the same format. Store the applicable format and balls-per-over rule where your product supports variations.

Test boundary cases

Include the opening ball, the end of an over, an extra delivery, an innings reset and a corrected delivery. Verify that each innings has its own count and that a correction rebuilds dependent rates.

Preserve the source's original over label for investigation, but calculate only from fields whose meaning has been confirmed. A mismatch between the source label and your derived label should trigger review.

Validate the boundary values

For a six-legal-ball over format, valid completed-ball components are zero through five before the display advances to the next whole over. An input labelled 12.6 should trigger review of the source convention rather than automatic interpretation as a valid normalized over value.

Build test cases for 0.0, 0.5, 1.0 and an innings-ending partial over. Include separate events that do not add a legal ball where the feed distinguishes them. The delivery record and the legal-ball count serve different purposes.

For an integer count of 77 legal balls, integer division by six gives twelve completed overs and a remainder of five, producing 12.5 in the chosen notation. For 78 legal balls, the result is 13.0. These conversions should remain true after a round trip through storage and display.

Keep notation out of generic numeric formatting

A locale formatter might change punctuation or trim a trailing zero. Either can make domain notation ambiguous if the rest of the interface expects a specific format.

Store the structured count or separate components and format the over label deliberately. If a source supplies only a string, parse it according to the documented convention and preserve the raw value for investigation. Avoid treating every dotted string as a decimal number.

A useful acceptance exercise asks one developer to supply the boundary fixtures and another to explain the displayed values without seeing the implementation. Misunderstandings often appear sooner in that conversation than in a happy-path screenshot of a familiar scorecard.

Apply the model to the integration

When evaluating a cricket Score API, ask how deliveries, legal-ball counts and innings are represented. Use the API documentation request route to resolve any ambiguity before rendering live statistics.

This is a small modelling choice with broad consequences. Integer counts make the arithmetic explicit; display notation remains a presentation concern rather than an unreliable calculation input.