[Date Index]
[Thread Index]
[Author Index]
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,
>>
>
Prev by Date:
**Re: Superscript Problem**
Next by Date:
**Re: Superscript Problem**
Previous by thread:
** Re: //N bug, but WHY?**
Next by thread:
** ListDensityPlot Legend?**
| |