Re: //N bug, but WHY?
- To: mathgroup at smc.vnet.net
- Subject: [mg58651] Re: //N bug, but WHY?
- From: Bill Rowe <readnewsciv at earthlink.net>
- Date: Tue, 12 Jul 2005 05:21:34 -0400 (EDT)
- Sender: owner-wri-mathgroup at wolfram.com
On 7/11/05 at 4:19 AM, symbio at has.com (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?
When you use //N on an expression transformed by FullSimplify, you are not evaluating the identical expression. This is important since in a more complex expression you can get loss of precision as each portion of the expression is converted to machine precision.
In your particular case, consider
In[9]:=
N[{Cosh[(43*Pi)/Sqrt[2]], (1 - Cosh[43*Sqrt[2]*Pi])*
Csch[43*Sqrt[2]*Pi]* Sinh[(43*Pi)/Sqrt[2]]}]
Out[9]=
{1.526301024376754*^41,
-1.5263010243767541*^41}
As you can see, the original expression is summing two nearly equal things with opposite sign. This leads to loss of precision whenever it occurs. By using FullSimplify, you are transforming the expression to a form where this doesn't occur. As a result, you get a more accurate answer.
This really isn't a bug in N. It is just the nature of using finite precision.
--
To reply via email subtract one hundred and four