Mathematica 9 is now available
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: [mg58675] Re: //N bug, but WHY?
  • From: Peter Pein <petsie at dordos.net>
  • Date: Thu, 14 Jul 2005 02:49:00 -0400 (EDT)
  • References: <data3n$mec$1@smc.vnet.net> <db030a$r7o$1@smc.vnet.net> <db2g59$din$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

Richard Fateman schrieb:
> ....
> 
>>symbio wrote:
>>
>>
>>>Evaluating (using //N) two exact same expressions, gives wrong answer unless 
>>
>>...
> 
> 
> The same question was asked the previous day, and answered, in sci.math.symbolic.
> Symbio knows about email enough to provide a bogus return address, but
> doesn't know much about numerical computation, and is unwilling to learn.
> So he or she asks and asks. At least Symbio found the mathematica newsgroup.
> 
> It occurs to me that the right answer, for someone like Symbio
> who really doesn't want to
> be burdened by any computational knowledge, is simple:
> 
> Never EVER use N[...],
> but always N[...,<somenumber>], and hope for the best.
> 
> 
> In Symbio's case he or she should just replace the
> the locution  ......//N
> 
> with the locution
>                .....//N[#,16]&
> 
> 
> and Symbio's answer comes out "right".   No need for FullSimplify etc etc.
> 
> So in this regard, there is a "bug" and it even has a "fix".
> 
> More significantly, and the reason I bother to write again, is
> the following advice.
> (at least if you believe in the validity of the Mathematica
> software-float numerics).
> 
> Suggestion to WRI:
> 
> Change the meaning of  N  to N[#,16]&  and alter N so that
> the only time the current N[] is used is by explicit
> demand, e.g.  N[...., DoItFasterAndMaybeWrongUsingMachineArithmetic]
> 
> 
> Regards
> RJF
> 
I tried it this way:

Unprotect[N];

N /: Options[N] = Union[Evaluate[Options[N]], {QuickAndDirty -> False}];

HoldPattern[N[x_, opt:(o_ -> v_)..]] :=
  If[(QuickAndDirty /. {opt}) == True,
    N[x, MachinePrecision, (* NOT $MachinePrecision! *)
      Sequence @@ DeleteCases[{opt}, QuickAndDirty -> True]],
    N[x]];

HoldPattern[N[x_]] := N[x, $MachinePrecision];

N::usage = "N[expr] gives the numerical value of expr.\
 N[expr, n] attempts to give a result with n-digit precision.\
 N[expr,QuickAndDirty->True] will most likely ignore problems\
 arising from a poorly conditioned expr.";

QuickAndDirty::usage = "QuickAndDirty is a boolean option for N.\
 If set to True, N will not recognize ill conditioned expressions";

Protect[N];


In[8]:= expr = Cosh[(43*Pi)/Sqrt[2]] +
 (1 - Cosh[43*Sqrt[2]*Pi])*Csch[43*Sqrt[2]*Pi]*Sinh[(43*Pi)/Sqrt[2]];

In[9]:=N[expr, QuickAndDirty -> True]

Out[9]=-1.9342813113834067*^25

In[10]:=N[expr]

From In[10]:=
 N::meprec: Internal precision limit $MaxExtraPrecision =
49.99999999999999` reached while evaluating Cosh[(43*Pi)/Sqrt[2]] + (1 -
Cosh[43*Sqrt[2]*Pi])*Csch[43*Sqrt[2]*Pi]*Sinh[(43*Pi)/Sqrt[2]]. More...

Out[10]=
0``21.45463265565461

so we see at least, that something has gone wrong.

In[11]:= Block[{$MaxExtraPrecision = 86}, N[expr]]

Out[11]= 6.551787517854344014050058`15.954589770191*^-42

-- 
Peter Pein
Berlin
http://people.freenet.de/Peter_Berlin/


  • Prev by Date: Light and surface colors
  • Next by Date: Re: Superscript Problem
  • Previous by thread: Re: //N bug, but WHY?
  • Next by thread: Re: //N bug, but WHY?