Re: //N bug, but WHY?

*To*: mathgroup at smc.vnet.net*Subject*: [mg58681] Re: //N bug, but WHY?*From*: "Carl K. Woll" <carlw at u.washington.edu>*Date*: Thu, 14 Jul 2005 02:49:06 -0400 (EDT)*Organization*: University of Washington*References*: <data3n$mec$1@smc.vnet.net> <db030a$r7o$1@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

dh, I don't think the help for N[] is partly wrong, as I try to explain below. "dh" <dh at metrohm.ch> wrote in message news:db030a$r7o$1 at smc.vnet.net... > Hi, > your expression consists of a sum with 2 terms that have opposite signs > and nearly the same magnitude. The absolute value is of the order of > 10^41 and the difference 10^-41. Therefore, if you calculate with > machine precision= 16 digits, this is doomed to fail. > > On the other hand, the help for N[] is partly wrong. > Consider the help: > "N[expr] is equivalent to N[expr, MachinePrecision]" Here it is important to note that MachinePrecision is not 16. From the help we have "The numerical value of MachinePrecision is $MachinePrecision." So, In[1]:= $MachinePrecision Out[1]= 15.9546 Or even: In[2]:= N[MachinePrecision] Out[2]= 15.9546 > a=10^16+1; b=10^16; > N[a-b] gives 1. because the argument of N is evaluated with infinite > precision before N sees it. Since N does not have any Hold attributes, like any such function it evaluates its arguments before doing anything else. > We can prevent this by wrapping a and b in a > function that can not be evaluated with infinite precision: > a=Sqrt[10^16+1]; b=Sqrt[10^16]; > N[a-b] gives 0. because 10^16+1 is now evaluated with machine precision > giving 10^16. As the help says, "N converts each successive argument of any function it encounters to numerical form, unless the head of the function has an attribute such as NHoldAll." This explains the behavior you observed. > On the other hand, > N[a-b,16] gives 5.00.. 10^-9, here it seems that the intermediate > calulations are done with higher precision, exactly what the help says. > Even > N[a-b,1] gives 5. 10^-9 > You seem to be assuming that N[a-b,16] is equivalent to N[a-b], but as I pointed out above, that is incorrect. N[a-b,16] essentially converts all numbers to extended precision numbers in order to achieve a result of at least 16 digits of precision. It does not convert numbers to machine precision numbers. > In short: > N[expr] does all calculation in machine precision, whereas > N[expr,number] does all intermediate calculation with high enough (up to > an upper Limit of "$MaxExtraPrecision") precision to garantee a result > precision of "number" > I believe this is a reasonable paraphrase of the help. Carl Woll Wolfram Research > sincerely, Daniel > > > symbio wrote: >> Evaluating (using //N) two exact same expressions, gives wrong answer >> unless >> fullsimplify is used first, I spent 2 days on a problem thinking my >> answer >> was wrong, but turned out Mathematica 5 was giving me buggy answers, I >> debugged it to this point, but WHY in the world is this happening? >> Please >> help!!! >> >> cut and paste below to see the test case: >> >> In[243]:= >> \!\(\(Cosh[\(43\ \[Pi]\)\/\@2] + \((1 - Cosh[43\ \@2\ \[Pi]])\)\ Csch[ >> 43\ \@2\ \[Pi]]\ Sinh[\(43\ \[Pi]\)\/\@2] // FullSimplify\) >> // >> N\[IndentingNewLine] >> Cosh[\(43\ \[Pi]\)\/\@2] + \((1 - Cosh[43\ \@2\ \[Pi]])\)\ Csch[ >> 43\ \@2\ \[Pi]]\ Sinh[\(43\ \[Pi]\)\/\@2] // N\) >> Out[243]= >> \!\(6.551787517854307`*^-42\) >> Out[244]= >> \!\(\(-1.9342813113834067`*^25\)\) >> >> >> >> thanks, >> >

**Re: Superscript Problem**

**Re: Superscript Problem**

**Re: //N bug, but WHY?**

**ListDensityPlot Legend?**