2.20.1. The properties

user_data

this is so that the user can tailor the information to pass around functions written by him but called by RISE

Help for rise/user_data is inherited from superclass dsge

nsols

number of solutions

Help for rise/nsols is inherited from superclass dsge

definitions

values of auxiliary parameters defined in the model file with a #

Help for rise/definitions is inherited from superclass dsge

equations

equations of the system

Help for rise/equations is inherited from superclass dsge

filename

name of the rs/rz/dsge file read

Help for rise/filename is inherited from superclass dsge

model_description

comments on the model

Help for rise/model_description is inherited from superclass dsge

legend

attribute for giving a tag to a specific version of a model

endogenous

information on endogenous variables (names, number, types, etc.)

exogenous

information on exogenous variables (names, number, types, etc.)

observables

information on observable variables (names, number, types, etc.)

options

structure holding information on modifiable settings

parameters

information on parameters (names, number, types, etc.)

Help for rise/parameters is inherited from superclass estimable

markov_chains

information on markov chains, regimes and related items

Help for rise/markov_chains is inherited from superclass estimable

estimation

information on estimation: posterior maximization and simulation

Help for rise/estimation is inherited from superclass estimable

2.20.2. The methods

abcd

Compute the ABCD test statistics of Fernandez-Villaverde, Rubio-Ramirez, Sargent, and Watston (2007) Uses the state-space system

and computes the eigenvalues of

If all eigenvalues are smaller than 1, the poor man’s invertibility condition is satisfied and the structural shocks can be recovered from the observables

Syntax
[test, A, B, C, D] = abcd(m);

[test, A, B, C, D,retcode] = abcd(m);
Args:

m (model object): model object

Returns:
:

test : check above

A : check above

B : check above

C : check above

D : check above

retcode : =0 if no problem

Reference:
Fernandez-Villaverde, Rubio-Ramirez,Sargent, and Watson (2007), “ABCs (and Ds) of Understanding VARs”, American Economic Review, 97(3), 1021-1026

Help for rise/abcd is inherited from superclass dsge

accuracy

accuracy : computes the Euler errors of dsge models
Euler_errors=accuracy(m)
Euler_errors=accuracy(m,order)
Euler_errors=accuracy(m,order,nxcuts)
Euler_errors=accuracy(m,order,nxcuts,nsims)
Args:

m (rise | dsge): scalar or vector of model objects.

order ({solve_order} | integer): Approximation order for which to
compute the accuracy. Always less than or equal to solve_order

nxcuts ({10} | integer): Number of quantiles per discretized
continuous shock

nsims ({1000} | integer| 1x2 cell): Number of simulations to generate
the state of the endogenous variables.

Returns:
:

g [cell | struct]: if the number of models is greater that one, the output is a cell array of structures. Each structure has the following fields: - eqtn1, eqtn2,… : structures containing “mean” (mean of the euler error across all simulations), “max” (maximum of the euler error across all simulations) and “min” (minimum of the euler error across all simulations)

Note:

The errors are NOT log10(abs(error)). The user can take the log10 or any other transformation as desired.

The smaller the standard deviation of the shocks the higher the accuracy even if the solution is not very accurate in the first place.

The accuracy of the solution may critically depend on the tolerance level used for solving the model in the first place. For instance, if an iterative algorithm (e.g. mfi) is used, the solution might not be 100% accurate even in a linear model

The errors are provided in absolute value for all equations, rather than being normalized as is customarily done in the literature

Help for rise/accuracy is inherited from superclass dsge

calculate_loss

Calculates welfare
[welf,retcode,V,d]=calculate_loss(m,lossstr)

[welf,retcode,V,d]=calculate_loss(m,lossstr,shocksdb)

[welf,retcode,V,d]=calculate_loss(m,lossstr,shocksdb,varargin)
Args:

m (rise | dsge): scalar or vector of model objects.

lossstr (char): loss function

shocksdb (ts | struct | empty): Shocks database to condition on over simulation. if empty, the unconditional welfare is returned. if not empty the conditional welfare is calculated instead

varargin : optional arguments coming in pairs

Returns:

welf [scalar|vector]: conditional loss (scalar) or unconditional loss (scalar if number of regimes = 1)

retcode [scalar]: return code

V [n x n x h]: array of equilibrium matrices

d [h x 1 vector]: constant in loss

Note:

