Handle time-varying model coefficients

[jason-ash]

For example, in the Hull-White model.

[jason-ash]

In fact, the Vasicek model should be a subclass of the Hull-White in which the theta parameter is fixed over time. Perhaps there needs to be a TermStructure class that can handle these types of inputs?

[jakemcaferty]

I like the idea of a TermStructure class, which could have a few useful functions:

• Bootstrapping yield curves
• Fitting interest rate model parameters
• Interest rate conversions/calculations (discount rates, spot rates, forward rates, swap rates, etc)

Do you plan/desire to also incorporate financial security classes (bonds, derivatives, equities, portfolio, etc.) or financial analysis calculations into this pyesg package, or do you want users/developers to build those outside/on top of pyesg?

For example, one of the use cases for pyesg is creating scenarios for retirement planning. Is that something you would want users to construct on their own and pull in pyesg for the scenarios only, or should a user be able to construct a portfolio in pyesg with certain parameters (perhaps allocations to fixed income assets and equities that change as they age) and project the returns natively using only pyesg?

[jason-ash]

Do you plan/desire to also incorporate financial security classes (bonds, derivatives, equities, portfolio, etc.) or financial analysis calculations into this pyesg package...

Short answer is "not really", but more accurately is "not unless there's a need." Suppose you want to value an option. You need scenarios, and you need some cash flow logic tied to the scenarios. The first one is squarely in scope for pyesg. In my opinion, generating the scenarios is the harder part of the two, so that was where I focused. I wanted users to be able to overlay any number of contingent cash flows using the scenarios from pyesg, understanding that it would take some coding on their part.

Instead of building functionality like that within pyesg I think a good option would be to create example notebooks with those sorts of things: how you would value an option, or construct an equities portfolio, or measure tail risk, etc.

For example, one of the use cases for pyesg is creating scenarios for retirement planning. Is that something you would want users to construct on their own and pull in pyesg for the scenarios only, or should a user be able to construct a portfolio in pyesg with certain parameters (perhaps allocations to fixed income assets and equities that change as they age) and project the returns natively using only pyesg?

This one feels different than the above to me, because it's still focused on generating scenarios. If I could rephrase, I think your main question is actually about the API. Right now, users can generate scenarios with a pyesg.GeometricBrownianMotion class, but not with a pyesg.RetirementPortfolio(equity=0.7, bond=0.3) class. This feels to me like a question about what level of abstraction is most useful based on how people want to use the library. I think all the functionality to do what you describe is definitely in scope for the library, and it would be an interesting discussion for what sorts of classes and functions would make it easiest for the users to solve their problems. pyesg.GeometricBrownianMotion might be easiest for someone in a financial math class, while pyesg.RetirementPortfolio might be easiest for a financial planner. I could easily see both being in the library, leveraging the underlying stochastic processes to generate scenarios.

[jason-ash]

By the way, thanks @jakemcaferty for the suggestions! Really appreciate them!

[jakemcaferty]

That makes sense, and you're correct that my main question was about the capabilities of the API. I agree that the economic scenarios are much more challenging than the financial calculations (which are relatively easy to code into a function as needed). I actually like the idea of coding the financial analysis calculations in a notebook better anyways since it grants more flexibility.

I do think some kind of general TermStructure class makes sense, particularly for many of the models that are currently available within pyesg which are most likely to be used for interest rates. In addition to the Vasicek being a subclass of Hull-White, you could actually create a generalized AffineTermStructure(StochasticProcess), which could be inherited by Hull-White, Ho-Lee and CIR processes; all of which are more specific examples of the generalized affine term structure model.