and total number of *unique* numbers $k_3$ are additonal useful characterizations of the search depth. Obviously, $k_3 \leq k_2 \leq k_1$. For perfectly efficient enumeration $k_1=k_2=k_3$. Unfortunately, this is currently possible only for rational numbers, see Appendix B. Case $k_1=k_2$ is equivalent to knowledge of unique tree enumeration algorithm. To achieve $k_2=k_3$ ($p=1$ in Fig. \[k2k3\], dashed diagonal line) algorithm must magically somehow know in advance all possible mathematical simplifications. Not only those trivial, like $e^{ \ln{x} } = \ln{(e^x)}=x$ but anything mathematically imaginable, e.g, $2^{1-\ln{\ln{\pi}}} = 2 (\ln{\pi})^{-\ln{2}}$. We doubt this is possible at all. Some ideas, based on solved rational numbers enumeration, are presented in Appendix B. In practice, we achieved $k_3/k_2 = 0.59, 0.06, 0.08, 0.49$ for calculators 1-4 , respectively. Large $k_3/k_2$ ratio for is a result of very simple tree structure, in which only every nine-th odd-$K$ RPN codes are valid. Without taking this into account, $k_3/k_2=0.59/2/9 = 0.03$, i.e., the worst of four. Full calculator perform surprisingly well.

![\[k2k3\] Number of unique formulas $k_3$ *versus* number of valid codes $k_2$. Solid lines show $k_3 = {k_2}^p$ fits, with $p=0.96491, 0.826455, 0.848559, 0.948259$ for calculators 1-4, respectively. Dashed diagonal line shows perfect case $k_3=k_2$. ](figs/k2k3){width="50.00000%"}

