I need some help with repeat and a Riemann Sum calculator. Matt made use of Peter Keep’s work on a Riemann Sum calculator and graph Doenet but in Matt’s activity, he asks for students to do two different functions with n=25 and n=100, as well as n=6. I previously asked my students to do this using Desmos, and it was doable there, but the Doenet version crawls when you first change the n to 25, and it takes up to a couple of minutes when you change it to 100.
I don’t understand everything Peter did, but it looks to me like it’s going through the sequence of n terms at least 3 times, possibly more like 6 or 7: to calculate the x values and then the function values, and then the minimum and maximum of those functions values for the range of the graph, and then creating the rectangles on the graph, and then calculating the Riemann Sum. I could be wrong about that, but I thought maybe it would be faster if I could reduce the number of times it has to go through a long list/sequence.
I started making some changes, among them just using f(b) for the max y-value because I know this activity only uses the functions 2x+1 and x^2+1, but that won’t be generally applicable. I’m also considering cheating and using at most 40 or 50 rectangles on the graph even if the n entered is higher because who’s counting that high? But I feel like the activity could be even better and still general if I understood more about how to combine the passes.
Can anyone please help me speed this up?
Chrissy
Yeah, we’ve run into speed issues with Riemann sum applets like that. I think people have come up with the ways that end up working better. @Virginia_Mae or @Jonathan_Rogness, do either of you have insights on what works to make this faster?
I’ve gone through a few iterations of Riemann Sum applets – here’s one example. I’ve yet to figure out how to get this to be as fast as the comparable applets I’ve made in (for example) GeoGebra, where I have a slider from n=1 box to n=50 boxes, and everything changes smoothly.
In the Doenet version, changing a, b, or the choice of endpoints all goes smoothly, but adjusting the number of boxes is still slow. (The version I linked to is a little slower because when an option is changed, it does a bunch of computations to adjust the viewing window of the graph.) I capped n at 20 on the slider because otherwise things get too slow. You can still enter higher values of n in the input box. I just tried n=40 and on my relatively fast computer it took 12 seconds. (For something which is instantaneous on GeoGebra. 
)
My recollection from when @Duane_Nykamp and I looked through this before is that the bottleneck was jsxgraph creating and destroying objects when n changes.
With that in mind, I remember trying the following scheme to avoid the slowdown of creating / destroying objects:
- Create 40 rectangles at the beginning
- Make 40-n of them “degenerate rectangles” with zero width (like x_38 = x_39 = x_40 = b)
It didn’t work, but at the moment I don’t recall why – nor do I recall when I last tried this. So it’s probably worth trying again. Maybe there are some related things to try – maybe make rectangles hidden or visible depending on the value of n?
Looks like I can’t upload / attach .ggb files, but if anybody is interested, here’s a link to a comparable GeoGebra applet.
Thanks, Jonathan. It appears to me that you and Peter built off of similar work.
Just a note that something seems to be wrong with the sum in your linked Doenet activity.
I’ve made some alterations to my version, some of which match up to differences I can see between your activity and Peter’s. But I’ve also tried to reduce computations where I can, like multiplying the sum by dx at the end, rather than each height by dx as we add, and by calculating the values once, and then referring to the array rather than computing the heights again. I don’t know if that any of that makes any difference.
I think I did figure out a better way to resize the y-values on the graph without going through the whole array, using built-in Doenet attributes.
It’s faster than it was before, for sure, but still not fast like geogebra or Desmos.
Based on suggestions from Duane and Anurag at dropin, I did cap the number of rectangles ever drawn on the graph at 30. It’s not too bad to do n=25 now, and trying it with n=100 is more like 10-15 seconds instead of a minute or more. (I also implemented a check that n is an integer, haha!)
@Anurag_Katyal I also made the table values populate automatically when the interactive is used to compute them. I think it’ll be much more painless for students to complete now, and puts the focus back where it should be: on the meaning of the values. Thanks for the suggestion!
1 Like