When two bus routes arrive together again, and the formula is one line
Two routes, one every 6 minutes and one every 8 minutes, leave at the same time; how long until they arrive together again? It is the least common multiple problem, and the answer is 24. Common denominators, gear teeth and cycle alignment all use the same expression, LCM(a, b) = |a × b| ÷ GCD(a, b). With 8, 12, 20 as input the working line reads |24 × 20| ÷ 4 = 480 ÷ 4 = 120: multiply the two numbers out in full first, then divide.
That line is Math.abs(result * numbers[i]) / g at line 146 of the source, multiply then divide. Whether LCM Calculator gives the right number depends on that intermediate value, not on the result: the true LCM might still be representable while a × b has already overflowed.
The limit is not 9007199254740991, it is about 94.9 million
The maximum safe integer, 9007199254740991 (2^53-1), looks like an input ceiling, but what it actually governs is the intermediate value. All 500500 pairs with 1 ≤ a ≤ b ≤ 1000 fail in 0 cases; widening a to 2000 and raising b until the product overflows gives 148001000 pairs, still 0 failures. So the condition applies to the product, and translated back to inputs it means neither number exceeds about 94.9 million: 94906265² = 9007199136250225 is still inside the limit, 94906266² = 9007199326062756 is already past it.
Crossing the limit is not the same as a wrong answer. In this range the spacing of doubles is 2, only even numbers are exact, and the 1 that GCD eats cancels out. I enumerated all 5151 pairs in [94906266, 94906366] (the lower bound is proven) and found 1275 inaccurate pairs, 24.75%; the first failing pair is the same number typed twice, 94906267, 94906267. The window holds 101 equal-value pairs, with 0 even failures and 50 odd ones.
| n typed twice | True n² | Double a × b | Product error | LCM shown on the page |
|---|---|---|---|---|
| 94906266 | 9007199326062756 | 9007199326062756 | 0 | 94906266 |
| 94906267 | 9007199515875289 | 9007199515875288 | -1 | 94906266.99999999 |
| 94906269 | 9007199895500361 | 9007199895500360 | -1 | 94906268.99999999 |
The mechanism is in the last column: the square of an odd number is odd, it gets rounded to the neighbouring even number (error 1), and dividing by the odd g = n leaves 1 undivided, so the quotient becomes an LCM with a decimal. The first pair that comes out as an integer but off by 1 is 94906267, 94906269, with g = 1 and a deviation of 1.
Move the division ahead of the multiplication and 271 more pairs survive
Same 5151 pairs, same g, only the division moved ahead as (a / g) * b: both forms are exact for 3876 pairs, only divide-first is exact for 271, both are inexact for 1004, and only multiply-first is exact for 0. Those 1004 are not an ordering problem: the true LCM itself is above 2^53-1, and divide-first only relaxes the condition to the result not overflowing.
Figure 1 | Exhaustive 5151 pairs classified by exactness for the two forms; 1275 inaccurate pairs = 1004 + 271, and the last cell is 0.
Remainder steps: neighbouring Fibonacci numbers take 40
That g comes from the iterative Euclidean loop at lines 97-100, while (b !== 0), measured by the number of remainders: gcd2(18, 12) takes 2, gcd2(12, 18) has to swap first and takes 3, so order affects the count. The slowest case is neighbouring Fibonacci numbers, where every quotient is 1 and the remainder shrinks by one layer each time; 102334155 with 165580141 needs 40 steps. That pair is coprime, so the LCM is the product, and the code returns 16944503814015856 against a true value of 16944503814015855.
Figure 2 | Measured remainder counts, bars scaled by count; the last row is a pair of neighbouring Fibonacci numbers, the worst case for the Euclidean algorithm.
One card, two faces: change the order and the number changes
The big number goes through toLocaleString() at line 152 while the working line uses string concatenation, so the same value has two faces: with 1073741824, 95367431640625 the headline expands to 102,400,000,000,000,000,000,000 while the working line writes 1.024e+23. This one is exact, because 2^30 and 5^20 are coprime; when finding common denominators you can look at the common denominator directly (Common Denominator Calculator). Multiple numbers are folded strictly left to right at lines 142-149, with no deduplication and no sorting, so order matters on floats: the six permutations of 94906267, 94906267, 3 give 284718801 and 6369051764850687, the former being correct, and the first permutation in input order happens to be the wrong one.
Silent rewriting at the input, square roots in the factoring
Line 70 is parseInt(p, 10); invalid input is not reported, only truncated or dropped: 4.9 becomes 4, 12abc leaves 12, and negatives and 0 are filtered out by n > 0 at line 71. The separator only recognises the comma and whitespace at line 67, so 1,000, 2,000 is cut into 1 and 2, the LCM shows 2, and nothing warns you. When fewer than 2 values parse, line 138 returns early and the result area disappears entirely. The count has a ceiling too: 124746 runs to completion, 124747 makes Math.max.apply at line 179 throw a RangeError.
Factoring is trial division, with the condition d * d <= num at line 114, and the cost grows with the square root: 999983 needs 998 divisions, 1000000007 needs 31621, the 15-digit 999999999999989 needs 31622775, and the template has 0 limits and 0 timeouts. Two measured paths really do pin the tab: 100000000001, 99999999989 writes its 22-digit result and then hangs at line 173 factoring it; a 309-digit number is read as Infinity, enters an infinite loop, and wall=8013ms passes with no further DOM write.
Q: Why does the LCM of two large numbers come out with a decimal?
The intermediate value is wrong, not the result. Once the product passes 9007199254740991 it is rounded to the neighbouring even number, an error of 1, and then divided by g; when g is odd, 1 does not divide evenly and the interface shows 94906266.99999999. Keep both numbers under 94.9 million and the problem does not arise.
Q: What happens with decimals, negatives or thousands separators?
None of them raise an error: decimals are truncated, negatives and 0 are dropped, 1,000 is read as two numbers, and if fewer than 2 positive integers remain the result area does not appear at all. To check the common factor, run it through GCD Calculator first.
Q: Why does prime factorisation spin forever?
Trial division only runs to the square root and has no upper bound, and on top of factoring every input the page also factors the LCM result itself, which dominates the cost. Two primes with a dozen digits each are enough to keep the tab spinning, and it starts halfway through typing, because the calculation runs on every keystroke.