Re: locating overlow/underflow (and the issue of accuracy)
- To: mathgroup at smc.vnet.net
- Subject: [mg112327] Re: locating overlow/underflow (and the issue of accuracy)
- From: Bill Rowe <readnews at sbcglobal.net>
- Date: Thu, 9 Sep 2010 04:24:14 -0400 (EDT)
On 9/7/10 at 6:07 AM, nbbienia at cyf-kr.edu.pl (Leslaw Bieniasz) wrote: >Well, I am afraid you do not answer my question. Assuming that I >eliminated the underflow/overflow error messages by restricting down >the range of y, for which I tabulate my expression, what is the >accuracy of the results I obtain? Can I trust that it is 70 >significant digits? This is what I need to know in the first place. >If there are limitations of N in this respect, then how can I know >if the limitations enter into play? Does the fact that I don't get >error messages or warnings mean that there are no errors, or not? >Apart from that, I believe that the issues of accuracy and >maximum/minimum numbers are closely interrelated, since they both >depend on the floating point representation used. What I don't know >is whether this representation is adaptively chosen by Mathematica >in order to achieve a particular goal (accuracy), or it is fixed. In >the latter case, I would argue that the feature of "arbitrary >precision" is a fiction. I don't believe describing what is happening for the process of converting an exact expression to a representation with a large number of digits in Mathematica is accurately described as being a floating point representation issue. That is I strongly suspect, Mathematica's internal representation of values with precision greater than machine precision do not map into anything IEEE refers to as "floating point". For cases where an expression is exact and composed of elementary operations, I am confident doing N[expr, 70] returns 70 digits that can be trusted to be accurate. But this may well not be the case when the expression contains non-elementary functions such as Erfc. My understanding of what apply N accomplishes is first every number is converted to the specified precision + some additional guard digits (given by $MaxExtraPrecision). Next the expression is evaluated. And finally, the result is returned with the specified number of digits. For expressions with elementary operations only this should be adequate to ensure all of the requested digits are accurate. But, when non-elementary functions such as Erfc are included, there has to be an additional step of evaluating that function to the desired accuracy. Now achieving the desired number of digits is determined by details of the algorithm used to evaluate the non-elementary function as well as details of the arbitrary precision algorithms Mathematica uses. Most likely, Erfc is sufficiently common that the algorithm used by Mathematica to compute this is well understood, bug free and there is no reason not to trust all of the digits returned. But clearly, not all of the computations done by Mathematica are bug free. And, evaluation of some non-elementary functions likely entail fairly complex algorithms which have their own limitations. If you take "arbitrary precision" to imply you can ask for any number of accurate digits no matter how many, then yes, it is a fiction. There are always limitations. If nothing else, you have a finite amount of RAM and finite time you are willing to spend waiting for a result. Even if Mathematica or any software package is totally bug free, RAM and CPU time limit the number of accurate digits that can be obtained. But if you are reasonable about the number of digits you ask for and you are not pushing things to near the limits of what Mathematica can do with its representation of arbitrary precision values, then I believe it is safe to trust the digits you get. And in this case, "arbitrary precision" is not a fiction. Also, since I do not work for Wolfram, I do not have access to the source code for Mathematica. So, my comments reflect my current understanding of how Mathematica works and may not be entirely correct.