While creating a program to calculate Riemann Sums for left, right, and midpoint rectangles, I decided to find the limitations of my program. While running the program, I noticed that there were some values that deviated from the average. I decided to investigate this.

I ran this program until the calculator's memory limited the number of times it could run. It got up to θ=441, which means that there were 441 values in all four lists. Y₁ is defined as 1/X.

Code:

L₁ is the data for LeftRAM, L₂ is the data for RightRAM, L₃ is the data for MidpointRAM. L₄ is the data for the number of subdivisions.
After I exported the lists into a statistical program, I graphed the data to see any trends. To my surprise, there were a couple of trends in these graphs.

Left Riemann Sum

Code:



Right Riemann Sum

Code:



Midpoint Riemann Sum

Code:



All Riemann Sums


The variation is small but noticable. There might be a value that decreases 0.0005 from the previous value but go right back up 0.0005.
I was using a TI-84+SE 2.55 MP OS on Wabbitemu at 400% speed to run the program. It gets somewhat slow at the end.

Is this due to the error of floating point numbers or some other phenomenon? What else could explain these trends?

I think it might be because the seq() command might be messing with the step amount, which could be the cause. Let's see...

I tested the following code on both jsTIfied and Wabbitemu using a TI-84+SE 2.43 rom. They both resulted in the same data.

Code:


I got the following data.


All of the values should be two. However, the values deviate and follow a trend. Is this really an error in how the calculator handles seq()?

This artifact is a result of step sizes that cannot be exactly represented in base 10 and are rounded up when added to X. The first step size to do this in your test program is 1/6, which is represented as 0.16666666666667. Theoretically it should take 12 steps to get from 1 to 3, resulting in 13 terms, but here's what the sequence really looks like. The first column shows the term before rounding to 14 digits; the second column shows it after rounding.

1.0000000000000|
1.1666666666666|7 => 1.1666666666667
1.3333333333333|7 => 1.3333333333334
1.5000000000001|7 => 1.5000000000001
1.6666666666667|7 => 1.6666666666668
1.8333333333334|7 => 1.8333333333335
2.0000000000001|7 => 2.0000000000002
2.1666666666668|7 => 2.1666666666669
2.3333333333335|7 => 2.3333333333336
2.5000000000002|7 => 2.5000000000003
2.6666666666669|7 => 2.6666666666670
2.8333333333336|7 => 2.8333333333337
3.0000000000003|7 => 3.0000000000004

As you can see, the final result is ever so slightly larger than 3. And as a result, the final "3" term that you'd expect to find in the sequence is skipped because it has become greater than the upper bound of 3.

The simplest way to fix a problem like this is to make the upper bound slightly larger than the exact upper bound desired (but not large enough so as to add another term). You'll still have these tiny rounding errors propagating through each term, but you'll at least have the correct number of terms.

If the step is known as a fraction, a more precise but more complicated solution is to delay the division by the denominator so rounding is only performed once per term. Using this method, your example would change into this:

Code:

Thanks Runer112! It looks as if Mateo was indeed correct.

Thanks Runer112! I totally blanked on testing this out for myself; great explanation!