Clear one box and the visible cards drop to 0
The input here is a grid of numerator and denominator columns, one row per fraction, preset to 1/2, 1/3, 1/4 on three rows. Get it to compute, then clear any single box completely: how many output cards are still visible? Four clearing patterns give the same answer, 0 — no result card, no error card, and the error message is an empty string.
The calculation function sets both the result card and the error card to display:none on entry, then reads each row with parseInt. If any box parses to NaN it returns at once, and those two display flags are never touched again. Failure here is not a message branch: it is a return to the starting state where both cards are hidden.
| Input state | Cards visible | Error message |
|---|---|---|
| 3-row page, numerator of row 1 cleared | 0 cards | 0 code units |
| 3-row page, both boxes of row 3 cleared | 0 cards | 0 code units |
| Denominator of row 2 set to 0 | 1 error card | 20 code units / 48 bytes |
| Only 1 row left, both boxes empty | 1 error card | 15 code units / 39 bytes |
The zero denominator is the only case that talks. Its message is fixed wording with the row number filled in, telling the user that the denominator of fraction N is 0 and asking for a fix, and it runs 20 code units / 48 bytes while N is a single digit; N counts from 1, so rows 1, 2, 3 and 5 report 1, 2, 3 and 5. When NaN and 0 are both present, whether anything is said depends on row order: an empty box in row 1 makes the function return at the first row, and the 0 in row 2 is never mentioned.
Figure 1: visible card counts by path — one empty box and two empty rows both end at 0 cards.
The silent run leaves the old result and the old message in place
Follow the steps. The Common Denominator Calculator page writes to only 8 ids. Two rows, 1/2 and 1/3, compute successfully and the result area reads "1/2 = 3/6" and "1/3 = 2/6". Setting the denominator of row 2 to 0 replaces that with 1 error card. Clearing the numerator of row 1 then drops the card count to 0 while the DOM stays as it was: the 20-code-unit message is still there, the common denominator box still shows 6, the result area still shows those 2 rows, the copy text is still 26 code units, and the working area still carries 6 rows of old working. The copy button sits inside the result card, so once that card hides, the stale text cannot be clicked either.
parseInt with no radix: 7 silent exits, 22 truncations
Both boxes are read as parseInt(value), without the second radix argument. Of 29 test strings, 7 return NaN and take the silent path — the empty string, three spaces, ".5", "abc", "Infinity", "NaN", "½" — and all remaining 22 truncate without a sound.
| "1.5" | "3.9999" | "-1.9" | "1e3" | "0x10" | "08" | "12abc" | "1,5" |
|---|---|---|---|---|---|---|---|
| 1 | 3 | -1 | 1 | 16 | 8 | 12 | 1 |
A denominator of "1.5" gives a common denominator of 3 and result rows that read "1/1 = 3/3" and "1/3 = 1/3": the page works out 1/1 and never writes the 1.5 back into the box. "1e3" also travels as 1/1, so a 1000 is used as 1. Whether a browser keeps "0x10" or "12abc" inside a type=number box was not measured in this batch; what is certain is that an empty box value always makes parseInt return NaN.
Negative denominators: three fates of the sign
The common denominator side takes the absolute value, the multiplier side keeps the sign. Pairing 1/2 with 1/-3 gives common denominator 6, a result row "1/-3 = -2/6", and working rows "denominator list: 2, 3" plus "LCM(2, 3) = 6" — the sign has already vanished by the denominator list, while the multiplier row writes it out: multiply numerator and denominator by -2, giving -2/6. Three rows of 1/-2, 1/-3 and 1/-4 give common denominator 12 and results -6/12, -4/12, -3/12. Zero times a negative multiplier is negative zero, which stringifies to 0, so the line reads "0/-2 = 0/4"; with -2/-3 the two signs cancel and the output is "-2/-3 = 10/15".
Chained LCM, and 990 rows that are not reduced
With several denominators the common one is a chain folded from 1 by reduce, and the fold count always equals the number of denominators: 2, 3, 4 passes through 2, 6, 12; 12, 18, 30 passes through 12, 36, 180, and the intermediate 36 is not a factor of the result; 3, 5, 7, 11 gives 1155; 2, 3, 5, 7, 11, 13 gives 30030.
No reduction step exists in the code, and there is no second greatest-common-divisor call in the whole file. Put 1/2 and 2/4 in the same grid and the common denominator is 4, the output reads "1/2 = 2/4" and "2/4 = 2/4", and the second line is an identity row whose original denominator already equals the common one. Widen the sample to 576 two-row grids and 1152 result rows: 990 rows leave the new numerator and the common denominator sharing a factor, 537 grids have at least one unreduced row, 453 have both rows unreduced, and 180 contain an identity row. Of the 289 grids where both original fractions are already reduced, 250 still come out unreduced. This counts output text, not guidance for whoever reads it.
"Fraction 4" and "Fraction 2" name the same row
A row label is the word for fraction plus a counter that only goes up; deleting a row never reclaims its number. The first screen shows 3 rows labelled "Fraction 1, Fraction 2, Fraction 3". Delete row 2 and add one back and the labels read "Fraction 1, Fraction 3, Fraction 4": still 3 rows, but the highest number is already 4. The working area uses array indexes, so that third row is called "Fraction 2" there. Add and delete through 20 rounds and the row count stays 3 while the labels reach "Fraction 21, Fraction 22, Fraction 23" and the counter sits at 23. Only Reset puts the counter back to 0, and only then do the labels run from 1 to 3 again.
Deleting a row searches the DOM for cd-row- plus the original number, skips when nothing matches and raises no error: clicking delete again on a row that is already gone changes the row count by 0, and number 99 does nothing either — yet the final recalculation sits outside the if, so a delete that removed nothing still recomputes once. Adding a row does the opposite and computes nothing: in one measured case the page held 4 rows labelled "Fraction 1, Fraction 4, Fraction 5, Fraction 6" and still displayed that 15-code-unit message, while the result card kept the previous round's 2 rows "1/2 = 2/4" and "1/4 = 1/4" with common denominator 4.
The copy text has one more segment than there are rows
Copying takes the textContent of a hidden span whose first line is the label for the common denominator, followed by one line per fraction, so the segment count is always the row count plus 1: 2 rows give 3 segments and 26 code units, 3 rows give 4 segments and 40 code units, 4 rows give 5 segments and 55 code units, 8 rows give 9 segments and 137 code units, and 10 rows give 11 segments and 193 code units. Assembly appends one newline per row, and one trim runs before the write: 41 code units / 47 bytes becomes 40 code units / 46 bytes, the split drops from 5 segments to 4, a difference of exactly 1 code unit / 1 byte. The string starts with the character for common, has no leading whitespace and ends in a digit. With 12 rows whose denominators run up to 12 the common denominator is 27720, and the first line reads "1/1 = 27720/27720".
Frequently asked questions
Q: Why does the page show nothing after I clear one box?
Both cards are hidden at the top of the function, a NaN parse returns straight away, and nothing later brings either card back, so the visible count is 0; only a denominator of 0 produces that 20-code-unit message.
Q: The result is not a reduced fraction, is the calculation wrong?
This page performs only the multiplication step of finding a common denominator and outputs same-denominator forms; across the 576 sample grids, 990 rows still share a factor. What comes after the common denominator, the additions and subtractions and whether to reduce before or after, is covered in the fraction addition and subtraction article.
Q: Do very large denominators cause trouble?
The largest size measured on this page is the 27720 that appears with 12 rows whose denominators run up to 12; bigger inputs are outside what this page measured. The floating-point behaviour of the least common multiple on very large numbers was measured in the multiply-before-divide intermediate value article.