Enter RPN

Ballpark Accuracy
Login

Ballpark Accuracy

Help

Motivation

The calculator forensics algorithm was designed to infer which calculators used which internal math implementations. It avoided the need for destructive acts like breaking open a heat-welded case or decapping a CoB IC merely to discern that two externally-different devices used the same calculator chip internally.

This same algorithm has another purpose which I find more interesting: it’s a good way to probe into a calculator’s inherent accuracy. Simpler tests can be optimized around, but this one is complex enough that — as far as I’m aware — nothing short of a CAS can avoid error.

The Algorithm

Mathematically, the sequence is:

sin-1(cos-1(tan-1(tan(cos(sin(9))))))

The inverse trig functions are sometimes denoted arcsin() and such, but on a cramped calculator faceplate, it is more common to see the abbreviation ASIN().

This test was purposefully designed to use a low angle relative to the X axis1 to produce a long decimal value that is difficult for calculators to optimize. We must avoid the special-casing calculators perform at multiples of 45° and 90° where mathematically-important results lay: infinities and zeroes and ones, depending on the function, which precludes using them for this type of diagnostic purpose.

Because the final three operations roll back the first three in inverse order, the output should ideally be the exact 9° value we gave as input, but this is rare to see short of rounding and CAS logic. (Find out which below!)

Textbook Entry

One of the original purposes behind this test’s design was to allow a calculator shopper standing in a store aisle to punch the sequence in through the flexible plastic covering the calculator’s buttons. A knowledgeable eye could then study the result and choose whether to buy based on whether it scored well on this test or not.

This sequence was invented long enough ago that trig functions were generally postfix regardless of whether the machine was RPN or algebraic, which allowed our prospective shopper to enter it without resorting to parentheses:

9
SIN
COS
TAN
ATAN
ACOS
ASIN

But what if you’re testing a later calculator that did feature algebraic textbook entry?

As professional users moved to computers, hand-held calculators began to focus increasingly on the education market, gaining textbook entry modes. For our purposes here, that means you need to input the test using the mathematical formulation at the top of the prior section.

This change in market focus gave aid and comfort to students — plus any others who had the fortune of having the expression written out for them ahead of time — who are merely transcribing that printed form into the machine to get an answer without thinking too hard. That’s great until one runs into a situation where the only alternative to thinking hard is to fail the task, presuming you are not one of those fabled math prodigies, able to “see” the answer in finished form right from the start. For us mere mortals, we succeed by step-by-step calculation, and for that, RPN remains supremely useful.

The quality of textbook entry modes ranges from excellent to downright miserable, as on the TI-60X. Imagine the following printed in a super-blocky 5⨉4 pixel per character dot matrix LCD font:

SIN-1 COS-1 TAN-1 TAN COS SIN 9 =

That mess gets you the “calculator forensics” value, though it takes a bit of study to see why given how far it is from a true textbook presentation.

Continuing on with our refined algorithm means pressing ÷ 9 = which works as expected for an algebraic-input calculator, but how then do you get the final logarithm? You must press LOG ANS = because it, too, is a prefix function now, not postfix as on all TIs before it, taking the displayed value as its sole input. If you are used to that historical behavior and incorrectly hit LOG = you end up destroying the intermediate result. Worse, you get an extra lump coal in your stocking: clearing the ugly ERROR message also tosses the prior answer, meaning you cannot recover with the ANS key. No, you have to start all over, you poor sod.

But remember, this is the easy mode.

Right?

Sigh.

Textbook entry fans may reply that I could instead have said this:

LOG (9 ÷ SIN-1 COS-1 TAN-1 TAN COS SIN 9)

But once again, that requires that one have the complete expression written out ahead of time, assuming you are like me and lack the mental acuity to string that together in the correct order the first time, every time.

And I did not get it right to start with! I tried leaving out the parentheses, expecting the order of operations to continue from right to left as with the simpler expression, but I did not immediately recognize that LOG has higher priority than ÷, causing the calculator to evaluate a bogus LOG(9) ÷ SIN-1(…) expression, not at all what I wanted. I ended up needing to try with two layers of parentheses before I got the expected answer, then needed to strip them away in alternation to figure out which one was the critical fix. The only way to be certain on this machine from “go” without memorizing the finer details of the order of operations rules is to add all parentheses manually:

