According the Hewlett-Packard, this calculator is not a programmable model. I have to respectfully disagree: the ability to store an equation and recall it later for evaluation is precisely what makes a calculator programmable. Not very programmable mind you: there are no conditional instructions, loop constructs, subroutines, the ability to store multiple programs, etc. Even so, calculators much more primitive than the HP-30S were called programmable by their respective manufacturers, so the HP-30S definitely belongs in this category.

The HP-30S is one of HP's latest models, one that can be considered part of an overall attempt to re-enter the calculator field that has been all but dominated by HP's competitors, most notably Texas Instruments, Casio, and Sharp in recent years. The HP-30S is a "cheap" scientific calculator; I picked mine up for 20 Canadian dollars the other day at a large electronics store.

My first impression: I long for that era where the quality of a product or its documentation mattered more than its cosmetic appearance. HP used to be famous for their top quality manuals; now all we get is two flimsy sheets and a small quick reference card (mind you, even this is more than you get with most other manufacturers' products!). What you do get instead is faceplates of three different color packaged with the machine...

At least it appears that HP resisted the temptation to package a generic scientific calculator chip under its own brand name. At least that's what I thought when I first encountered this seemingly unique machine. Alas, the machine turns out to be not so unique after all: it is part of a lineup by Kinpo, and may have also been sold under the Citizen and/or Truly brand names.

One particularly interesting feature is that this machine uses binary arithmetic to perform floating point calculations. What? But you thought all calculators used binary logic, right? Well, almost. Most calculators since time immemorial (i.e., since the mid 1960s when the first electronic desktop calculators appeared) used BCD (Binary Coded Decimal) arithmetic that made it relatively easy to convert internally represented values for display purposes and vice versa.

How do I know that the HP-30S uses binary arithmetic? Take the value of Pi for instance. The manual (if it can be called that) states that the calculator uses up to 24 digits of precision. But when I subtract numeric values from the symbolic constant Pi, the result indicates there might be more digits:

Pi-3.141592653589=7.932384626·10^-13

Ans-7.932384626e-13=4.917309898·10^-23

So it seems that the calculator "knows" more than 24 digits of Pi: 3.14159265358979323846264917309898...

But there's something wrong here. You see, these aren't the digits of Pi. The correct value is 3.14159265358979323846264338327950...

So the manual was correct after all... we have 24-digit accuracy. But what are these extra digits, then? Where do they come from?

If you're familiar with the representation of floating-point numbers in various number bases, you already know the answer: it is rounding error. A number that can be accurately represented in one number system may require an infinite number of fractional digits in another. For instance, the number 0.1₃ in base 3 can only be represented as 0.33333333... in base 10. In this case, I suspect that the calculator stores Pi internally as 3.243F6A8885A308D3132_hex, and what we see on the display is, in fact, the result of a rounded conversion to the decimal number base.

Since the HP-30S has no built-in Gamma function, my favorite programming example may even prove to be useful. So here is not one, but two implementations of the logarithm of the Gamma function for the HP-30S. The first version uses the extended Stirling formula:

Ans ln(Ans)-Ans+ln(√(2π/Ans))+((((1/99Ans²-1/140)/Ans²+1/105)/Ans²-1/30)/Ans²+1)/12Ans

The second version uses the Lanczos approximation and requires that you preload four variables with the necessary values:

ln((A+B/(Ans+1)+C/(Ans+2)+D/(Ans+3))/Ans)+(Ans+.5)ln(Ans+4.055)-Ans-4.055
A=2.506628665008
B=37.09157206171
C=-22.99812587159
D=1.641518102127

Both implementations are fairly accurate; the advantage of using Stirling's formula is that it uses no extra variables, whereas the Lanczos approximation remains accurate for small (<5) arguments where Stirling's formula fails.

In both cases, the formula should be loaded into the EQN variable; when recalled and executed, it uses the result of the most recent calculation (i.e., the contents of the Ans variable) as its argument.