Be more flexible about variable declarations

Is this to be the new default behavior or should this behavior be turned on with a keyword to dynare? e.g. nostrict or development I guess the same would go for issue #1 (closed)

We should certainly not change the default behavior. A line option, nostrict could transform the errors in warnings, while writing them a limited number of times when there are lots of them.

Just to be clear, if nostrict is passed, this entails looping through all endogenous variables in the symbol_table and seeing if they're used in at least one equation. If not, then remove the unused endogenous variable(s) from the symbol_table, type_table, name_table, and tex_name_table.

Makes sense to me. The Matlab fields in M_ should contain and refer only to the symbols actually used in the model. (This doesn't apply for parameters)

Houtan Bastani writes:

Just to be clear, if nostrict is passed, this entails looping through all endogenous variables in the symbol_table and seeing if they're used in at least one equation. If not, then remove the unused endogenous variable(s) from the symbol_table, type_table, name_table, and tex_name_table.

Reply to this email directly or view it on GitHub: https://github.com/DynareTeam/dynare/issues/2#issuecomment-24175681

Michel Juillard

This is turning out to be more of a hack than I envisaged....

SymbolTable stores symbols in multiple associative vectors and maps (symbol_table, name_table, tex_name_table, type_table). So, if a symbol is to be removed from here, the vectors need to be resized and hence the symb_id's > than that of the variable that was removed need to be decreased by one. Changing the symb_ids however causes problems with the equations which have a symb_id associated with each variable.

A cleaner solution might be to make the vectors name_table, tex_name_table and type_table into maps, with the key being the symb_id. In this case, we wouldn't have to renumber anything when it was deleted from the symbol_table and would only have to change the lookup functions. It would also make sense to get rid of the variable size, which just confuses the code (replacing it with symbol_table.size() or maxid where appropriate)

Other solutions would be to modify endo_ids and type_specific_ids, though since tsids needs to be the same length as symbol_table, we run into a problem removing entries here as well.

A simple hack would be to pass the variables to be ignored to freeze, though this seems like too much of a hack as it doesn't seem to have too much of a connection to what's going on. Given the imminent release of 4.4, it would be better to hold off on this change and make a bigger, neater change to the code when we have more time to test it.

Of course, I'm open to ideas if someone sees a way of solving this that I may have missed.

My advice is to skip it for 4.4. Spending the necessary time will make for a better code, easier to maintain.

Best

Michel

Houtan Bastani writes:

This is turning out to be more of a hack than I envisaged....

SymbolTable stores symbols in multiple associative vectors and maps (symbol_table, name_table, tex_name_table, type_table). So, if a symbol is to be removed from here, the vectors need to be resized and hence the symb_id's > than that of the variable that was removed need to be decreased by one. Changing the symb_ids however causes problems with the equations which have a symb_id associated with each variable.

A cleaner solution might be to make the vectors name_table, tex_name_table and type_table into maps, with the key being the symb_id. In this case, we wouldn't have to renumber anything when it was deleted from the symbol_table and would only have to change the lookup functions. It would also make sense to get rid of the variable size, which just confuses the code (replacing it with symbol_table.size() or maxid where appropriate)

Other solutions would be to modify endo_ids and type_specific_ids, though since tsids needs to be the same length as symbol_table, we run into a problem removing entries here as well.

A simple hack would be to pass the variables to be ignored to freeze, though this seems like too much of a hack as it doesn't seem to have too much of a connection to what's going on. Given the imminent release of 4.4, it would be better to hold off on this change and make a bigger, neater change to the code when we have more time to test it.

Of course, I'm open to ideas if someone sees a way of solving this that I may have missed.

Reply to this email directly or view it on GitHub: https://github.com/DynareTeam/dynare/issues/2#issuecomment-24274873

Michel Juillard

Instead of removing the symbols from the table, can't we simply change their type to a bogus type?

I view this as a hack akin to passing the variables to ignore into freeze; something that solves the problem but confuses the code. However, if you want me to implement it this way, I can.

Basically I vote for the solution that requires the minimal amount of changes to the preprocessor, whichever it is. The code is already complex, I don't want to add complexity or introduce potentially disruptive changes for a feature that is relatively unimportant.

Though the idea with the bigger change would be to simplify the code, it would be potentially disruptive. I'll make this hack then.

I agree Houtan Bastani writes:

Though the idea with the bigger change would be to simplify the code, it would be potentially disruptive. I'll make this hack then.

Reply to this email directly or view it on GitHub: https://github.com/DynareTeam/dynare/issues/2#issuecomment-24394401

Michel Juillard

mentioned in commit e93c7b6b

mentioned in commit ca697085

mentioned in issue #1878 (closed)

Be more flexible about variable declarations

Designs

Child items ...

Activity