4

I'm reading a paper right now which criticizes a method because it uses trapezoid rule, rather than "more advanced quadrature rules like the Gauss quadrature"...

The Gaussian quadrature rule requires, given $N$, the calculation of a bunch of weights and nodes. After these weights and nodes are known, the integral can be calculated as a simple sum $\sum w_i f(x_i)$.

Okay.

But on standing foot, nobody knows what $w_i$ and $x_i$ are. They need to be calculated. That takes time.

On the other hand, you can straight away apply the trapezoid rule. If you use a uniform grid, you can calculate the nodes and weights in no time, and so the only real computational expense is to actually evaluate the sum.

So what am I missing here? Why is there even a debate here? Wouldn't we always prefer trapezoid rule since the weights and nodes are easier to calculate?

To give an example, in R, I can compute the nodes and weights needed for $N$-point Gaussian quadrature using the function gauss.quad. With $n = 2^{12} = 4096$, gauss.quad(4096) takes about a full second on my computer to compute.

In comparison, if we want to compute the evaluation points needed for trapezoid rule on a uniform grid, it takes 0.01 milliseconds!!.

So what am I missing? What's the big deal about "advanced quadrature rules" when trapezoid rule is only sliiiightly less accurate and a million times faster?

Anton Menshov
  • 8,672
  • 7
  • 38
  • 94
Vazuoeow
  • 51
  • 2
  • Let me reverse your question: why should we ever care about the trapezoid rule, when it takes just one second to get something more accurate? – Orntt Feb 10 '20 at 00:43

4 Answers4

7

How accurate do you want the answer ?

How costly is evaluating your function ? If it is costly, then you dont want to use a rule with too many nodes.

How many times do you want to do the quadrature ? If it has to be repeated many times, like in finite element methods, the cost of computing weights/nodes of gauss rule will not matter much since it has to be done only once, and the higher accuracy will pay off.

Based on these questions, use whichever method is faster for your particular application.

In terms of accuracy vs cost, trapezoidal method is best for periodic functions. For other types of functions, gauss rules are expected to be better, excluding the cost of computing weights/nodes.

cfdlab
  • 3,028
  • 13
  • 19
  • "gauss rules are expected to be better, excluding the cost of computing weights/nodes" .... riiiight, and why would you exclude the cost of that? You can say gauss-quad is more accurate, but then I can say that trapezoid is faster hence you can take MORE terms in the calculation and become more accurate. – Vazuoeow Feb 09 '20 at 12:58
  • 1
    As I already wrote in my answer, you can ignore cost of gauss weight/node computation if you are going to use it repeatedly. If your function evaluation is costly, then gauss rule can still win since it requires fewer nodes, and hence fewer function evaluations. – cfdlab Feb 09 '20 at 13:20
  • Oh, ok. So gaussian quadrature is only worth using when you need to use it 10.000 times in a row for the same choice of $N$. Gotcha. What an incredibly useful algorithm. – Vazuoeow Feb 09 '20 at 13:37
  • 6
    @Vazuoeow yes, it is extremely useful and powerful. For most practical problems, the cost of calculating the nodes & weights is negligible compared to other components. Moreover, the Gaussian quadrature calculation can be performed before that, once, and hardcoded. – Anton Menshov Feb 09 '20 at 15:54
  • 4
    @Vazuoeow This answer provides three upsides A, B, C. Your flippant comment "oh, then it is only worth using in case C?" does not seem too appropriate here. – Federico Poloni Feb 09 '20 at 16:15
  • 3
    @Vazuoeow -- it's a valid question to ask why some algorithm is widely used. It's rather dangerous to believe that everyone is mistaken in using a widely used algorithm :-) – Wolfgang Bangerth Feb 10 '20 at 21:50
4

Your principal assumption is wrong:

But on standing foot, nobody knows what wi and xi are. They need to be calculated. That takes time.

It's just not true that "nobody knows" what the weights and points are: They are tabulated and don't need to be computed any more. We also don't use 4096 points -- we subdivide the interval of integration into smaller intervals and then use Gauss quadrature with 4 or 6 or maybe 8 points -- for which you can look up the weights and locations in every numerical analysis textbook to 16 digits of accuracy. In other words, we use Gaussian integration in much the same way as we do the trapezoidal rule: On sub-intervals; it's just way more accurate!

Wolfgang Bangerth
  • 55,373
  • 59
  • 119
3

A typical use case is when you are fine with a fixed low number of nodes, for instance $n=4$ or $n=10$. In that case, you hardcode the weights in your code, and you get higher precision than the trapezoidal rule at basically no cost.

Federico Poloni
  • 11,344
  • 1
  • 31
  • 59
1

There is not enough information to determine if the criticism of the original paper is merited or not!

In general, approximations are useless unless we can obtain a reliable and accurate error estimate or an error bound which is not too large. Our ability to do just that is compromised when the integrand is not sufficiently smooth. The demands on the smoothness of the integrand are high for advanced quadrature and low for simple methods such as the trapezoidal rule. It is entirely possible that the original paper deals with functions that are not smooth enough to support the use of high order methods.

In practice, the accuracy of our a posteriori error estimates is compromised by rounding errors when we shrink the step-size. This is not really an issue for low order methods, but a significant issue for high order methods even when the integrand is infinitely differentiable.

On the other hand, it is entirely possible that the criticism is merited. In general, every function evaluation is vastly more time consuming than the small number of arithmetic operations required to find the quadrature nodes and compute the weights.

Carl Christian
  • 1,391
  • 11
  • 16