The sum says 2, the list has 1 row, and the screen gives no hint
The trap starts with a single string. Type scientific notation 1e3 into the term-count box meaning 1000 terms, and the page returns a sum of 2 with a detail list of 1 row; in the test every validity flag came back false while the screen stayed silent. 10.9 is more confusing still: the page computes 10 terms, the sum is still 155 and the list still has 10 rows, because this box truncates toward zero rather than rounding. .5 yields NaN and drops straight into the empty state, and -10.9 truncates to -10 for the same empty state. The first term and the common difference both run through parseFloat and are never rounded at all, so the claim that decimals are supported holds only for those two boxes, and the term count is not one of them.
One n feeds three places and produces three different rules
What has to be laid out is this: that single n feeds the sum, the detail list and the copy output, each one covering a different range, and not one of the three ever tells you what the other two cover.
| Rule | Coverage | Measured at n=501 | Measured at n=10000 (a1=1, d=3) |
|---|---|---|---|
| Sum S_n | Closed form covers n terms | counted as 501 terms | 149,995,000, covering 10000 terms |
| Detail list | hard cut at the first 500 terms, plus one notice row | 501 DOM rows | 501 rows |
| Copy output | always exactly the first 500 terms | 500 numbers | 500 numbers, 2,629 bytes |
Fig. 1: two groups drawn to the same scale, showing how many terms each of the three places covers. On the left the gap is a single notice row; on the right all 9500 missing terms sit off screen.
Why the detail list always stops at 501 rows
Line 145 on the forward path and line 194 on the reverse path carry the very same statement, Math.min(n, 500). At n=500 the page prints 500 rows with no hint at all. At n=501 it prints 501 DOM rows, because after the 500 data terms there is one extra notice line, "... 501 terms in total, only the first 500 are shown ...". At n=10000 and at n=999999 it still stops at 501 rows, and only the total inside that notice changes. So the row count never equals the term count: it is one more than the copy entries (that notice row), and n-500 short of the terms actually generated. The wording "generates the list of the first n terms" is exactly where this falls apart.
That cut is not a rendering bottleneck either. A full redraw costs 0.7 ms at n=10, 9.8 ms at n=500, still 12.5 ms at n=10000, and 16.1 ms at n=100000000 on the reverse path; three consecutive triggers at n=10000 together take 33.8 ms. The cost is pinned by those 500 rows, so a larger term count adds nothing. The template contains setTimeout, debounce and requestAnimationFrame 0 times each, meaning there is no throttling anywhere.
The toast fires but never clears the screen
The forward path carries one guard, n>10000, written on lines 131-134, and hitting it returns immediately. It raises only a toast, "Too many terms, keep it under 10000", and does not clear the result already on screen. Tests at n=10001, 15000, 999999 and 100000000 all produced nothing but that toast, while the screen still showed the 150,005,000 and the 501 rows from the previous run at n=10000. The next step is worse: clicking Copy sequence at that moment still hands you the stale 500 terms and 2,629 bytes, so the clipboard and the toast flatly contradict each other.
The reverse solve has no upper bound branch at all
Move the same n to the reverse solve and the guard simply does not exist. The very same 1e3 becomes 1 through parseInt here, collides with the n<2 check on line 181, and lands in the empty state; yet n=999999 and n=100000000 both return results, S=15,499,984.5 and S=1,550,000,000, and the detail list again holds only 501 rows. The forward path blocks oversized counts (although blocking leaves the stale screen untouched) and the reverse path never checks, so the two sides are not symmetric about large term counts. The truncation also happens at the letter e: 1e7 is treated as 1 term and 10e1 as 10 terms, while parseFloat reads the same string as 1000, 10000000 or 100. The input semantics of the term-count box are simply not the ones used by the other two boxes.
The gap between the three sides is an account that balances
Take a1=1, d=3, n=10000. The page reports S_n=149,995,000 covering 10000 terms, while the 500 terms visible on screen sum to only 624,750, so 9,500 terms are missing and the coverage is 0.25%. The copied string is 2,629 bytes holding 500 numbers with 0 line breaks, and its last value is 1,498. Anyone in the habit of adding up the visible numbers to check S_n will never get a match, but the cause is not precision: the sum comes from the closed form on line 139, n*(a1+an)/2, while lines 146-148 generate each term independently with no accumulation, so the page never adds the detail list and the two figures were never sourced from the same computation.
Floating point takes exactly one line in this story: the closed form and a term-by-term accumulation diverge in 3 of 15 samples, the earliest at the 4th decimal place (a1=5, d=0.1234, n=17) and the latest at the 15th, while fmt() sets maximumFractionDigits: 10 on line 115 and displays all of them as one and the same number.
The box that really breaks is the overflow one
Line 139 adds before it divides, which puts the overflow boundary at MAX_VALUE/2 = 8.988465674311579e307. With d=0 and n=1, a1=9e307 already shows the sum as infinity, even though S1 equals a1 exactly in mathematics and the last-term box still holds a finite string. Setting a1=1e308, d=1e308 and n=10 goes further: the first detail row is a 411-character thousands-separated string (309 digits plus 102 commas), and rows 2 through 10, together with the last term, the sum and the average, are all infinity, while the page neither reports an error nor hides the result.
Use the three rules apart from each other
- Type a plain integer in the term-count box only: the arithmetic sequence calculator cuts that box at the letter e, so 1e3 and 1e7 both become 1 term, 10.9 silently truncates to 10, and .5 as well as -10.9 drop into the empty state.
- Ask for more than 500 detail rows by running the page in segments: from n=501 onward only the first 500 terms are copyable, and the extra row 501 is a notice rather than data.
- When the notice reads "Too many terms, keep it under 10000", treat the result area as blank before clicking copy, because the 150,005,000 and the 501 rows on screen are leftovers from the previous round.
- Do not add up the visible numbers to check the sum: S_n covers n terms, while the visible area only reaches the scale of 624,750.
- The statistics strip on the forward path carries 4 entries (first term, last term, term count, average, with no sum) and the reverse path also 4 (a common difference but no average), so the 5 entries the page copy advertises do not survive measurement.
- Of the 12 assertions in that copy, 6 match, 4 conflict and 2 only partially match, so fold "list of the first n terms" through min(n,500) before quoting it; the geometric sequence page runs its own rules, covered in that measured write-up.
Frequently asked questions
Q: why does 1e3 in the term-count box count only 1 term?
This box uses parseInt (line 123) and stops reading the moment it reaches the letter e, so 1e3 leaves only 1 behind. The first term and the common difference use parseFloat and read that same string as 1000. If you want 1000 terms, type 1000 directly.
Q: is the extra detail row the data of term 501?
No. Line 145 and line 194 both cut the rendered range to the first 500 terms, so the row that follows n=501 is only a notice stating that the first 500 terms are shown. Both n=10000 and n=999999 stop at 501 rows, and the number of copy entries stays 500.
Q: after the "too many terms" notice, can the sum on screen still be quoted?
Not as a result of this run. The guard on lines 131-134 returns directly, raising a toast without clearing the screen, so what remains visible is the 150,005,000 and the 501 rows from the previous n=10000 run, and clicking copy then still delivers the stale 500 terms and 2,629 bytes.