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

Evaluation of NSum arguments

  • To: mathgroup at smc.vnet.net
  • Subject: [mg53318] Evaluation of NSum arguments
  • From: Maxim <ab_def at prontomail.com>
  • Date: Thu, 6 Jan 2005 02:51:51 -0500 (EST)
  • Sender: owner-wri-mathgroup at wolfram.com

In version 5.1, NSum seems to lock up at the stage of symbolically  
preprocessing the summand in this example:

NSum[(HarmonicNumber[1/2 - k] + HarmonicNumber[-3/2 + k] + Log[16])/2^k,
   {k, 2, Infinity}]

NSum keeps running after 10 minutes (and EvaluationMonitor won't print  
anything). Strangely, multiplying the summand by 1.0 doesn't make any  
difference, but replacing Log[16] with Log[16.] fixes the problem.

In general, it's supposed to be a good idea to symbolically evaluate the  
argument of a function which performs repeated numerical evaluations.  
First, it's needed in order for the expression to be compiled: if we define

f[k_] = Sum[i, {i, k}]
g[k_?NumericQ] := Sum[i, {i, k}]

then g cannot be effectively compiled (roughly speaking, the compiled code  
will be just one external call) and for a large number of terms the speed  
difference between Compile[{k}, f[k]] and Compile[{k}, g[k]] will be  
significant. Next, of the two definitions

f[k_] = NIntegrate[Sin[k*x], {x, 0, k}]
g[k_?NumericQ] := NIntegrate[Sin[k*x], {x, 0, k}]

the f[k] definition may be preferable to g[k] because the evaluation of  
g'[k] using finite differences takes several (can be as many as 17)  
evaluations of g and therefore several calls to NIntegrate. On the other  
hand, f' is evaluated symbolically and then computing the derivative  
requires only one call to NIntegrate (and probably the result will be more  
precise too). These considerations are mentioned in the Advanced  
Documentation on the topic of unconstrained optimization.

However, in practice that doesn't seem to work so smoothly; the symbolic  
preprocessing often fails if the summand contains NIntegrate:

NSum[
   NIntegrate[(MeijerG[{{0, 1}, {}}, {{1/2}, {}}, x] - Sqrt[Pi])/x,
     {x, k, k + 1}],
   {k, Infinity}]

generates Infinity::indet messages and returns unevaluated. Besides, the  
case of NIntegrate containing lists of options is handled incorrectly:

NSum[
   NIntegrate[E^-x, {x, Log[k], Log[k + 1]},
     {Method -> GaussKronrod}],
   {k, Infinity}]

generates NIntegrate::vars and NSum::nsnum messages saying that  
NIntegrate[E^-Log[k + 1], {Method -> GaussKronrod}] isn't numerical -- for  
some reason it loses the iterator {x, Log[k], Log[k + 1]}. Curiously,  
everything works correctly if {x, Log[k], Log[k + 1]} is replaced with {x,  
k, k + 1}. So in all the NSum examples shown above we have to define the  
summand using f[k_?NumericQ]:=... only to emulate the behaviour of  
Mathematica 4.0, thus getting no benefits from the changes made in version  
5.0. Incidentally,

NIntegrate[Sin[k*x]/x, {x, 0, Infinity}, Method -> Oscillatory]

already gives an invalid output containing some internal variables -- it's  
impossible to substitute numerical values for k in the output to obtain a  
numerical result.

Maxim Rytin
m.r at inbox.ru


  • Prev by Date: Re: Partial evaulation of function terms
  • Next by Date: global assumptions?? How far can I go?
  • Previous by thread: Re: Re: precission/accuracy in mathlink for excel
  • Next by thread: global assumptions?? How far can I go?