Number Rendering¶

{{ n }} renders a number the same way JavaScript's Number.prototype.toString() would: the shortest decimal string that round-trips to the same IEEE-754 double, choosing fixed or exponential notation the same way a browser console does. This applies to every numeric interpolation, including math-transform results.

{{ 1.0 }}     {{! 1 — no trailing .0 }}
{{ 100.0 }}   {{! 100 }}
{{ 1e20 }}    {{! 100000000000000000000 }}
{{ 1e21 }}    {{! 1e+21 — switches to exponential notation }}
{{ 0.1 | plus: 0.2 }}    {{! 0.30000000000000004 — ordinary floating-point rounding, rendered exactly }}

Int and float are not distinguishable in output¶

{{ 2 }} and {{ 2.0 }} both render "2" — kBars does not echo the source literal's int/float distinction in rendered output. The distinction survives only in comparison (==, <, …), which already coerces both operands to a floating-point number before comparing, so equality and truthiness treat 2 and 2.0 identically as well:

{{#if 2 == 2.0}}equal{{/if}}    {{! equal }}

Why this matters for consumers¶

If you're rendering numbers into a context where formatting matters — currency, fixed decimal places, locale-specific separators — pipe the value through a formatting transform (see Math Transforms's round, or Date/Time Transforms for date formatting) rather than relying on the raw numeric rendering, which always produces the shortest round-trip decimal form and nothing else.

This rendering rule is normative for the whole kBars language, not just an implementation detail — see Number Rendering in the Porting section for the exact ECMA-262 specification this implements and why every port must match it byte-for-byte.