Math.f16round converts a Number directly to the nearest representable binary16 value using roundTiesToEven. It does not first perform Math.fround. Most ordinary values hide that distinction, but values near a binary16 midpoint can be rounded once to binary32 and then a second time to binary16, producing a different answer from direct binary64-to-binary16 rounding. The result must also be interpreted with binary16 overflow, subnormal, signed-zero, infinity and NaN limits in view.
This specialist guide belongs to the Websites root. It also connects to The Gold Standard of Education | Learning That Transfers into Life and the How X Works hub. The worked cases are original teaching examples; their values and event logs are stated so each conclusion can be checked.
eduKateSG · Websites
Find your next learning step
Use the routes to build the binary16 model, trace direct ties-to-even rounding, reproduce a double-rounding counterexample, transfer values through Float16Array and DataView, and test special and boundary outcomes.
ROUTE 1 · CHAPTERS 1–3
Build the first model
Name the input, state, conversion or predicate before following user-visible results.
ROUTE 2 · CHAPTERS 4–5
Trace the decisive branch
Work the accepted path and the nearest boundary case with original examples.
ROUTE 3 · CHAPTERS 6–8
Change one premise
Rebuild the mechanism when state, value, realm, timing or object kind changes.
ROUTE 4 · CHAPTERS 9–10
Handle limits and failures
Keep abrupt completion, availability and application limits visible.
ROUTE 5 · CHAPTERS 11–12
Verify and explain
Use a decisive fixture, changed-context check and concise final account.
Chapter contents
Build the first model · Chapters 1–3
1. Build the binary16 value model
Trace the decisive branch · Chapters 4–5
Change one premise · Chapters 6–8
Handle limits and failures · Chapters 9–10
Verify and explain · Chapters 11–12
The short answer is that binary16 has one sign bit, five exponent bits and ten stored fraction bits, so its spacing depends on magnitude. Chapter 1 focuses on build the binary16 value model. Begin with the input Number’s exact binary64 value, neighbouring binary16 values, midpoint and tie parity, direct binary16 result, optional binary32 intermediate, second-round result, normal or subnormal range, signed zero, overflow, NaN and storage path. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Around one, identify 1 and 1.0009765625 as adjacent binary16 values. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for build the binary16 value model is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Move the fixture to the interval around two and recalculate the wider spacing. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: A Number returned by Math.f16round is still an ECMAScript Number; it merely has a value exactly representable in binary16. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. State the two neighbours and their gap before discussing the rounded result. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of build the binary16 value model should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that Math.f16round applies roundTiesToEven to the input’s binary64 value at binary16 precision. Chapter 2 focuses on round directly from the number input. Begin with the input Number’s exact binary64 value, neighbouring binary16 values, midpoint and tie parity, direct binary16 result, optional binary32 intermediate, second-round result, normal or subnormal range, signed zero, overflow, NaN and storage path. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Round 1.0006 and select the nearer upper binary16 neighbour. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for round directly from the number input is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Change the input to 1.0004 and select the lower neighbour. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Decimal display can hide the exact binary value that decides a very close case. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Use hexadecimal bits or a sufficiently precise decimal fixture when testing a boundary. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of round directly from the number input should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 3 OF 12 · Build the first model
3. Use the even significand at an exact tie
The short answer is that at an exact midpoint between adjacent binary16 values, roundTiesToEven selects the neighbour whose least significant retained significand bit is even. Chapter 3 focuses on use the even significand at an exact tie. Begin with the input Number’s exact binary64 value, neighbouring binary16 values, midpoint and tie parity, direct binary16 result, optional binary32 intermediate, second-round result, normal or subnormal range, signed zero, overflow, NaN and storage path. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Take the exact midpoint 1.00048828125 between 1 and 1.0009765625 and select 1. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for use the even significand at an exact tie is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Move to a midpoint whose lower neighbour has an odd retained bit and identify the upper even neighbour. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Ties-to-even is not the same as always rounding halves upward. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Label neighbour parity in the worked table. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of use the even significand at an exact tie should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 4 OF 12 · Trace the decisive branch
4. Expose a double-rounding counterexample
The short answer is that rounding binary64 to binary32 can land exactly on a binary16 midpoint and erase which side the original value occupied. Chapter 4 focuses on expose a double-rounding counterexample. Begin with the input Number’s exact binary64 value, neighbouring binary16 values, midpoint and tie parity, direct binary16 result, optional binary32 intermediate, second-round result, normal or subnormal range, signed zero, overflow, NaN and storage path. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Use k = 1.00048828125000022204; direct Math.f16round(k) yields 1.0009765625. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for expose a double-rounding counterexample is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Compute Math.f16round(Math.fround(k)) and obtain 1 because the binary32 intermediate becomes the midpoint. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: The difference is narrow but decisive evidence that Math.fround is not an implementation of direct f16 rounding. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Assert both paths from the same stored Number and keep the intermediate value. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of expose a double-rounding counterexample should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 5 OF 12 · Trace the decisive branch
5. Do not infer the difference from every decimal
The short answer is that many inputs round identically by both paths because the binary32 intermediate stays on the same side of the relevant binary16 boundary. Chapter 5 focuses on do not infer the difference from every decimal. Begin with the input Number’s exact binary64 value, neighbouring binary16 values, midpoint and tie parity, direct binary16 result, optional binary32 intermediate, second-round result, normal or subnormal range, signed zero, overflow, NaN and storage path. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Test 1.1 and compare the direct and two-step results. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for do not infer the difference from every decimal is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Move the input progressively toward the documented midpoint fixture. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Agreement on common inputs cannot prove the algorithms are equivalent. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Include at least one separating fixture and several ordinary controls. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of do not infer the difference from every decimal should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that rounding a sufficiently small negative magnitude can produce negative zero, whose sign remains observable with Object.is. Chapter 6 focuses on preserve signed zero. Begin with the input Number’s exact binary64 value, neighbouring binary16 values, midpoint and tie parity, direct binary16 result, optional binary32 intermediate, second-round result, normal or subnormal range, signed zero, overflow, NaN and storage path. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Round a negative value smaller in magnitude than half the least positive binary16 subnormal. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for preserve signed zero is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Change only the sign and obtain positive zero. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Printing either result as 0 hides the sign and can mislead later reciprocal or branch behaviour. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Use Object.is(result,-0) and record the original sign. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of preserve signed zero should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that binary16 subnormals represent evenly spaced tiny magnitudes below the minimum normal value, with the least positive subnormal equal to 2^-24. Chapter 7 focuses on trace the subnormal range. Begin with the input Number’s exact binary64 value, neighbouring binary16 values, midpoint and tie parity, direct binary16 result, optional binary32 intermediate, second-round result, normal or subnormal range, signed zero, overflow, NaN and storage path. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Round a value near three times 2^-24 and identify the nearest subnormal multiple. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for trace the subnormal range is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Move the value across the midpoint between two adjacent subnormals. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Subnormal support does not mean every small Number remains non-zero. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Express the fixture as powers of two so the boundary can be checked exactly. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of trace the subnormal range should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that finite Number inputs beyond the binary16 finite range can round to positive or negative infinity. Chapter 8 focuses on recognise overflow to infinity. Begin with the input Number’s exact binary64 value, neighbouring binary16 values, midpoint and tie parity, direct binary16 result, optional binary32 intermediate, second-round result, normal or subnormal range, signed zero, overflow, NaN and storage path. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Round a sufficiently large positive Number and observe positive infinity. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for recognise overflow to infinity is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Use a large negative Number and preserve the infinity sign. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Overflow is a representational range result, not proof that the original Number was infinite. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Check Number.isFinite on the input and the exact final infinity on the result. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of recognise overflow to infinity should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 9 OF 12 · Handle limits and failures
9. Pass through infinity and NaN classes
The short answer is that positive zero, negative zero and infinities are preserved by class, while NaN produces NaN. Chapter 9 focuses on pass through infinity and nan classes. Begin with the input Number’s exact binary64 value, neighbouring binary16 values, midpoint and tie parity, direct binary16 result, optional binary32 intermediate, second-round result, normal or subnormal range, signed zero, overflow, NaN and storage path. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Apply f16round to Infinity, -Infinity, NaN, 0 and -0. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for pass through infinity and nan classes is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Replace NaN with a finite overflow case and distinguish their causes. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: NaN payload details are not a portable application-level identity guarantee. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Use Number.isNaN, Object.is and equality checks suited to each result class. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of pass through infinity and nan classes should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 10 OF 12 · Handle limits and failures
10. Compare with Float16Array storage
The short answer is that storing a Number in Float16Array performs binary16 conversion and reading returns a Number with that stored binary16 value. Chapter 10 focuses on compare with float16array storage. Begin with the input Number’s exact binary64 value, neighbouring binary16 values, midpoint and tie parity, direct binary16 result, optional binary32 intermediate, second-round result, normal or subnormal range, signed zero, overflow, NaN and storage path. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Store k in a one-element Float16Array and compare the readback with Math.f16round(k). Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for compare with float16array storage is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Store Math.fround(k) instead and expose the two-step path. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Array storage also introduces buffer identity, indexing and view-state concerns beyond the rounding function. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Verify the stored element and retain the original input separately. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of compare with float16array storage should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that DataView float16 access adds an explicit endianness choice around the same numeric representation. Chapter 11 focuses on control byte order with dataview. Begin with the input Number’s exact binary64 value, neighbouring binary16 values, midpoint and tie parity, direct binary16 result, optional binary32 intermediate, second-round result, normal or subnormal range, signed zero, overflow, NaN and storage path. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Write a known binary16 value with little-endian true and inspect its two bytes. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for control byte order with dataview is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Read the same bytes with the opposite endianness and obtain a different value. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Endianness changes byte interpretation, not the definition of roundTiesToEven. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Assert bytes and numeric readback in both orders. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of control byte order with dataview should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that a complete account names the original Number, target precision, neighbours, midpoint relation, tie rule and any intermediate precision. Chapter 12 focuses on explain one rounding path at a time. Begin with the input Number’s exact binary64 value, neighbouring binary16 values, midpoint and tie parity, direct binary16 result, optional binary32 intermediate, second-round result, normal or subnormal range, signed zero, overflow, NaN and storage path. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Report k’s direct upper result and its binary32-mediated lower result. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for explain one rounding path at a time is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Change k to the exact midpoint and show why the direct result is the even lower neighbour. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Do not attribute a double-rounding difference to random floating-point noise. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. End with the exact fixture, both expressions, observed values and the range limits that apply. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of explain one rounding path at a time should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
Contents · Previous chapter · Return to the Websites subject guide
Frequently asked questions
Does Math.f16round return a Float16 value type?
No. It returns a Number whose value is representable in binary16.
Is Math.f16round the same as Math.f16round(Math.fround(x))?
No. A binary32 intermediate can cause double rounding.
What tie rule is used?
Round to nearest, ties to even.
Can a finite input become infinity?
Yes, when it overflows the binary16 range.
Can a tiny negative input become negative zero?
Yes.
Should tests use rounded decimal literals near boundaries?
Use exact powers of two, bit patterns or sufficiently precise fixtures so the intended side of the boundary is clear.
Continue through the verified reading routes
Start with the wider system
The Gold Standard of Websites · The Gold Standard of Education | Learning That Transfers into Life · How X Works hub
Compare the closest mechanisms
Math.sumPrecise special-value outcomes · DataView bounds after buffer shrinkage and regrowth · Summation order, Kahan compensation and lost digits · parseInt prefix parsing and complete conversion
Choose the next lesson by reader job
Use the subject root to move from this focused mechanism to the next verified question. Follow a specialist link when its preconditions match your code; return to the wider hub when the next task belongs to a different system.
Authoritative sources and evidence checks
ECMAScript 2027: Math.f16round · ECMAScript 2027: Float16Array · ECMAScript 2027: DataView float16 operations · IEEE 754-2019 overview
The ECMAScript specification defines the language algorithms. A cited proposal draft is used where it contains the integrated Stage 4 text. Controlled runtime checks can confirm an implementation’s current behaviour, but feature availability and performance still depend on the runtime version and environment.