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