preprocessor issueshttps://git.dynare.org/Dynare/preprocessor/-/issues2020-07-22T10:30:58Zhttps://git.dynare.org/Dynare/preprocessor/-/issues/52Fail to read PAC equations without lags on the endogenous (LHS) variable2020-07-22T10:30:58ZStéphane Adjemianstepan@adjemian.euFail to read PAC equations without lags on the endogenous (LHS) variableSee example in `tests/pac/trend-component-31/example.mod` (Enterprise).See example in `tests/pac/trend-component-31/example.mod` (Enterprise).4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/preprocessor/-/issues/50PAC model: improve robusteness of detection of non-optimising agents part2020-07-08T13:36:40ZSébastien VillemotPAC model: improve robusteness of detection of non-optimising agents partThe method `BinaryOpNode::getPacNonOptimizingPart()` is not sufficiently robust. It may fail for expressions of the form `(1-optim_share)*A*B`, if the preprocessor reorders the factors.
This can be reproduced with `tests/pac/trend-component-2-mce/example_det.mod`, by replacing `(1-gamma)*(.5*diff(y1)-.7*diff(y2))` with `(1-gamma)*beta*(.5*diff(y1)-.7*diff(y2))` (adding `beta` as a 2nd factor) in equation `eq:pac`.
The solution is probably to create a new method `ExprNode::decomposeMultiplicativeFactors()` (similarly to `ExprNode::decomposeAdditiveTerms()`), and use it for detecting the non-optimising part.The method `BinaryOpNode::getPacNonOptimizingPart()` is not sufficiently robust. It may fail for expressions of the form `(1-optim_share)*A*B`, if the preprocessor reorders the factors.
This can be reproduced with `tests/pac/trend-component-2-mce/example_det.mod`, by replacing `(1-gamma)*(.5*diff(y1)-.7*diff(y2))` with `(1-gamma)*beta*(.5*diff(y1)-.7*diff(y2))` (adding `beta` as a 2nd factor) in equation `eq:pac`.
The solution is probably to create a new method `ExprNode::decomposeMultiplicativeFactors()` (similarly to `ExprNode::decomposeAdditiveTerms()`), and use it for detecting the non-optimising part.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/preprocessor/-/issues/48Provide a debug mode that gives information about the objects computed in sta...2020-05-20T10:09:49ZSébastien VillemotProvide a debug mode that gives information about the objects computed in static and dynamic filesFor each object in the `static` or `dynamic` file, this mode could add:
- the equation number
- for derivatives, the (possibly dynamic) variable(s) against which the derivative is taken
- the human-readable form of the expression (with readable variable names, without temporary terms)
This should also be done for block decomposition mode (in particular, the renormalized equations could be an additional information).For each object in the `static` or `dynamic` file, this mode could add:
- the equation number
- for derivatives, the (possibly dynamic) variable(s) against which the derivative is taken
- the human-readable form of the expression (with readable variable names, without temporary terms)
This should also be done for block decomposition mode (in particular, the renormalized equations could be an additional information).4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/preprocessor/-/issues/43Defining macro-variables without a value2020-05-07T17:44:07ZHoutan BastaniDefining macro-variables without a valueFrom @stepan-a
> I have no opinion about the null value (it is an implementation detail that will not affect the user experience). In C macro language I believe it's legal to use the #define statement without assigning a value (and that an error is thrown if one is trying to do something with its value). I really don't like the idea of providing a value to a variable if we only have to test for the existence of the variable in the sequel, and I would prefer to issue an error if the variable is used later for arithmetic or anything else involving its value (I also consider this as safer since the variable is not intended for this, so in this sense the alternative you advocate is not equivalent). We are currently forced to do as you suggest when declaring variables in the .mod files and it is rather ugly...From @stepan-a
> I have no opinion about the null value (it is an implementation detail that will not affect the user experience). In C macro language I believe it's legal to use the #define statement without assigning a value (and that an error is thrown if one is trying to do something with its value). I really don't like the idea of providing a value to a variable if we only have to test for the existence of the variable in the sequel, and I would prefer to issue an error if the variable is used later for arithmetic or anything else involving its value (I also consider this as safer since the variable is not intended for this, so in this sense the alternative you advocate is not equivalent). We are currently forced to do as you suggest when declaring variables in the .mod files and it is rather ugly...4.7https://git.dynare.org/Dynare/preprocessor/-/issues/39`det_cond_forecast` interface is buggy2020-06-30T12:10:35ZHoutan Bastani`det_cond_forecast` interface is buggyThere is currently an implementation in the preprocessor that does not work correctly. Rework this.There is currently an implementation in the preprocessor that does not work correctly. Rework this.4.7MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/preprocessor/-/issues/32macro processor: look into passing `env` and `paths` to the interpret function2020-05-07T17:44:48ZHoutan Bastanimacro processor: look into passing `env` and `paths` to the interpret function4.7