Arbitrary Precision Floating Point (APFP)
by Dennis Darland  pal at dennisdarland dot com
dennisdarland.com
Comments welcome
 Initially developed as procedures in Icon then reworked as classes & overloaded operators in Unicon.

Reworked much more elegantly in Ruby. Mostly because of greatly increased
knowledge of problem from having done it before. Also conciseness of Ruby.
 2/3/2010 Start development of regression test for APFP (Ruby program to generate a Ruby Program to generate a Maple Program
to compare answers.
 2/5/2010 Test program for APFP almost finished.
 2/6/2010 Test program basically finished  tests ran OK on sin, cos and tan.
 2/7/2010 Tested all functions  fixed some problems  log, log10 and sqrt not as accurate as desired.
sinh and tanh also had one problem.
 2/8/2010 Enhanced information in Exception file and added time info. Maple took about 16 minutes clock time  but I didn't find a function for that.
 2/13/2010 Struggling with how to compute logarithms  I see what is wrong  but not how to fix it.
 2/13/2010 Fixed problems with logarithms and other less difficult problems. Links to programs and results below.
Maple produces results almost immediately if screen output is suppressed by using ":" instead of ";"
 2/15/2010 Correction to calculation of percentage
 Samples:
The Ruby Program to generate a Ruby program to generate a Maple test program
The generated Ruby program to generate a Maple test program
The generated Maple test program
Test Results  Just all functions
Test Results EXCEPTIONS  all functions
Ap.rb
ApConfig.rb
Apc.rb
Apfp.rb
Real.rb

NOTE about purpose of Apfp. I am trying to write an arbitrary precision floating point with a capability of
tracking the possible error in values calculated from possible error in input or through rounding error. It is very slow,
but its purpose is not speed. It is mainly an experiment to see how errors may propagate in calculations. In fact, in the
tests above I am calculating to only 16 digits. But in practical applications I doubt if inputs are often known to this
accuracy. Larger input errors can be specified as +/error in literals. I think some improvements in both speed and accuracy
are still possible  but it will never be very fast.
 Worked on Documentation: (via simple sample program)
Sample program with comments
Results are in: (I haven't checked all of them closely  I did check the comparison operators and made some improvements
The tests above were also updated.
Results from sample program.
Generated rdoc files (documentation)
 Sourceforge Project Apfp page APFP PAGE

Dennis J. Darland