Step Solver

Why a calculator on a blog about AI

Because the contrast is the argument. Everything in the box above is an algorithm. The expression evaluator runs Dijkstra's shunting-yard method, published in 1961, to convert your input into reverse Polish notation, then walks the resulting stack. The quadratic solver applies a formula that appears in Babylonian tablets in geometric form and reached its modern shape through Brahmagupta in the seventh century. The factoriser does trial division, which is as old as anyone can trace. The greatest common divisor uses Euclid's algorithm from around 300 BCE, still the method of choice after twenty-three centuries.

None of these guess. Given a valid input each produces the correct answer, and given an invalid input each says so rather than producing something plausible. That second property is the one worth dwelling on, because it is exactly what a language model does not offer.

What the steps are actually showing

The working panel is not a reconstruction. It is a log of the operations that produced the answer, emitted as they happened. When the expression evaluator tells you that it computed 4 raised to the power 2 and got 16, that multiplication genuinely occurred, in that order, and the 16 was genuinely carried into the next operation.

This distinction matters more than it sounds. When a language model shows its reasoning, the reasoning is generated text, produced by the same process that produces every other token. There is no mechanism connecting it to the computation that produced the answer, and there is published evidence that the two frequently diverge: models produce reasoning chains that do not reflect the factors actually driving their output. A chain of thought is a plausible explanation, not a trace.

Here the trace is the computation. If you disagree with the answer, you can point at the exact step where it went wrong, and that step is a real event.

The expression parser, in more detail

Parsing arithmetic correctly is one of those problems that seems trivial until you attempt it. The difficulty is precedence and associativity. Multiplication binds tighter than addition, so 2+3*4 is 14 and not 20. Exponentiation binds tighter still and associates to the right, so 2^3^2 is 2 raised to the ninth power, which is 512, and not 8 squared, which is 64. Unary minus is the awkward one: -3^2 is negative nine in standard mathematical convention, because the exponent binds before the negation, which surprises people and is a genuine source of bugs in spreadsheet software. Try all three in the box.

The shunting-yard algorithm handles this with an operator stack and a precedence table. Numbers go straight to the output. Operators pop higher-precedence operators off the stack before pushing themselves. Parentheses push and pop markers. What comes out is a sequence in reverse Polish notation, where the order of operations is explicit and no parentheses are needed, and evaluating that is a simple stack walk.

The whole thing is about a hundred lines. It is the sort of component that a language model will write for you correctly on most attempts, and where the failures are subtle: an off-by-one in the associativity comparison produces a parser that is right on almost every input and wrong on right-associative chains. This is why the implementation here ships with a test file that checks precedence, associativity, unary minus, division by zero, unbalanced parentheses and unknown identifiers. Run it with node solver.test.mjs.

Floating point, and where this tool is not exact

An honest tool states its limits. This one uses JavaScript numbers, which are IEEE 754 double-precision floats, and that has consequences.

Decimal fractions that terminate in base ten often do not terminate in base two. The value 0.1 is not representable exactly, so 0.1 + 0.2 evaluates to 0.30000000000000004 in any language using doubles. Display rounding hides this in the panel above, and the underlying value still carries the error.

Large integers lose precision above 2 raised to the 53, which is about nine quadrillion. The factoriser refuses inputs above 10 to the 15 for this reason rather than returning quiet nonsense.

Repeated operations accumulate error. Summing a million small numbers into a large running total loses low-order bits at every step, which is why numerical libraries use compensated summation instead of a naive loop.

Real computer algebra systems avoid all of this by using exact rational arithmetic and arbitrary-precision integers, representing one third as a pair of integers rather than as 0.333 repeating. That is the right design for a serious tool and it is more machinery than a page like this warrants. The tradeoff is stated here rather than hidden, which is the general principle worth applying to any calculator you did not write.

How to use this alongside a language model

The division of labour that works is consistent across every task in this area. Use the model for translation, use the algorithm for computation.

A word problem arrives in English. The model turns it into an expression or a set of coefficients, which is the part requiring interpretation of ambiguous human language, and the part where a parser is helpless. You then put the expression into a tool that evaluates it exactly. The answer comes back and the model helps you interpret what it means in the original context.

What goes wrong is when the model does the middle step too. It will produce a number. The number will be right often enough that checking feels unnecessary, and wrong often enough that skipping the check is a mistake. The failures are silent and carry no signal, which makes them worse than loud failures at the same rate.

So: paste the expression here, or into a Python interpreter, or into whatever exact tool you have. It takes four seconds and it converts a probable answer into a certain one.

Privacy

Nothing you type here leaves your browser. There is no analytics on this page, no request to any server after the page loads, and no storage of your input. You can verify this by opening your browser's network tab and watching it stay empty while you calculate. The whole engine is a single JavaScript file served from this domain, readable at /assets/solver.js.