Methodology note
Fixed-precision arithmetic and rounding
Limit checks compare numbers at their edges, where rounding decides the answer. Binary floating point cannot store most decimal fractions exactly, so sums drift by tiny amounts. Fixed-precision decimals avoid that drift, and comparing the full value stops a 5.001% holding passing a 5% cap because it displays as 5.00%.
cash_range · Custom formula limitscustom_formula · Eligibility tests (investment grade, listing, domicile)eligibility_test · Issuer concentration limit (single issuer, single instrument)concentrationWhy floating point is not enough
Spreadsheets and most programming languages use binary floating point. It cannot represent 0.1 exactly, so adding 0.1 and 0.2 gives 0.30000000000000004.
Across thousands of positions such errors rarely matter. At a limit's edge, they decide whether a result is compliant or a breach.
What the registry does
The rule engine's arithmetic runs on fixed-precision decimals. Custom formulas are evaluated that way, and a division by zero is not evaluated, never infinity or zero.
Eligibility tests parse both sides of a numeric comparison as decimals. A value that does not parse is a coverage gap, never a pass.
Rounding is for display
Compare the unrounded value with the limit, and round only when showing it. In the example, 50.01 of a 1,000 book is 5.001%: at two decimals it displays as 5.00%, and it still breaches a 5% cap.
State the display precision in reports, so a reader does not mistake 5.00% for a pass.
Pitfall: rounding written into the policy
A policy may state that limits apply to figures rounded to one decimal place. That is a real methodology, and it moves the boundary: 5.04% would pass a 5.0% cap.
If a policy says so, record it as an author decision on the rule, or express it as a tolerance. Do not round silently in the data feed.
Worked example
Cash of 50.01 in a 1,000 book is 5.001%: it displays as 5.00% at two decimals and still breaches a 5% cap.
Rule template:cash_range cashClassNames: Cash
Bounds: hard max 5%
| Holding | Class | Market value |
|---|---|---|
| Cash at bank | Cash | 50.01 |
| Listed equities | Stocks | 949.99 |
| Group | Status | Value | Bounds | Headroom to the hard bound | Code |
|---|---|---|---|---|---|
| Cash | Breach | 5% | ≤ 5% | -0% | ABOVE_HARD_MAXIMUM |
ABOVE_HARD_MAXIMUM: The measured value exceeds the approved hard maximum, beyond any stated tolerance.
Largest contributors: Cash → Cash at bank 5%
Computed at build time by the Acclimetry rule engine (backend commit 8197063); the same code runs in the product.
Questions
Can floating point really change a result?
Only at a limit's edge, where a tiny error falls on the wrong side of the bound. The risk is highest for limits that sit close to their bounds.
How many decimal places should results show?
Enough to make the comparison visible, often two or three for percentages. Whatever the display, keep the full value on record.