# How does my pocket calculator do this?

March 28, 2004 10:06 AM Subscribe

How does my pocket calculator do this?

I've got an old pocket calculator that I'm playing around with when I'm bored. If I enter a very small number, like 1.000,000,001, and raise it to the power of 10

More about calculators cutting corners if anyone's interested. At work, we sell calculators. Once a girl came back and complained about her Texas Instruments TI-83 graphical calculator: it gave the wrong answer. She showed me: a calculation where the result should be exactly zero was not zero but a very small number. This was beyond me, so I called Texas customer support, and they explained that this was because of the algorithm the calculator used. In other words, it's not a bug, it's a feature. But a cheap 12 dollar calculator was able to give the correct answer.

I've got an old pocket calculator that I'm playing around with when I'm bored. If I enter a very small number, like 1.000,000,001, and raise it to the power of 10

^{11}it takes less than two seconds to get the answer. I don't know much about computing but I don't think my ten year old calculator can multiply that number by itself 100 billion times within two seconds. So how does it do it? Does it use some kind of mathematical shortcuts?

More about calculators cutting corners if anyone's interested. At work, we sell calculators. Once a girl came back and complained about her Texas Instruments TI-83 graphical calculator: it gave the wrong answer. She showed me: a calculation where the result should be exactly zero was not zero but a very small number. This was beyond me, so I called Texas customer support, and they explained that this was because of the algorithm the calculator used. In other words, it's not a bug, it's a feature. But a cheap 12 dollar calculator was able to give the correct answer.

actually, there's another reason for errors too, that i forgot. calculators only store a limited number of digits, plus a "size". so

12345678901234567890 might be stored as 1.23456 * 10^19 (the calculator stores the digits "123456" and "19" and knows how to display them as you expect). so, again, what's in the calculator's memory isn't the number you expect and you get odd results.

posted by andrew cooke at 10:59 AM on March 28, 2004

12345678901234567890 might be stored as 1.23456 * 10^19 (the calculator stores the digits "123456" and "19" and knows how to display them as you expect). so, again, what's in the calculator's memory isn't the number you expect and you get odd results.

posted by andrew cooke at 10:59 AM on March 28, 2004

*in that case the calculator would need to know how to calculate the logairthm from a number (log(...)) and get a number back from a logarithm (invlog(...)). there are ways to do this*

To expand on andrew cooke's answer: most of the elementary functions (exp(x), log(x), sin(x), etc...) have Taylor series expansions that provide good approximations with a small number of terms--at least few enough that the calculator can add them up before you notice a big delay.

Many other functions have Taylor series expansions that do not converge quickly enough to evaluate a function in a split second. However, more often than not, there will be

*some*series expansion (perhaps not Taylor) that will work. For example, one can approximate a factorial by writing it in terms of the Euler Gamma function, which can be rapidly approximated by the Lanczos approximation.

posted by Galvatron at 12:11 PM on March 28, 2004

For the TI-83, I forget which one, but they can't

posted by jmd82 at 12:23 PM on March 28, 2004

**actually**perform all of the four basic functions. Something like they multiply by actually adding the number each time or something like that which can lead to very very exact numbers being off. Also, I know for integration and derivatin, calculators don't actually know how to perform them, but simply use algorithms of some of the 4 basic functions.posted by jmd82 at 12:23 PM on March 28, 2004

Taylor series expansions are computationally expensive. Handheld calculators more commonly use an algorithm called CORDIC. It computes sin, arcsin, ln, etc... with only addition, shifting and table lookup. I think it's a beautiful example of engineering and a fascinating example of something that is fundamental to many of our daily lives yet goes completely ignored.

posted by stuart_s at 2:50 PM on March 28, 2004

*Elementary Functions and Calculators*, Richard Parris (PDF)posted by stuart_s at 2:50 PM on March 28, 2004

Well, OK, if we're going to get all

But Taylor series are a whole lot easier to talk about, and they can be fast if you have the capability to table coefficients for multiple expansion points.

Good link regarding CORDIC, btw.

posted by Galvatron at 5:51 PM on March 28, 2004

*serious*, then Chebyshev series (which can be related to the Taylor expansion) are used a lot, as well as various types of rational approximations. The ideal algorithm to use in a given situation depends not only on the overall convergence rate, but also on the speed of various operations within the processor. (Yeah, CORDIC is real good if you have a processor that doesn't know how to multiply fast, like many pocket calculators. If you have a fast multiply operation available, polynomial approximations are usually better.)But Taylor series are a whole lot easier to talk about, and they can be fast if you have the capability to table coefficients for multiple expansion points.

Good link regarding CORDIC, btw.

posted by Galvatron at 5:51 PM on March 28, 2004

This thread is closed to new comments.

log(x^y) = y * log(x), so x^y = invlog(y * log(x))

in that case the calculator would need to know how to calculate the logairthm from a number (log(...)) and get a number back from a logarithm (invlog(...)). there are ways to do this (i think it's what babbage was trying to do, in a way, with his mechanical computers).

your other point, about small differences, is because calculators can't store some fractions that you can write down easily in decimal as binary. for example 1/2 is 0.5 in decimal and 0.1 in binary, but 9/10, which is 0.9 in decimal, is something like 0.1110011... (it keeps going for ever, just like 1/3 is 0.33333.... in decimal).

so some numbers aren't stored exactly in a calculator and this lets errors creep in. different calculators handle this in different ways. some display less digits than they have information for, so a very small number would be displayed as 0. that's probably what is happening in your case (either that or it uses slightly different algorithms which, in that particular example, didn't give an error - perhaps because two errors cancelled each other out!)

posted by andrew cooke at 10:48 AM on March 28, 2004