Mathematica 9 is now available
Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2010

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: locating overlow/underflow (and the issue of accuracy)

  • To: mathgroup at smc.vnet.net
  • Subject: [mg112293] Re: locating overlow/underflow (and the issue of accuracy)
  • From: Daniel Lichtblau <danl at wolfram.com>
  • Date: Wed, 8 Sep 2010 00:58:08 -0400 (EDT)

Leslaw Bieniasz wrote:
> Hi,
> 
> 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.
> 
> Leslaw

You were using SetPrecision[whatever,n], if I recall correctly. That 
will not guarantee n digits for numerical evaluation of whatever. it 
will simply plug in 70 digits apprximations to inputs, and evaluate from 
there (so precision may be lost).

N[whatever,70] will indeed ratchet precision internally, subject to 
limitations imposed by $MaxExtraDigits and internals of N[]. For most 
numerics it gives a reliable result. That said, tere may be some special 
functions for which reliable methods (that is methods that can be 
certified to produce the requested number of correct digits) are not 
known. I think this can happen in some MeijerG numeric evaluations.

To validate results, it is generally safe to use N again to several more 
places (say, 1.1*n) and check for agreement up to n digits. Note that I 
do not claim this to be foolproof, only that it almsot always works as 
advertised (that is, provides a correct yes/no to the question of 
whether you have attained your desired precision). I think it would 
require luck in addition to a great deal of care to construct a 
counterexample where this incorrectly "certifies" a bogus result. And it 
may be lack of imagination on my part, but I do not foresee any 
situation wherein a correct result might be declared wrong using this 
sort of oracle.

by the way, from documentation for N:
"N[e,p] works adaptively using arbitrary-precision numbers when p is not 
MachinePrecision". While I would not expect every Mathematica user to 
know this, I would expect someone to check this documentation in some 
detail before writing the last part of the note above.

Daniel Lichtblau
Wolfram Research


> On Tue, 7 Sep 2010, Bill Rowe wrote:
> 
>> On 9/6/10 at 6:36 AM, nbbienia at cyf-kr.edu.pl (Leslaw Bieniasz) wrote:
>>
>>> Thanks for your comments. I have reduced the range of y, and I am
>>> now obtaining results without any error messages. However, this
>>> exercise raises my doubts whether the desired "arbitrary precision"
>>> is indeed reached, especially when y approaches 100. The program
>>> output yields infinity for the number of valid significant digits,
>>> but how many digits can I really trust if I declare 70 digits?
>>> Shouldn't the output contain warnings if the number of valid digits
>>> is smaller than 70? I don't perhaps need as many as 70, something
>>> like 30 would be enough, but I need to be sure that I really have
>>> that accuracy. I don't know how all that works, but I can imagine
>>> MATHEMATICA should automatically allocate appropriately more bytes
>>> to the floating point representations used, if the current number of
>>> bytes is insufficient. There are algorithms that can do that, I
>>> believe, like interval arithmetics? How can I check whether the
>>> accuracy is indeed as I want it to be?
>> You are conflating two separate issues. Your comments above
>> center on arbitrary precision. But the issue you are having is
>> related to underflow/overflow. There are limits to how
>> large/small of a number can be represented in Mathematica's
>> arbitrary precision format. Specifically, these are given by
>> $MinNumber and $MaxNumber. On my system, I get
>>
>> In[1]:= Log[10, $MaxNumber]
>>
>> Out[1]= 3.232284580911158146609071*10^8
>>
>> In[2]:= Log[10, $MinNumber]
>>
>> Out[2]= -3.232284580911158146609071*10^8
>>
>> In[3]:= Log[10, Erfc[10^4]] // N
>>
>> Out[3]= -4.34295*10^7
>>
>> That is long before you get to a value of 5 10^19 for y,
>> Erfc[Sqrt[y]] is outside the range of values that can be
>> represented in Mathematica's arbitrary precision format.
>>
>> It might be possible to obtain the number of accurate digits you
>> want. But this cannot be done using a simplistic approach with
>> Mathematica's built-in functions such as N due to the
>> limitations of what can be represented.
>>
>> Note, I am not saying Mathematica cannot be used to obtain what
>> you want. Since Mathematica can be seen as a general purpose
>> programming language, any mathematical problem that can be
>> solved on your system can be solved with the tools available in
>> Mathematica. But to obtain accurate digits for values that lie
>> outside the range of $MinNumber to $MaxNumber means you will
>> need to write your own code in Mathematica to deal with such
>> large/small numbers. Moreover, since you are using functions
>> like Erfc, you will need to write code to replace these as well.
>> This is clearly not a simple thing to do. It will not be easy to
>> do even if you use something other than Mathematica.
> 
> 
> 



  • Prev by Date: Re: SelectionMove[nb,Next,?Group?]
  • Next by Date: Re: How to delay action of ...[[i]] (Part[...,i])
  • Previous by thread: Re: locating overlow/underflow (and the issue of accuracy)
  • Next by thread: Re: locating overlow/underflow (and the issue of accuracy)