Riemann Sums are a way of estimating definite integrals and are taught early in Calculus I. This project visualizes and calculates these estimations in several different formats: Left Hand, Right Hand, Midpoint, and Trapezoidal. This was a way for me to supplement my Calculus AB class and I wanted to expand/share it. Since I wanted to explore the underlying formulas behind Riemann Sums, I did not use pre-built functions such as NIntegrate.

Developing Sum Algorithms

Each method of estimation has it's own algorithm which I implemented below

LRAM

LRAM’s, or Left Hand Riemann Sums, use the following algorithm to estimate area:
n
∑
i=1
f(
x
i
)Δx
where Δx =
(b-a)
n
with b being the end point, a being the starting point, and n being the number of divisions or estimations. This algorithm is shown below. A Left Hand Riemann Sum over an interval over the interval 0 to 5 for
f(x)=
2
x
with 5 intersections gives an area shown below
Implementation of LRAM algorithm shown above:
In[]:=
AreaLRAM[a_,b_,n_,f_]:=Module[{x1,y1,cord,deltax},​​deltax=(b-a)/n;​​x1=0;​​Table[x1+=(f[i]*deltax),{i,a,b-deltax,deltax}];​​Round[N[x1],0.001]]
Initializing variables:
In[]:=
a=0;​​b=5;​​f[x_]:=x^2;​​n=5;
Using the algorithm to find/compare estimated:
In[]:=
AreaEstimated=AreaLRAM[a,b,n,f];​​AreaActual=Integrate[x^2,{x,0,5}];​​PercentDiff=PercentForm@((AreaEstimated-AreaActual)/AreaActual)
Out[]//PercentForm=
-28%
This is a significant amount of error. Lets see what happens when we increase the amount of divisions to 40
Reinitializing n or number of divisions to 40:
In[]:=
n=40;​​AreaEstimated=AreaLRAM[a,b,n,f];​​AreaActual=Integrate[x^2,{x,0,5}];​​PercentDiff=PercentForm@((AreaEstimated-AreaActual)/AreaActual)
Out[]//PercentForm=
-3.719%
To understand why this works, it is easier to visualize it. The way I implemented this visualization was by generating the x coordinates of a rectangle using Δx and the y coordinates using f(
x
i
)
then riffle them together.
Implementing LRAM on a graph:
In[]:=
LRAM[a_,b_,n_, f_]:=Module[{x1,y1,cord,deltax},​​deltax=(b-a)/(n);​​x1 = Table[{i,f[i]},{i,a,b, deltax}];​​y1 = Table[{i+deltax,0},{i,a,b, deltax}];​​cord = Drop[Partition[Flatten[Riffle[x1,y1]],2],-2];​​Plot[f[x],{x,a,b},Prolog->{Orange,Table[{EdgeForm[Thick],Rectangle[cord[[z]],cord[[z+1]]] },{z,1, Length[cord]-1,2}]}, ImageSize->Large]​​]
Plotting Left Hand Sum on x^2 from 0 to 5:
LRAM[a,b,n,f]
Out[]=
1
2
3
4
5
5
10
15
20
25
Given this graph, its easy to see why LRAM underestimates the actual area. The rectangles consistently leave a space below the graph, leading to an underestimation.

RRAM

