Calculator

Hand a math teacher the expression 2 + 3 × 4 and the answer is 14: multiplication binds tighter than addition under the standard order of operations (PEMDAS in the US, BODMAS in the UK and much of Asia). Hand it to a typical desk calculator — or to this one — and you will get 20. Neither device is broken; they implement different execution models. Simple four-function calculators use immediate execution: every time you press an operator, the pending operation is resolved first. Keying 2 + 3 × 4 therefore computes 2 + 3 = 5 the instant you press ×, then 5 × 4 = 20. Scientific calculators use algebraic (formula) logic instead: they hold the whole expression and apply precedence rules, returning 14. Casio and Sharp desk calculators for accounting are deliberately immediate-execution because bookkeepers chain operations left to right; TI and Casio scientific models are algebraic because students need textbook behavior. This split is behind the periodic internet fights over expressions like 6 ÷ 2(1 + 2). Strict left-to-right evaluation with explicit multiplication gives 9, but many people — and some older calculators — treat implied multiplication next to parentheses as binding tighter, giving 1. The expression is genuinely ambiguous as written; professional style guides tell you to add parentheses rather than rely on precedence. Practical rule for this tool: it chains left to right, so enter one operation at a time in the order you want it performed. For 2 + (3 × 4), key 3 × 4 first, then add 2.

Same keystrokes, two machines:

  2 + 3 x 4 =

  Immediate execution (desk calculators, this tool):
    press x  ->  2 + 3 = 5
    press =  ->  5 x 4 = 20

  Algebraic logic (scientific calculators):
    whole expression parsed -> 2 + (3 x 4) = 14

To get 14 here: key  3 x 4 =  (12), then  + 2 =  (14).

Type 0.1 + 0.2 into almost any programming language and the answer is 0.30000000000000004. This is not a bug in JavaScript or in this calculator — it is a property of IEEE 754 double-precision floating point, the number format used by virtually every CPU made since the 1980s. Computers store numbers in binary, and 0.1 has no exact binary representation, for the same reason 1/3 has no exact decimal one. In base 10, one tenth is a clean 0.1; in base 2 it is 0.0001100110011... repeating forever. A 64-bit double keeps 52 fractional bits, so the repetition is cut off and 0.1 is actually stored as 0.1000000000000000055511151231257827... Add two such approximations and the tiny errors can surface in the visible digits. The consequences show up in real money handling. Summing 0.1 ten times gives 0.9999999999999999, not 1 — a naive equality check fails. Financial software therefore never stores currency as floating-point dollars: it works in integer cents (or uses decimal libraries), so 10 cents is exactly 10 with no rounding at all. Some languages expose this directly: banker's rounding (round-half-to-even), the IEEE default, rounds 2.5 to 2 rather than 3 to avoid systematic upward bias across millions of transactions. For everyday use of this calculator, the practical advice is simple: expect the 16th decimal place to be noise, round displayed results to the precision you need, and when checking money by hand, count in the smallest unit — cents, 원, 円, 分 — rather than in decimal fractions.

0.1 + 0.2            = 0.30000000000000004   (not 0.3)
0.1 x 10 (by adding) = 0.9999999999999999    (not 1)
0.3 - 0.1            = 0.19999999999999998   (not 0.2)

Why: 0.1 in binary = 0.000110011001100... (repeats forever)
     a 64-bit float keeps only 52 fraction bits

Money-safe approach: work in the smallest unit
  $1.10 + $2.20  ->  110 + 220 = 330 cents  ->  $3.30 exactly

The percent key is the least standardized button in calculator history. On many desk calculators, 200 + 10 % yields 220, because the machine interprets it as "add 10 percent of 200". On others, and in this tool, % simply divides the current entry by 100, so 10 % becomes 0.1 and what you do with it is up to you. Knowing which convention a calculator follows prevents real billing mistakes. Three worked patterns cover most daily needs. Discount: a 25% off jacket listed at 79,000 (in any currency) is 79000 × 0.75 = 59,250 — multiplying by what remains (0.75) is one keystroke shorter than computing the discount and subtracting. Tip: 15% on a 48.60 restaurant bill is 48.60 × 0.15 = 7.29, total 55.89. Tax-inclusive prices are the one that trips people up: Korea and Japan quote 10% VAT/consumption tax, and extracting the pre-tax amount from a tax-inclusive 22,000 requires dividing by 1.1 (= 20,000), not multiplying by 0.9 (= 19,800, wrong by 200). The error happens because 10% of the smaller pre-tax base is less than 10% of the gross. Percentage-point confusion deserves a mention too: an interest rate rising from 2% to 3% has increased by one percentage point but by 50 percent. News headlines mix these constantly. When you need chained or reverse percentage work — what percent X is of Y, percentage change between two values — the dedicated percentage tool linked below handles those forms directly.

VAT trap (10% tax-inclusive price of 22,000):

  Correct:   22000 / 1.1  = 20000  pre-tax
             20000 x 0.1  =  2000  tax      (20000 + 2000 = 22000 ok)

  Wrong:     22000 x 0.9  = 19800  "pre-tax"
             19800 x 1.1  = 21780  (does not rebuild 22000!)

Discount vs tip on this calculator (% divides by 100):
  25% off 79000:   79000 x 0.75 = 59250
  15% tip on 48.6: 48.6  x 0.15 = 7.29

Division by zero is undefined in ordinary arithmetic — there is no number that, multiplied by 0, gives 8 — and calculators have handled the impossibility differently across the decades. Classic desk calculators lock up with an E or Error indicator that must be cleared; raw JavaScript evaluates 8 / 0 to the special value Infinity and 0 / 0 to NaN (not-a-number); spreadsheet software shows #DIV/0!. This calculator takes a fourth path and returns 0, a deliberate design choice that keeps the display and the history panel usable instead of wedging the machine. The mathematical truth is unchanged: treat any division-by-zero result as "check your input", not as an answer. The history panel on the right stores your last ten completed operations in plain text, which is more useful than it looks: it serves as a paper-tape substitute for reconciling a column of figures, and because each entry shows both operands, you can spot a mistyped digit after the fact instead of re-running everything. All of it lives only in your browser's memory and disappears on reload — nothing is transmitted anywhere. Keyboard support makes repeated work markedly faster than clicking: digits and the decimal point enter numbers, the four operator keys chain operations, Enter or = evaluates, Backspace deletes the last digit, and Escape clears everything. One habit worth adopting from professional ten-key operators: enter long sums in a steady rhythm without watching the display, then verify the total once at the end against the history — it is faster and catches more errors than checking every intermediate result.