That’s great!
One more tip. If you know that the integration bounds are going to be constant over certain iterations (which is likely given that you are doing value function iteration), it helps performance significantly if you precompute the nodes and weights before the iterations begin, and then simply call do_quad using these same nodes and weights each iteration. If you do have to have changing bounds, there is a helper function <https://github.com/QuantEcon/QuantEcon.jl/blob/master/src/quad.jl#L622-L636> called quadrect(f::Function, n, a, b, kind="lege") that takes a function, number of nodes, bounds (a, b), and an optional argument for the type of nodes and computes nodes/weights for you then callsdo_quad`. On Wednesday, October 8, 2014 10:03:28 AM UTC-4, Nils Gudat wrote: Hi Spencer, hi Hans, > > Thanks for both of your replies. > > Spencer, you make a good point about the nodes - of course 65 are way too > many here, and stuffing that many nodes in a small interval is bound to > make your `do_quad` function unnecessarily slow. In fact, in my own > implementation, I get reasonable accuracy (this being defined as the > distance between quadgk and do_quad <1e-10, or the distance in the > resulting saving choice in my decision problem being smaller than 0.0001) > with just 9 nodes. Then, the time required to complete one round of the > loop goes down to 2.9 seconds, narrowly beating quadgk (and obviously > beating it by quite a lot when you take into account those iterations at > which quadgk implodes...) > > Hans, that's an interesting observation as well, but I'm not sure it > explains my issue. I'll try to investigate this further though, as this > might potentially be an issue with `quadgk` that would merit being raised > on Git. >
