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!
For what it’s worth, I’ve been experimenting with using <spreadsheet> to do the Riemann sum computations, and it’s promising. Here’s an unlisted activity, where the spreadsheet (with the calculations) is displayed, and with plenty of comments in the DoenetML code:
https://beta.doenet.org/activityViewer/e3QBivM7zjk7yzmPhjbRWK
It’s really fast with 1 to 25 rectangles. Before creating that shared link, I bumped the maximum number of rectangles up to 100. There’s a slight pause now when loading, but otherwise it runs well as you adjust the slider from 1 to 100 and back. (Not quite as smooth as with 25, but much more usable overall than the previous attempts.)
Of course, there are no graphics in this version, which will slow everything down. I’m going to add those in next and will report back.
Mostly good news to report! Here’s a version with f(x)=e^x and up to 25 rectangles which is much smoother than the previous (non-spreadsheet) version:
https://beta.doenet.org/activityViewer/7F49MWKLyxQo9nfvuh7vsk
On my computer it takes about 4 seconds to load, but after that, switching any values of n, a, or b goes very quickly. Just for fun, @Chrissy – since you were dealing with Matt’s activity that aimed for n=100, I made a version with up to 100 rectangles as well:
https://beta.doenet.org/activityViewer/8xqxhgcNmCyrkGL9sSDYcV
The downside is that it takes about 10 seconds to load and do the initial computations on my computer. But once it’s loaded, it’s usable, and only a little more laggy than the 25 box version (at least on my computer). Huzzah!
Ok, now the bad news: you can’t change f(x). All the computations of f(x_i) are done in the spreadsheet, and there’s no great way to convert MathQuill user input into a valid spreadsheet formula. So this approach still won’t work for a “generic” Riemann Sum Applet where students can enter their own function.
However, I think it would work to have a drop down choice of 3-4 different examples, each of which would use different formulas for f and values of a and b. I’ll work on that next.