Services & Resources / Wolfram Forums
MathGroup Archive
*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
  • Subject: [mg58651] Re: //N bug, but WHY?
  • From: Bill Rowe <readnewsciv at>
  • Date: Tue, 12 Jul 2005 05:21:34 -0400 (EDT)
  • Sender: owner-wri-mathgroup at

On 7/11/05 at 4:19 AM, symbio at (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

N[{Cosh[(43*Pi)/Sqrt[2]], (1 - Cosh[43*Sqrt[2]*Pi])*
    Csch[43*Sqrt[2]*Pi]* Sinh[(43*Pi)/Sqrt[2]]}]
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

  • Prev by Date: Re: FrameTicks bug (SUMMARY)
  • Next by Date: Re: //N bug, but WHY?
  • Previous by thread: Re: //N bug, but WHY?
  • Next by thread: Re: //N bug, but WHY?