calc82: Project Introduction and Devlog #1

calc82: because calculators are for everyone

The aim of this project is to create a free, software-based browser calculator which mimics the behaviour of the Casio fx-82au. This is the most common calculator in high schools in my country.

🔥 Motivation

My motivation for this project is the following:

1. calculators are cool
2. i dont always have my calculator on me
3. (most notably) not everyone has access to a scientific calculator

🎯 Approach

I will take a black-box reverse engineering approach. This means analysing the inputs and outputs of the calculator and attempting to replicate the behaviour without looking at the underlying code. This along with avoiding patents and copyright should keep the project okay legally.

📈 Goals and scope

The final goal for the project is to create a fully functional calculator (obviously) which works on most types of devices. This means both touch and keyboard input, resolution scaling, wide browser support…

I have moderate experience with creating web apps. and a lot of experience using this calculator. so this project should be pretty fun :)

Devlog #1 06/07/2026

This devlog covers the initial development of the parts of the calculator that do math. Essentially turning an input expression into an output.

I chose a high-level structure similar to that used by programming language syntax analysers. That is:

Input -> Tokeniser -> Parser -> Evaluator -> Output

🪙 Tokeniser

yes, with an s >:(
The tokeniser converts the input into a list of tokens (think individual pieces of the expression). It does this by scanning the input string and identifying what each character corresponds to. The tokeniser only knows what each symbol is, not what it does. Then it passes the token array to the…

🌲 Parser

The parser converts the token array into an Abstract Syntax Tree (AST). Essentially this is a tree which shows how the expressions should be evaluated in order to produce the desired output. This properly lets me implement order of operations.

The exact type of parser I am using is a recursive descent parser. It attempts to match the tokens with known symbols recursively, meaning i can rely on the call stack :)

The order of operations can be defined by the order of function calls within the parser.

🧮 Evaluator

The evaluator’s job is easy: it just traverses the tree made by the parser and runs the necessary operations. Because all of the hard work regarding order of operations has been done by the other components, implementing the evaluator was really easy. Its also recursive. your call stack is gonna love me for this

🗒️ Notes

Why not eval?
It’s true that JavaScript has a perfectly good expression parser, which I could have used. However, its behaviour is more suited to a programming language than a calculator.
For example, 4(2+3) should implicitly multiply, but will instead complain TypeError: 4 is not a function. Writing my own system gives me more flexibility to make the calculator how I want.

Floating point precision
Because it uses Javascript’s internal math engine, i have floating-point problems. This results in expressions like
sin(2pi) = -2.44929360e-16
I will likely fix this by using a math library, or a novel approach.

Last-minute catch
I was just writing an example for this devlog when I found that .3ln(4)*5^2 raised an error. In fact, ANYTHING * or / followed by x^n would error - but other operators wouldn’t. This was a quick fix, but I’m glad I caught it!

📈 Next steps

Immediate:

• Fix math imprecision
• Add fractional I/O

Medium:

• Create algebraic display functionality
• Multi-line calculation (Ans) and variables

Long-term:

• Make the calculator functionally equivalent to the fx-82
• Build UI
• Ship :)

Thanks so much for reading! If you have any suggestions, please leave me a comment