The Museum of HP Calculators

HP Forum Archive 17

[ Return to Index | Top of Index ]

Determining significand length of the HP 33s
Message #1 Posted by G. Cone on 16 May 2007, 5:32 p.m.

When dealing with numerical programming, one often is confronted with a conditional statement that requires a decision to be made based upon the difference or ratio between two variables being reasonably close to zero. The question then arises: how close is reasonably close? At first impulse, one may simply choose to select a tiny arbitrary value, say 10-6 or better yet 10-20 based upon the user's desire for precision. While this may seem like a acceptable method, it ignores the realities of the floating point representation being used by the machine.

Floating point numbers are ususally represented in binary as follows:


where 'S' is the sign bit, the 'Ei' are the exponent bits, and the 'Tj' are the significand bits (also known as the mantissa). This implies that there is a maximum relative spacing between any two numbers for a given floating point representation. Given a common floating point representation such as double precision IEEE found on standard personal computers, this maximum relative spacing is 2.22E-16, yielding 16 digits of precision. This value can be determined from the formula:

maximum relative spacing (epsilon) = 21-n

where 'n' is the number of bits in the significand (note that IEEE uses a "hidden bit method" so that while there are only 52 bits in a 64-bit number dedicated to the significand, the value of 'n' in that case is really 53).
So for programmable calculators like the HP 33s, knowing what epsilon is important. The manual states that typical calculations are accurate to 12 decimal digits. This would imply an epsilon value of around 10-12 to 10-13 or the number of significand bits being as low as 39 up to 41 bits. Mr. Hanson mentioned in his article about a "Cadillac" quadratic solver for the HP 33s that the "tricky properties" of the statistical operations allow precision up to 15 digits; more in line with the 52 to 53 bit significand used in the IEEE floats.
I attempted to ask HP directly about the number of bits used for the significand in the HP 33s for both sets of operations to no avail. I'm trying to come up with a nifty program to determine the appropriate value for 'n' for standard operations. If anyone comes up with something, please post it.
For the time being, the few programs I have written (Mr. Hanson's program translation being the exception) use:


Stay tuned for some programs that I've successfully translated to the HP 33s!
Re: Determining significand length of the HP 33s
Message #2 Posted by Antonio Maschio (Italy) on 17 May 2007, 2:27 a.m.,
in response to message #1 by G. Cone

I stay tuned.

-- Antonio

Edited: 17 May 2007, 2:27 a.m.

Re: Determining significand length of the HP 33s
Message #3 Posted by John Limpert on 17 May 2007, 1:30 p.m.,
in response to message #1 by G. Cone

I'd just add that most calculators use decimal, not binary, floating point arithmetic. An excellent resource for information on decimal arithmetic is Mike Cowlishaw's web page at IBM Hursley (

Re: Determining significand length of the HP 33s
Message #4 Posted by G. Cone on 17 May 2007, 10:49 p.m.,
in response to message #3 by John Limpert

Thank you Mr. Limpert. That's a piece of information that I obviously was unaware of. I'll definitely check that website out!

Re: Determining significand length of the HP 33s
Message #5 Posted by Les Wright on 17 May 2007, 11:08 p.m.,
in response to message #1 by G. Cone

I must admit that in pretty all of my RPN program that require convergence to equality of some sort, whether it is to zero or to something else, I simply go until actual equality and don't use epsilon in the same way one does in C, Visual Basic, or Pascal code.

My understanding is that even though the RPN calculators I use carry internal guard digits, these extra digits are lost when a value is returned to the stack. Therefore, in virtually all cases where I need a desired value to stop changing in the 12 (or 10) displayed digits before exiting a loop, simply testing for non-equality is the way I do it. If "old" and "new" values of the desired parameter are not equal, I loop back to the beginning of the loop, otherwise I skip the GTO after the conditional test and carry on.

This almost always works in cases where I am computing a convergent series or continued fraction representation of a desired function. In root solving, though, there may be some "wiggle" in the last digit which I can see if I display interim approximations. In those cases the loop ends when I do specify some desired epsilon, such as 1e-8.


Re: Determining significand length of the HP 33s
Message #6 Posted by hugh steers on 18 May 2007, 4:51 a.m.,
in response to message #5 by Les Wright

hi guys,

there's an interesting method to calculate the net accuracy in bits and as decimal equivalent. its not rigorous, but helpful. i first saw this in Jean Meeus' book (the astronomer).

here's a lua version (easier to see what's going on):

function precision()
   x = 1
   j = 0
   while (1)
      x = x*2
      if x + 1 == x then
         print(j, j*0.30103)
      j = j + 1

transcript (hplua hp50g):

hplua -i acc.lua
Lua 5.1.2 Copyright (C) 1994-2007, PUC-Rio
HPLua version 0.4
> 83	24.98549
first number is bits, second is decimal equivalent. so i'm seeing a payload of nearly 25 decimals on my 50g with this.

running this on a PC (IEEE754 doubles) as:

#include <stdio.h>
void showPrecision()
    double x = 1;
    int j = 0;
   while (1)
       x = x*2;
       if (x + 1.0 == x) 
           printf("%d %f\n", j, (double)j*0.30103);
       j = j + 1;
int main()
    return 0;
i get, 52 15.653560 which is 52 bits and 15.6 decimals. maybe someone would like to try this method in RPL (i don't RPL anymore).

Re: Determining significand length of the HP 33s
Message #7 Posted by G. Cone on 22 May 2007, 10:00 a.m.,
in response to message #1 by G. Cone

I believe this link answers my original question quite well.

Given the BCD operation of these calculators, the epsilon value is 5.00000000001E-12.
Oddly enough, 5.0E-12(exact) when added to 1.0(exact) doesn't add up to 1.00000000001, go figure...

[ Return to Index | Top of Index ]

Go back to the main exhibit hall