Math Evaluator

How to use this math evaluator

1. Type an expression using numbers, operators, and functions.
2. The result updates instantly as you type.
3. Use parentheses to control the order of operations.

Supported functions

sqrt, abs, sin, cos, tan, log (base 10), ln (natural log), and the operators +, -, *, /, ^ (power), and parentheses.

How a parser actually enforces order of operations

Correctly evaluating an expression like 2 + 3 * 4 requires more than reading it left to right — it requires understanding operator precedence, the same PEMDAS/BODMAS rules taught in school, where multiplication and division are evaluated before addition and subtraction regardless of the order they're written in. A hand-written expression parser implements this formally through a technique often called recursive descent parsing, which processes an expression in distinct precedence layers — first handling the lowest-precedence operators (addition and subtraction) by breaking the expression into terms, then recursively handling each term's higher-precedence operators (multiplication and division) within it, and so on down through exponentiation and parentheses. This layered structure is exactly what makes 2 + 3 * 4 correctly evaluate to 14 rather than 20 — the multiplication is resolved as a complete sub-expression before the addition around it is ever applied.

Why this tool deliberately avoids JavaScript's eval()

JavaScript's built-in eval() function can technically evaluate a math expression string in a single line of code, which makes it tempting for a simple calculator — but it comes with a serious, well-documented security cost that a dedicated math parser avoids entirely. eval() doesn't just evaluate arithmetic — it executes absolutely any JavaScript code contained in the string passed to it, meaning a malicious input crafted to look partly like a math expression could actually run arbitrary code with the same privileges as the rest of the page. A hand-written parser designed specifically to only recognize numbers, defined math operators, and a fixed, known set of function names has no mechanism for executing arbitrary code at all, regardless of what text it's given — it either recognizes valid math syntax and computes a numeric result, or it rejects the input as invalid, with no other possible outcome.

Why 0.1 + 0.2 doesn't equal exactly 0.3 in any calculator like this one

A famous, genuinely common surprise in any tool doing floating-point math (not just this one) is that 0.1 + 0.2 computes to 0.30000000000000004 rather than exactly 0.3. This isn't a bug — it's an unavoidable consequence of how computers represent decimal fractions in binary floating-point format (IEEE 754, the standard nearly every programming language uses for decimal numbers). Just as 1/3 can't be written exactly as a finite decimal in base 10, many ordinary decimal fractions like 0.1 can't be represented exactly in binary, so they're stored as the closest possible approximation instead, and tiny rounding differences from that approximation surface when such numbers are added together. This affects every general-purpose programming language and calculator that uses standard floating-point arithmetic, not something specific to any one particular tool or implementation.

Why exponentiation is right-associative, unlike most other operators

Beyond precedence (which operator binds tighter), associativity determines how a chain of the same operator resolves, and exponentiation is a genuine, notable exception to how most other operators behave. Addition, subtraction, multiplication, and division are all left-associative, meaning 10 - 3 - 2 evaluates left to right as (10 - 3) - 2 = 5. Exponentiation, however, is right-associative by mathematical convention, meaning 2^3^2 evaluates right to left as 2^(3^2) = 2^9 = 512, not (2^3)^2 = 64. This distinction matters genuinely for correctly implementing a math parser — treating exponentiation with the same left-to-right associativity as the other operators produces a different, mathematically incorrect result for any expression chaining more than one power operator together.

Limitations of this tool

This tool evaluates standard arithmetic expressions with the functions and operators listed above (sqrt, abs, sin, cos, tan, log, ln, and the basic arithmetic operators) — it doesn't support variables, custom function definitions, complex numbers, or units of measurement, and as noted in the FAQ, trigonometric functions expect radians rather than degrees, following standard mathematical and programming convention. Results are subject to the standard floating-point precision limitations described above, which affects any general-purpose calculator using this same underlying number representation, not something unique to this specific tool.