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