If calculating the nodes and weights is the bottleneck, another suggestion might be on spot:
Sometimes Clenshaw-Curtis is considered to be faster than Gauss-Legendre as it computes nodes and weights using the Fast Fourier Transform (FFT). In my own tests some time ago (not in Julia at that time) Clenshaw-Curtis was up to 5 times faster for the same number of nodes and comparable accuracy. On Wednesday, October 8, 2014 4:31:51 PM UTC+2, Spencer Lyon wrote: > > 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. >> > >
