echo list of macro-variables

would it be possible to set a command that prints the value of all macro-variables defined at a given point in the code? I am starting to have lots of macro flags and would be good to have this to trace back which kind of options have been selected for a given experiment.

@rattoma I think that the value of the macro variables should be displayed in the matlab command window at the beginning of the run of a mod file. You will then have a trace of what has been done in the log file. This could be a default behaviour, and we may add an option to the dynare command to prevent this... But I do not have strong opinion on what should be the default behaviour.

I do not think that we need to have a new command, that would be placed at an arbitrary place in the mod file as you suggest, because the macro processing is not dynamic. When the expanded mod file is actually run, we know the values of the macro variables and we cannot change them.

@stepan-a We would need to have an actual command. Because within the mod-file, you can still define macro-flags and change their value. So it is not clear what you would provide as an output after preprocessing: the value at the end or the beginning?

Say you have a

@#define sticky_price=0
stoch_simul();
@#define sticky_price=1
stoch_simul();

then in the command window the first output of stoch_simul will be associated with a different value of the macro-variable than the second one. Allowing to print out the value of the macro-variable before the call to stoch_simul allows you tracking what has been executed and makes the output unique.

@JohannesPfeifer I do not understand your example... Do you expect that this macro would change the model on the fly? This cannot be the case. @houtanb will correct me if I am wrong, the macroprocessing is done in a first step, reading the entire mod file. At the end of this first step, ie before the actual preprocessing of the expanded mod file, we know the value of all the macro variables.

That said, it is true that it can be the case, even if I can't imagine right now an example where this would be useful, that you change the value of a macro variable in the mod file (actually this what we do when we run a loop). But this case is not a problem for @rattoma, if my understanding of the issue is correct, since the value of the variable is known (it is hard coded in the mod file).

@stepan-a Maybe this is not intended behavior, but you can change macro-variables on the fly within mod-files. Simply execute

@#define countries = [ "H", "F" ]
@#for co in countries
var C_@{co} L_@{co} N_@{co} A_@{co} K_@{co} Z_@{co} X_@{co} LAMBDA_@{co} S_@{co} NX_@{co} Y_@{co};

varexo E_@{co};

parameters beta_@{co} alpha_@{co} eta_@{co} mu_@{co} gamma_@{co} theta_@{co} nu_@{co} sigma_@{co} delta_@{co} phi_@{co} psi_@{co} rho_@{co}_@{co};
@#endfor


@#define countries = [ "H"]
@#for co in countries
var C_@{co} L_@{co} N_@{co} A_@{co} K_@{co} Z_@{co} X_@{co} LAMBDA_@{co} S_@{co} NX_@{co} Y_@{co};

varexo E_@{co};

parameters beta_@{co} alpha_@{co} eta_@{co} mu_@{co} gamma_@{co} theta_@{co} nu_@{co} sigma_@{co} delta_@{co} phi_@{co} psi_@{co} rho_@{co}_@{co};
@#endfor

with the savemacro option and check the output.

@stepan-a @JohannesPfeifer : indeed my primary idea is to echo hard-coded macro-variables associated to various options. So, the idea of having them printed the command line at the beginning of the run of a mod file would be OK. An this may well be a default option. At the same time, @JohannesPfeifer correctly pointed to another possible use of the macro-variables. This would require an additional specific option to dynare call like -echomacrovars in my view, that option may trigger some disp command in the same place where the macro-variable is defined with arguments the name of the macro and its value. @JohannesPfeifer would this tackle what you have in mind?

@stepan-a @rattoma The problem I see is that the value of macro variables at the beginning of a run is not well-defined as my example above shows. What do you display? That the country is H or F and H? I.e. would you go for the value set when the variable is encountered for the first time? My suggestion was having a command within the mod-file that displays the values set at that point. This would be unique.

@JohannesPfeifer you are right. I would then echo all variables set at that point by triggering disp commands with name/value couples. for all macro vars defined

then the command should be a macro command inside the mod file, not as a dynare instance option, i.e. something like @#echomacrovars

@stepan-a @rattoma @JohannesPfeifer this is not a problem to do.

@stepan-a in response to your statement above, you are correct. It just seems to me that @rattoma and @JohannesPfeifer want the macro variable values at some point during the macroprocessing step.

@JohannesPfeifer for me, the macro variables are well defined at the beginning of the macro processing step in that they do not exist. In other words, if we were to print the values at the beginning of the macro processing step, the only ones that should be printed are those that were passed on the command line via the -D option.

But, I agree with all of you that the default, without the @#echomacrovars command, would be to print the macro variable values at the end of macro processing, before continuing with the preprocessing step. If the @#echomacrovars command were passed, the values at that point would be printed. If multpile @#echomacrovars commands are present, the macro variable values set when the last @#echomacrovars command was encountered would be printed.

They will be stored in options.echoed_macro_variable_values unless someone prefers a different name.

@houtanb Thanks for clarifying the terminology. What we had in mind is a simple display in the command window that will therefore also be in the log-file. No need for storing it in options_. The values at the beginning of the macroprocessing step are already displayed in the unstable version. I don't think we need to duplicate this. We would only need @#echomacrovars displaying the value of all macro variables currently set.

@JohannesPfeifer great, that's even easier to implement.

@JohannesPfeifer @houtanb I agree. many thanks!

@houtanb ... actually, your idea of transforming macro vars into a matlab structure may be very useful. Perhaps as an additional command. What about @exportmacrovars2matlab that stores

options_.macro_variables.('name1') = val1;
options_.macro_variables.('name2') = val2;
...

?

@rattoma if we have this command, is there any reason to have the first?

Why not? If the user just needs to have an echo in the log, this is done automatically by the macro-processor without one having to do it on purpose from the options_. does it make sense?

@houtanb The difference is being able to access that information from Matlab vs. having a log-file of what was done.

@rattoma @JohannesPfeifer I understand the difference. I just think it's messy to have two options that provide the same information in slightly different ways.

@houtanb I would be fine with having a preprocessor option @exportmacrovars2matlab to write to options_ and then have a separate Matlab function to display the contents of this field in the command window.

@JohannesPfeifer that sounded good, but then I guess it would still require two lines to get the output into the .log file. What about just having an option to the macro command, such as:

@#echomacrovars
@#echomacrovars(save)

Every time @#echomacrovars is encountered, its output is printed to screen. If @#echomacrovars(save) is encountered, no output is printed to screen; rather it is saved to options_ as @rattoma specified above. NB that @#echomacrovars(save) will only return the last set of macro vars encountered.

@houtanb Fine with me.

@houtanb @JohannesPfeifer fine also for me. thanks

@JohannesPfeifer @rattoma that change implements @#echomacrovars but not @#echomacrovars(save), which I'll do at a later date. There are also improvements to be made (differentiating between string arrays and int arrays, adding quotes around elements of string arrays) that I'll do in a later commit. I just wanted to push this so you could have something to work with.

@JohannesPfeifer @rattoma in the end I set it up such that multiple @#echomacrovars(save) commands can be supported. The value contained in options_.macrovars will be that saved when the previous @#echomacrovars(save) was encountered.

Reopening, because the command still needs to be documented.

Actually it is documented, closing again, sorry for the noise.