FAQ Etc.
Here are some answers to questions I have received about the calculator app, and maybe some answers to questions no one has asked yet.
Why is the exponent button labeled x^y, when HP labels it y^x?
In the old HP calculators, x always referred to the top of the stack (the last value entered or calculated), and y referred to the previous entry on the stack, which depending on the model was above the x value in the display or not visible. This was an HP convention which made all of the buttons labels heavily tied in to the stack implementation - and not particularly consistent with mathematical convention or the order in which the values were entered.
In the Visual RPN Calculator, x and y do not refer to positions on the stack, they refer to arguments for the calculations to be performed by the various buttons.
So the meaning of the "x^y" button is that the button takes two arguments. The first argument is the x value, it will be the value to the left, the first value you entered or calculated. The second argument is the y value and is to the right and is the second number you entered or calculated. This operation is more consistent with mathematical convention and relates the alphabetical order of the label characters to the order in which the values were entered and appear on the stack.
An argument can be made for either case, although I would argue that to someone unfamiliar with HP calculators the Visual RPN way is substantially more intuitive. However, there are at least a couple of cases where the HP convention is just flat out terrible. Consider the two buttons "x + yi" and "(x, y)" in the Special menu tab. The labels follow mathematical convention and are fairly clear in their intent. It would be outright confusing if they were labeled "y + xi" and "(y, x)". What exactly is the meaning of "(y, x)"? Sure, it is a data pair, but when I feed it into a regression, which value is the independent variable - the one on the left or the one labeled "x"?
Long story short, the developer is sticking with the naming convention that is currently in use for this app, because in spite of what old HP users are used to, it is the better option. To be clear, the top of the stack is not x - it is just the top of the stack. The x and y refer to the order of arguments fed into an operation (alphabetically left to right), and that is all.
How accurate is the calculator?
The calculator uses double floating point binary numbers, which allows for up to about 16 decimal digits of accuracy. However, because the internal representation is binary (not decimal), some numbers that have exact representation in decimal do not have exact representation in the calculator. For instance, .8 in binary looks like .11001100110011001100.... (repeating) so it can't be represented exactly. To the most part you will never notice this difference, because the calculator displays far fewer digits of accuracy than it uses internally, but there are a few corner cases where limitations stand out.
For an example of a corner case where the calculator accuracy is limited, look at the following calculation:
1 / 3 - .3333333333 = 3.333333609E-11
Obviously, the answer is only accurate in the first 6 or 7 digits. The answer wouldn't be any more accurate if it were 3.33333E-11, though it would be arguably less misleading because such an answer wouldn't include digits that are wrong. However, the calculator doesn't try to track digits of accuracy, it just always displays significantly fewer digits than it holds internally. This generally works very well, except when taking the difference between two numbers that are extremely close (to within 7 digits or more). In such cases some of the lower digits in the answer may be inaccurate.
Now, if you subtract two numbers that are even more extremely close (i.e., the same within 12 digits of accuracy), you get the following:
1 / 3 - .333333333333 = 0
The calculator decides that the difference between the two numbers is too small for the internal accuracy available, and it just assumes they are essentially the same number and the difference is zero. That is also why if you take 4/5 - .8 you get zero instead of something else, even though the calculator may not represent 4/5 and .8 exactly the same way because of representation limitations in binary.
Note: There are other numerical data formats available that provide higher accuracy than the double floating point used by the calculator. For instance, there is a "Decimal"" data type which provides more digits of accuracy (around 28) and better decimal mapping. However, calculations using the Decimal type are orders of magnitude slower and math library support is limited. In any case, whether the accuracy is 16 digits or 28, computer accuracy will always be limited at some point, so the double floating point type was decided upon as the best compromise.
Accuracy Summary
- The calculator accuracy is not unlimited, though the accuracy is quite high (up to 16 decimal digits).
- The accuracy limits become most apparent in subtraction of numbers with very small differences (see examples above), or potentially the addition of very small numbers to very large ones.
- The double floating point representation used by the calculator is a compromise between calculation speed together with availability of math libraries, versus the most extreme possible accuracy.
- Although double floating point accuracy should be more than adequate for the vast majority of purposes, it is always good to understand the limitations of any computer calculations - this app included.