>>>I realized the calculation must be done using character strings instead of numbers. I found the code on Tek-Tips, which gives the correct result:
>>
>>Looks like something I did back in the 80s (when I was trying to calculate e to 600 digits). It's OK as a method, except the speed. My method was to chop it into smaller pieces and stuff them into an array, 6 digits at a time, although with IEEE number I can probably even do multiplication with 7 without overflow. So I'd do an operation on a pair of elements of two arrays and stuff into the corresponding element of the third array, take the carry to the next element and so on. The end result was converted back into a string. Used to be reasonably fast even on a Spectrum with a 1.7MHz z80.
>
>Done that too, years ago. A class with an auto expanding array. And yes, you can safely keep 7 digits per array element (multiplication yields 14 digits)
>8 digits is not safe.
>
>Even started trig functions using CORDIC ( http://en.wikipedia.org/wiki/CORDIC#Software_implementation )
>
>But, never finished it

Speaking of math with extended precision... UBASIC was (and still is) a rather nifty implementation of the BASIC language with a number of mathematical goodies that make it rather useful for math-oriented problems.
http://en.wikipedia.org/wiki/UBASIC