There are certain problems with which all non-linear estimation techniques in RATS (and other software) must deal. One difficulty is that, on a computer, floating point numbers are represented only approximately. Most systems running RATS show fourteen to fifteen significant digits. This does not mean, however, that you can get answers from estimation problems correct to fourteen digits. Intermediate calculations can often push the significance limit long before that. For instance, \(f(x)=50+(x-1)^2\) will give identical values for \(x=1\) and \(x=1.00000001\). Because the computer can’t distinguish between the function value for these two (or anything in between), we can’t get greater accuracy than eight digits in minimizing \(f\).

 

A related problem is that floating point numbers have a huge, but limited, range, typically with around \(10^{300}\) as the largest number and \(10^{-300}\) as the smallest positive number. This can cause problems if a calculation is done in such a way that intermediate calculations overflow the range. If, for instance, you attempt to calculate the binomial coefficient \(\left( {\begin{array}{*{20}c}{200}  \\ {100}  \\\end{array}} \right)\) using %FACTORIAL(200)/%FACTORIAL(100)^2, RATS will produce a missing value, as %FACTORIAL(200) overflows. As these difficulties typically arise where a logarithm of the big number is needed, the way to work around this is to make sure you take logs early on and add or subtract them as needed, rather than risking overflow by multiplying and dividing huge numbers. Here the log of the binomial coefficient can be computed by %LNGAMMA(201)-2.0*%LNGAMMA(101). For normal densities, use %LOGDENSITY rather than %DENSITY if you’ll eventually be taking logs anyway.

 

Copyright © 2025 Thomas A. Doan