What the parser reads, and in what order
Addition, subtraction, multiplication, division and parentheses. The symbols × and ÷ are accepted, and a lowercase or uppercase x sitting between two numbers is read as multiplication. Dollar signs and thousands separators are stripped before parsing, so $1,250 * 3 works.
Precedence runs tightest first: parentheses, then a trailing %, then a leading + or - sign, then multiplication and division left to right, then addition and subtraction left to right. That is ordinary school order, so 1200*3+500 is 4,100 and not 1200 × 503. Two values written next to each other with no operator between them are added, at the addition level: a line reading 120 85 32 comes out as 237. That is convenient for copying figures off a receipt, and it is also the one rule that can hide a mistake, because a line where you meant to type a multiplication sign and missed will quietly add instead. If a result looks wrong, that is the first thing to check.
How percent behaves
The % sign does two different jobs depending on where it sits, matching the percent key on a desk calculator.
| Written | Read as | Result |
|---|---|---|
15% on its own | fifteen hundredths | 0.15 |
980 * 15% | 15 percent of 980 | 147 |
980 - 15% | 980 less 15 percent of itself | 833 |
980 + 15% | 980 plus 15 percent of itself | 1,127 |
Inside a multiplication or division the percent is just a division by a hundred. After a plus or minus it becomes relative to whatever is on the left. If that distinction is going to bother you six months from now when you reread the line, write 980 * 0.85 instead and the intent is unambiguous.
Labels and comments
Start a line with Lumber = 4.87 * 26 or Delivery: 45 + 12.50 and the label carries through to the results table and the copy box. A label is only recognised when the text before the equals sign or colon contains something that is not a digit or an operator, so (45+55)/2 is still read as arithmetic. Anything after # or // is a comment and is dropped before parsing; a line that is nothing but a comment does not appear in the results at all. Keeping a quote in this form means the working is still there the next time somebody asks how you arrived at the number.
Lines that fail, and why there is no eval here
A line with a unit in it (26 ft, $18 each) fails and is marked in red with the reason. Everything else on the page keeps working, and the count of failed lines sits above the table so a silent shortfall in the total is hard to miss. Division by zero, unbalanced parentheses and stray operators each get their own message.
The expressions are read by a tokenizer and a recursive-descent parser written out above — JavaScript's eval and new Function are not used anywhere in this page. That is why the feature list is short: only digits, the five operators and parentheses are recognised as anything at all, and every other character is an error rather than something that gets executed. Exponents, functions and conditionals are deliberately absent; if you need them, the job belongs in a spreadsheet.
Questions people ask
Will amounts copied out of a spreadsheet with commas in them work?
Yes. A comma followed by exactly three digits is treated as a thousands separator and removed, so 1,250 reads as 1250. A comma in any other position is treated as a separator between values, which means 10,20,30 is read as three numbers and added to 60. A line that mixes both conventions, like 10,200,30, is genuinely ambiguous and will not give what you expect. If a line has commas doing two jobs, strip them and separate the values with spaces.
Does a failed line make the total wrong?
A failed line contributes nothing to the total, the average, the largest or the smallest — it is left out entirely. So the total is correct for the lines that ran, but it is smaller than you intended if you did not notice the failure. That is why the failure count appears in the headline and the failed lines are marked in red. Before trusting the total, check that the "lines that computed" figure matches the number of lines you actually wrote.
Can I use exponents or functions like round and sqrt?
No. The parser recognises the four operators, parentheses, decimals, negatives and percent, and nothing else. Squaring is written out as 12*12. Rounding is handled by the decimal-places setting rather than by a function. The narrow feature set is the point: because no arbitrary code is executed, the only thing your text can do is produce a number or an error message.
Why does the average sometimes not match the total divided by the number of lines?
Because the average is taken over the lines that went into the total, not over every line you typed. Failed lines are excluded, and if you turn off "count lines that come out to zero" then zero results are excluded as well. Both counts are shown in the summary — "lines that computed" and "lines in the total" — so you can see which denominator the average used.