Hypercalc The Calculator That Doesn't Overflow
Hypercalc is an open-source interpreted calculator program designed to calculate extremely large numbers (such as your phone number raised to the power of the factorial of the Gross world product) without overflowing.
It handles numbers much larger than tools such as bc, dc, MACSYMA/maxima, Mathematica and Maple, all of which use a bigint library. For example, you can use Hypercalc to determine whether 128481024 is larger than 888888.
Overview: Versions and Features
There have been three manifestations of Hypercalc:
- The original Palm Pilot version, no longer maintained
- The Perl version (because Perl rules!) for the terminal/console in UNIX, Linux, Mac OS and Cygwin systems. Source code is here
- The excellent HyperCalc Javacript, which was translated from the Perl by by Kenny TM~ Chan.
All versions of Hypercalc use an internal representation similar to level-index.
Background: Avoiding Overflow
The primary advantage of Hypercalc is that its numeric range is far greater than any other calculator, numeric library, or mathematics software. Here is a brief comparison (more on my floating-point formats page):
I began exploring very large numbers such as 265536 in the early 1970's using a Texas Instruments SR-50 calculator, and had to manually take logarithms, extract fractional parts and compute mantissas, etc. I made my own BIGNUM library in assembly language for the Apple II, and again on later machines. Such an approach is limited by computer memory (on my Large Numbers page I refer to this as the class-2 limit).
I always wanted a portable calculator that could do my huge-numbers problems, and the Palm Pilot was the first device that really made this possible. I created the Palm OS HyperCalc in October 1998, and got it working within about a week.
The screen on my Pilot cracked, and I could see that the platform wouldn't last too long. More importantly, I wanted to be able to copy and paste numbers and results to other files while working on my web pages. So I created the vastly more powerful Perl version in the summer of 1999. I have maintained and expanded it greatly over the years, adding extended precision (up to 295 digits) later in 1999, the BASIC interpreter late in 2005, base-60 formatting in late 2007, uncertainty calculation in 2011, and so on.
The Perl version is the latest and most capable version. The source code is here.
Here is a sample interaction session:Hypercalc is distributed under the terms and conditions of the GNU General Public License, version 2, June 1991. Type 'help gpl' at the Hypercalc prompt for details. Go ahead -- just TRY to make me overflow! _ _ |_| . . ._ _ ._ _ ._ | _ | | | | | ) (-` | ( ,-| | ( ~ ~ 7 |~ ~' ~ ~ `~` ~ ~ -' mrob.com/hypercalc Enter expressions, or type 'help' for help. C1 = 27^86! R1 = 10 ^ ( 3.4677786443013 x 10 ^ 130 ) C2 = scale=50 Note: For all values less than 23, factorial will give only 31 digits of accuracy; and for values less than 136.032, it will give fewer than the requested 50 digits. C2 = c1 C1: 27^86! C2: (27^86!) R2 = 10 ^ ( 3.4677786443012627135848832197820460548430862081954 x 10 ^ 130 ) C3 =
There is extensive built-in help, accessed by typing help at the
Hypercalc prompt. After an initial introductory help page, just
Non-Intuitive Results When Working With Huge Numbers
If you spend a while exploring the ranges of huge numbers HyperCalc can handle, you will probably start noticing some paradoxical results and might even start to think the calculator is giving wrong answers.
For example, try calculating 27 to the power of googolplex (a googolplex is 10 to the power of googol and a googol is 10100). Key in:
and Hypercalc prints:
10^(10^(1.00 x 10^100))
It appears that the calculator thinks that
27^(10^(10^100)) = 10^(10^(10^100))
This is clearly wrong and it doesn't even seem to be a good approximation. What's going on?
Let's try calculating the correct answer ourselves. We need to express the answer as 10 to the power of 10 to the power of something, because that's the standard format the calculator is using, and we're going to see how much of an error it made. So, we want to compute
as a "tower" of powers of 10. The first step is express the power of 27 as a power of 10 with a product in the exponent, using the formula xy = 10(log(x) . y) :
271010100 = 10(log1027 . 1010100)
log1027 is about 1.43, so we have
271010100 = 101.43 . 1010100
Now we have a base of 10 but the exponent still needs work. The next step is to express the product as a sum in the next-higher exponent; this time the formula we use is x . y = 10(log(x) + log(y)) :
101.43 . 1010100 = 1010(log101.43 + 10100)
log101.43 is about 0.155, and if we add this to 10100 we get
1010(0.155 + 10100) = 10101000...000.155
= 1010(1.000...000155 . 10100)
where there are 94 more 0's in place of each of the "...". So our final answer is:
271010100 = 1010(1.000...000155 . 10100)
Now that we've expressed the value of 27^googolplex precisely enough to see the calculator's error and look how small the error is! The calculator would need to have at least 104 digits of precision to be able to handle the value "1.000...000155" accurately but it only has 16 digits of accuracy. Those 16 digits are taken up by the 1 and the first fifteen 0's so when the calculator gets to the step where we're adding 0.155 to 1.0.10100, it just rounds off the answer to 1.0.10100 and produces the answer we saw when we performed the calculation:
10^(10^(1.00 x 10^100)) = 10101.00 × 10100
The original Palm version of Hypercalc had a calculator-like display, a short, wide rectangle giving enough room to show one line of text with about 30 or 40 characters. Given this limited display area, even if it did have the necessary 104 digits of precision, it wouldn't have room to print the whole 104 digits on the screen, so the answer displayed would still look the same.
More to the point, no matter how many digits of accuracy we try to display, there's always going to be another even bigger number that we won't be able to handle. For example, Hypercalc would need slightly over a million digits of accuracy to distinguish
2710101000000 from 1010101000000
and if we just add one more 10 to that tower of exponents, all hope of avoiding roundoff is lost!