MathGroup Archive 2007

[Date Index] [Thread Index] [Author Index]

Search the Archive

NIntegrate preprocessing and rule selection

  • To: mathgroup at smc.vnet.net
  • Subject: [mg81098] NIntegrate preprocessing and rule selection
  • From: "Andrew Moylan" <andrew.j.moylan at gmail.com>
  • Date: Wed, 12 Sep 2007 03:48:29 -0400 (EDT)

Here's an integrand that is highly oscillatory for large values of its first
argument:

f[w_, x_] = Sin[w*x]/(x^2);

For small w, NIntegrate automatically selects GaussKronrodRule as usual:

Reap[NIntegrate[f[1, x], {x, 1, 2}, EvaluationMonitor :> Sow[x]]]

For large w, NIntegrate's preprocessor decides the integrand is highly
oscillatory and uses its specialised Clenshaw-Curtis rule for oscillatory
integrands:

Reap[NIntegrate[f[10, x], {x, 1, 2}, EvaluationMonitor :> Sow[x]]]

(One way to tell that the specialised rule was used is to notice that the
endpoints (1. and 2.) were sampled.)

Now consider this example:

Reap[NIntegrate[f[1, x], {x, 1, 2}, Method -> "ClenshawCurtisRule", 
     EvaluationMonitor :> Sow[x]]]

As expected, NIntegrate's preprocessor does not decide to use the
specialised Clenshaw-Curtis rule (because w is too low to be called "highly
oscillatory"). However, the integration then apparently proceeds using
GaussKronrodRule rather than the requested ClenshawCurtisRule. Why is this?

One way to get around this for particular cases where you know it is going
to happen is to use the option "SymbolicProcessing"->0. But what should we
do if we *do* want symbolic processing, but want ClenshawCurtisRule to be
used (instead of GaussKronrodRule) in those cases to which none of
NIntegrate's specialised rules apply?



  • Prev by Date: Re: design question, how to have a set of manipulate controls, but have separate expression associated with each control?
  • Next by Date: Re: Slow Show/Graphics in v6.0
  • Previous by thread: Re: framed plots with two y axes scales
  • Next by thread: Re: NIntegrate preprocessing and rule selection