I haven't looked at your alg document, but there are some pretty GNU open source multiple precision codes in C available that have already been tested to some very significant extent. What might be more interesting would be a high-quality implementation of Gosper's arbitrary precision continued fraction algorithms which return -- not a number -- but a number 'pump'. You pump the handle & another set of digits comes out. If this were integrated with Maxima, it would be pretty cool. At 02:45 PM 4/7/2011, quad wrote:
Hello all!
Many months ago, maybe even a couple years ago (I lost count), I wrote a high precision floating point arithmetic library in C. Here's a sample demo of it:
WINDOWS: http://dl.dropbox.com/u/734346/rpn.exe [open a command prompt, cd to the right directory, then type "rpn" to see the options]
LINUX (32-bit): http://dl.dropbox.com/u/734346/rpn [should work on 64-bit]
The LINUX executable might run on OS X. In fact, I'd like to know if it does, if any one could test it!
I can assure you it's safe. It was written in ANSI C by me in a very portable fashion. No file writing, no system calls, etc. If you think it's dodgy, then feel free to disassemble it or something.
It's an RPN calculator. Basic usage is along the lines of
$ ./rpn -p1000 1 tta 4 x
which does 4*atan(1) (tta = trig tan arc; x = multiply) to 1000 digits.
Anyway, you don't need to run it, and it's not the point of this email. The algorithms I use are here:
http://www.symbo1ics.com/files/algs.pdf [Section 3]
Any corrections would be helpful.
Anyway, I'm looking:
1. to include more algorithms that are known to work well for computing special functions and whatever to high precision. 2. to include improvements to what I have at the moment, algorithmically. Is the way I compute sine slow? Are there faster ways? 3. for criticism on the way I represent big floats. I don't know if there is a better way to express arbitrary precision floats than what I have. I prefer *not* to go the "do everything with rationals then divide" because that's memory intensive and has a good amount of overhead. Of course some algorithms work best by using rationals, but I don't want to use rationals entirely across all algorithms.
Mostly I'd like to improve what I have, but also document things I don't yet have, like Gosper's theta function products, and whatever.
Thanks all!
Robert