Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2005
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2005

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

Search the Archive

Re: //N bug, but WHY?

  • To: mathgroup at smc.vnet.net
  • Subject: [mg58659] Re: //N bug, but WHY?
  • From: dh <dh at metrohm.ch>
  • Date: Tue, 12 Jul 2005 05:21:42 -0400 (EDT)
  • References: <data3n$mec$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

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]"
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. 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.
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

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"

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: Fw: Re: Set of strings reducing problem
  • Next by Date: Fw: Re: Set of strings reducing problem
  • Previous by thread: Re: //N bug, but WHY?
  • Next by thread: Re: //N bug, but WHY?