PPC Maximumx are as follows for double precision.

Maximum Decimal digits 15-16
Maximum positive 1.8 x 10^308
Maximum positive norm 2.2 x 10^-308
Maximum negative norm -2.2 x 10^-308
Maximum negative -1.8 x 10^308


The actual number displayed (and to some extent rounding) is 
determined by a global called gFBMaxFloatDigits. In public release 3, 
this is not fully "tuned". but in the next release, we have pretty 
well nailed it down. Note that increasing the number of digits past 
16 has no effect. The math package does not have the horsepower to 
support that many digits. Going past 12 is not of great value either 
since the trailing decimal digits are seldom accurate. This of course 
would not be true of large whole numbers since fractions do not come 
into play.

As previously noted, decimal calculations are notoriously inaccurate 
in modern math packages. Any decimal must be assumed to be the 
nearest neighbor of 1/2 + 1/4 + 1/8 + 1/16, etc. FB does (IMHO) an 
excellent job of translating math package values into expected 
values. True answers returned from the math package can be things 
like NAN (not a number) and INF (infinity). Otherwise, you could 
never get a correct answer to things like the following...

To show this error, you have to use single precision because double 
precision is too accurate to display the PPC math package error. The 
example code is this:

dim x!,y!
dim z!
print "All answers should be 1"
for z! = 1 to 21
x! = 1\z!
y! = (z!-1)\z!
print  z!")";x! " +" y! " =",x! + y!
next


All answers should be 1
  1) 1 + 0                      =  1
  2) 0.5 + 0.5                  =  1
  3) 0.333333313 + 0.666666626  =  0.99999994
  4) 0.25 + 0.75                =  1
  5) 0.199999988 + 0.799999952  =  0.99999994
  6) 0.166666656 + 0.833333313  =  0.99999997
  7) 0.142857134 + 0.857142806  =  0.99999994
  8) 0.125 + 0.875              =  1
  9) 0.111111104 + 0.888888835  =  0.99999994
  10) 0.099999994 + 0.899999976 =  0.99999997
  11) 0.090909086 + 0.909090876 =  0.999999962
  12) 0.083333328 + 0.916666626 =  0.999999955
  13) 0.076923072 + 0.923076868 =  0.99999994
  14) 0.071428567 + 0.928571403 =  0.99999997
  15) 0.066666662 + 0.933333277 =  0.99999994
  16) 0.0625 + 0.9375           =  1
  17) 0.058823525 + 0.941176414 =  0.99999994
  18) 0.055555552 + 0.944444418 =  0.99999997
  19) 0.052631575 + 0.947368383 =  0.999999959
  20) 0.049999997 + 0.949999988 =  0.999999985
  21) 0.047619044 + 0.952380895 =  0.99999994

It actually took a lot of fancy footwork to bypass all of FB's 
built-in handlers and show this error. If you print the calculation, 
PRINT (1\z!)+((z!-1)\z!), you get the expected 1 as an answer every 
time. (Score one for the good guys!)

Package errors like this are the reason that the real math-heads use 
our supplied ERF# and ERFC# functions. But only people born with a 
calculator in their diapers really understand what such functions do. 
:)



Best,

-STAZ  ~)~

800.348.2623 Orders  http://www.stazsoftware.com
228.255.7086 FAX     mailto:staz@...