Numbers and Precision

Numbers, Precision and Silent Loss

The grammar sets no limit on a number's size or precision; parsers do. Most store IEEE 754 doubles, whose 53-bit significand cannot hold every integer above 2^53, so RFC 8259 promises agreement only within [-(253)+1, (253)-1]. BIGINT keys and snowflake-style IDs routinely exceed that:

Three parsers read the order ID 2^53 + 1

DOC='{"order_id": 9007199254740993}'
echo "$DOC" | node -p 'JSON.parse(require("fs").readFileSync(0, "utf8")).order_id'
echo "$DOC" | python3 -c 'import json, sys; print(json.load(sys.stdin)["order_id"])'
echo "$DOC" | jq -r '"\(.order_id) after +0: \(.order_id + 0)"'

Output

9007199254740992
9007199254740993
9007199254740993 after +0: 9007199254740992

Node.js 24 2,131 rounds silently; Python parses an exact int; jq 1.8.1 133,477 keeps the literal until it does arithmetic. Fractions fare worse: 16.20 has no exact binary form, so Python's 16.20 * 3 prints 48.599999999999994. Parse money with parse_float=Decimal or into a DECIMAL column, and in APIs send amounts as strings or integer cents and 64-bit IDs as strings. BookNest's sample generator computes every total with Decimal.

MENU