LOG (9 ÷ SIN-1(COS-1(TAN-1(TAN(COS(SIN(9)))))))

Now at last we have achieved something approximating the appearance of textbook notation, but at a cost: increased wear on the parenthesis keys.

None of that is needed with RPN. You have an X value and a choice of operators to apply at each step. Even a non-mathematician like me can handle that.

Now, to be fair, there are much better exemplars of the art, such as the Casio fx-115ES, which prevents the user from committing the order of operations error because pressing the log key puts “log(” on the screen without any way of removing the parenthesis. This allows you to enter the entire expression as printed above without keying in any explicit parentheses. The function keys add the opening parens, and the = key implicitly closes any you left open. You can manually close the parens if you want a better match to what’s printed above, but you don’t have to.

The Interpretation Problem

Irrespective of the method by which you input the sequence, it should ideally produce a perfect “9” on every calculator.

In practice you get either:

…and then some number of incorrect error digits. This then indicates which implementation produced the result, because different ones have different internal errors. Two different units that produce the exact same answer are likely using the same trig algorithms internally, with the same core math precision, implying that they’re using the same calculator IC internally. (Or at least, a faithful emulation of it.) Given two calculators from the same top-tier manufacturer, this becomes a near-certainty. When you instead see this happen with two different manufacturers but with similar external appearance, it likely betrays an OEM/relabeler relationship. With two different external appearances, one is forced to dig deeper, likely to find that they’re both using the same third-party IC.

Thus “forensics.”

The exact value is not as important for those like me, who are more interested in accurate answers to real-world math questions than in digging into internal implementation choices.

One practical use for this is to find a good starting point for the calculator’s display precision setting. For instance, putting it into what HP calls FIX 3 mode will get you the ideal “9” answer when the actual calculated result is 8.999945378645.

Contrast FIX 4 mode, where you should see 8.9999 instead because the following “4” doesn’t allow rounding up to 9.

The Ballpark-Accuracy Refinement

Counting zeroes/nines after the decimal point sucks. If all we’re interested in is a ballpark accuracy figure, can we not do better?

Yes, we can! Enter the power of logarithms, giving values more easily compared.2 In algebraic entry form:

9.000015685
÷
9
=
1.000001742
LOG
1.742776259e-6

Now drop that noisy mantissa and keep only the exponent, allowing us to call this a 10-6 class calculator.3

This small refinement converts a long decimal value into a useful power-of-ten estimate of how far off from the ideal the calculator landed. Given two machines that produce the same exponent, it’s fair to say they’re as close to equally accurate as matters for most applications. A difference only becomes meaningful in practice when you get different exponents, because it means the number of significant digits lost is the difference in the powers, roughly speaking.4

I give several results below, but I can boil it down into the following regimes:

Exponent5 Broad Meaning
<2 worse error than 1:100, thus objectively broken
2 or 3 1.0 - 0.1% accuracy; early electronic calculators
7 or 8 high-end early 1980s machines; mid-grade late 1980s ones
>10 64-bit floating point math; mainly PC calculators
>15 top-end, but still an approximation; likely 128-bit FP

That last category can also indicate things like arbitrary-precision arithmetic (APA) but with limited precision for the irrational results we get for our low-angle trig test here. Without additional software to handle specific cases, APA gives exact results only for calculations that terminate; it can compute the factorial of a large integer precisely, but if you ask it what ⅓ is as a decimal, it will have to cut it off at some point.

Results

I’ve done this test on all the calculators I have here, augmented by a firsthand report from one who chose not to be identified. I do realize these results add almost nothing to the calculator forensics algorithm results table, but I do find them useful for slotting various machines into the scheme above:

Rank Calculator Variant(s) Test Unit Mfg.
10-3 TI-30 the classic 1980 (Abilene, TX)
10-5 HP-15C, 11C same Voyager processor in all 1983 (USA), 1988 (USA)
10-7 HP-12c Platinum Voyager sans BCD rounding 2006 (China)
10-7 TI-36X Solar gray-blue, gray-green 1997 (Italy), 2000 (Shanghai)
10-7 fx-115N normal 1995? (Japan)
10-8 fx-115W normal 1998? (China)
10-8 TI-60X TI-68X-like 1991 (Italy)
10-8 HP-28S HP is all-Saturn from here on 1988 (USA)
10-8 HP-20S yep, Saturn again 1994 (Indonesia)
10-8 HP-32S/II 20S family-mate and successor 1990 (Singapore)
10-8 HP-48GX surprise; Saturn still! 2000 (Indonesia)
10-8 HP-50g ARM, but emulating Saturn 2010 (China)
10-10 fx-nnnES6 silver 115ES, white 2nd Ed. 2004 (China), 2025 (Thailand)
10-11 PCalc 4 on Apple Silicon, iOS & macOS 2021 (A15), 2024 (M4)
10-12 WP 34s HP 30b base, FW v3.2 2010 (China)
10-13 PCalc 4 on macOS, Intel x86_64 2020 (i9-10910)
10-30 DM32 Intel 128-bit FP math 2025 (Switzerland)

There are several useful take-aways to be had here:

|

Again, in Radians!

The calculator forensics algorithm requires its input in degrees so that you get comparable results between machines. The only other element to the reasoning behind this choice is that calculators hanging on a peg in the store aisle default to degrees, so it avoids the need to work out how to punch it into radians mode through the clear plastic packaging.

The thing is, the result is mathematical nonsense. No one takes the cosine of a sine in real-world applications short of oddball tests like this, or possibly as driving functions for whizzy computer graphics demos, where one is not making a mathematical point but being purely artistic.

So why redo all the tests in radians, then? Because there are calculators — I am thinking of one in particular — that offer trig in radians only, and we wish to have results we can all compare.

You will notice that the orders of magnitude we get are lower. This is again a reflection of the fact that this algorithm gives a result that is meaningful only within this very specific context; there is no objective interpretation one can make, not even in comparison to the degrees-based results above. To attempt it is not merely to perpetrate a mathematical apples-and-oranges folly, it is akin to comparing two novelists’ speculative descriptions of made-up space alien fruit, and then having the hubris to attempt meaningful conclusions.

But speaking within this strictly confined scope, the results are useful:

Rank Calculator
10-8 TI-30
10-8 HP-12C (original)
10-9 HP-11C/15C
10-10 TI-36X Solar
10-10 Casio fx-115W
10-11 Casio fx-115N
10-11 HP-12c Platinum
10-11 HP-20S/28S/32S/48GX/50g
10-12 TI-60X
10-13 Casio fx-115ES, 115ES PLUS 2/e
10-15 WP 34s
10-15 PCalc 4, ARM
10-19 PCalc 4, MacIntel
10-33 DM32

These results were done with a base value of 0.1, not 9° converted to radians = 0.15707963267949. This preserves the original intent of choosing 9° without losing its simplicity. It gives us an easy-to-enter oddball angle that won’t be optimized out by the calculator, yet which is close enough to the X axis to force round-off errors without producing near-random results. I tried using 1 to avoid the need for the division step, but that turned out to be too easy a problem, preventing me from making useful distinctions.

Brief comments on the results:

Now, have you guessed which specific calculator drove me to add this section?

No?

Want a hint?

Okay, it is this: Which machine did not appear in the prior table?

That’s right, it’s the HP-12C, which won’t run the Platinum program referenced above. To get this result, one must:

  1. Type in Valentin Albillo’s impressive 99-step program, filling its entire program RAM.
  2. Issue opaque GTO calls7 and perform stack register manipulations8 to get the results.
  3. Compare the result to 0.1 using the same divide-and-log method above.

One of the major limitations of this program is that it operates in radians only, which finally provides the motivation for this section’s existence. If we had no other results to compare, we could not place this program’s results into any kind of perspective.

If the calculator is in the freshly-started state so that we can treat the GTO 00 in the first three steps as implicit, the complete key sequence for this test is:

.1 R/S x≷y       # sin(.1)
R/S              # cos(sin(.1))
R/S ÷            # tan(cos(sin(.1)))
g GTO 30 R/S     # arctan(tan(cos(sin(.1))))
g GTO 93 R/S     # arccos(arctan(tan(cos(sin(.1)))))
g GTO 37 R/S     # arcsin(arccos(arctan(tan(cos(sin(.1)))) ≅ 0.1
.1 ÷ g LN        # natural log version of accuracy measure
10 g LN ÷        # convert to base-10 log

The original article includes the GTO 00 step for all three basic operations, but once we successfully call sin(0.1), we know the pointer’s state for a certainty. These routines always finish by returning to 00.

You may wish to pause at the first step because Albillo’s article gives the expected output of sin(0.1) as a test result for checking that you typed the program in correctly. Alas, none of the other provided test vectors are helpful to us here.

Now contrast the 12c Platinum running Barbosa’s trig package, where the test sequence is:

g GTO 272 R/S    # put it in radians mode; reset PC to 000
.1 R/S           # sin(.1)
g GTO 090 R/S    # cos(sin(.1))
g GTO 100 R/S    # tan(cos(sin(.1)))
g GTO 177 R/S    # arctan(tan(cos(sin(.1))))
g GTO 157 R/S    # arccos(arctan(tan(cos(sin(.1)))))
g GTO 137 R/S    # arcsin(arccos(arctan(tan(cos(sin(.1)))) ≅ 0.1
.1 ÷ g LN        # natural log variant of accuracy measure
10 g LN ÷        # convert to base-10 log

This turned in another strong result. For the same 12-digit BCD rounding reason cited above, its accuracy measure on this test matches the later Saturn-based HP scientific calculators.

License

This work is © 2025 by Warren Young and is licensed under CC BY-NC-SA 4.0

  1. ^ 9°, being certain to have the calculator in degrees mode
  2. ^ Thus decibels, the Richter scale…
  3. ^ You may need to put the calculator into a full-precision scientific mode to see this properly.
  4. ^ A difference of one point on this scale may be insignificant. If one machine gives 9.99e-8 and the other 1.01e-7, the error difference between them is small even though our “drop the mantissa” rule misleads us into seeing a power-of-ten difference. If you need to make fine distinctions, you cannot ignore the mantissa.
  5. ^ Technically, the absolute value of the exponent. It came down to a choice of confusions. The present notation scheme is idiosyncratic, but that has the upside that I can declare, “This is how it is” and get my way. I rejected the alternative because it creates a confusing combination with the relation operators I use. Take the “<-2” I would have had to use on the first row; the intent would be that the reader interpret that to include “-1” and exclude “-3,” but I feel certain I’d be doomed to confront the mathematical nit-pickers who would insist that <10-2=0.01 ∴ 0.009 matches. 🙄
  6. ^ Casio has a long history of releasing multiple products under different names with little to no difference among them. In the late 1980s, you might find an fx-100, 115, 570, and 991 with the same trailing letter code, differing only in a 2×2 matrix of choices: whether it lacked the solar cell option (100/570), and whether it lacked the constants/conversions button (100/115). The choice between the 570 and 991 therefore came down to whether you wanted the solar cell; both had the const/conv button. This collapse of market differentiation appears to be increasing, with the fx-115ES PLUS 2nd Edition being nearly identical to the 991 in the same line excepting only color options and where in the world each is intended to be sold. The fx-300 series are feature-reduced to meet school qualifications meant to keep their kids from letting the calculator do all their thinking in math class, but for our purposes here, they give identical results to the others, as verified on a blue fx-300ES PLUS 2nd Edition made between the two 115 units reported on above.
  7. ^ The two-digit GTO addresses afforded by the HP-12C programming model have mnemonic value at best, and in this specific case, none at all, that I can see. If the early parts of the program had to be reworked, resulting in a change in the documented addresses for getting the arc-trig functions from Albillo’s program, the new addresses would likely end up equally meaningless to the end user.
  8. ^ Before I explain what I mean here, contemplate the fact that this program gives all three of sin(), cos(), and tan() from GTO 00 R/S. How? It is because the top routine computes the sine and cosine simultaneously in order to give the tangent as nearly-free fallout, costing nothing but a ÷ keypress. That in turn explains why it leaves the cosine in x instead of putting the sine there, as you might expect. Doing so would give an inverted tangent ratio unless you either pressed x≷y before dividing, or went ahead and divided first, followed by 1/𝑥 to flip it, losing accuracy due to an unfortunate double division. Cute, yes? Indeed, but hardly memorable.