Is this package for deterministic or stochastic difference equations?

[azev77]

Is this package for deterministic or stochastic difference equations?

It would be great to fill both left quadrants

BTW, doesn't SolveDSGE.jl already solve difference equations?

[ChrisRackauckas]

It's for both of the left quadrants. SolveDSGE does not satisfy what we need: it doesn't match the SciML common interface for ModelingToolkit integration, it doesn't have a generic solver interface, etc. We need something rather specific but extendable and that plays well with symbolic and automatic differentiation.

[azev77]

If the goal is composability, check out @mcreel's DSGE, where he combines SolveDSGE.jl, Flux.jl, Turing's MCMCChains.jl, and SimulatedNeuralMoments.jl to solve-simulate-estimate a system of stochastic difference equations.

[ChrisRackauckas]

That is literally the opposite of composable since it requires a text parser for the model form "The model description file, CK.txt, contains the lines". Also, it doesn't have the split structure/value interface (problem/solve) that's required for the MTK modelingtoolkitize and other analyses,

[azev77]

If you intend to make a package that is more convenient/easy to "compose" I can't wait!

[ChrisRackauckas]

Yup that's the point. We need it to follow exactly the principles of the SciML common interface and hook into the symbolic tooling so that way the swapping between continuous and discrete can occur seamlessly/automatically.

[mcreel]

I'm not at all sure if it is of interest, but the SolveDSGE package has a parser that turns the model description file into Julia code. The file https://github.com/mcreel/SNM/blob/master/DSGE/CK_processed.txt is the output of the parser for the above mentioned file. Perhaps this code would be closer to what is needed? If there is some hope of this sort of code being useful for the planned framework, then perhaps SolveDSGE could be extended to accommodate what is need.

[ChrisRackauckas]

• It should have its interface defined in SciMLBase using the problem/solve style
• It should match the array interface tools and use RecursiveArrayTools
• It should define autodiff overloads via the sensealg machinery
• Its arguments should match the SciML common arguments
• It should have a symbolic analogue matching in ModelingToolkit
• It should be type-generic (i.e. support non-Array types, non floating point types, etc.)
• It should use the the SciML interfaces for layering (linear solvers via LinearSolve.jl, nonlinear solvers via NonlinearSolve.jl, differentiation via AbstractDifferentiation.jl)
• It should rely on ArrayInterface.jl functions for handling type-specific checks
• It should use the AbstractNoiseProcess interface and allow AbstractDiffEqOperators for matrix-free functions
• It should use the JuliaBLAS tools (LoopVectorization.jl, RecursiveFactorization.jl, etc.) where necessary in CPU-specific dispatches
• It should have both the solve and iterative init forms.
• It should downstream test usage with Turing and DiffEqFlux (particularly SimpleDense stuff)

Those are the main things I can think of that need to be done. Basically, if someone is using StochasticDiffEq.jl they should be able to move on over to this and feel almost no change in syntax or design. The two will actually need to be integrated together so that's pretty crucial, and that would make some things like NeuralPDE.jl and HighDimPDE.jl be able to do more automated translations of problems.

[wupeifan]

@mcreel in DifferentiableStateSpaceModels we provide a domain-specific language that processes general nonlinear DSGE models. This DifferenceEquations package can be downstream of the DSSM package mentioned above where we pass gradient information to the estimation blocks. If you are interested, there are some DSGE examples that you can play around with https://github.com/HighDimensionalEconLab/DifferentiableStateSpaceModels.jl/tree/main/src/Examples . We provide solutions and derivatives with respect to the parameters to both first- and second-order DSGEs, There are already a lot of Julia packages out there that solve DSGE, but there are not so many -- if not only DSSM -- that provide AD.

[mcreel]

@wupeifan Thanks, that looks very interesting.

[jlperla]

Thanks @mcreel and @azev77 Just doing a cleanup before we make a push in the next month on the implements. The short answer here is that this is intended as a downstream package for anything that can create statespacemodels that is as SciML compliant as we possibly can be. It takes models as given and simulates them, calculates likelihoods, etc.. So @mcreel in a few months many you could consider using it as a downstream implementation but it is never intended to generate the "models" itself.

[azev77]

I'll try it out when it's ready. To clarify, is this package intended to (eventually) solve systems of stochastic difference equations using perturbation & projection methods? If so, please check out Oren Levintal's Taylor Projection toolbox. In addition to Dynare/Dolo/SolveDSGE

[jlperla]

@azev77 Not exactly. This is a composable package intended to be used by those sorts of packages. In an ideal world all sorts of other packages would be able to use this for their simulations, likelihoods, etc. given a state space model. Not just "DSGE" stuff but also more traditional time-series that needs these things. There are a million different algorithms to generate state space models with various tradeoffs and all of them need to do the same things AFTER they have "solved" the DSGE.

Think about it this way: (1) either handcode a state space setup or system of deterministic or stochastic difference equations as an IVP (this is basically what DSGE things spit out, of course, after it uses perturbations to get rid of the forward looking term); (2) then given that state space setup you may want to simulate it, calculate likelihoods, etc.; (3) make sure that the state space stuff can be differentiated with reverse-mode AD for things like samplers and estimation.

Among other things, the main reason we are doing this is that we need the simulatioin/likelihoods/etc. to be differentiable themselves, which is why SciML is so natural of a home since it is just the discrete-time version of the StochasticDiffEq stuff (except with an optional observation equation). In all of the other packages we have found they seem to tightly connect the solution method itself to the simulation/estimation routine, and none of those simulations/likelihoods are themselves built for AD to work. Hence the need for this package.

The reason AD is essential is that this is also an upstream package for our https://github.com/HighDimensionalEconLab/DifferentiableStateSpaceModels.jl package and paper - which does a traditional DSGE solution but makes things differentiable. That one we would hope gets eclipsed by Dynare etc. if they add in the custom gradients for the perturbation solution itself treating our package as a proof of concept. But the DifferenceEquations repo is not intended as a proof of concept and is meant to be composable and long-lived.

We would LOVE some help when we get the basic framework up and running, hopefully in a little over a month. Things will be a little messy here while we hack away at the minimal support we need for a paper, then start adding in features we don't strictly need. But we will post up when we think it is time for help and with a very specific set of missing features and fixes to temporary hacks.