MathGroup Archive 2007

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

Search the Archive

NIntegrate preprocessing and rule selection

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

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

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

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