Math.sumPrecise performs an accurate sum over an iterable of Numbers, but its edge outcomes are governed by an explicit state machine. An empty iterable or a sequence containing only negative zeros returns negative zero. Either infinity can dominate finite values, opposite infinities produce NaN, any NaN produces NaN, and a non-Number item throws instead of being coerced.
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 trace iterable consumption, the special-value state, exact finite accumulation, negative zero, infinities, TypeError and iterator closing without treating every unusual result as rounding error.
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. Begin with an iterable of Numbers
Trace the decisive branch · Chapters 4–5
4. Keep negative zero when every item is negative zero
5. Let a finite non-negative-zero value choose the finite path
Change one premise · Chapters 6–8
Handle limits and failures · Chapters 9–10
Verify and explain · Chapters 11–12
The short answer is that Math.sumPrecise obtains a synchronous iterator and requires every yielded item to be a Number rather than coercing it. Chapter 1 focuses on begin with an iterable of numbers. Begin with the iterable and iterator, current item, item count, special-value state, exact mathematical sum, Number-only requirement, iterator closing, final conversion and Object.is checks for signed zero. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Sum [1,2,3] and record three Number items and result six. 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 begin with an iterable of numbers 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 the middle item with the string ‘2’ and stop at TypeError. 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: Numeric-looking strings, BigInts and boxed Number objects are not accepted as primitive Numbers. 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 a generator that logs each yield and its finally block. 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 begin with an iterable of numbers 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 the algorithm begins in a minus-zero state and moves among finite, plus-infinity, minus-infinity and not-a-number states. Chapter 2 focuses on trace the special-value state. Begin with the iterable and iterator, current item, item count, special-value state, exact mathematical sum, Number-only requirement, iterator closing, final conversion and Object.is checks for signed zero. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Feed [2,-5,4] and move from minus-zero to finite on the first non-negative-zero finite value. 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 special-value state 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. Start with -0 values before the two and show why the first finite non-negative-zero item changes the state. 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 state records result class separately from the exact mathematical finite sum. 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. Write one state row per consumed item. 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 special-value state 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 an empty iterator leaves the initial minus-zero state unchanged, so the result is negative zero. Chapter 3 focuses on return negative zero for empty input. Begin with the iterable and iterator, current item, item count, special-value state, exact mathematical sum, Number-only requirement, iterator closing, final conversion and Object.is checks for signed zero. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Call Math.sumPrecise([]) and check Object.is(result,-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 return negative zero for empty 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. Compare ordinary [].reduce with and without an explicit initial 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: Printing the result as 0 can hide its sign. 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 1/result is negative infinity only as a secondary observation, with Object.is as the direct check. 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 return negative zero for empty 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 4 OF 12 · Trace the decisive branch
4. Keep negative zero when every item is negative zero
The short answer is that items equal to negative zero do not move the state out of minus-zero or add to the finite sum. Chapter 4 focuses on keep negative zero when every item is negative zero. Begin with the iterable and iterator, current item, item count, special-value state, exact mathematical sum, Number-only requirement, iterator closing, final conversion and Object.is checks for signed zero. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Sum [-0,-0,-0] and preserve negative zero. 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 keep negative zero when every item is negative 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. Insert positive zero and show that positive zero is not negative zero, so the state becomes finite and the result is 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: A visually identical zero sequence can produce a different signed result. 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 on every input and on the final output. 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 keep negative zero when every item is negative 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.
CHAPTER 5 OF 12 · Trace the decisive branch
5. Let a finite non-negative-zero value choose the finite path
The short answer is that any finite Number other than negative zero changes minus-zero to finite and contributes its mathematical real value. Chapter 5 focuses on let a finite non-negative-zero value choose the finite path. Begin with the iterable and iterator, current item, item count, special-value state, exact mathematical sum, Number-only requirement, iterator closing, final conversion and Object.is checks for signed zero. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Sum [-0,5,-5] and obtain positive zero after exact cancellation. 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 let a finite non-negative-zero value choose the finite path 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 five to the smallest positive subnormal value and preserve the finite-state reasoning. 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: Exact cancellation after entering finite does not restore the initial minus-zero state. 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. Record state and exact sum separately so the final signed zero is predictable. 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 let a finite non-negative-zero value choose the finite path 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 encountering NaN changes any non-NaN state to not-a-number and later items cannot restore a numeric result. Chapter 6 focuses on propagate nan through the state. Begin with the iterable and iterator, current item, item count, special-value state, exact mathematical sum, Number-only requirement, iterator closing, final conversion and Object.is checks for signed zero. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Sum [1,NaN,2] and return NaN after consuming the iterable. 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 propagate nan through the state 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 NaN to the first or last position and compare the same final class with different consumption logs. 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 here is an input-class result, not evidence that finite summation lost precision. 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.isNaN and retain iterator event order. 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 propagate nan through the state 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 one or more positive infinities with no negative infinity produce positive infinity, and the symmetric rule holds for negative infinity. Chapter 7 focuses on keep one infinity sign. Begin with the iterable and iterator, current item, item count, special-value state, exact mathematical sum, Number-only requirement, iterator closing, final conversion and Object.is checks for signed zero. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Sum [10,Infinity,-3,Infinity] and return 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 keep one infinity sign 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 both infinities with negative infinity. 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: Finite values do not cancel an infinity in this state machine. 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 the exact sign of infinity and the number of consumed items. 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 keep one infinity sign 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 once both positive and negative infinity have appeared, the state becomes not-a-number. Chapter 8 focuses on turn opposite infinities into nan. Begin with the iterable and iterator, current item, item count, special-value state, exact mathematical sum, Number-only requirement, iterator closing, final conversion and Object.is checks for signed zero. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Sum [Infinity,5,-Infinity] and return NaN. 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 turn opposite infinities into nan 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. Reverse the infinity order and trace the symmetric transition. 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: This NaN is not the result of subtracting finite floating-point approximations. 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. Show the state transition at the second opposite infinity. 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 turn opposite infinities into nan 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. Accumulate finite values before one final rounding
The short answer is that finite items contribute their real-number values to a mathematical sum that is converted to a Number at the end. Chapter 9 focuses on accumulate finite values before one final rounding. Begin with the iterable and iterator, current item, item count, special-value state, exact mathematical sum, Number-only requirement, iterator closing, final conversion and Object.is checks for signed zero. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Use [1e16,1,1,-1e16] and compare the accurate result two with an ordinary left-to-right loop. 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 accumulate finite values before one final rounding 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. Reorder the values and verify the same mathematical sum under sumPrecise. 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: Accurate summation cannot recover information already rounded before values entered the iterable. 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. Compare source Numbers, exact intended values and final result in separate columns. 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 accumulate finite values before one final rounding 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. Close the iterator on a non-Number item
The short answer is that when an item is not a Number, the algorithm creates TypeError and performs IteratorClose. Chapter 10 focuses on close the iterator on a non-number item. Begin with the iterable and iterator, current item, item count, special-value state, exact mathematical sum, Number-only requirement, iterator closing, final conversion and Object.is checks for signed zero. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Yield one, then ‘2’, and use finally to record generator closing. 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 close the iterator on a non-number item 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. Make the iterator’s return method throw and inspect which abrupt completion is observed under the iterator-closing rules. 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: An early TypeError does not justify assuming the producer’s cleanup was skipped. 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 yield, close and catch events in order. 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 close the iterator on a non-number item 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 11 OF 12 · Verify and explain
11. Keep count limits and practical limits distinct
The short answer is that the specification includes a count ceiling at 2^53-1 items, while real programs meet time and memory limits far earlier. Chapter 11 focuses on keep count limits and practical limits distinct. Begin with the iterable and iterator, current item, item count, special-value state, exact mathematical sum, Number-only requirement, iterator closing, final conversion and Object.is checks for signed zero. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Explain the RangeError branch without pretending to construct an infeasible test sequence. 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 keep count limits and practical limits distinct 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 small custom iterable to validate ordinary count increments and closing on another failure. 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: An unreachable-in-practice boundary is still different from environment performance. 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 the count-ceiling claim as specification reasoning rather than executed evidence. 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 keep count limits and practical limits distinct 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 12 OF 12 · Verify and explain
12. Explain result class before numerical accuracy
The short answer is that a complete account first identifies Number-only input and special-value state, then discusses accurate finite accumulation. Chapter 12 focuses on explain result class before numerical accuracy. Begin with the iterable and iterator, current item, item count, special-value state, exact mathematical sum, Number-only requirement, iterator closing, final conversion and Object.is checks for signed zero. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Report [-0,+0] as finite positive zero and [Infinity,-Infinity] as NaN. 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 result class before numerical accuracy 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 one item in each sequence and rebuild the state table. 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 call every NaN or signed-zero result a floating-point error. 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 input sequence, state transitions, final check and one scope limit. 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 result class before numerical accuracy 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
What does an empty iterable return?
Negative zero.
Are numeric strings converted?
No. A non-Number item causes TypeError.
What if both infinities appear?
The result is NaN.
Does any NaN make the result NaN?
Yes.
Can an accurate sum recover rounded input data?
No. It works with the Number values it receives.
Why use Object.is for zero?
It distinguishes positive zero from negative zero directly.
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
Iterator.reduce omission versus explicit undefined · Summation order, Kahan compensation and lost digits · parseInt prefix parsing versus 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.
Continue through the new companion lessons
Separating ArrayBuffer slice Species Construction from Source Revalidation · Separating Atomics.pause Hints from Waiting on a Shared Condition · Separating Error.isError Brand Checks from instanceof Across Realms
Authoritative sources and evidence checks
ECMAScript 2027: Math.sumPrecise · ECMAScript 2027: iterator operations · ECMAScript 2027: Number type · Shewchuk: Adaptive Precision Floating-Point Arithmetic
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.