Status of integration, optimization, and nl solvers

Specific Domains Numerics
21

If you go with Expectations.jl, you can see that this is pretty much exactly what it does. Expectations.jl/iterable.jl at master · QuantEcon/Expectations.jl · GitHub is what generates the structure. The structure is Expectations.jl/types.jl at master · QuantEcon/Expectations.jl · GitHub and pretty much the only fancy behavior is that it is overloaded to support the properties you would think of as a linear opertor (i.e. Expectations.jl/iterable.jl at master · QuantEcon/Expectations.jl · GitHub and Expectations.jl/iterable.jl at master · QuantEcon/Expectations.jl · GitHub). There is a convenience operator for “functions” in Expectations.jl/iterable.jl at master · QuantEcon/Expectations.jl · GitHub

You can see all of the operations in GitHub - QuantEcon/Expectations.jl: Expectation operators for Distributions.jl objects that it supports. I bring this up because if you are writing any custom code, it would be awesome if you instead added mini features or fixed a performance/etc. issue there instead as I suspect it does close to what you need.

2 Likes
22

Initially I was confused, since I was not taking an expectation (not integrating over a distribution). Now that you pointed out that there is method for regular functions, I will explore that package more in depth. Thank you.

23

I think the way that the current interface is setup it accepts a distribution, which of course you could pass in a uniform distribution to have it just return back the simplest uniform nodes that would be the definite integral. A more convenient interface could be written if you think it is worth it.

But a few thoughts without knowing the exact details of your problem.

  • If you are doing a discounted integral to infinity, in principle you can write it as an expectation over gauss-laguerre quadrature and an exponential distribution (look at the PDF of the exponential distribution and you will see it immediately)
    • But be warned. I have found that using the change-of-variables formula for this can lead to quadrature nodes that are too far apart close to the origin and become way too large and useless on the other side. I would take a look at the nodes that the method spits out as it would depend on your discount rate.
  • If you do that approach (or even truncate it with a large T and use Gauss-Legendre quadrature), you may want to figure out a change of variable for your \hat{H} thing so it in on the [0,\infty) domain in all cases. At that point you could reuse the same nodes and quadrature points even if you are changing the t internally to that transformed function.
  • If you doing some sort of algorithm with a fixed point and need to solving these equations already on a time grid (which you can choose out of convenience or it needs to be uniform for whatever reason) , then it is sometimes more efficient to use trapezoidal or simpsons rule. That is, you could line up the grid of what you are solving with the quadrature. But this doesn’t apply if you would need to evaluate the functions directly.
  • It is entirely possible that in this case the Expectations.jl code isn’t helpful and you can just keep around the weights/etc. in your structure as @Tamas_Papp has suggested.

As always, only worry about this stuff if you find it to be too slow in practice. If this isn’t going to be the crux of your speed issues, then it isn’t worth worrying about. But it might be here given the expressions you listed above.

1 Like