The loss is such that \(v(x_t,r_t)=x_t.'\*Vrt\*x_t+drt\)

Help for rise/calculate_loss is inherited from superclass dsge

calibrate

calibrate : estimates the parameters of a model without the need of evaluating the likelihood
[m]=calibrate(m)

 m=calibrate(m,varargin)
Args:

m (rise | dsge): model object or vectors of model objects

Returns:

m (rise | dsge): model object or vectors of model objects with information on the calibrated parameters

Note

It is assumed that varargin includes information on priors and possibly endogenous priors

Help for rise/calibrate is inherited from superclass dsge

check_derivatives

Compares the derivatives and the solutions from various differentiation techniques
check_derivatives(obj)
retcode=check_derivatives(obj)
Args:
obj (rise | dsge): model object or vectors of model objects

Returns:
:

retcode [numeric]: 0 if no problem is encountered during the comparisons. Else the meaning of recode can be found by running decipher(retcode)

Note:

The derivatives computed are ‘automatic’, ‘symbolic’ or ‘numerical’

The comparisons are done relative to automatic derivatives, which are assumed to be the most accurate.

Help for rise/check_derivatives is inherited from superclass dsge

condition_draws_on_model

condition routines on the model e.g. routines for drawing skewed shocks may depend on the model and its parameterization.

Help for rise.condition_draws_on_model is inherited from superclass dsge

counterfactual

counterfactual Computes counterfactual history of a nonlinear DSGE model

Syntax:
counterf=counterfactual(m)
counterf=counterfactual(m,sim_engine)
counterf=counterfactual(m,sim_engine,nsim)
counterf=counterfactual(m,sim_engine,nsim,shock_names)
counterf=counterfactual(m,sim_engine,nsim,shock_names,varargin)
[counterf,actual]=counterfactual(...)
Inputs:

m : [rise|dsge] model(s) for which to compute the counterfactual. m could be a vector of models. The computation of the counterfactual requires a computation of smoothed history. Hence either m should contain all the information needed for that purpose or the information should be passed along through varargin below

sim_engine : [empty|function handle] function computing forecasts

nsim : [empty|numeric|{100}] Number of simulation to consider for the integration exercise. nsim is automatically set to 1 if the model is detected to be solved at order 1 and not contain regime switches.

shock_names : [empty|char|cellstr] list of shocks to consider in the computation of the counterfactual

varargin : additional information needed for the computation of the smoothed quantities through filtration.

Outputs:

counterf : [struct|cell array] structure or cell array of structures with the counterfactuals in each model and each solution.

actual : [struct|cell array] structure or cell array of structures with the actuals (smoothed variables) in each model and each solution.

Remarks:

Note

For a nonlinear model (e.g linear but switching), the type of decomposition/counterfactual we do for linear/linearized constant-parameter models is not feasible. RISE uses a monte carlo integration to provide an approximation to the decomposition/counterfactual

if m is a vector of models, then each model should return a unique solution (implying a unique filtration), else the concatenation of counterfactuals will fail. In that case it is better to run one model at a time.

When a model has multiple solutions, there is no guarantee that every solution will have succeed at filtration. For this reason, the result of each counterfactual is stored in a separate cell. Empty cells represent the solutions for which the filtration could not be obtained.

Examples:

See also

dsge/historical_decomposition

Help for rise/counterfactual is inherited from superclass dsge

dbminusdb

INTERNAL FUNCTION

draw_parameter

Random parameter draws for RISE model objects.
[draw,obj] = draw_parameter(obj,simulation_folder);
Args:

obj (rise | dsge | rfvar | svar): RISE model object

simulation_folder (char | struct):

char(1): simulation folder : the stored elements should be structures with fields:

x : parameter vectors

f : value of minus(log posterior kernel)

char(2): [‘mode’|’prior’]: draw from the prior distribution or from a multivariate normal distribution around the mode.

Returns:

draw [cell]: the first entry is the names of the estimated parameters and the second is a vector of drawn parameters. The whole cell can be pushed in to a model as obj=set(obj,’parameters’,draw).

obj [rise|dsge|rfvar|svar]: RISE model object in which the drawn parameter has been pushed.

Help for rise/draw_parameter is inherited from superclass estimable

drop

DROP : drops model parameterizations
obj=drop(obj,w)
Args:

obj (rise | dsge): single or vector of RISE models

w (scalar|vector) : parameterizations to drop

Returns:

obj [dsge|rise]: model(s) with dropped parameterizations

Help for rise/drop is inherited from superclass dsge

estimate

Estimate the parameters of a RISE model
obj=estimate(obj)
obj=estimate(obj,varargin)
[obj,filtration]=estimate(...)
[obj,filtration,post_max]=estimate(...)
[obj,filtration,post_max,logfile_name]=estimate(...)
Args:
obj (rise | dsge | rfvar | svar): model object

varargin : additional optional inputs among which the most relevant for estimation are:
estim_mle [{false}|true]: if true, the contribution of priors is zero. This permits a clean MLE estimation, but with bounds set by the prior information. Both the curvature of the priors and their level is ignored. If false, we estimate a Bayesian model.

estim_eval_lik [false|{true}]: if false, likelihood is not evaluated. This allows for an easy calibration of parameters in the case of instance of endogenous priors.

estim_parallel [integer | {1}]: Number of starting values

estim_start_from_mode [true | false | {[]}]: when empty, the user is prompted to answer the question as to whether to start estimation from a previously found mode or not. If true or false, no question is asked.

estim_start_date [numeric | char | serial date]: date of the first observation to use in the dataset provided for estimation

estim_end_date [numeric | char | serial date]: date of the last observation to use in the dataset provided for estimation

estim_max_trials [integer | {500}]: When the initial value of the log-likelihood is too low, RISE uniformly draws from the prior support in search for a better starting point. It will try this for a maximum number of estim_max_trials times before squeaking with an error.

estim_general_restrictions [{[]} | function handle | cell array]: when not empty, the argument can be a function handle or a cell array containing the function handle and additional input arguments. The general syntax for the calling the function handle is viol=myfunc(obj,varargin), with obj the parameterized RISE object which will be used in the computation of the restrictions violations. Hence the restrictions are entered either as @myfunc or as {@myfunc,arg2,arg3,…}. Originally, RISE will call the function without any inputs. In that case, RISE expects the output to be a structure with fields :

number_of_restrictions : number of restrictions

kf_filtering_level [0 | 1 | 2 | 3]: if 0, no filters are required for the computation of the restrictions. If 1, only the filtered variables are required. If 2, the updated variables are required. If 3, the smoothed variables are required.

When the function is called with inputs, RISE expects as output the values of the restrictions. The sign of the violations does not matter. All the user has to do is to put a zero where the restrictions are not violated.

estim_linear_restrictions [{[]} | cell]: This is most often used in the estimation of rfvar or svar models either to impose block exogeneity or to impose other forms of linear restrictions. When not empty, estim_linear_restrictions must be a 2-column cell:

Each row of the first column represents a particular linear combination of the estimated parameters.

Each row of the second column holds the value of the linear combination.

estim_nonlinear_restrictions [{[]} | cell]: When not empty, estim_nonlinear_restrictions must be a k x 1 cell, with each row representing a particular restriction on the parameters. e.g. for a switching model, one can have alpha(zlb,1)>alpha(zlb,2), which can also be written as alpha_zlb_1>alpha_zlb_2. The restrictions can also be equality restrictions. In this case, however, it is assumed that the parameters entering the lhs of restrictions are not estimated. e.g. alpha(zlb,1)=3*cos(alpha(zlb,2))+1.

estim_priors [{[]}|struct]: This provides an alternative to setting priors inside the rise/dsge model file. Each field of the structure must be the name of an estimated parameter. Each field will hold a cell array whose structure is described in help GENERIC/setup_priors.

estim_endogenous_priors [empty|cell array | function handle]: When not empty, estim_endogenous_priors must be either a cell array of cell arrays with each subcell array having the format {item,args2,args3,…} where “item” is the thing to evaluate and args2, args3, etc. are the usual arguments for setting priors EXCEPT the start value. These are some of the forms that “item” can take

‘corr{endo,endo,horizon}’

‘irf{endo,exo,horizon}’

‘userfun(irf{endo,exo,horizon})’

‘userfun(a1,a2,…,an)’

In other words there is support for correlations, impulse responses and combinations of parameters and all those items should evaluate to a scalar. This approach works well but is not very flexible.

Alternatively, estim_endogenous_priors could be a function handle such that when called without inputs, it returns a struct with fields:

priors : cell array of estimation priors. more explicitly, each entry of the cell array is itself a cell with the same syntax as the priors for estimation, EXCEPT the start value!

kf_filtering_level [0 | 1 | 2 | 3]: if 0, no filters are required for the computation of the endogenous priors. If 1, only the filtered variables are required. If 2, the updated variables are required. If 3, the smoothed variables are required.

When the function handle is called with TWO inputs, what is returned is a vector of values for which RISE will evaluate the endogenous prior. This vector should have the same length as the previous cell array. The two inputs are:

obj : The model object

filtration : a structure containing the filters

estim_blocks [{[]} | cell]: When not empty, this triggers blockwise optimization. For further information on how to set blocks, see help for dsge.create_estimation_blocks

estim_penalty_factor [numeric | {10}]: when general nonlinear restrictions are present, RISE uses an estimation strategy in which the objective function is penalized as f_final=fval+estim_penalty_factor*sum(max(0,g)^2) where g is a vector of the values of the restrictions, which are expected to be of the form g(x)<=0. See estim_general_restrictions above.
optimizer [char | function handle | cell|{fmincon}]: This can be the name of a standard matlab optimizer or RISE optimization routine or a user-defined optimization procedure available of the matlab search path. If the optimzer is provided as a cell, then the first element of the cell is the name of the optimizer or its handle and the remaining entries in the cell are additional input arguments to the user-defined optimization routine. e.g. estimate(m,’optimizer’,{‘fmincon’,’MaxFunEvals’,1000,…}). A user-defined optimization function should have the following syntax
[xfinal,ffinal,exitflag,H]=optimizer(fh,x0,lb,ub,options,varargin);
That is, it accepts as inputs:

fh: the function to optimize

x0: a vector column of initial values of the parameters

lb: a vector column of lower bounds

ub: a vector column of upper bounds

options: a structure of options whose fields will be similar to matlab’s optimset

varargin: additional arguments to the user-defined optimization procedure

That is, it provides as outputs:

xfinal: the vector of final values

ffinal: the value of fh at xfinal

exitflag: a flag similar to the ones provided by matlab’s optimization functions.

H: an estimate of the Hessian
estim_barrier [{false} | true]: never allow constraints to be violated in no circumstances.
Returns:

obj [rise | dsge | rfvar | svar]: model object parameterized with the mode found and holding additional estimation results and statistics that can be found under obj.estimation

filtration [struct]: structure with the filtration information of the model parameterized at the mode

post_max [struct]: structure with prior and posterior maximization information

logfile_name [{‘’}|char]: name of the file capturing the output of posterior maximization

Note:

recursive estimation may be done easily by passing a different estim_end_date at the beginning of each estimation run.

It is also possible to estimate a dsge model using conditional future information on endogenous (forecast_cond_endo_vars) as well. as on exogenous (forecast_cond_exo_vars). The dataset provided in this case must have several pages. The first page is the actual data, while the subsequent pages are the expectations data. See help dsge.forecast for more information

Option estim_penalty which is the value of the objective function when a problem occurs (e.g. no solution found, very low likelihood, stochastic singularity, problems computing the initial covariance matrix, non-positive definite covariance matrices, etc.) is deprecated. If needed you should rather set ObjectiveLimit as part of the options of the optimizer. e.g. estimate(m,’optimizer’,{‘fmincon’,’ObjectiveLimit’, -1e+10})

See also

ESTIMABLE/SETUP_PRIORS

Help for rise/estimate is inherited from superclass dsge

extract_first_order_structure

EXTRACT_FIRST_ORDER_STRUCTURE Extracts the first-order structure of a DSGE model.

Syntax:

[Aplus, A0, Aminus, B, Q, ss, growth] = extract_first_order_structure(obj) [Aplus, A0, Aminus, B, Q, ss, growth] = extract_first_order_structure(obj, sm)

Inputs:

obj [rise|dsge]: Model object.

sm [struct]: Derivatives computed by RISE (optional).

Outputs:

Aplus [h x h cell array]: Coefficients on the forward-looking terms multiplied by the transition matrix.

A0 [1 x h cell array]: Coefficients on the contemporaneous terms.

Aminus [1 x h cell array]: Coefficients on the backward-looking terms.

B [1 x h cell array]: Coefficients on shocks.

Q [h x h matrix]: Transition matrix (qij) with i=today and j=tomorrow.

ss [n x h matrix]: Steady states.

growth [n x h matrix]: Balanced growth.

Notes:

The steady state is returned instead of the constant term. This assumes that the model is at least conditionally stationary. The constant term can be recovered as b = -(Aplus{i,i}/Q(i,i) + A0{i} + Aminus{i}) * ss(:, i).

In case of a model with multiple parameterizations, all the outputs are cell arrays, with each cell representing one parameterization.

Description:

The function extracts the first-order structure of a DSGE model, allowing the user to use their own algorithms externally. It returns the coefficients on various terms in the linearized model equations, as well as the transition matrix, steady states, and balanced growth rates.

Example:
% Extract first-order structure from a DSGE model model = rise(‘my_model_file’); [Aplus, A0, Aminus, B, Q, ss, growth] = extract_first_order_structure(model);

See also

rise.solve

Help for rise/extract_first_order_structure is inherited from superclass dsge

filter

Filtering of DSGE models
[filtration,LogLik,Incr,retcode,obj]=filter(obj,varargin)
Args:

obj (rise | dsge): model object

varargin (name,value): valid pairwise options with the most relevant being:

kf_ergodic [{true}|false]: initialization at the ergodic distribution

kf_init_variance [{[]}|scalar]: initial variance factor (Harvey scale factor). If not empty, the information in T and R is ignored.

kf_presample [{0}|integer]: Number of observations to discard before computing the likelihood.

kf_filtering_level [0|1|2|{3}]: 0: Likelihood only, 1: 0+ filtered series 2: 1+ updated series 3: 2+ smoothed series

kf_user_init [{[]}|cell]: User-defined initialization. When not empty, it can take three forms. {a0}, {a0,cov_a0}, {a0,cov_a0,PAI00} where a0 is the initial state vector with the same order as the rows of T, cov_a0 is the initial covariance of the state vector (same order as a0) and PAI00 is the initial vector of regime probabilities. Any information provided here will override kf_init_variance.

a0 (numeric, struct or function_handle): State vector for each regime. Default is the steady state.

The struct is such that each field is a numeric e.g p.y=0.3 or a char in which the parameters of the model can appear e.g. p.y=’0.3-alpha/beta’;

The function handle should accept a regime-specific parameter structure and a steady-state vector i.e. a0(p,stst) and returns a vector corresponding to the regime-specific state.

cov_a0 (numeric or function_handle): Covariance matrix of state vector for each regime. Default is repmat(eye(m), [1, 1, h]).

The function handle should accept a regime-specific parameter structure and a steady-state vector i.e. cov_a0(p,stst) and returns a regime-specific covariance matrix.

If numeric and scalar, then cov_a0 = repmat(cov_a0*eye(m), [1, 1, h])

If numeric and vector, then cov_a0 = repmat(diag(cov_a0), [1, 1, h])

If numeric and size(cov_a0,3)=1, then cov_a0 = repmat(cov_a0, [1, 1, h])

PAI00 (numeric, function_handle, or vector): Initial probabilities for each regime. The function handle should accept a regime-specific parameter structure and a steady-state vector i.e. PAI00(p,stst) and returns a scalar!!!: the probability of the specific regime. Default is ones(h, 1) / h.

kf_user_algo [{‘’}|char|cell|function handle]: User-defined filtering algorithm. The filter should take as inputs (syst,y,U,z,options), with

syst [struct]: structure or model object both provided by dsge.filter (see notes below)

y [matrix]: matrix of data or structure both provided by dsge.filter (see notes below)

U [matrix]: matrix of trends provided by dsge.filter

z [matrix]: matrix of deterministic terms provided by dsge.filter

options [struct]: options provided by dsge.filter

The filter should return [LogLik,Incr,retcode,Filters], with

LogLik [numeric]: value of the log likelihood

Incr [vector]: contributions to the likelihood in each period

retcode [numeric]: flag equal to 0 if there is no problem

Filters [struct]: structure containing all the filtering information

In some (rare) circumstances, the information provided by the inputs is not sufficient to run the specific filter of the user. In that case, it is assumed that the user would know how to retrieve the relevant information from the parameterized model object. The user filter should then be written in such a way that when provided with two inputs (input1= model object, input2=structure), it returns a modified structure (input2) containing the information needed. This process is triggered by writing a star in front of the name of the user filter. e.g. ‘kf_user_algo’,’*user_filter’, or ‘kf_user_algo’,{’*user_filter’,…}. In this case the function handle option is not available.

kf_householder_chol [{false}|true]: if true, return the cholesky decomposition when taking the householder transformation. This option is primarily used in the switching divided difference filter.

Returns:

filtration [struct]: structure containing the filters

LogLik [numeric]: log likelihood

Incr [vector]: contributions to the likelihood for each time t

retcode [integer]: 0 if no problem encountered

obj [rise|dsge]: model object possibly parameterized and solved.

See also

rise.filter_initialization, dsge_tools.filtering_initialization

Help for rise/filter is inherited from superclass dsge

fisher

INTERNAL FUNCTION

Help for rise/fisher is inherited from superclass estimable

fold_solution

fold_solution : folds higher-order solutions in order to facilitate comparison with other software

Syntax :

[foldsol,zlist_reordered,ylist_reordered]=fold_solution(m)

[foldsol,zlist_reordered,ylist_reordered]=fold_solution(m,order)

[foldsol,zlist_reordered,ylist_reordered]=fold_solution(m,order,user_state_list)

[foldsol,zlist_reordered,ylist_reordered]=fold_solution(m,order,user_state_list,user_endo_list)

Inputs:

m [rise|dsge]: scalar or vector of solved model objects, possibly with multiple parameterizations

order [numeric|empty]: Desired order of perturbation <= order of solution

user_state_list [cellstr|empty]: List of state variables as appearing in the non-RISE solution

user_endo_list [cellstr|empty]: List of endogenous variables in the non-RISE solution

Outputs:

foldsol [cell array]: folded solutions

zlist_reordered [cellstr]: reordered list of state variables

ylist_reordered [cellstr]: reordered list of endogenous variables

Help for rise/fold_solution is inherited from superclass dsge

forecast

Compute forecasts for rise/dsge/svar/rfvar models
cond_fkst_db = forecast(obj,varargin)
Args:

obj (rise | dsge | svar | rfvar): model object

vararginadditional inputs coming in pairs. These include but are
not restricted to:

forecast_to_time_series [{true}|false]: sets the output to time series format or not

forecast_nsteps [integer|{12}]: number of forecasting steps

forecast_start_date [char|numeric|serial date]: date when the forecasts start (end of history + 1)

forecast_cond_endo_vars [{‘’},char|cellstr]: names of conditional endogenous variables to be used either in forecasting or in estimation

forecast_cond_exo_vars [{‘’},char|cellstr]: names of conditional exogenous variables to be used either in forecasting or in estimation

forecast_endo_exo_vars [{‘’},char|cellstr]: names of exogenous variables that are potentially modified under conditional forecasting with forward-back shooting

forecast_shock_uncertainty [true|{false}]: draw shocks over the simulation horizon.

Returns:
:

cond_fkst_db [struct|matrix]: depending on the value of forecast_to_time_series the returned output is a structure with time series or a cell containing a matrix and the information to reconstruct the time series.

Note:

the historical information as well as the conditioning information come from the same database. The time series must be organized such that for each series, the first page represents the actual data and all subsequent pages represent conditional information. If a particular condition is “nan”, that location is not constrained

Conditional forecasting for nonlinear models is also supported. However, the solving of the implied nonlinear problem may fail if the model displays instability

Both HARD CONDITIONS and SOFT CONDITIONS are implemented. In order to do soft conditions, the variables one wishes to condition on must have lower and upper bounds represented by the presence of variables with names “lower_CONDNAME” and “upper_CONDNAME”, where CONDNAME is the name of a particular variable we want to condition on.

The data may also contain time series for a variable with name regime in that case, the forecast/simulation paths are computed following the information therein. regime must be a member of 1:h, where h is the maximum number of regimes.

Further options for conditional forecasting can be found in RSCF.FORECAST

See also

rise_generic/simulate

rscf.forecast

forecast_real_time

Forecast from each point in time

Syntax
[ts_fkst,ts_rmse,rmse,Updates]=forecast_real_time(obj)

[ts_fkst,ts_rmse,rmse,Updates]=forecast_real_time(obj,varargin)
Args:

obj (dsge): model object

varargin : valid optional inputs coming in pairs. The main inputs of interest for changing the default behavior are:

forecast_rt_nsteps [integer] : number of periods ahead

Returns:

ts_fkst [struct] : fields are forecasts in the form of ts objects for the different endogenous variables

ts_rmse [ts|struct] : if only one object is processed, the output is a ts. If instead several objects are processed, fields are RMSEs in the form of ts objects for the different endogenous variables

rmse [matrix] : RMSEs for the different endogenous variables

Updates [struct] : fields are the updated (in a filtering sense) in the form of ts objects for the different endogenous variables

See also

plot_real_time

Help for rise/forecast_real_time is inherited from superclass dsge

frontier

Compute standard devations of the model for a grid over a given parameter
f = frontier(obj,lambda_name,lambda_vals)
Args:

obj (rise | dsge): model object

lambda_name (char): name of the parameter to vary

lambda_vals (vector): 1 x 2 or 1 x N vector of values for the parameter. When N=2, a grid of 50 points is constructed between the two values. When N>2, lambda_vals is the grid.

simul (true | {false}): use simulation instead of theoretical moments.

seed (numeric | {1971}): seed for simulations

Returns:

f [struct]: standard deviations of all variables in the model for each value of lambda_name and some further information about the simulation process under a substructure with name stats__. The fields of the sub-structure are:

lambda [vector]: discretized values of lambda

ngrid [scalar]: number of grid points

simul_periods [integer]: number of simulations. If strictly positive, then simulation is used for computing the moments of the process

retcode [vector]: information on how successful each run in the grid is. if retcode=0, there is no problem. If retcode different from zero, then the information can be retrieved by running decipher(retcode)

Note

improvements to consider are how to deal with regime switches or nonlinear models in general. One solution is to use simulation

Help for rise/frontier is inherited from superclass dsge

get

Fetches information from generic objects
[Reply,retcode] = get(obj,PropertyName)
Args:

obj (rise | dsge | rfvar | svar): model object

PropertyName (char): name of the property or element desired. This
includes:

‘structure’ [char]: derivatives + transition matrices + other information need to solve the model

‘equations’ [char]: all dynamic model equations in their transformed form

‘equations(number)’ [char]: specific set of dynamic model equations in their transformed form. “number” can be a scalar or a vector. e.g. 3, [1,4,20], etc.

‘equations(type)’ [char]: all equations of a specific type. “type” must be one of the following:

‘original’ : original dynamic equations.

transf’ : transformed dynamic equations to fit the format Ef(x{t+1},x{t},x{t-1},e{t},theta)=0

shdyn’ : transformed and encoded equations as processed internally

shssmodel’ : encoded steady-state model equations as processed internally.

ssmodel’ : steady-state model equations.

tags’ : Tags on the dynamic equations

‘equations(number,type)’ [char]: specific equations of a specific type. E.g.:

‘equations(original,5)’ : Returns the 5th original dynamic equation.

‘equations(transf,3:5)’ : Returns equations 3 to 5 from transformed dynamic equations.

‘definitions’ [char]: definitions. This requires the model to be solved. If there are no definitions or if the definitions have been substituted, the result will be an empty structure.

‘solution’ [char]: solution of the model

‘bgp’ [char]: balanced growth path. It is also possible to further taylor the output:

‘bgp’|’bgp(default)’ will give the same result (default) result

‘…(struct)’ will return the BGP in vector of structures, where each structure is a separate regime

‘…(cell)’ will return the BGP in a cell array in which the first column is the list of variables and the subsequent columns are the different regimes.

N.B. For linear variables the BGP is x_t-x_{t-1}, whereas for log-linear variables the BGP is x_t/x_{t-1}

‘sstate’ [char]: steady state. It is also possible to further taylor the output:

‘sstate’ | ‘sstate(default)’ will give the same result (default) result

‘…(struct)’ will return the sstates in vector of structures, where each structure is a separate regime

‘…(cell)’ will return the sstates in a cell array in which the first column is the list of variables and the subsequent columns are the different regimes.

‘description’ [char]: description of all the atoms in the model. The description can take two forms: (1) some text only: “Inflation” (2) some text with latex split: “Inflation # pi”:

get(m,’description’) will give the entire description e.g. “Inflation # pi”

get(m,’description(long)’) will give the text only e.g. “Inflation”

get(m,’description(math)’) will give the latex/math part only e.g. “pi”

‘parameters’|’par_vals’ [char]: parameter values. It is also possible to further taylor the output:

‘parameters’|’parameters(default)’|’par_vals’|’par_vals(default)’ will give the same result: only the declared parameters will appear and for switching ones, the name will be appended with the chain name and the state. This is the most natural way of getting parameters and setting parameters from this output should be unproblematic.

‘…(legacy)’ will return the parameters without appending the name of the chain and the state of the chain. The parameter values are given for all regimes. It is not advisable to push the parameters “set(m,’parameters’,p)” in this form.

‘…(struct)’ will return the parameters in vector of structures, where each structure is a separate regime

‘…(cell)’ will return the parameters in a cell array in which the first column is the list of the parameters and the subsequent columns are the different regimes.

‘par_list’ [char]: list of parameters. Instead of the full list, a sub-list or its complement (using a “~” sign in from of the attribute) can also be queried:

‘…(switching)’ : list of parameters that are switching

‘…(trans_prob)’ : list of transition probability parameters

‘…(measurement_error)’ : list of measurement-error parameters

‘…(in_use)’ : list of parameters that are in use

‘const_list’ [char]: list of constant terms ordered as p|d|s|x|g (i.e parameters,definitions,endo_stst,exo_stst,endo_growth)

‘par_tex’ [char]: description of the parameters

‘endo_list’ [char]: list of the endogenous variables. Instead of the full list, a sub-list or its complement (using a “~” sign in from of the attribute) can also be queried:

‘…(lagrange_multiplier)’ : Lagrange multipliers for optimal policy models

‘…(static)’: static variables or variables appearing only contemporaneously in the model

‘…(predetermined)’: predetermined variables i.e. variables appearing with lags and not with leads

‘…(pred_frwrd_looking)’: variables appearing with both a lead and a lag

‘…(state)’: endogenous state variables i.e. all variables appearing with a lag

‘…(frwrd_looking)’: variables appearing with leads but not lags

‘…(log_var)’: variables for which a log-linear approximation is declared from within the model file.

‘…(log_expanded)’: variables for which a log-linear approximation is requested after the model object is built.

‘…(auxiliary)’: auxiliary variables automatically created by RISE for support. Leads and lags greater than 1, lags or leads in parameters or exogenous variables.

‘…(original)’: endogenous variables declared in the model file i.e. excluding the auxiliary variables

‘…(affect_trans_probs)’: variables entering the calculation of endogenous probabilities

‘…(hybrid_expect)’: variables for which a hybrid expectation is taken.

‘…(stationary)’: variables that are not trending over time.

‘endo_tex’ [char]: description of endogenous variables

‘exo_list’ [char]: list of exogenous variables. Instead of the full list, a sub-list or its complement (using a “~” sign in from of the attribute) can also be queried:

‘…(observed)’ : list of exogenous variables that are observed

‘…(in_user)’ : list of exogenous variables that appear in the model block

‘exo_tex’ [char]: description of exogenous variables

‘obs_list’ [char]: list of observable variables. Instead of the full list, a sub-list or its complement (using a “~” sign in from of the attribute) can also be queried:

‘…(endogenous)’ : list of observable variables that are endogenous.

‘obs_tex’ [char]: description of observable variables

‘def_list’ [char]: list of definitions

‘chain_list’ [char]: list of markov chains

‘chain_tex’ [char]: description of markov chains

‘regime_list’ [char]: list of regimes (i.e. composites of states from different chains)

‘regime_tex’ [char]: description of regimes. Few things to keep in mind :

if you give names to the different states, those names will be used in the description of the regimes

if you give names to the regimes, the regimes will not be described, i.e. written as regime_1(policy=1 & const=1 & vol=1)

The description always includes const=1

‘state_list’ [char]: list of states of all the markov chains

‘state_tex’ [char]: description of the states of all the markov chains

‘tex’|’description’ [char]: description for all the atoms in the system.

‘state_vars’ [char]: variables and their lag structure as required for forecasting.

‘mode’ [char]: parameters maximizing the posterior distribution

‘prior_mean’ [char]: prior mean of the parameters

‘start’ [char]: initial values for estimation (maximization of the posterior)

pname [char]: name of a particular parameter in the models

sstate_exogenous [char]: steady state for exogenous variables, which is not always zero. Very useful for instance in the context of deterministic simulations

Returns:
:

Reply []: value for the queried property/information

retcode [numeric]: 0 if an error is not encounted

Note: It is possible to get the math tex_name for any tex_name type e.g. get(m,’par_tex(math)’). You may want to also try get(m,’par_tex(math)’) or get(m,’par_tex(decoy)’)

Example:

growth_database

INTERNAL FUNCTION

hessian

Computes the hessian of the model at a specific point
[obj,H,issue] = hessian(obj)

[obj,H,issue] = hessian(obj,x)

[obj,H,issue] = hessian(obj,x,varargin)
Args:

obj (rise | dsge | rfvar | svar): model object

x ([] | vector): vector at which one wants to compute the hessian

varargin: additional optional inputs among which the most relevant for estimation is:

hessian_type [{‘fd’}|’opg’]: The hessian is either computed by finite differences (fd) or by outer-product-gradient (opg)

Returns:
:

obj [rise|dsge|rfvar|svar]: model object containing the new hessian in case the model was previously estimated.

H [d x d matrix]: hessian matrix

issue [char|’’]: any issue encountered during the computation of the hessian

Help for rise/hessian is inherited from superclass estimable

historical_decomposition

historical_decomposition Computes historical decomposition of a nonlinear DSGE model

Syntax:
mycontrib=historical_decomposition(m)

mycontrib=historical_decomposition(m,sim_engine)

mycontrib=historical_decomposition(m,sim_engine,nsim)

mycontrib=historical_decomposition(m,sim_engine,nsim,groups)

mycontrib=historical_decomposition(m,sim_engine,nsim,groups,varargin)
Inputs:

m : [rise|dsge] model(s) for which to compute the historical decomposition. m could be a vector of models. The computation of the historical decomposition requires a computation of smoothed history. Hence either m should contain all the information needed for that purpose or the information should be passed along through varargin below

sim_engine : [empty|function handle] function computing forecasts

nsim : [empty|numeric|{100}] Number of simulation to consider for the integration exercise. nsim is automatically set to 1 if the model is detected to be solved at order 1 and not contain regime switches.

groups : [structure|cell array |{empty}] grouping of shocks in the decomposition. By default, the shocks are not grouped. The syntax is of the form {group1,{v11,v12,…},…,groupn,{vn1,vn2,…}}. The shocks that are not listed are put in a special group called “others”. The “others” group does not include the effect of initial conditions. e.g. p=struct(); p.demand={‘Ey’,’Er’}; p.supply={‘Ep’}; e.g. p={‘demand’,{‘Ey’,’Er’},’supply’,{‘Ep’}};

varargin : additional information needed for the computation of the smoothed quantities through filtration.

Outputs:

mycontrib : [struct|cell array] structure or cell array of structures with the contributions in each model and each solution. The decompositions are given in terms of:

the exogenous variables

init : the effect of initial conditions, which includes the steady state!!!

Remarks:

N.B : For a nonlinear model (e.g linear but switching), the type of decomposition/historical_decomposition we do for linear/linearized constant-parameter models is not feasible. RISE uses a monte carlo integration to provide an approximation to the decomposition/historical_decomposition

N.B : if m is a vector of models, then each model should return a unique solution (implying a unique filtration), else the concatenation of decompositions will fail. In that case it is better to run one model at a time.

N.B : When a model has multiple solutions, there is no guarantee that every solution will have succeed at filtration. For this reason, the result of each decomposition is stored in a separate cell. Empty cells represent the solutions for which the filtration could not be obtained.

N.BFor variables declared as @endogenous(log), the
decomposition is given in terms of the transformed variable (log) and not in terms of its level or original units.

Examples:

See also

rise/historical_decomposition

Help for rise/historical_decomposition is inherited from superclass dsge

historical_decomposition_switch

historical_decomposition Computes historical decomposition of a regime-switching DSGE model

Syntax:
mycontrib=historical_decomposition_switch(m)

mycontrib=historical_decomposition_switch(m,groups)

mycontrib=historical_decomposition_switch(m,groups,varargin)
Inputs:

m : [rise|dsge] model(s) for which to compute the historical decomposition. m could be a vector of models. The computation of the historical decomposition requires a computation of smoothed history. Hence either m should contain all the information needed for that purpose or the information should be passed along through varargin below

groups : [structure|cell array |{empty}] grouping of shocks in the decomposition. By default, the shocks are not grouped. The syntax is of the form {group1,{v11,v12,…},…,groupn,{vn1,vn2,…}}. The shocks that are not listed are put in a special group called “others”. The “others” group does not include the effect of initial conditions. e.g. p=struct(); p.demand={‘Ey’,’Er’}; p.supply={‘Ep’}; e.g. p={‘demand’,{‘Ey’,’Er’},’supply’,{‘Ep’}};

varargin : additional information needed for the computation of the smoothed quantities through filtration.

Outputs:

mycontrib : [struct|cell array] structure or cell array of structures with the contributions in each model and each solution. The decompositions are given in terms of:

the exogenous variables

init : the effect of initial conditions, which includes the steady state!!!

Remarks:

N.B : For a model with switching, RISE adds the contribution of the switching process

N.B : if m is a vector of models, then each model should return a unique solution (implying a unique filtration), else the concatenation of decompositions will fail. In that case it is better to run one model at a time.

N.B : When a model has multiple solutions, there is no guarantee that every solution will have succeed at filtration. For this reason, the result of each decomposition is stored in a separate cell. Empty cells represent the solutions for which the filtration could not be obtained.

N.BFor variables declared as @endogenous(log), the
decomposition is given in terms of the transformed variable (log) and not in terms of its level or original units.

Examples:

See also

rise/historical_decomposition

Help for rise/historical_decomposition_switch is inherited from superclass dsge

indirect_inference

indirect_inference : Estimates coefficients using indirect inference
[outputs]=indirect_inference(m,myobjective)
[outputs]=indirect_inference(m,myobjective,varargin)
Args:

m (rise | dsge): scalar or vector of model objects.

myobjective (function handle):

Function with call [critmin,retcode]=myobjective(m)

Inputs:

m: Model object

Outputs:

critmin: Evaluated criterion to minimize

retcode: Flag set to 0 if the criterion is successfully computed and a different integer otherwise.

varargin : usual options for a dsge/rise object

Returns:
:

varargout: Variable number of output arguments from estimate(m).

Note:

Help for rise/indirect_inference is inherited from superclass dsge

initial_conditions

INTERNAL FUNCTION

growth_type,’zero’ growth_type,’steady’

initial_sstate

initial_sstate : provides a template for initial values in the calculation of the steady state of a dsge model

Syntax
db=initial_sstate(obj)
Args:

obj (rise | dsge): scalar or vector of model objects.

Returns:

db [struct | cell]: structure or cell array of structures if
several models are given as input. the fields of a structure are the names of the endogenous variables of the model. The number of concatenated structures is the number of regimes of the model. each field is a 1 x 2 cell array. e.g bounds.C={sstateInfo,bgpInfo} where sstateInfo and bgpInfo are 1 x 3 vectors organized as [start_value,lower_bound,upper_bound].

Note:

The information in each structure is given in original units/levels of the variables before any potential log transformation.

See also rise.sstate

Help for rise/initial_sstate is inherited from superclass dsge

irf

Computes impulse responses for a RISE model
[myirfs,retcode]=irf(obj)

[myirfs,retcode]=irf(obj,varargin)
Args:

obj (rise | dsge): single or vector of RISE models

varargin : optional options coming in pairs. The notable ones that will influence the behavior of the impulse responses are:

irf_shock_list [char | cellstr | {‘’}]: list of shocks for which we want to compute impulse responses

irf_var_list [char | cellstr | {‘’}]: list of the endogenous variables we want to report

irf_periods [integer | {40}]: length of the irfs

irf_shock_sign [numeric | -1 | {1}|struct]: sign or scale of the original impulse.

If irf_shock_sign is numeric and scalar and >0, we get impulse responses to a positive shock. If irf_shock_sign <0, the responses are negative. If If irf_shock_sign =0, all the responses are 0.

If irf_shock_sign is a structure, the fields are names of shocks. This is not a proper impulse response as such but a scenario with a cocktail of shocks. Note that in this case, the irfs are only computed for the cocktail of shocks. However, the result is written to all the shocks and therefore, the output is identical for all individual shocks !!!

irf_draws [integer | {50}]: number of draws used in the simulation impulse responses in a nonlinear model. A nonlinear model is defined as a model that satisfies at least one of the following criteria

solved at an order >1

has more than one regime and option irf_regime_specific below is set to false

irf_type [{irf} | girf]: type of irfs. If the type is irf, the impulse responses are computed directly exploiting the fact that the model is linear. If the type is girf, the formula for the generalized impulse responses is used: the irf is defined as the expectation of the difference of two simulation paths. In the first path the initial impulse for the shock of interest is nonzero while it is zero for the second path. All other shocks are the same for both paths in a given simulation.

irf_regime_specific [{true} | false]: In a switching model, we may or may not want to compute impulse responses specific to each regime.

irf_girf_regime_uncertainty [{false} | true]: If we consider regimes as shocks, then they should be treated as other structural shocks under generalized impulse response functions : the path for the regimes across the two simulations needed for computing an impulse response is the same (uncertainty = false). Otherwise the sequence of regimes may differ in the two simulations (uncertainty =true).

irf_initial_conditions [{empty} | struct]: if not empty, this is a structure with fields endogenous and regime

irf_order [{empty} | integer]: order of the solution simulation of the irfs. If the order is greater than solve_order, the model is resolved.

irf_to_time_series [{true} | false]: If true, the output is in the form of time series. Else it is in the form of a cell containing the information needed to reconstruct the time series.

irf_truncate_real_time [{true} | false]: If true, under anticipated shocks, only the first page is returned. Otherwise, all pages are returned.

Returns:

myirfs [{struct}|cell]: Impulse response data

retcode [{0}|numeric]: return code in case different from 0 if
there is a problem

Note:

for linear models or models solved up to first order, the initial conditions as well as the steady states are set to 0 in the computation of the impulse responses.

for nonlinear models, the initial conditions is the ergodic mean

Help for rise/irf is inherited from superclass dsge

is_forward_guidance_puzzle

is_forward_guidance_puzzle: Checks whether a DSGE model exhibits a forward-guidance puzzle.

The function can handle multiple models simultaneously, and each model can have multiple parameterizations. Under regime switching, it is not possible to characterize the forward guidance as in constant-parameter models because the impact of shocks differs across regimes.

Syntax:
o=is_forward_guidance_puzzle(m)

o=is_forward_guidance_puzzle(m,errIfMultReg)
Inputs:

m: DSGE model or an array of DSGE models to analyze.

errIfMultReg [{true}|false]: If True, raise an error when handling regime switching models. If False, assume shock impacts are the same across regimes.

Output:

o: A logical array indicating whether each model exhibits a forward-guidance puzzle for each parameterization and regime.

maxEig: maximum eigenvalue criterion

The function checks whether a given DSGE model or a list of DSGE models exhibit a forward-guidance puzzle. The forward-guidance puzzle occurs when the model’s dynamics lead to explosive responses to future shocks.

This function returns a logical array where each element corresponds to a specific model parameterization and regime. A value of True indicates that a forward-guidance puzzle is present, and False indicates no forward-guidance puzzle.

Note

When analyzing a single model, the result is a logical array.

When analyzing multiple models, the result is a cell array of logical arrays, with one element for each model.

Warning

When dealing with regime-switching models (models with multiple regimes), setting errIfMultReg=True will raise an error because it’s not possible to characterize forward guidance in such models due to differing shock impacts across regimes.

Help for rise/is_forward_guidance_puzzle is inherited from superclass dsge

is_stable_system

Checks the stability of a linear markov switching system.

Syntax
flag = is_stable_system(obj)

flag = is_stable_system(obj,varargin)
Args:

obj (dsge|rise): model object

varargin (name,value): pairwise valid options for RISE. The most relevant in this case are

stability_criterion (numeric\|{1.000001}): stability criterion. All eigenvalues must be smaller than this criterion for the system to be MSS

stability_algorithm (‘cfm’\|{‘gmh’}): CFM stands for Costa-Fragoso-Marques while HMG stands for Hassibi-Murray-Gupta.

Returns:

flag (false\|true|vector|cell array): result of the investigation on whether the system is stable or not.

retcode (0|25|vector|cell array): result of the investigation on whether the system is stable or not.

overall_retcode (0|25|vector): result of the investigation on whether the system is stable or not.

cellFlag (cell array): stability flag for each parameterization

Note:

RISE implements two algorithms from the engineering literature to check for the stability. They are

Costa-Fragoso-Marques [Costa et al., 2005]

Hassibi-Murray-Gupta [Gupta et al., 2003]

Refer to the references to see the specific algorithms. However, for most applications, one can just use the default options.

References:

[Costa et al., 2005]

[Gupta et al., 2003]

is_stationary_system

Checks whether a the model is stationary. i.e., does not containt trending variables
flag=is_stationary_system(obj)
Args:

obj (rise|dsge): rise/dsge model object

Returns:
:

flag (bool): true if the model is stationary

Note:

There is a difference between stability and stationarity

stability refers to the system as a whole and conditions for stability are often assessed through eigenvalues inside the unit circle

stationarity refers to a scalar stochastic process. And such a process will be said stationary if its first and second moment do not vary with time.

See also

rise_generic/is_stable_system

Help for rise/is_stationary_system is inherited from superclass dsge

isnan

INTERNAL FUNCTION

itranslate

translate – Translates comprehensible atoms (model variables) into RISE codes
outList=translate(obj,inList)
outList=translate(obj,inList,order)
Args:

obj (rise | dsge): scalar model object.

inList (char | cellstr): List of atoms to translate e.g. C,
X{+1}, lambda_x, EPS_A,

Returns:
:

outList [cellstr]: List of translated atoms

Example:
:

list=get(obj,’endo_list’) outList=itranslate(obj,list) outList=itranslate(obj,list,0) % contemporaneous or steady state

list=get(obj,’exo_list’) outList=itranslate(obj,list)

list=get(obj,’param_list’) outList=itranslate(obj,list)

list=get(obj,’def_list’) outList=itranslate(obj,list)

See also

rise/translate :

Help for rise/itranslate is inherited from superclass dsge

link_parameters

LINK_PARAMETERS Dynamically binds parameters together by creating links between parameters for future evaluation.

m = LINK_PARAMETERS(m, expressions)

This function is responsible for dynamically binding parameters together by creating links between parameters for future evaluation.

m: Scalar or vector of model objects. Each model may have multiple parameterizations.

expressions: Character or cell array of strings representing the expressions to bind. For example, expressions = ‘alpha = beta + gamma’.

Returns: - m: Updated model object with dynamically bound parameters.

Example:
m = LINK_PARAMETERS(m, expressions)

See also

rise.view_linked_parameters, rise.unlink_parameters

Help for rise/link_parameters is inherited from superclass dsge

loadObj

loadObj loads a dsge object from a MAT file.

Help for rise.loadObj is inherited from superclass dsge

load_parameters

load_parameters loads the parameters. This allows the user to quickly load the parameters from a file, which may be the output of estimation, and get going with irfs, simulations, etc.
model=load_parameters(model,the_mode_file)
Args:

model (estimable object): model object

the_mode_file (m-file): file containing the parameters and their values

Returns:

model (estimable object): reparameterized model object

Help for rise/load_parameters is inherited from superclass estimable

log_posterior_kernel

Computes the log posterior of the dsge model
[log_post,log_lik,log_prior,Incr,retcode,obj]=log_posterior_kernel(obj, param)
Args:

obj (estimable object): model object

param (column vector): parameter values

Returns:

log_post (double): log posterior

log_lik (double): log likelihood

log_prior (double): log prior

Incr (double):

retcode : return code

obj (estimable object): model passed through

See also

log_prior_density

Note

In effort to make RISE modular, this function is available so that one can use a different sampler if needed, but most likely, one should just use available stock samplers.

Help for rise/log_posterior_kernel is inherited from superclass estimable

log_prior_density

Computes the probability density function of the prior corresponding to the parameter values
[lnprior, retcode] = log_prior_density(model)
[lnprior, retcode] = log_prior_density(model, param)
[lnprior, retcode] = log_prior_density(model, param,filtration)
Args:

model (estimable object): model object

param (column vector): parameter values

filtration (empty|struct): results from model filtration that can potentially be used for endogenizing priors.

Returns:

lnprior (double): log of prior density function

retcode: return code

See also

log_posterior_kernel

Note

In effort to make RISE modular, this function is available so that one can use a different sampler if needed, but most likely, one should just use available stock samplers.

Help for rise/log_prior_density is inherited from superclass estimable

map_solution

MAP_SOLUTION Transforms the solution of a DSGE/RISE model object into a start value for the solution of another DSGE/RISE model object.

This function maps fields in a solution structure (e.g., Tz, Tzz, Tzzz, …) from a reference model (m1) to align with the organization and structure of a target model (m2). Each field represents a matrix of model parameters at different orders, and columns are Kronecker products of the state list. The function generates the Kronecker products as needed and maps values across structures based on row and column indices.

Syntax:
[Sol2, adjudicator] = map_solution(m1, m2) [Sol2, adjudicator] = map_solution(m1, m2, fill_option)

Inputs:
m1            - First/reference DSGE model object in RISE.
                Must have only one parameterization and one solution.
m2            - Second DSGE model object in RISE, which will receive the
                mapped solution structure.
fill_option   - Specifies how to handle additional regimes in m2
                if m2 has more regimes than m1. Options:
                  'zeros'          - (Default) Fills additional regimes with zero matrices.
                  'replicate_last' - Replicates the matrix of the last regime in `Tzk2`
                                     across all additional regimes.
                  'extrapolate'    - Extrapolates a trend based on the last two regimes.
                                     Only valid if `num_regimes_m1 > 1`.
                  'average'        - Fills additional regimes with the average matrix
                                     computed across all existing regimes in `Tzk2`.
                  'random'         - Fills additional regimes with random values within
                                     the range (min, max) of each element across all regimes.
Outputs:

Sol2 - Transformed solution structure where each field aligns
with the organization of the solution in model m2.

adjudicator - Function handle to modify specific entries in Sol2 by
name, usage: adjudicator(endo_name, state_name, value, regime)

Internal Workflow:

Input Validation: Checks that both m1 and m2 are DSGE model objects, and that m1 has only a single parameterization and solution.

Generate Lists: Uses helper function lift_from_models to retrieve the solution (Sol1) and lists of endogenous and state variables for both models.

Kronecker Expansion and Mapping: For each field (e.g., Tz, Tzz, etc.) in Sol1, iteratively generate Kronecker-expanded column names and align the rows and columns to match the structure of m2.

Value Assignment: Populate Sol2 with values from Sol1 for shared regimes. Additional regimes in m2 are filled according to fill_option.

Provide Adjudicator Function: A nested function that allows specific entry modifications in Sol2 by name. This function can access each level of Kronecker expansion.

Example Usage:
% Map solution from m1 to m2 and update specific entries in Sol2 [Sol2, adjudicator] = map_solution(m1, m2); adjudicator(‘A’, ‘X,Y’, 3.5, 1); % Sets the entry at (A, ‘X,Y’) in Sol2 for regime 1 to 3.5

Help for rise/map_solution is inherited from superclass dsge

max_discrepancy

max_discrepancy – Calculate the maximum absolute difference between the solutions of two DSGE models.

This function calculates the maximum absolute difference between the solutions of two DSGE (Dynamic Stochastic General Equilibrium) models. It can be used to assess the dissimilarity between the state space representations of two models.

INPUTS: - m1: The first DSGE model. - m2: The second DSGE model.

OUTPUT: - o: The maximum absolute discrepancy between the two models.

The function works by comparing various properties of the state space representation of the two models, such as state transition matrices, transition matrices for different orders, and covariances of measurement errors.

EXAMPLE: - Calculate the maximum discrepancy between two DSGE models model1 and model2:

` max_discrepancy(model1, model2); `

Help for rise/max_discrepancy is inherited from superclass dsge

mode_curvature

Checks the curvature at the posterior mode
db = mode_curvature(obj)

db = mode_curvature(obj,varlist)

db = mode_curvature(obj,varlist,N)

db = mode_curvature(obj,varlist,N,type)
Args:

obj (rise | dsge | rfvar | svar): model object

varlist (char | cellstr | empty): list of parameters for which we want to check the curvature

N ({20} | integer): Number of grid points

type ({‘max’} | ‘min’ | ‘range’): normalization of the log-posterior and the log-likelihood.

dbin (struct|empty): structure containing the information to plot the curvature. Each field is the name of a particular parameter. This is to avoid a costly recomputation of db

Returns:

db [struct|cell array|vector]: structure containing the information to plot the curvature. Each field is the name of a particular parameter. Alternatively, when dbin is not empty, db is a handle to the plots.

Note:

when no output is requested, plots are made but not saved.

one way to plot the curvatures from the output is to use the function utils.plot.curvature

See also

utils.plot.curvature

Help for rise/mode_curvature is inherited from superclass estimable

model_information

rise/model_information is a function.: out = model_information(obj, info)

observables_decomposition

Decomposes all variables of a DSGE model in terms of observables.

Syntax
weights=observables_decomposition(obj,select,xrange,db)

[weights,dec1,...,decn]=observables_decomposition(obj,select,xrange,db1,...,dbn)
Args:

obj (rise | dsge): scalar model object

select ({[]} | ‘a’ | ‘att’ | ‘alpha’ | ‘v’ | ‘r’ | ‘epsilon’ | ‘eta’): type of decomposition to perform

a : filter

att : update

alpha : smooth

v : forecast errors

r : variables calculated during the smoothing process

epsilon : measurement errors

eta : structural shocks

[] : all the above

xrange ({[]} | vector | cell array): start date and end date for the decomposition

db (ts): database with the data to be used in the decomposition

Returns:

weights [struct]: weights for the different elements requested from the variable select

dec1 [struct]: hyper structure containing the time series for the various decomposition types and variables

Note:

if select is empty, all the decompositions are performed

After doing the decomposition of different variables, one can take the differences in the decomposition to perform, e.g., the decomposition of forecast errors in terms of observables.

See also

historical_decomposition

Help for rise/observables_decomposition is inherited from superclass dsge

optimal_simple_rule

optimal_simple_rule : Estimates optimal simple rules coefficients
[m]=optimal_simple_rule(m,lossstr)
[m]=optimal_simple_rule(m,lossstr,shocks)
[m]=optimal_simple_rule(m,lossstr,[],varargin)
[m]=optimal_simple_rule(m,lossstr,shocks,varargin)
Args:

m (rise | dsge): scalar or vector of model objects.

lossstr (string|cell array): loss function two possibilities

string : lossString. In this case discount = 0.99

cell array : {discount,lossString}

priors (struct): parameters to estimate

shocks (ts | struct | double| function handle| empty): if empty, the
theoretical (unconditional) welfare will be calculated. Otherwise the conditional welfare will be computed.

Returns:
:

m [scalar|vector]: scalar or vector of model objects.

Note:

Help for rise/optimal_simple_rule is inherited from superclass dsge

parameters_to_file

PARAMETERS_TO_FILE Writes the parameters of a model object to a file.

PARAMETERS_TO_FILE(model, fname) writes the parameters of the model object (typically a DSGE model) to a file with the specified filename.

Inputs: - model: Model object containing the parameters. - fname: File name to write the parameters to. The extension should be “.m”.

Example:
parameters_to_file(model, ‘parameters_file.m’)

See also

get

Help for rise/parameters_to_file is inherited from superclass dsge

perfect_foresight

perfect_foresight : Perfect foresight and extended path simulations
[db, fval, retcode] = perfect_foresight(obj, varargin)
Args:
obj [dsge|rise]: model object
varargin : additional arguments including but not restricted to
simul_stack_solve_algo [{‘sparse’}|’fsolve’|’lsqnonlin’|cell]: Algorithm or ordered fallback chain for solving the problem. When given as a nested cell array each element is {algo, opts}:
{ {'sparse',opts1}, {'fsolve',opts2}, {'lsqnonlin',opts3} }
The default ‘sparse’ solver (rise_newton) is a damped Newton method whose convergence is judged on the max-abs (infinity norm) residual (scale-invariant, so a fixed tolerance is reachable at any horizon). Its options accept a JacobianUpdate field controlling Jacobian / factorization reuse: 1 (default) = full Newton (refactorize every iteration); inf = modified Newton (factorize once and reuse the LU factors, refreshing adaptively only when the line search backtracks); K>1 = refactorize every K iterations. Reuse cuts the cost of the linear solve on long horizons while leaving the solution unchanged.
simul_reuse_sstate [true|{false}]: skip the internal steady-state re-solve when the model handed in is already solved (is_solved_stst==1), reusing its stored steady state. Useful for pre-solved / repeated / extended-path runs. Default false keeps the normal solve-on-demand behaviour.

simul_initial_guess [{‘sstate’}|’linear’]: choice of Newton seed for NaN interior cells. 'sstate' (default) fills every NaN endogenous cell with the prevailing regime’s steady state – the constant-in-time guess. 'linear' forward-iterates the first-order perturbation solution from the period-0 initial condition through the horizon (with whatever exogenous values the plan supplies) and uses that linear path as the seed; pinned cells stay pinned. The linear seed dramatically cuts Newton iteration count on scenarios where the new state is far from the old (permanent shifts, regime changes, large impulses). Requires the model to carry a first-order perturbation solution; if state_space is empty the solve is triggered lazily at solve_order = 1.

simul_enforce_hybrid [true|{false}]: force all blocks to be solved as hybrid (both backward and forward looking).

simul_pf_bounds [struct|{empty}]: box constraints on endogenous variables during simulation.
Returns:
sims [struct]: simulated series. In the recursive case (npages>1), sims.expectations is a 3D array (nvar x bigt x npages) storing the full expectations history:
page 1 = realized values
page p = p-1 step-ahead expectation formed at each time t
fval [scalar]: maximum residual norm across all passes

retcode [integer]: 0 = success; else call decipher(retcode)
Algorithm:
Standard PF (npages==1): single pass over the full horizon.

Recursive extended path (npages>1):
  At each pass t = 1..bigt the solver window shrinks naturally:
    width = ncols - t + 2  (one less column per pass)
  NaN in yxr page 1 = free variable (solver optimises)
  non-NaN in yxr page 1 = fixed (held constant)
  Pages 2:npages supply surprise conditioning at time t.
  No-surprise shortcut: if pages 2:npages are all NaN at t and a
  previous solution exists, shift it left by one -- no re-solve.
See also

rise.simulate

Help for rise/perfect_foresight is inherited from superclass dsge

plan2database

plan2database creates a database suitable for conditional forecasting
db=plan2database(obj,plan,start_date,end_date)
Args:

obj (rise | dsge): model file

*plan*n x 3 cell array where n is the number of conditions

the first column includes the names of the variables in strings or in cell array

the second column includes the dates for conditioning

the third column includes the values scalar or vectors

*start_date*: start date of the database as recognizable by the ts
class. this is typically the end of history

*end_date*: end date of the database as recognizable by the ts
class.

Returns:
:

db [ts]: time series object with the various variables in and conditioning information

N.B:
:

There cannot be multiple variables and multiple dates simultaneously in one row

See also ts.fold, rise.growth_database, rise.initial_conditions

Help for rise/plan2database is inherited from superclass dsge

posterior_sample

Computes a sample of any quantity of interest using parameter draws from a population e.g. a posterior simulation
[result]=posterior_sample(m,pop,dowhat)

[result]=posterior_sample(m,pop,dowhat,howmany)

[result]=posterior_sample(m,pop,dowhat,howmany,ouf)

[result]=posterior_sample(m,pop,dowhat,howmany,ouf,varargin)

[result,is_failed,time_it_took]=posterior_sample(...)
Args:

m [rise|dsge|svar|rfvar|valid rise object]: model object

pop [m x n struct]: parameter draws, with “m” the number of chains and “n” the number of draws in each chain. Each element of “pop” is a structure with fields “f” (not used), the value of the posterior and “x” the parameter vector

dowhat [fhandle]: function (handle) to apply to each parameterized model object. e.g. dowhat=@irf, dowhat=@simulate, dowhat=@forecast, etc. “dowhat” need not be a method of “m”: it represents the quantity of interest.

howmany [integer|{m x n}]: number of draws to use in the calculation

ouf [fhandle|{[]}]: output update function. Function that updates the output before storing it. e.g. if dowhat=@filter, one may be interested in the filters only and in that case ouf=@(x)x.filtering.

varargin [pairwise args]: valid pairwise arguments for the model object

Returns:

result [1 x howmany cell]: container of the various applications of the “dowhat” handle

time_it_took [numeric]: number of seconds needed to run all the simulations.

See also

draw_parameter

Note

the function will exploit parallel computation if there are workers idle.

Because the solving of the model is sometimes iterative, a change of solver or of the settings of the solver can result in the model not being solved or more generally simulations failures. The algorithm will loop until the requested number of simulations is obtained. But it will not point to the parameter vectors that fail.

Help for rise/posterior_sample is inherited from superclass estimable

predictive_analysis

PREDICTIVE_ANALYSIS: Perform predictive analysis for a dsge model

[draws, ok, retcode, timing, varargout] = predictive_analysis(m, priors, userfun)

[draws, ok, retcode, timing, varargout] = predictive_analysis(…,myDrawsMatrix)

[draws, ok, retcode, timing, varargout] = predictive_analysis(…,’halton’)

[draws, ok, retcode, timing, varargout] = predictive_analysis(…,{‘halton’,N})

[draws, ok, retcode, timing, varargout] = predictive_analysis(…,’sobol’)

[draws, ok, retcode, timing, varargout] = predictive_analysis(…,{‘sobol’,N})

[draws, ok, retcode, timing, varargout] = predictive_analysis(…,’latin_hypercube’)

[draws, ok, retcode, timing, varargout] = predictive_analysis(…,{‘latin_hypercube’,N})

[draws, ok, retcode, timing, varargout] = predictive_analysis(…,’prior’)

[draws, ok, retcode, timing, varargout] = predictive_analysis(…,{‘prior’,N})

Inputs:

m (rise/dsge model object): RISE/DSGE model object.

priors (structure): Structure with parameter names and their distributions.

userfun (function_handle): Function that checks whether a particular parameterization yields the desired outcome. The function should take as input the parameterized model (m) and return at least two outputs in which the first is a boolean (true or false) and the second is the retcode. The function can return additional outputs that will be captured in varargout (see below).

DrawsInfo: could be

Matrix : this represents the draws computed/obtained elsewhere

char : procedure to use for the draws ({‘prior’}|’latin_hypercube’|’sobol’|’halton’):

cell array : {procedure,N} where N is the number of draws with default value 2^12.

Outputs:

draws (numeric): Draws from the sampling.

ok (logical): 1 x n vector of booleans, with true where a particular parameter vector checks the desired behavior.

retcode (numeric): 1 x n vector of return codes, where 0 means there are no problems.

timing (structure): Structure with the timing of various sampling.

varargout (cell): User desired additional outputs beyond the two first outputs of userfun

Notes:

The function performs prior predictive analysis by drawing parameter values from specified distributions and checking their effects using a user-defined function.

The function can exploit parallelization if workers are fired up.

Example:

` [draws, ok, retcode, timing, o3,o4,...,on] = predictive_analysis(m, priors, userfun); `

See also: QUASI_MONTE_CARLO

Help for rise/predictive_analysis is inherited from superclass dsge

print_estimation_results

PRINT_ESTIMATION_RESULTS: Display the results of estimation.

retcode = print_estimation_results(obj) retcode = print_estimation_results(obj, detail)

Args:

obj (estimable): Model object.

detail (true|{false}): If true, the description of parameters is given alongside the code name. If they are the same, i.e., the description has not been provided, then the code name is given only once.

Returns:

retcode (numeric): 0 if there is no problem.

Notes:

If there are multiple objects in the array, each object’s results will be displayed.

The function displays information such as log-posterior, log-likelihood, log-prior, etc.

The displayed results include information about the estimation sample, solution algorithm, estimation algorithm, number of estimated parameters, number of function evaluations, and the time taken for estimation.

If there are any issues, a list of issues is displayed.

Example:
print_estimation_results(obj) print_estimation_results(obj, true)

See also: TABLE_DISPLAYER

Help for rise/print_estimation_results is inherited from superclass estimable

print_solution

Print the solution of a model or vector of models
print_solution(obj)
print_solution(obj,varlist)
print_solution(obj,varlist,orders)
print_solution(obj,varlist,orders,compact_form)
print_solution(obj,varlist,orders,compact_form,chop)
print_solution(obj,varlist,orders,compact_form,chop,capture)
Args:

obj (rise | dsge): model object or vector of model objects

varlist (char | cellstr | {[]}): list of variables of interest

orders (numeric) : orders for which we want to see the solution (default: [1:solve_order])

compact_form ({true} | false): if true, only the solution of unique tuples (i,j,k) such that i<=j<=k is presented. If false, the solution of all combinations is presented. i.e. (i,j,k)(i,k,j)(j,i,k)(j,k,i)(k,i,j)(k,j,i)

chop ({1e-9} | numeric >0 && <1e-4) : any number, which in absolute value is less than chop is set to 0.

capture ({‘’} | char) : generic name for files to be written to disk in capturing the solution for each model.

Returns:

outcell [cellstr] : dummy output not important, kept for legacy compatibility. Might be removed in future versions

Note

In the state vector (first column), the variables appearing should be understood as deviations from the steady state.

@sig denotes the impact of the perturbation parameter or more technically, the impact of future uncertainty.

for nonstationary models:

the real part of @sig denotes the impact of future uncertainty.

the imaginary part of @sig denotes the growth rate

In constant-parameter models, the impact of future uncertainty is zero for odd orders of perturbation i.e. 1, 3, 5, 7, etc. For a first-order approximation, this result is known as certainty equivalence. In regime switching, sometimes the first-order approximation is not certainty equivalent

When the solution is printed in the presence of log variables, the policy functions appear as follows :

Each log variable X appears as log(X) in the row giving the solution for each variable (first row)

In the state vector (first column) the log variables appear with an asterisk (*). This is to ease the writing of higher-order perturbation solutions as they involve cross products of the state variables. in other words X*{-1} = log(X{t-1})

Help for rise/print_solution is inherited from superclass dsge

pull_objective

Pulls the objective function to optimize
[ff,lb,ub]=pull_objective(obj)
[ff,lb,ub]=pull_objective(obj,varargin)
[ff,lb,ub,x0]=pull_objective(obj,varargin)
[ff,lb,ub,x0,vcov]=pull_objective(obj,varargin)
[ff,lb,ub,x0,vcov,obj]=pull_objective(obj,varargin)
Args:

obj (rise | dsge | svar | rfvar): initial model object

varargin (pairwise addional inputs): usual RISE arguments

Returns:

ff [function handle]: for computing “minus log posterior kernel”

lb [d x 1 vector]: lower bound of the parameters to optimize

ub [d x 1 vector]: upper bound of the parameters to optimize

x0 [d x 1 vector]: posterior mode if available

vcov [d x d matrix]: covariance matrix at the posterior mode if available.

obj [rise|dsge|svar|rfvar]: updated model object

Note:

The function can be used for :

optimization,

gradient computation,

hessian computation,

posterior simulation

The updated object should be used for doing various exercises (irfs, simulations, etc.) if the posterior mode is not computed.

Using this function is potentially costly. One could alternatively simply use log_posterior_kernel. However, if there are restrictions, they will not be enforced. Nevertheless it is an interesting proposition that should be investigated further.

Help for rise/pull_objective is inherited from superclass dsge

randsample

Generate random time series from a model returns K samples of length N
- db=randsample(obj,N,K)
- db=randsample(obj,N,K,varargin)
- [db,states,retcode]=randsample(...)
Args:

obj (rise | dsge | svar | rfvar): model object

N (integer): length of the time series

K (integer): number of time series

varargin : additional options for the model object

Returns:

db [struct]: time series

states [matrix]: NxK matrix of visited states

retcode [numeric]: 0 if no problem

refresh

INTERNAL FUNCTION: - refresh the options of an old object with a newer version of the software

Note:

REFRESH is the same as RISE_GENERIC.REFRESH except that it also refreshes parts of the system that are specific to DSGE or RISE objects.

See also

RISE_GENERIC.REFRESH

Help for rise/refresh is inherited from superclass dsge

regime_partition_analysis

regime_partition_analysis: Perform Monte Carlo simulations on a DSGE model and analyze regime-switching probabilities. Method of RISE/DSGE class.

Parameters: - m: DSGE model object (RISE/DSGE). - nperiods: Number of periods for each simulation. - nsim: Number of Monte Carlo simulations. - Labeling: Structure mapping regime names to indices. - show_progress: Show progress monitor (default: true).

Returns: - figure_handles: Cell array of figure handles. - results: Struct with stats, bigp, summary_table, num_regimes.

Help for rise/regime_partition_analysis is inherited from superclass dsge

resid

Compute the residuals from the steady state
r=resid(obj)
r=resid(obj,trim)
Args:

obj (rise | dsge): model object

trim (true|{false}|1x1 cell|1x2 cell): * if false, print all residuals as is and Do not print equations * if true, set to zero residuals that are less than a tolerance level whose default is 1e-13. Do not print equations * If it is a cell array, then it must be either {tol,false} or {tol,true}. Either element can be empty, the default is {1e-13,false}

the first element is the tolerance level below which all residuals are set to 0

the second element is either “true” or “false” and decides whether to additionally print the equation

Returns:
:

r [vector|matrix]: residuals

Note:

if no output is requested, the residuals are printed on screen

if the model has not been solved, resid will call sstate to try to solve for the steady state, with option imposed set to true in order to avoid reoptimization.

The trim option is for display only. If the function is called with an output argument, trim is not used.

Help for rise/resid is inherited from superclass dsge

resimulate

Uses the intial conditions given in x0h and shocks information in structure fx to resimulate the data using model m. The variables in m not appearing in fx are initialized at zero if x0h is empty

Syntax:
mysimul=resimulate(m,fx)

mysimul=resimulate(m,fx,x0h)

[mysimul,retcode]=resimulate(...)
Inputs:

m : [rise|dsge] model(s) to simulate

fx : (possibly modified output of) filtration.

x0h : (n_x x 1 x h): initial conditions in all the regimes. N.B: this has to be in log-form. If the model has variables declared as @endogenous(log), those variables should be entered here in log. RISE will not take the log of x0h.

fxlogvars : vector of booleans specifying which endogenous variables in fx are log variables

Outputs:

mysimul : [struct|cell array] structure or cell array of structures with the simulations

retcode : [double] return code. 0 if there is no issue

Note: all the simulations are returned in their log-form i.e. they are not re-exponentiated !!!

See also

rise/historical_decomposition

Help for rise/resimulate is inherited from superclass dsge

rise

rise – constructor for dsge models
obj=rise(model_filename)

obj=rise(model_filename,varargin)
Args:
model_filename [char | cellstr]:

if “char”,name of the model file. The file should have extensions rs, rz or dsge.

If “cellstr”
each cell contains the name of a separate model file. The files are then meant to be combined into one single model.
the entire model is given as a cell with an example as follows
simpleModel={
    'model:someModel'
    '%% model without parameters and shocks'
    '@endogenous x'
    '@model'
    'x=1.05\*x{-1};'
    };

m=rise(simpleModel);
varargin []: pairwise arguments with possiblities as follows:

parameter_differentiation [true|{false}]: compute or not parameter derivatives

definitions_inserted [true|{false}]: substitute definitions given in the model block. Necessary if the definitions contain variables.

definitions_in_param_differentiation [true|{false}]: insert or not definitions in equations before differentiating with respect to parameters

saveas [true|false|char|{‘’}]: save the possibly expanded model file. If “true”, the name of the main original file is used appended with “_expanded.dsge”. Alternatively, the user can provide a name under which he wants the file to be saved.

max_deriv_order [integer|{1}]: order for symbolic differentiation. It is recommended to set to 1, especially for large models in case one does not intend to solve higher-order approximations. It is also possible to set it 0 in case one intends to use numerical or automatic derivatives or just do perfect foresight-type of simulations.

parse_debug [true|{false}]: debugging in the parser

rise_flags [struct|cell]: instructions for the partial parsing of the rise file. In case of a cell, the cell should be a k x 2 cell, where the first column collects the conditional parsing names and the second column the values.
Returns:

obj [rise|dsge]: model object

Note

The pairwise options listed above are the ones that will be processed in the parser. Additional options related to specific methods can also be passed at this stage, but will only be applied or used when the specific method dealing with them is called.

In RISE it is possible to declare exogenous and make them observable at the same time. The exogenous that are observed are determisitic. This is the way to introduce e.g. time trends. This strategy also opens the door for estimating partial equilibrium models.

saveObj

saveObj saves the dsge object to a MAT file.

Help for rise/saveObj is inherited from superclass dsge

set

Sets options for dsge|rise models

Syntax
obj=set(obj,varargin)
Args:

obj(rise | dsge): model object

vararginvalid input arguments coming in pairs. Notable fields to
that can be set include and are not restricted to:

parameters [struct|cell] : e.g. set(obj,’parameters’,p), where p is a struct or a cell

parameters(ignore) [struct|cell] same as above but issues a warning instead of an error if a parameter is not found

parameters(vector) [struct|cell] : syntax for multiple parameterization. e.g.

set(obj,’parameters(2)’,p):

set(obj,’parameters(2:3)’,p): As usual, p is either a strucutre or a cell array. In case of a cell array, the first columns gathers the names of the parameters to update and the second column the values to add. dsge_tools.cell2struct is responsible for the dispatch.

set(obj,’parameters([2:3,5,7])’,p): The holes i.e. 4 and 6 are filled with the last parameterization in the model object, which is 1 in the present example

parameters(A,B): Combination of the two above i.e. ignore and vector. e.g.

set(obj,’parameters(ignore,2:3)’,p)

set(obj,’parameters(2:5,ignore)’,p)

solve_shock_horizon [integer|struct|cell]

for the integer case, all shocks are set to the same integer

for the struct case, the input must be a structure with shock names as fields. Only the shock names whose value is to change have to be listed. In this case, different shocks can have different horizons k. The default is k=0 i.e. agents don’t see into the future. The value of the fields is one of the following:

k

{k,chainName_state}

{chainName_state,k}

for the cell case, the cell should have two columns. The first column includes the names of the shocks whose horizon is to change. The second column is one of the following:

the horizon for the shock

{horizon,chainName_state}

{chainName_state,horizon}

solve_function_mode [{explicit/amateur}|vectorized/professional|disk]

in the amateur or explicit mode the functions are kept in cell arrays of anonymous functions and evaluated using for loops

in the vectorized or professional mode the functions are compacted into one long and unreadable function.

in the disk mode the functions are written to disk in a subdirectory called routines.

sstate_exogenous [struct|cell|scalar]: values to push. There are three possibilities:

struct: the fields are the exogenous names and each name contains a exogenous value.

cell: the cell has two columns. The first column holds the names of the exogenous to change and the second column their values.

scalar: the scalar value is pushed as the steady state for all exogenous variables. This is useful for instance when resetting all the steady state values for the shocks.

Returns:
:

obj [rise|dsge]: model object

Example:

obj=set(obj,’solve_shock_horizon’,struct(‘shock1’,2,’shock3’,4))

obj=set(obj,’solve_shock_horizon’,5)

See also generic/set

Help for rise/set is inherited from superclass dsge

set_z_eplus_horizon

SET_Z_EPLUS_HORIZON Modifies the DSGE model’s state-space matrices to respect shock horizons.
OBJ = SET_Z_EPLUS_HORIZON(OBJ) adjusts the state-space representation of a DSGE model within the object OBJ by setting elements corresponding to the anticipation of shocks beyond their specified horizons to zero in the transition matrices. This function is applicable when solving models with expectations for future shocks that may not materialize beyond certain horizons.

Details:
Input:
    obj - A DSGE model object, using these properties:
        exogenous.shock_horizon (matrix): per-shock maximum anticipation horizon
        options.solve_order (int): order of the perturbation solution
        topology.locations.z.e_0 (int): end index of the current-period shocks in z
        state_space.{Tz, Tzz, ...}: transition matrices, by regime
        markov_chains.regimes_number (int): number of regimes

Output:
    obj - the same object with the transition matrices updated.

For every regime, entries in the transition matrices that would
anticipate a shock beyond its shock_horizon are set to zero.
Example:
model = set_z_eplus_horizon(model);
See also

nullify_constraint_enforcers

Help for rise.set_z_eplus_horizon is inherited from superclass dsge

simulate

simulate - simulates a RISE model
[db,states,retcode] = simulate(obj,varargin)
Args:

obj [dsge|rise]: model object

varargin : additional arguments including but not restricted to

simul_sig [numeric|{1}]: value of the perturbation parameter

simul_tol [numeric|{sqrt(eps)}]: tolerance used for complementarity constraints. e.g. R>=1 becomes tol+R>=1 and A<=b becomes A<=b+tol

simul_pruned [true|’one_step_pruning’| ‘one_step_pruning_automatic’|function handle|{false}]: if true, pruning is applied using engine “one_step_pruning_automatic” as default.

simul_initial_regime [integer|{1}]: Historical regime for the simulations.

simul_order [integer|{[]}]: Suppose the model has been solved with an n-order perturbation. Then one may still want to simulate the model for an order m<n, without having to resolve the model. The default, of course, is to apply the same order as the solution.

simul_constraint_enforcer [true | {false}]: If true, simulations are also computed for the “constraint_enforcer” shocks.

simul_disable_constraints [true | {false}]: If true, the constraints are not enforced.

simul_with_growth [{true}|false]: if true, the growth rate is added to simulations for nonstationary models. x_t-xss = g + Tz*zhat

simulator [empty|{‘regime_switch’}|’occbin’|’anticip_shocks’|…
‘cforecast’|cell array|char]: Simulation procedure

simul_constraints [{empty}|cell array]: cell array of simulation constraints used to solve occasionally binding constraints. The constraints are of the form restr = { ‘f1(v,c)<g1(v,c)’,’x1=h1(c)’,shkList1 … ‘fn(v,c)<=gn(v,c)’,’xn=hn(c)’,shkListn }

where the third column is optional. “shkListi” : list of shocks for fixing restriction i. Shocks need to be unique in each least but can appear in other lists as well. The second column, ‘xi=hi(c)’, is needed only in the case of anticipated shocks but is compulsory anyway even in regime switching (including piecewise linear approximation)

Returns:

db [struct|cell array]: if simul_to_time_series is true, the output is a time series, else a cell array with a matrix and information on elements that help reconstruct the time series.

states [vector]: history of the regimes over the forecast horizon

retcode [integer]: if 0, the simulation went fine. Else something got wrong. In that case one can understand the problem by running decipher(retcode)

Note:

simul_historical_data contains the historical data as well as conditional information over the forecast horizon. It may also include as an alternative to simul_regime, a time series with name regime, which indicates the regimes over the forecast horizon.

For a model with measurement errors, the simulations are stored as complex numbers. The real part is the data without measurement errors and the imaginary part is the measurement error component. The two can be added for some variable x as x = real(x)+imag(x).

Example:

See also

generic.simulate

Help for rise/simulate is inherited from superclass dsge

simulate_nonlinear

For help see : dsge.perfect_foresight

Help for rise/simulate_nonlinear is inherited from superclass dsge

solve

Solves dsge models
[obj,retcode,structural_matrices]=solve(obj)

[obj,retcode,structural_matrices]=solve(obj,varargin)
Args:
obj (rise | dsge): scalar or vector of model objects. The optional options below come in pairs.

solve_initial_guess ({empty} | cell array): Initial guess for the first-order dynamics. When not empty, it should be the equivalent of obj.state_space{1}.Tz

solve_accelerate ({false} | true): Accelerate or do not accelerate the solving

solve_check_stability ({true} | false): check stability of Markov switching models while solving. The stability of constant-parameter models is always checked whether that of markov-switching models is optional. This is optional because (1) the procedure is computationally intensive and (2) there is no define stability criterion under endogenous switching

solve_derivatives_type (numeric | automatic | matlab| {symbolic}): choice of derivatives

solve_order (integer|{1}): order of approximation

solve_shock_horizon (integer|{0}|struct|cell): anticipation horizon of shocks beyond the current period. When the input is :

integer : all the shocks receive the same anticipation horizon

struct : the fields are the names of the shocks whose horizon is to be modified. e.g. struct(‘ea’,4,’eb’,3) means shock ea has horizon 4 while shock eb has horizon 3

cell : the cell must have two colums. Each row in the first column holds the name of a particular shock and each row in the second column holds the horizon of the shock. e.g. {‘ea’,4;’eb’,3}

NOTE : Under regime switching, it is possible to set different horizons for the same shock in different regimes. in that case, the values are no longer scalars. They are 2-columns cell arrays in which one of the columns is the state and the other column the value. e.g. shks.EPS_R={‘dan_1’,0;’dan_4’,0} column the value. e.g. shks={‘EPS_R’,{‘dan_1’,0;’dan_2’,4}}

solve_alternatives_nsim (integer | {100}): Number of initial guesses for the solution sampled randomly, when attempting to find all possible solutions.

solve_function_mode ({explicit/amateur} | vectorized/professional | disk)

in the amateur or explicit mode the functions are kept in cell arrays of anonymous functions and evaluated using for loops

in the vectorized or professional mode the functions are compacted into one long and unreadable function.

in the disk mode the functions are written to disk in a subdirectory called routines.

solve_initialization ({‘backward’} | ‘zeros’ | ‘random’): Type of initialization of the solution of switching models:

backward : the initial guess is the solution of the model without forward-looking terms

zeros : the initial guess is zero

random : the initial guess is random
solve_linsyst_solver ({‘tfqmr’, opts} | cell | char | function_handle): solver for linear systems. A {algo, opts} cell where algo is a char naming a MATLAB iterative solver (tfqmr / bicg / bicgstab / bicgstabl / cgs / gmres / minres / pcg / qmr) or a function_handle, and opts is a struct carrying at least TolFun and MaxIter. The function (whether builtin or user-supplied) should accept at least 4 inputs:
[X,FLAG,RELRES,ITER,RESVEC] = bicgstabl(A,B,TOL,MAXIT,varargin)
where:

A : matrix or function handle

B : right-hand side of system to solve

TOL : tolerance level

MAXIT : maximum number of iterations

The function must return 5 outputs as in Matlab’s tfqmr, bicgstab, bicgstabl, gmres, etc. :

X : the solution

FLAG : convergence flag

RELRES : relative residual NORM(B-A*X)/NORM(B)

ITER : iteration number

RESVEC : residual vector for various iterations

As far as the outputs are concerned, only the two first are relevant for RISE and so the three last can be empty. But they must be returned by the function all the same.
solver ({[]} | char | user_defined): solver for the dsge model. The following are possible:

loose_commitment : RISE automatically uses this when it detects an optimal policy model to be solved under commitment, discretion or loose commitment

rise_1 : default solver for constant-parameter dsge models. Similar to the dynare solver.

cr/cyclic_reduction : solves the constant-parameter dsge model using cyclic reduction

klein : solves the constant-parameter dsge model using the Klein method

AIM : solves the constant-parameter dsge model using the AIM solver

mfi : functional interation solver: default for switching dsge models

mnk : newton solver with kronecker products

mn : newton solver without kronecker products

mfi_full : full version of mfi, that does not exploit sparsity

mnk_full : full version of mnk, that does not exploit sparsity

mn_full : full version of mn, that does not exploit sparsity

fwz : Farmer, Waggoner and Zha (2011)’s Newton solver

dsge_groebner : Attempts to find all solutions using Groebner basis, a technique from computational algebraic geometry

dsge_udc : Solves the regime-switching dsge model using a version of the undetermined coefficient method

dsge_schur : Solves the regime-switching dsge model using a schur decomposition (works only for the Maih-Waggoner perturbation)

user_defined : In this case the function must take as inputs:

Gplus01 [n x n x h x h array]: where the 3rd dimension represent the current regime and the 4th dimension is the future regime.

A0 [n x n x h array]: matrix of contemporaneous variables

Aminus [n x n x h array]: matrix of backward-looking terms

Q [square matrix]: transition matrix, in which the rows are the current period and the columns the next period

T0 [n x h x h array]: initial guess of the solution

tol [scalar]: A tolerance criterion

maxiter [scalar]: the maximum number of iterations

The function should return as outputs

Tz_pb [n x h x h array]: solution of the problem given the inputs

eigenvalues [empty|vector]: optional vector of eigenvalues of the problem

retcode : 0 if no problem found when solving the problem

The function can be passed along as a string, a function handle or a cell array in which case the first element of the cell contains the function itself and the remaining cells contain further arguments required by the function but unknown to RISE.

N.B:: Oftentimes, RISE checks the type of the model in order to determine what the most appropriate solver should be. This may not always be the behavior that the user wants. It is possible to override that behavior by forcing RISE to use your intended solver. The way to do this is simply to add a “+” sign in front of the name of the solver. e.g. m=set(m,’solver’,’+mySolver’)

solve_automatic_differentiator (function_handle | {@adolm.diff}): automatic differentiator engine

solve_occbin (integer | {empty}): Solves the occasionally binding constraints model ala [Cagliarini and Kulish, 2013], [Guerrieri and Iacoviello, 2015] or [Guerrieri and Iacoviello, 2017]. It is then assumed that the transition matrix is diagonal. if not empty, the value entered is the reference regime.

solve_bgp (true | {false}): Solves the model as non-stationary.

solve_linear (true | {false}): set this to true in order to use more efficient algorithms for solving the steady state when the original model is truly linear.

solve_derivatives_only (true | {false}): if true, the derivatives are computed but the model is not solved. The derivatives can be collected in the third output argument of the function.

solve_user_defined_shocks (struct|{empty}): When empty, an independent normal distribution is assumed for each shock. Hence the shocks are not skewed! When not empty, the argument is a structure whose fields are the names of the shocks for which the user wants to change the distribution. Each field/shock is 1 x 2 cell array such that:

The first entry is a function handle that admits two inputs: the model object (in case it is needed) and the maximum order for the moments of the shocks. The function should then return in a row vector the moments from 1 to order. e.g. f(obj,5)=[0,1,0,3,0,15] for a standard normal distribution.

the second entry is also a function handle with one input argument. This function should return in a row vector random variates for the underlying distribution. e.g. we could have f(3)=[-0.6685 1.0613 -0.5339] for a normal distribution.

solve_perturbation_type (char | cell array | {‘maih’}): pertubation type which should be one of the following

‘maih’ or ‘m’: pertubation strategy of Maih(2014): regime-specific steady states

‘maih_waggoner’ or ‘mw’: pertubation strategy of Maih and Waggoner(2018): regime-specific steady states + perturbed transition probabilities for ALL Markov chains.

{‘maih_waggoner’,mkv_list} or {‘mw’,mkv_list}: where mkv_list is a cellstr with the list of the partitioned markov processes.

‘frwz’: pertubation strategy of Foerster, Rubio-Ramirez, Waggoner and Zha(2016): unique steady state solved at the ergodic mean of the parameters, imposing a perturbation on ALL the switching parameters.

{‘frwz’,part_list}: where part_list is a cellstr with the list of the partitioned parameters (perturbed parameters).

mkv_list and part_list : could also be {’*none’}, {’*all’}, {’*all_but’}, {’*all_but’,’v1’,’v2’,…’vn’}

solve_kill_g (false | {true}): kill off the growth element in first-order solution

solve_policy_type (‘discretion’ | {‘ramsey’}): choice of the type of policy in the absence of loose commitment or more generally stochastic replanning. Under stochastic replanning the option is set automatically as ‘stochastic_replanning’, which cannot be set directly by the user. The option solve_policy_type is case insensitive.

solve_policy_equilibrium (‘MPE’ | {‘OLE’}): choice of equilibrium concept in non-cooperative policy games. ‘OLE’ is the open-loop equilibrium (RISE’s traditional Lagrangian formulation, each player takes the opponent’s path as given). ‘MPE’ is the Markov-perfect equilibrium (each player takes the opponent’s policy function as given; the FOC’s forward shadow row is the gradient of the player’s own value function rather than the forward Lagrange multiplier). The two options are orthogonal: solve_policy_type controls commitment vs discretion; solve_policy_equilibrium controls OLE vs MPE. All four combinations are supported. Case insensitive.

solve_qz_criterium (numeric | {sqrt(eps)}): cutoff criterium for eigenvalues in the solving of constant-parameter DSGE models.
Returns:

obj [rise | dsge]: scalar or vector of model objects

retcode [integer]: if 0, no problem was found when solving the model. If positive, the reason for the problem can be obtained by running decipher(retcode)

structural_matrices [struct]: Structure holding various types of derivatives that are used in the computation of the solution

Note:

constant-parameter models can also be solved using the procedures for switching parameter models. There is no guarantee, however, any obtained solution will be determinate (unique and stable)

determinacy is only checked for constant-parameter models. For determinacy computations for switching dsge models with constant transition matrices, see [Cho, 2014]

In RISE we consider that it is in the nature of nonlinear models to have many solutions. Obtaining even one of those solution is usually difficult and a concept such as determinacy is NEVER used in the solving of models with, say, global methods.

See also rise.sstate

Help for rise/solve is inherited from superclass dsge

solve_alternatives

Attempts to find all solutions of a MSDSGE model
[allobj,mean_square_stable] = solve_alternatives(obj)
[allobj,mean_square_stable] = solve_alternatives(obj,varargin)
Args:

obj (rise | dsge): RISE model object

solve_alternatives_nsim (numeric | {100}): Number of random starting values generated.

Returns:
:

allobj [rise|dsge]: vector of RISE objects with the solutions found

Help for rise/solve_alternatives is inherited from superclass dsge

srf

SRF : shock response function, a flexible way to implement irfs.

Syntax :

myirfs=srf(m)

myirfs=srf(m,x0)

myirfs=srf(m,x0,r0)

myirfs=srf(m,x0,r0,shkCombo)

myirfs=srf(m,x0,r0,shkCombo,irf_periods)

myirfs=srf(m,x0,r0,shkCombo,irf_periods,order)

myirfs=srf(m,x0,r0,shkCombo,irf_periods,order,girf_runs)

Inputs:

m [rise|dsge]: model object(s)

x0 [empty|struct]: initial conditions for endogenous variables

r0 [empty|integer]: initial/historical regime

shkCombo [numeric|struct|empty]: shock information such that

if numeric : shock sign and or magnitude

if struct : structure with the names of the shocks and their values for the initial impulse : the impulse response is computed for a cocktail of shocks (scenario) rather than for one specific shock. Note that in this case, the outputwill be the same for all individual shocks!!!

irf_periods [empty|numeric]: period length for the irfs

order [empty|integer]: order of the solution used in the computation of the irfs

girf_runs [empty|numeric]: if girf_runs>1, this triggers the computation of generalized impulse responses. It automatically sets irf_regime_specific and irf_girf_regime_uncertainty to false

Outputs:

myirfs [struct]: structure in which the fields are the names of the shocks of the model. This is true whether we have a cocktail of shocks or not. The only difference is that for convenience, under a cocktail of shocks, the responses are the same for all the shocks in the model.

sstate

Computes the steady state of a dsge model
[obj,structural_matrices,retcode]=sstate(obj,varargin)
Args:
obj (rise | dsge): model file

varargin : usual optional arguments in pairs

sstate_blocks (true|{false}): blockwise solution of the steady state.

sstate_file (char | function_handle | {‘’}): name of the steady state file

sstate_default_value (numeric|{0}): initial value for all the steady-state values for the variables which are not bounded (sstate_bounds) or solved in a steady-state program (e.g. sstate_file)

sstate_discr_policy_init (numeric|{0}): initial value for all the elements of the dynamic solution (Tz, Tzz, etc.) for the discretionary policy problem

sstate_use_file (false | {true}): use the steady state file or program(in the model file) to solve the steady state

sstate_solver (char | function_handle | {‘lsqnonlin’}): Other solvers known to RISE include “fsolve”, “fminunc”, “fminsearch”. If you want to supply your own solver, then it should be of the format [x,f,exitflag]=yourSolver(Objective,x0,lb,ub,options,varargin) i.e. it accepts the same inputs as lsqnonlin and returns the same 3 first outputs of fsolve

sstate_bgp_shift (numeric | {5}): shift/lead of the static model for solving the balanced growth path.

sstate_unique (true | {false}): In a regime switching model, there are potentially multiple steady states if some of the switching parameters affect the steady state of the model. When this is the case, the option “sstate_unique” is used for forcing the steady state to be unique nevertheless. In that case, the unique steady state is computed at the ergodic mean of the parameters.

sstate_imposed (true | {false}): is typically used when

one wants to approximate the model around a point that is not the steady state of the model. For instance, in the piecewise linear approach, there is a reference regime (normal times) which assumes that no alternative regime exists and therefore the steady state of the model is computed as the steady state of that particular regime. That steady state is then imposed to be the steady state even in the alternative regime (e.g. the zero-lower bound regime).

one wants to prevent RISE from treating the steady state file or model as initial condition. For instance, under estimation, with sstate_imposed set to false, RISE will always try to compute the steady state numerically if the program computing the steady state fails. But this is wasteful since the numerical solution can never be better than the analytical solution. In other words, if the analytical solution fails, the numerical solution cannot succeed.

one wants to prevent RISE from trying to solve the steady state if the steady state equations do not hold. This useful for inspecting the offending equations by means of the “resid” method.

sstate_loop (true | {false}): This option is used to inform RISE that the steady state file (or model) would accurately compute the steady state of a selected number of variables if it is given the steady state values for some other variables. Therefore, RISE will loop over (iterate) over values of the unsolved variables until the steady state is found. This is typically the case for instance in optimal policy, where, say, we do not know the steady state value of the interest rate. Note that when sstate_loop is triggered, block decomposition (sstate_blocks) becomes “inactive” It is important to note that when the option is used in combination with sstate_bounds, only the variables looped over are constrained.

sstate_use_jacobian (true | {false}): In linear models, the jacobian is always used. In the nonlinear case, however, the true jacobian tends not to work as well as its finite differences approximation. Hence by default, we do not invoke the use of the true jacobian.

sstate_endo_param_swap (cell array | {} ): When not empty, it is a cell array with n rows and 3 columns, where n is the number of restrictions, the first column gathers the names of the endogenous variables whose values are given in the second column, the third column includes the parameters names that are endogenized.

sstate_impose_commitment (true|{false}): impose the steady state of commitment to the solving of the steady state for discretion, loose commitment and stochastic replanning.
sstate_bounds (struct | {} ): When not empty, it is a structure such that each field is the name of an endogenous variable for which we have constraints. Each field itself is either

a scalar e.g bounds.C=2, which becomes bounds.C=[2,-inf,inf]

or a 3-element vector bounds.C=[2,-inf,inf], where the first element represents the start value (initial guess), the second element the lower bound and the third element the upper bound.

It is also possible to simultaneously specify the growth rate of a variable in case the model is nonstationary. In that case the syntax above generalizes to a 1 x 2 cell array bounds.C={sstateInfo,bgpInfo} where sstateInfo and bgpInfo at scalars of 1 x 3 vectors as above.

It is also possible to specify multiple regimes in case of a regime-switching DSGE model. In that case the user as to specify as many dimensions to the structure as the number of regimes. e.g. bounds(2).C=bounds(1).C

If no information is provided beyond the first regime, RISE automatically extrapolates the first regime information to the others.

The default bounds for the steady states are -inf and inf The default bounds for the growth rates are -log(2) and log(2), i.e.:
-log(2) <= C{t}-C{t-1} <= log(2) or
-log(2) <= log(C{t}/C{t-1}) <= log(2)
Irrespective of the initial conditions chosen through sstate_bounds, in the presence of a steady state file or a steady state model, the procedure will go through such program and distort the initial conditions

Setting “sstate_bounds” to be initial_sstate(m), where m has been previously solved, returns good initial conditions for both the steady state and growth but poor bounds, which doesn’t matter if the guess is exact or good

Setting “sstate_bounds” to be get(m,’sstate’) returns the steady state only, which is fine if the model is stationary, internally those values are going to be imposed so that x0=lb=ub

There is probably a need for a sstate_bgp or sstate_growth call that will also return the growth rate simultaneously but this is not implemented at this point

In the presence of good or exact initial conditions, it is the responsibility of the user to remove a defectuous or inexact steady state program. This is done by simply reinitializing the steady state m=set(m,’sstate_file’,’’) This also suggests that having a steady state model written inside the model file is not a good idea.
Returns:

obj [rise|dsge]: model file

structural_matrices [struct]: structure containing various important elements for the solution of the system

retcode [numeric]: 0 if there was problem computing the steady state.

Note:
There are 2 cases to consider:
The user does not provide any steady state equations: RISE will attempt to solve the steady state using a vector of zeros as initial guess. It makes life easy if the user provides the status of the variables in the system i.e. whether they grow linear or log-linearly.
The user provide some equations for solving the steady state. This is done in two ways:
the steady_state_model block: the variables that do not appear in the block will be initialized at zero. Some parameters can also be computed inside the block. The user can define an optimization to solve for a subset of steady state values inside the block. The block has three attributes:

imposed(default=false): RISE computes the solution at the specified point without checking that the point solves for the steady state

unique (default=false): RISE computes the steady state at the ergodic distribution of the parameters. In case the probabilities are endogenous, the ergodic distribution of the parameters is itself a function of the steady state of the variables.

loop(default=false): RISE considers the equations calculating the steady state as true and just solves for the missing variables by looping over the steady state program. The user can then use the values pushed into the steady state program to calculate the steady state for the included variables.
the steady state file: The user writes a function which can be called in two possible ways:
[vnames,info]=ssfile();

In this case the first output argument is the list of variables for which the user computes the steady state; the second output is a structure with fields unique, imposed and loop just as in the case of the steady state model.
The other call to the function is
[y,newp,retcode]=ssfile(y,p,d,id,obj)
In this case, the first input (y) is the vector of steady states, which is updated and returned as the first output. The locations of the modifications are indicated by the fourth input (id), which is computed based on the list of the variables in vnames above. As for the other outputs, p is a structure with parameters, d is a structure with definitions, obj is the model object in case the user needs some further information for computing the steady state. In case some parameters are computed in the steady state file, they should be returned in the structure “newp”. The last output “retcode” indicates whether no problem was encoutered in the computation of the steady state (retcode=0) or the opposite (retcode = any number different from 0).
Writing the steady state file in this ways makes it possible to use the same file whether there is regime switching or not.
See also rise.initial_sstate, dsge_tools.sstate.set_bounds

Help for rise/sstate is inherited from superclass dsge

state_var_list

INTERNAL FUNCTION: state_var_list creates the list of the state variables in the solution
final_list=state_var_list(m)
final_list=state_var_list(m,orders)
final_list=state_var_list(m,orders,compact_form)
Args:

m (dsge | rise): model object

orders (integer array | {1:m.options.solve_order}): approximation orders

compact_form (true | {false}): if true, only unique combinations will be returned. Else, all combinations will be returned.

Returns:
:

final_list [cellstr] : list of the state variables

kept [vector] : location of kept state variables (computed only if compact_form is set to true)

Help for rise/state_var_list is inherited from superclass dsge

stoch_simul

stoch_simul – attempts to emulate dynare’s stoch_simul
oo_=stoch_simul(obj)

oo_=stoch_simul(obj,var_list)

oo_=stoch_simul(obj,var_list,varargin)
Args:

obj (dsge | rise ): model object

var_list (empty | char | cellstr ): List of variables for which to run stoch_simul

varargin : Pairwise list of extra arguments

Returns:
:

oo_ [struct]: structure containing

irfs [struct]: structure containing impulse responses in time series format

simulations [struct]: structure containing impulse responses in time series format

vcov [matrix]: (simulated) variance-covariance

skewness [vector]: skewness measure

kurtosis [vector]: kurtosis measure

variance [vector]: (simulated) variances for the endogenous variables

stdev [vector]: (simulated) standard deviations for the endogenous variables

corrcoef [matrix]: (simulated) correlation coefficients for the endogenous variables

summary

SUMMARY Displays a summary of the DSGE model

Help for rise/summary is inherited from superclass dsge

table

TABLE Produce a summary table of posterior estimates.

Inputs:

m : model object or vector of models

mcmcobj : object(s) containing posterior simulation information

vararginoptions in (name, value) pairs:
‘mode’ (true/false) ‘mcmc_mode’ (true/false) ‘median’ (true/false) ‘mean’ (true/false) ‘credibility_interval’ (e.g., 90) ‘prior_mean’ (true/false) ‘prior_std’ (true/false) ‘prior_quantiles’ (90 or other) ‘prior_distrib’ (true/false) ‘latex_filename’ (char array|{char,precision}|empty by default)

Output:

T : a MATLAB table

If ‘latex_filename’ is provided, a corresponding LaTeX file is saved.

If there are more than one models, the rows of the table are sorted to that the parameters with similar names can be more easily inspected and compared.

Help for rise/table is inherited from superclass dsge

theoretical_autocorrelations

theoretical_autocorrelations computes (mostly) regime-specific partial autocorrelations

Args:

obj : [rise|dsge] : model object

varargin : pairwise arguments with the most relevant for this function being :

autocorr_ar : [numeric>=0|{5}] : order of autocorrelation. If you want to compute the contemporaneous correlation only set to order to 0

autocov_aggregate : [true|{false}] : when true and under regime switching, the autocovariances are aggregated across regimes with the weights being the ergodic distribution of the regimes. Then the autocorrelations are computed out of the aggregated autocovariances. Otherwise, by default, the theoretical autocorrelations are regime-specific

autocov_model_resolve : [{true}|false] : if true, the function tries to solve/resolve the model first

Returns:
:

Acorr [cell array]: cell array of regime-specific correlations, when autocov_aggregate is false. When there is only one regime or when autocov_aggregate is true, the cell array contains only one element. Inside each element is Acorr is a possibly 3-dimensional array where the 3rd dimension represents the order of autocorrelation. In order words, Acorr{regime=i}(:,:,1) is the contemporaneous correlation while Acorr{regime=i}(:,:,2) is the autocorrelation of order 1, so that Acorr{regime=i}(:,:,k+1) is the autocorrelation of order k.

Acov [cell array]: cell array of regime-specific autocovariances, following the same logic as the autocorrelations described above

retcode [scalar]: return code

Note:

The sucessful computation of the autocorrelations depends on the solving of the discrete Lyapunov or Stein equation.

theoretical_autocovariances

THEORETICAL_AUTOCOVARIANCES - Compute regime-specific autocovariances

Syntax:
[V,retcode] = theoretical_autocovariances(obj) [V,retcode] = theoretical_autocovariances(obj, autocov_ar) [V,retcode] = theoretical_autocovariances(obj, autocov_ar, vList) [V,retcode] = theoretical_autocovariances(obj, autocov_ar, vList, varargin)

Args:

obj : [rise|dsge] : Model object

autocov_ar : [numeric>=0|{5}] : Order of autocovariance. If you want to compute the variance only, set the order to 0.

vList : [empty|cellstr|vector] : Names of indices/positions for the variables for which to compute the autocovariance.

varargin : Additional options specified as key-value pairs.

Returns:

V : [cell array] : Cell array of regime-specific covariances. When autocov_aggregate is false, each element of V is a 3-dimensional array, where the 3rd dimension represents the order of autocovariance. In other words, V{regime=i}(:,:,1) is the variance, and V{regime=i}(:,:,k+1) is the autocovariance of order k.

retcode : [scalar] : Return code. 0 indicates success.

Note:

The successful computation of the autocovariances depends on the solution of the discrete Lyapunov or Stein equation. Different Lyapunov algorithms can be set through the option “lyapunov_algo”. The available algorithms are:

‘doubling’ OR @lyap_solvers.doubling (the default)

‘bicgstab’ OR @lyap_solvers.bicgstab

‘bicgstabl’ OR @lyap_solvers.bicgstabl

‘cgs’ OR @lyap_solvers.cgs

‘fevdcov’ OR @lyap_solvers.fevdcov

‘direct’ OR @lyap_solvers.direct

‘fix_point’ OR @lyap_solvers.fix_point

‘robust’ OR @lyap_solvers.robust

‘sandwich’ OR @lyap_solvers.sandwich

‘schur’ OR @lyap_solvers.schur

‘bartels_stewart’ OR @lyap_solvers.bartels_stewart

In the presence of a nonstationary model, it is not a good idea to use the doubling algorithm as it won’t converge. A different algorithm, such as “bartels_stewart,” may work better.

Options autocov_aggregate, autocov_aggregate, and autocov_ar can be passed as pairs in varargin. In the case of autocov_ar, passing it directly overrides the version passed in varargin.

See also

SOLVE, LYAPUNOV_EQUATION

translate

translate – Translates RISE codes into comprehensible atoms
outList=translate(obj,inList)
outList=translate(obj,inList,order)
Args:

obj (rise | dsge): scalar model object.

inList (char | cellstr): List of atoms to translate e.g. v_3_1, v(3,1), c(4), c_4

order (integer|0|{1}): If order>1 the returned list of atoms is a list of kroneckers in which the number of elements in each items is the order of the kronecker. This is useful for instance to understand what combination of variables makes up a column in a differentiation. If order=0, the translation is with respect to the static, rather than the dynamic model

Returns:

outList [cellstr]: List of translated atoms

Examples:
translate(m,{'v(1,1)','v_1_1','c(4)','c_4'})

list=obj.routines.symbolic_probs_times_dynamic{2}
outList=translate(obj,list)
outList=translate(obj,list,3)

Help for rise/translate is inherited from superclass dsge

unlink_parameters

UNLINK_PARAMETERS remove the selected links

m = UNLINK_PARAMETERS(m, expressions)

This function is responsible for unbinding dynamically bound parameters

m: Scalar or vector of model objects.

targets: Character or cell array of strings representing the parameters to unlink. e.g. targets = {‘alpha’,’beta’,’gamma’} will remove the definitions of the specified parameters. It could also be ‘*’, in which case all links are deleted.

Returns: - m: Updated model object with the remaining dynamically bound parameters.

Example:
m = UNLINK_PARAMETERS(m, {‘alpha’,’beta’,’gamma’})

See also

rise.view_linked_parameters, rise.link_parameters

Help for rise/unlink_parameters is inherited from superclass dsge

update_file

update_file update files for the latest syntax
dsge.update_file(filnavn)

dsge.update_file(filnavn,nyfilnanv)

rise.update_file(filnavn)

rise.update_file(filnavn,nyfilnanv)
Args:

filnavn (char): name of the rise/dsge file (with or without extension)
to update for the new syntax

nyfilnanv (char): name of the new rise/dsge file with default being the name of the original file

Returns:
:

none

See also

Help for rise.update_file is inherited from superclass dsge

variance_decomposition

Computes the variance decomposition for a DSGE model
[Vardec,obj]=variance_decomposition(obj)

[Vardec,obj]=variance_decomposition(obj,varargin)
Args:

obj (dsge | rise ): model object

varargin : Pairwise list of extra arguments

vardec_shocks [empty|char|cellstr]: list of shocks

vardec_periods [vector|{[1 4 8 16 40 100 200 400]}]: periods to consider for the decomposition

vardec_theoretical [false|{true}]: if true, the theoretical variance decomposition is computed to the extent that this is possible. If false, the decomposition is based on simulated data.

vardec_ergodic [{false}|true]: if true, compute the ergodic variance decomposition for a regime-switching model. If false, the computations are regime specific

Returns:

Vardec [struct]: structure containing the variance decomposition both for the

infinite horizon (infinity)

for each period (conditional)

retcode [numeric]: = 0 if there is no problem

N.B: The calculation of the variance is done by solving a Lyapunov equation. There are different Lyapunov algorithms which can be set through the option “lyapunov_algo”. The available algorithms are:

‘doubling’ OR @lyap_solvers.doubling (the default)

‘bicgstab’ OR @lyap_solvers.bicgstab

‘bicgstabl’ OR @lyap_solvers.bicgstabl

‘cgs’ OR @lyap_solvers.cgs

‘fevdcov’ OR @lyap_solvers.fevdcov

‘direct’ OR @lyap_solvers.direct

‘fix_point’ OR @lyap_solvers.fix_point

‘robust’ OR @lyap_solvers.robust

‘sandwich’ OR @lyap_solvers.sandwich

‘schur’ OR @lyap_solvers.schur

‘bartels_stewart’ OR @lyap_solvers.bartels_stewart

Notes:

In the presence of a nonstationary model, it is not a good idea to use the doubling algorithm : it won’t converge. A different algorithm such as “bartels_stewart” may work better.

The algorithms listed above are invoked either as char/string or directly as function handles prefixed with “lyap_solvers.”. e.g. ‘fevdcov’ or @lyap_solvers.fevdcov

In the presence of a nonstationary model, it is not a good idea to use the doubling algorithm : it won’t converge. A different algorithm such as “bartels_stewart” may work better.

view_linked_parameters

VIEW_LINKED_PARAMETERS displays the dynamically-bound expressions

VIEW_LINKED_PARAMETERS(m)

This function is responsible for unbinding dynamically bound parameters

m: Scalar or vector of model objects.

Example:
VIEW_LINKED_PARAMETERS(m)

See also

rise.link_parameters, rise.unlink_parameters

Help for rise/view_linked_parameters is inherited from superclass dsge