The mixed number on row 45 came back as a different value
Paste a whole block of fraction exercises into the batch box on the reduce page: 100 rows go in and 100 rows come out, and only a row-by-row check reveals that row 45 is wrong. I had typed one and three quarters, the string is 1 3/4, and the page echoed "row 45 1/4 = 1/4 (0.25)" — no error was raised, the whole exercise was simply replaced with a different number. The reason sits in the parsing step: batch mode runs through line 167, splitting each row into two halves at the half-width slash, then handing both ends to parseInt, a function that stops reading at a space. So 2 1/2 yields 1, 1+3/4 likewise yields 1/4, and 1.5/2 yields 1/2. The rows that really raise an error belong to another family: 3/4/5, 0.75, and １／４ written with a full-width slash — all judged 格式错误, "format error".
Telling those two families apart matters. A row that errors out is visible at a glance, while a row whose value was changed silently wears the costume of a normal result and slips past the red text of the batch — among 100 rows seeded with 5 bad ones, only 4 were judged wrong (three 格式错误 plus one 分母为0), and the fifth is the mixed number whose value got swapped.
The minus sign has one home, and the denominator side never keeps it
The template behind the reduce-fraction page flips the sign once at line 81: the minus only ever moves onto the numerator, and when the move is done the denominator stays positive. So -3/4 and 3/-4 both print -3/4, and -3/-4 prints 3/4. Batch mode adds one more move: line 178 reassembles each result in the form "original → simplest", so the spaces and the minus from the input are copied back verbatim before the landing spot appears — a row typed 3 / -4 echoes as 3/-4 → -3/4.
Negative zero is nothing to worry about either. Feed in -0/5 and 0/-5: across the four outputs — simplest form, equivalent decimal, percentage, reduction factor — the values are 0, 0, 0.00%, 1/5 in order, and no path on the page keeps a literal negative zero, because String writes negative zero as 0.
A denominator of zero never reaches the gcd step
The page stops division by zero upstream: single mode decides it at line 123 and prints 分母不能为 0, "the denominator cannot be 0", at line 125, while batch mode prints 分母为0 at line 173. One code path and one wording cover the spellings 0/0, 5/0, 5/-0 and 5/0.0, whereas the two denominator-zero branches sitting at line 80 and line 86 are actually unreachable from the interface. There is a more roundabout hit: 0b11/0b100 is judged a zero denominator too, because parseInt does not recognize the binary prefix and reads both ends as 0.
Batch rows match one to one, row numbers do not
100 rows in become 100 results; the 598 characters typed into the textarea lose nothing, failed rows are inserted back in place as red text, and the whole batch never breaks — the three early returns inside the loop at lines 166-183 only skip the current row. Measuring the output fragment gives 22167 characters and 22727 bytes. Yet the validCount declared at line 165 is read 0 times: the page shows no row count and no success total, so you have to count yourself.
The row numbers are renumbered as well: out of 8 physical lines, 4 are blank and only 4 render, so the exercise 24/36 on physical line 8 is labeled "row 4". For line endings, CRLF is caught by the trim at line 156 and 3 rows come out fine; but when a bare carriage return glues 3/6 and 4/8 together, the whole string counts as 1 row and reports a 格式错误.
| Spelling | What this page does with it | What the batch echoes |
|---|---|---|
1 3/4 | cut at the space, value changed in silence | row 45 1/4 = 1/4 (0.25) |
3/4/5 | split into three parts, judged invalid | 格式错误 |
5/-0 | blocked upstream, never reaches the gcd | 分母为0 |
9007199254740993/6 | folded into a double first, then reduced | 4503599627370496/3 |
The two single-mode boxes are number inputs
Paste +3, 1/1, 0x10 or even ½ into the numerator box and the browser sanitizes the box before parseInt ever runs: it is wiped to an empty string, the isNaN test at line 121 returns at once, both cards stay hidden and the error bar is an empty string — not even one line of complaint. Typing character by character is worse: 3/4 gets swallowed into 34 and 0x10 into 010, the calculation still runs, and the result box marches on to 5/2.
Equivalent decimals have no repetend, only a 14-character cutoff
The test at line 89 converts the division result to a string and checks whether its length exceeds 14; when it does, the page prints toFixed(10) and appends three dots. So 1/3 displays as 0.3333333333..., 1/6 displays as 0.1666666667... (the last digit rounded up), and 1/999 displays as 0.0010010010.... In reverse, 1/8192, which divides evenly, is still cut down to 10 places because its result runs 15 characters, while 1/4096 sits at exactly 14 and stays intact. To keep computing across fractions, entries like the fraction calculator give exact results over a common denominator; if you only want the decimal places trimmed to a chosen length, the decimal format page is the direct route.
Big numbers turn into floats at the parseInt step
BigInt appears 0 times in the template; the parseInt calls at lines 113/114 and line 167 fold long digit strings into doubles, and past the safe-integer limit the tail of the mantissa is simply gone. Measured on 9007199254740993/6: the page returns 4503599627370496/3, while the exact integer value is 3002399751580331/2, off by -0.166666…; 999999999999999999/3 is stranger still — the page declares it already simplest and echoes 1000000000000000000/3, while the truth is 333333333333333333, off by +0.333333…. Two more spellings drift: in 1e21/3 the parseInt stops reading at the first character e, turning the whole exercise into 1/3; and two neighboring large integers 9007199254740993/9007199254740992 fold into the same number and print the bare integer 1.
Figure 1: the same exercise on both sides of parseInt — whichever step rewrites the mantissa is the row where the gap shows up.
Push the digits higher and even the format falls apart: 12345678901234567891/2 yields 6172839450617284000, off from the exact value by -361.5; a fraction whose numerator has 200 digits is first folded into 1.2345678901234567e+199, the simplest-form column then prints 6.172839450617284e+198/3 outright, and the percentage column gives 2.0576131502057615e+200% — in that column the fraction has stopped being a fraction at all.
Frequently asked questions
Q: In the batch output, how do I spot the row whose value was changed silently?
Look at the echoed input. Line 178 prints the input verbatim before appending the result, so a row like 1 3/4 comes out as "1/4 = 1/4" — the side before the equals sign no longer holds the number you typed. The page offers no summary, so row-by-row comparison is the only way.
Q: Can mixed numbers be written at all?
This page knows only the two-part form: one part for the numerator, one for the denominator, and the output built at lines 75-78 has just two shapes, integers and fractions — 7/1 displays as 7. To enter one and three quarters, convert it to 7/4 yourself before pasting.
Q: What should I do with numerators or denominators longer than 16 digits?
Do not count on this page; it switches to floating point during parsing, and measurements show even its verdict of "already simplest" can be wrong. Either split the numbers into smaller pieces first, or work in an integer environment that supports arbitrary precision.