#214: in which order are auxiliary variable definitions stored ? --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: blocker | Milestone: 4.3 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- DynamicModel.cc:3787 and 3848, new definitions are inserted in front of the deque ModelTree.cc:1382, new definition is pushed in the back of the deque
1) The order of the definitions matters because, for example, a conditional expectation lagged by 2 periods is built on the basis of the auxiliary variable for the lagged expectation by 1 period.
2) StaticModel.cc:1707 and 1735 write the equations in the wrong order when equations are inserted in front of the deque
There are other problems related to the handling of auxiliary variables in the *.m files, when computing the steady state of models with auxiliary variables, see ticket 213.
#214: in which order are auxiliary variable definitions stored ? --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: blocker | Milestone: 4.3 Component: Preprocessor | Version: Keywords: | --------------------------+-------------------------------------------------
Comment(by sebastien):
The aux vars in DynamicModel::substituteLeadLagInternal() and DynamicModel::substituteExpectation() are added in front of the deque. The order is taken care of, but of course a bug cannot be ruled out.
The ModelTree::addAuxEquation() method (which adds at the back of the deque) is only used when cloning a ModelTree or converting a DynamicModel to StaticModel, in order to keep the order during the cloning/conversion.
Concerning the bug that you mention in StaticModel, can you be more specific or give an example? Also in that case I have taken care of the order (subject to the same disclaimer).
#214: in which order are auxiliary variable definitions stored ? --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: blocker | Milestone: 4.3 Component: Preprocessor | Version: Keywords: | --------------------------+-------------------------------------------------
Comment(by michel):
As the definitions of the auxiliary variables are added in the front of the deque, they should be written from the end back in order to replicate the order of definition.
I have made the necessary change. I still need to test.
#214: in which order are auxiliary variable definitions stored ? --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: blocker | Milestone: 4.3 Component: Preprocessor | Version: Keywords: | --------------------------+-------------------------------------------------
Comment(by sebastien):
First tentative fix in 347ab4d0c0c79ae9a42898c1d5409d78708bb8a8: rightly fix one problem in size of ys_, and incorrectly fixes an ordering issue. Also breaks the testsuite's Makefile (fix in aa1306651d20205cadf5a8a09c093fc7b3d3dd1a). The fix for size of ys_ still needs to be ported to 4.2.
#214: in which order are auxiliary variable definitions stored ? --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: blocker | Milestone: 4.3 Component: Preprocessor | Version: Keywords: | --------------------------+-------------------------------------------------
Comment(by michel):
The issue is corrected in 762f31bafd4b3a58c5a31c4e7d538d232e15a094
We still have to address how to fix 4.2
#214: in which order are auxiliary variable definitions stored ? ---------------------------+------------------------------------------------ Reporter: michel | Owner: michel Type: bug | Status: closed Priority: blocker | Milestone: 4.3 Component: Preprocessor | Version: Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien):
* status: new => closed * resolution: => fixed
Comment:
Fixed in 4.2 in 696763de8346c0c469e7d6ac5fa81f5a1a1af16b.