of buttons:

-   constants: $1,2,3,4,5,6,7,8,9,e,\pi,i,\phi$

-   functions:$\ln, \exp, \operatorname{inv}, \operatorname{minus}, \mathrm{sqrt}, \operatorname{sqr},$ $\sin, \arcsin, \cos, \arccos, \tan, \arctan,$ $\sinh, \operatorname{arsinh}, \cosh, \operatorname{arcosh}, \operatorname{tgh}, \operatorname{artgh},$

-   binary operations: $+, -, \times, / , y^x$.

”Full” calculator defined above use 13 constants, 18 functions of one variable, and 5 binary operations.

[Efficient formula enumeration \[enum\]]{}

Once calculator buttons, equivalent to some truncated computer language specification, are fixed, we face the next task: enumeration of all possible formulas. We exclude recursive implementation. While short and elegant, it quickly consumes available memory, and is hard to parallelize [@RIES]. For sequential generation, we notice that formulas are equivalent to set of all abstract syntax trees (AST) or valid reverse polish [@RPNorig] notation (RPN, [@RPN]) calculator codes. The former description has an advantage in case where efficient tree enumeration algorithm exists [@Knuth], e.g: binary trees [@tree]. Unfortunately, this is applicable only to the simplest calculator . Other mix binary and unary trees. Therefore, to handle variety of possible calculators, including future extension to genuine $n$-ary special functions (e.g: hypergeometric, Meijer G, Painleve transcendents) our method of choice is enumeration of RPN codes. This has two major advantages. First, enumeration is trivially provided by `itoa` function with 