RRAM’s (Right Hand Riemann Sums) work similarly to LRAMs except that it use
x
i+1
instead of using
x
i
. This can be shown as
n
∑
i=1
f(
x
i+1
)Δx
. This is implemented below.
Implementation of RRAM:
In[]:=
AreaRRAM[a_,b_,n_,f_]:=Module[{x1,y1,cord,deltax},​​deltax=(b-a)/n;​​x1 = 0;​​Table[x1+=(f[i+deltax]*deltax),{i,a,b-deltax,deltax}];​​Round[N[x1], 0.001]]​​AreaRRAM[a, b, n, f]
Out[]=
55.
Reinitializing n and finding/comparing the data:
In[]:=
n=5;​​AreaEstimated=AreaRRAM[a,b,n,f];​​AreaActual=Integrate[x^2,{x,0,5}];​​PercentDiff=PercentForm@((AreaEstimated-AreaActual)/AreaActual)
Out[]//PercentForm=
32%
The biggest differences we can spot here are that a) this a larger error and b) this is a positive difference instead of a negative one. Lets visualize this to figure out why.
Plotting Right Hand Sum graphically:
In[]:=
RRAM[a_,b_,n_, f_]:=Module[{x1,y1,cord,deltax},​​deltax=(b-a)/n;​​x1 = Table[{i+deltax,f[i+deltax]},{i,a,b,deltax}];​​y1 = Table[{i,0},{i,a,b, deltax}];​​cord = Drop[Partition[Flatten[Riffle[y1,x1]],2],-2];​​Plot[f[x],{x, a,b},Prolog->{Orange,Table[{EdgeForm[Thick],Rectangle[cord[[z]],cord[[z+1]]] },{z,1, Length[cord]-1,2}]},ImageSize->Large]]
Plotting Left Hand Sum on x^2 from 0 to 5:
RRAM[a,b,n,f]
Out[]=
1
2
3
4
5
5
10
15
20
25
As you might have guessed (or known), the reason for a RRAM overestimating in this case is because all of it’s estimations are above the graph. Will that persist when the function’s derivative is negative over an interval? Lets see.
Right Hand Sum with negative derivative:
RRAM[-5,0,5,f]
Out[]=
-5
-4
-3
-2
-1
5
10
15
20
25
We can gather that right hand sums will overestimate when a function has a positive derivative and underestimate when a function has a negative derivative. Let’s confirm that the opposite applies to left hand sums—it was shown already that they will underestimate when the function has a positive derivate.
Left Hand Sum with a negative derivative:
So, left hand seems to underestimate when the functions derivative is positive and overestimate when negative, with vice versa applying to Right Hand.

MRAM

Implementation of midpoint sum algorithm:
This area is (as you might’ve guessed) somewhere in the middle of the right hand and left hand sums. Lets check the error.
Finding percent error:
1% is by far the smallest error we’ve had thus far. It’s important to note that this is an underestimation. This can be more easily understood by looking at the visualization.
Implementing MRAM graphically:
Plotting Midpoint Sum on x^2 from 0 to 5:
Unlike left hand or right hand, this seems to almost perfectly fill in the underestimations on the right with over estimations on the left. However, it isn’t perfect. Instead of relying on the first derivative of a function to determine over/underestimation, MRAM relies on the second. Lets see this below by looking at just one estimation.
Reducing number of partitions to 1 in order to better visualize over/under estimation:
We can more clearly see why it is an underestimate here. There is a noticeably larger area to the right side of the midpoint than the left side of the graph, indicating that the sum will miss out on more than it attempts to make up—all leading to an underestimation.
Redefining f(x) to be concave down over the same interval and plotting:
In this example, things are not quite as clear. But if one looks carefully, they can tell that the extra area to the right of the midpoint is larger than the missed area to the left of it. Therefore, this is an overestimation. The general rule is MRAM over/underestimates a function when the area of the region to the one side of the graph is greater than the area to the other. From this, we can come to the conclusion that a Midpoint Riemann Sum overestimates when concave down and underestimates when concave up, with no regard for the first derivative of a function.
The last kind of Riemann Sum we will explore is a trapezoidal sum.

TRAM

Implementation of trapezoidal sum algorithm
Finding percent error and reinitializing n/f:
This is the second lowest error we have had, right after the Midpoint sum. It’s slightly different than what the graph shows, though.
Implementing TRAM graphically:
Plotting Midpoint Sum on x^2 from 0 to 5:
The trapezoidal sum looks almost identical to the graph; it’s actually hard to tell from this perspective whether it’s over or underestimating the actual integral. Lets zoom in.
Demonstrating a trapezoidal Riemann Sum with 1 partition to visualize estimation:
There, it’s obvious that the trapezoidal sum significantly overestimates—it’s important to note that the graph is concave up here. Based on what we saw with midpoint sums, it follows that it will underestimate with concave down sums.
Demonstrating a trapezoidal Riemann Sum on concave down curve with 1 partition to visualize estimation:
Clearly, the trapezoidal sum is underestimating the curve when it is concave down.

Combination

Here, I made a tool where someone can easily choose what kind of sum, how many partitions, and the stand and end bounds. I also attempted to implement customization by allowing someone to input a function and have that represented on the graph.
Change text input into a function:

Conclusion

Hopefully this helps anyone in need of clarification with understanding how/why each kind of Riemann Sum works and why each may over/underestimate a curve in certain circumstances. Graphical along with algebraic interpretations made this process much easier to explain (and understand). Thank you for reading!

CITE THIS NOTEBOOK

Visualizing Riemann sums​
by Nikhil Mani​
Wolfram Community, STAFF PICKS, October 17, 2024
​https://community.wolfram.com/groups/-/m/t/3299571