Allow adding auxiliary variables like Ramsey multipliers to var_list_

The auxiliary variables are endogenous variables like every other variable. A call like ramsey_policy(instruments=(i),irf=13,planner_discount=betta,periods=200) x pi MULT_1; would be suficient to display IRFs for the multiplier 1. However, the preprocessor does not allow adding MULT_1 to the variable list, because: Unknown symbol: MULT_1 We should allow adding any variable present in M_.endo_names to the var_list_. @houtanb Could you do this, please? Related to http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=12117

@houtanb Does this only work with ramsey_policy? Or also with stoch_simul after ramsey_model?

@JohannesPfeifer just ramsey_policy, as you said in the issue description.

@houtanb Given that we now phase out ramsey_policy in 4.6, we need to reopen this ticket. stoch_simul and perfect_foresight_solver need to accept this.

reopened

changed milestone to %4.6

@JohannesPfeifer does perfect_foresight_solver need to be modified to accept var_list_ ?

@houtanb That was my mistake. perfect_foresight_solver does not take a var_list_ argument. But this ticket applies generally to all commands that accept a var_list_. For example, you can run estimation after ramsey_model.

Statements that accept var_list_:

stoch_simul
forecast
ramsey_policy
discretionary_policy
estimation
rplot
osr
dynasave
dynatype
ms_irf
shock_decomposition
realtime_shock_decomposition
plot_shock_decomposition
initial_condition_decomposition
squeeze_shock_decomposition
plot_conditional_forecast
calib_smoother
gmm_estimation
smm_estimation

Should this now be the case for all of these statements?

@houtanb I think this is a wider issue. var_list_ should generally allow users to access auxiliary variables created by Dynare. Anything in M_.endo_names should be feasible on the preprocessor end. Of course, the allowed variable scope differs across commands. ms_irf can obviously not accept Lagrange multipliers.

Also, I don’t think we want to allow all types of auxiliary variable. Most auxiliary variables have unstable names, generated using an integer that depends on preprocessor internals, and that could therefore change across preprocessor versions (this is the case for all lead/lags aux vars, for example).

So in my opinion we should only allow this feature for the most stable names (e.g. Lagrange multipliers).

@sebastien I don't see any good reason for that type of restriction. Most users will probably never use this, but I have experienced cases where, for debugging purposes, I wanted to understand what is going on with the auxiliary variables introduced. The preprocessor restriction was a nuisance that I had to circumvent manually by overwriting var_list_.

I see. Note that technically, from an implementation point of view, it’s not a restriction. At parsing time, the preprocessor does not yet know about auxiliary variables. So it’s not straightforward to implement this, though it must be doable in some way.

Is there a generic structure one could use? For example, do not complain if the variable name starts with MULT_, AUX_EXPECT_, AUX_ENDO_, etc, without checking whether they are valid. That would put the burden on the user, which should be fine given that the features is intended for sophisticated users.

mentioned in commit 71792cd6

mentioned in commit preprocessor@c2399101

closed

also in preprocessor@32c3910e

mentioned in commit preprocessor@32c3910e

mentioned in commit preprocessor@54f73e08

mentioned in issue preprocessor#107 (closed)