Dev October 2009

dev@dynare.org

8 participants
29 discussions

Re: [DynareDev] Proposed specification for estimation functions
by G. Perendia 10 Dec '09

10 Dec '09

PS: Re naming suggestions: As M_.params is updated too in the 50-123 block, name update_params is also adequate though something like updateQHMparams() would still be more precise . ----- Original Message ----- From: G. Perendia To: List for Dynare developers Sent: Monday, September 21, 2009 10:27 AM Subject: Re: [DynareDev] Proposed specification for estimation functions Thanks Stephane Re: 3&4) Sorry for confusion: Overlapping variables refer to the results of Kalman from the previous period sub-sample block such as a(t|t-1) and P(t|t-1) and will not they be used as starting point entries for the next period block estimation. However, I am not sure if then their "meaning" for the next sub-sample may be distorted by separate data filtering (DataPreparation) for that sub-sample. I am however also not sure if I can take this into C++ DsgeLikelihood as yet in full - there are many unresolved items (and even more not yet properly understood by me, see below) - but I can at least start building bones for its future integration. E.g. have quite a few more questions: 5) How are we going to calculate and report overall (or sub-sample?) likelihood(s) to the parameter optimising/sampling DsgeLikelihood driving function (eg csminwel, fminunc or MCMC MH) and how to get it to optimise/sample parameters for different sub-samples? Or, is the parameter differentiation parametric/functional and planned to be included in "update_parameters" block? 6) How will the system know which name structure to target ID1 if "ID1 is a n by 1 vector of indices targeting to the (parameter, exogenous variable or endogenous variable) names (in M_.param_names, M_.exo_names and M_.endo_names" 7) If "the considered subsamples for different parameters may be different", then I believe we need to split the data subsamples and the estimation blocks into shorter common sub-samples. I.e., when you say: "xparam1 is a column n by 1 vector holding the current values of the estimated parameters" does "current" mean value at time t such that max(StartPeriod)< t < min(EndPeriod) for the set? 8) Are priors time-dependent, defined for each sub-sample (or the time slot of the parameter? Are they updated on the run, conditional on previous sub-sample or preset? 9) what do nv*_id nv* by 1 vector of integers represent? If shock IDs, then how the nv* shocks/errors can be linked to individual params' periods. I.e. are they time dependent too and if not, what is their role in this time-slot-dependent structure? 10) In the loop you refer to "NP" as number of periods: "LOOP on periods 1 to NP" but in the structure (lowercase) "np" seem to refer to the number of deep parameters- use of same word/literal (despite of the case difference) may be a bit confusing 11) which optimiser is the method of indirect inference in Dynare? May I also make some suggestions? re 4) Block of lines 50-123 updates and checks shocks and obs. errors cov kalman matrices Q and H using relevant subsets of the parameters vector xparam1 (but not changing xparam1). I believe a more precise and descriptive name for the block (e.g. updateQH() or updateShocksAndErrorMatrices() or something on those lines) may be less confusing with e.g. generating or updating the whole new set of all parameters. Also, DataCleanup, DataDetrend or DataPreparation instead of "data_filtering()" I believe may be less confusing with e.g. Kalman filtering. I hope this helps to clarify rather than confuse the issues even more. Best regards George ----- Original Message ----- From: Stéphane Adjemian To: List for Dynare developers Sent: Friday, September 18, 2009 12:09 PM Subject: Re: [DynareDev] Proposed specification for estimation functions Hi, I am not sure that it would be a good idea to implement the unexpected breaks stuff in the c++ version of the DsgeLikelihood... Because it's a new feature and we have no experience with it. I Changed Period1 to StartPeriod and Period2 to EndPeriod, thanks for the suggestion. In the data filtering step we remove the "deterministic part" of the data (constant and linear trends), so that we do not have to treat this in the kalman filter recursions. This is already done like this in the matlab version of DsgeLikelihood. I do not understand 3) and 4). What is an overlapping variable. The parameter update step corresponds to block between lines 50 to 123 in DsgeLikelihood.m I think that we do have a c version of the sims optimization routine (provided by Tao Zha). Best, Stéphane. 2009/9/18 G. Perendia <george(a)perendia.orangehome.co.uk> Hi I would like to start implementing period-dependent likelihood calculation within the new C++ DsgeLikelihood but that will add a bit of time. 1) I suggest that parameters description is defined by Start (or StartPeriod) and End (or EndPeriod) instead of a.. Period1 (beginning of sub-period) a.. Period2 (end of sub-period) respectively because we may have more than 2 periods and using terms Period1 and 2 as delimiters for other periods can bee a bit confusing in the context (as it did confuse me for a start) . 2) What is data_filtering (for period 1) step as opposed to Kalman filter - is it Kalman smoother? We have no working C++ implementation for smoother as yet. 3) Would it be right to say that the new period divided likelihood estimation requires overlapping variables Y(-/+n) for n>0 among the sub-period blocks? 4) What is parameters update? Is it param likelihood, hill climbing optimisation (or MCMC step) for each sub-period block separately (conditional on the previous period block?)? We do not have working optimiser in C++ yet. 4) Would the interim period-blocks' Kalman inputs be a(t|t-1) and P(t|t-1) as well as overlapping variables Y(-/+n) for n>0 from previous block Kalman output? Best regards George _______________________________________________ Dev mailing list Dev(a)dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev -- Stéphane Adjemian CEPREMAP & Université du Maine Tel: (33)1-43-13-62-39 ---------------------------------------------------------------------------- _______________________________________________ Dev mailing list Dev(a)dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev

2 7

[Trac] #36: Write a Wiki page on the various incompatibilities accross MATLAB versions
by Trac Dynare 23 Nov '09

23 Nov '09

#36: Write a Wiki page on the various incompatibilities accross MATLAB versions ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: Type: feature | Status: new Priority: minor | Milestone: Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ This wiki page should only document changes relevant to Dynare, in particular with respect to MEX files. All MATLAB release notes since R14 are available on: http://www.mathworks.com/access/helpdesk/help/techdoc/ -- Ticket URL: <https://www.dynare.org/trac/ticket/36> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #49: User guide: update chapter on installation of Dynare
by Trac Dynare 06 Nov '09

06 Nov '09

#49: User guide: update chapter on installation of Dynare ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: 4.1 Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ -- Ticket URL: <https://www.dynare.org/trac/ticket/49> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #39: Make warnings about unitialized params/vars optional
by Trac Dynare 06 Nov '09

06 Nov '09

#39: Make warnings about unitialized params/vars optional --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: 4.1 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/39> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] C++ DsgeLikelihood
by Michel Juillard 04 Nov '09

04 Nov '09

Dear George, thanks for the message. The issue needs to be discussed carefully. 1) We are trying to get rid of most global variables and to pass oo_, options_ and M_ as arguments. There is no good reason, why this has not been done yet in DsgeLikelihood.m 2) Besides a cleaner more robust code, we learned that accessing global variables in Matlab is expensive, and, most likely it is also true for Mex library 3) DsgeLikelihood++ is not primarily meant for calling from Matlab, but from a C++ version of dynare_estimation_1.m 4) There are only two of these variables that are changed in DsgeLikelihood: - M_.params, but a local version of modified params vector should probably be an argument to dynare_resolve - options_.kalman_algo that passes back the choice of Kalman algorithm. We can probably find another mechanism to pass back this information to Matlab. 5) My preference would be to have one C++ class that contains all the parameters from M_, options_ and bayestopt_ (the latter needs to be rethought), needed by the C++ estimation functions. This class should be initialized at the instanciation of the top class (here dynare_estimation++) from M_ and options_ pointers passed as arguments 6) One needs to think about a similar mechanism for output variables. 7) I have three problems with the current structures that we use *M_ contains parameters describing the model (OK) *oo_ contains output. We may want to distinguish output that is only made available to the user and intermediary output that is meant to be used by other routines such as structure dr. It could make accessing these intermediary results faster * options_ contains both real options_ and information on the current state of Dynare computations (such as kalman_algo here), These should probably be separated * bayestopt_ (and estim_params) is currently a mess and should be reconsidered. It is mainly meant to contained parameters describing the priors that are deduced from user input passed by the preprocessor in estim_params 8) In summary, for now, in DsgeLikelihood++, you should simply refer to a C++ version of these objects that we will build later. Best Michel G. Perendia wrote: > Dear Michel > > Regarding design of the interface with Matlab (and Octave?), there are many > variables from global structures that need to be referred to from various > parts of estimation (and some updated too). > > Is it ok if I make DsgeLikelihood++ system refer to options_, oo_ and other > large structures (and some other variable) using mex functions > mexGetVariable (and, if needed, mexPutVariable for updates) rather than > trying to pass whole structures at the call time and creating C++ instances > of all or (large) subsets of their data. > > e.g. > const mxArray *mexExt = mexGetVariable("base", "mexext"); > or > const mxArray *M_ = mexGetVariable("caller", "M_"); > > That will reduce number of variables that need to be passed on call and > writing code on their breaking down and passing around from mexFunction to > the other modules. > > I can optimise access to read-once only to reduce DLL-Matlab traffic too > using a permanent class on the lines of: > > class MexStruct > { > mxArray* mexStruct; > const char *base; // one of: base, caller, global > const char *structName; > MexStruct( char *sBase, char * mexStructName) > : base(sBase), structName(mexStructName) > { > mexStruct=mexGetVariable(base, structName); > } > mxArray * > getMexStructField(char * field) > { > return mxGetField(mexStruct, 0, field); > } > void > putMexStruct(){mexPutVariable(base, structName, mexStruct);} > void > setMexStructField(char * field, mxArray *newVal) > { > mxArray *fp = mxGetField(mexStruct, 0, field); > mxDestroy(fp) > mxSetField(mexStruct,0,field, newVal); > } > } > > Some global variables in those structures also need to be set so the above > class' methods can pass back updated global variables too at the end of the > DsgaLikelihood. Also, as another advantage of this model, they can be passed > back even in real time when if that may be needed for parallelisation. > > Best regards > > George > Mob. +44(0)7951415480 > artilogica(a)btconnect.com > > ----- Original Message ----- > From: "Michel Juillard" <michel.juillard(a)ens.fr> > To: "G. Perendia" <george(a)perendia.orangehome.co.uk> > Sent: Monday, August 24, 2009 11:15 AM > Subject: Re: C++ DsgeLikelihood > > > >> Hi George, >> >>> Dear Michel >>> >>> 1) Re email below, due to problem of code for calling >>> > <model>dynamic.dll, > >>> needed by estimation but being in the same file with mexFunction in >>> k_order_perturbation.cpp >>> >>> Alternatives: >>> a) I can use (a different) literal, e.g. >>> KORDERPERT_MEX_FILE >>> and compile k_order_perturbation.cpp for k_order_perturbation.dll using >>> -DKORDERPERT_MEX_FILE >>> and for DsgeLIkelihood/estimation without, - probably the easiest >>> > solution > >>> to implement and maintain until situation may change, - or, >>> >>> b) I can split k_order_perturbation.cpp in two - >>> > k_order_perturbation.cpp > >>> with mexFunction and another file for calling <model>dynamic.dll which >>> > will > >>> be placed into korderpertlib.a and linked to DsgeLikelihood/estimation >>> > too - > >>> probably the optimal solution. or, >>> >>> c) copy k_order_perturbation.cpp code for calling >>> > <model>dynamic.dll.into > >>> another file and keep it under DsgeLikelihood/estimation and have >>> DsgeLikelihood refer to k-orderpertlib for the rest - this may duplicate >>> effort on maintaining the dynamic.dll call management code but it is a >>> > clear > >>> cut. >>> >>> >>> >> I prefer 1.b) too >> >>> 2) Shall I treat C++ DsgeLIkelihood >>> a) as an extension of KF or KORDERPERT and put its code in one of those >>> > 2 > >>> mex/source directories, or >>> >>> b) create a new one, e.g. estimation, with its makefiile referring to >>> > the > >>> code and objects in the other two? >>> >>> >>> I suggest 1.b and to treat DsgeLIkelihood as a subdirectory of kalman >>> directory which will refer to korderpertlib and kalman src. >>> >>> >>> >> I prefer 2.b, because DsgeLikelihood calls Kalman code and it is weird >> to have it in a subdirectory of kalman >> >> All the best, >> >> Michel >> >>> Please let me know if that is OK with you. >>> >>> Best regards >>> >>> George >>> >>> ----- Original Message ----- >>> From: "G. Perendia" <george(a)perendia.orangehome.co.uk> >>> To: "Michel Juillard" <michel.juillard(a)ens.fr> >>> Sent: Friday, August 21, 2009 3:50 PM >>> Subject: Re: C++ DsgeLikelihood >>> >>> >>> >>> >>>> Dear Michel >>>> >>>> In k-order-perturbation makefile someone(you?) defined literal >>>> -DMATLAB_MEX_FILE >>>> for several cpp files, some of which do not contain mexFunction, e.g. >>>> >>>> k_order_test_main.o: k_order_test_main.cpp >>>> gcc -DMATLAB_MEX_FILE ... >>>> >>>> k_ord_dynare.o: k_ord_dynare.cpp k_ord_dynare.h >>>> gcc -DMATLAB_MEX_FILE .... >>>> >>>> k_order_perturbation.o: k_order_perturbation.cpp k_order_perturbation.h >>>> gcc -DMATLAB_MEX_FILE .... >>>> >>>> nlsolve.o: $(DYNAREPPDIR)/src/nlsolve.cpp >>>> gcc -DMATLAB_MEX_FILE .... >>>> >>>> whereas only k_order_perturbation.cpp contains mexFunction(). >>>> >>>> What is that switch/literal used for? >>>> >>>> I wandered if it is OK to use that literal and set a switch in >>>> k_order_perturbation.cpp to exclude mexFunction from compilation when >>>> > not > >>>> defined so that the file can be used with other mexFunctions such as >>>> > the > >>> one >>> >>> >>>> for DsgeLikelihood., e.g. >>>> >>>> #ifdef MATLAB_MEX_FILE // exclude mexFunction for other applications >>>> extern "C" { >>>> void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const >>>> > mxArray > >>>> *prhs[]) >>>> { >>>> ... here goes mexFunction .: >>>> } >>>> }; // end of extern C >>>> #endif // ifdef MATLAB_MEX_FILE >>>> >>>> Oterwise I can set another literal. >>>> >>>> Best regards >>>> >>>> George >>>> >>>> ----- Original Message ----- >>>> From: "Michel Juillard" <michel.juillard(a)ens.fr> >>>> To: "G. Perendia" <george(a)perendia.orangehome.co.uk> >>>> Sent: Tuesday, August 18, 2009 12:36 PM >>>> Subject: Re: C++ DsgeLikelihood >>>> >>>> >>>> >>>> >>>>> Hi George, >>>>> >>>>> currently there are 3 different cases: >>>>> >>>>> 1) the steady state is not affected by estimation. This is the case >>>>> > that > >>>>> we are implementing now >>>>> 2) A Matlab function is provided by the user to compute the steady >>>>> > state > >>>>> as a function of model's parameters. >>>>> The implementation is cumbersome for the user and should become a >>>>> feature of the preprocessor. As long as the definitive version is not >>>>> done, there is no point in losing time writing a C interface for that >>>>> 3) The steady state must be solved for by calling a nonlinear equation >>>>> solver. We will need to implement this as well, but it is a lower >>>>> priority. I would like to have the entire estimation chain in C++ >>>>> working first with just a constant steady state. >>>>> >>>>> All the best, >>>>> >>>>> Michel >>>>> >>>>> >>>>> G. Perendia wrote: >>>>> >>>>> >>>>>> Dear Michel >>>>>> >>>>>> Regarding steady state, can you remind me why we can not use ss >>>>>> >>>>>> >>>> calculation >>>> >>>> >>>>>> inside the k-order-perturb ? >>>>>> Can we than instead call Dynare Matlab steady state calculation, >>>>>> >>>>>> >>>> currently >>>> >>>> >>>>>> called from resol.m, from estimate_1.m just before calling the new >>>>>> >>>>>> >>> C++ >>> >>> >>>>>> DsgeLikelihood (or from a new Matlab shell DsgeLikelihood_m.m that is >>>>>> >>>>>> >>>> then >>>> >>>> >>>>>> calling C++ DsgeLikelihood) where new C++ resol will not call ss >>>>>> calculation as the Matlab one does? >>>>>> >>>>>> Best regards >>>>>> >>>>>> George >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Michel Juillard" <michel.juillard(a)ens.fr> >>>>>> To: "G. Perendia" <george(a)perendia.orangehome.co.uk> >>>>>> Sent: Monday, August 17, 2009 8:37 PM >>>>>> Subject: Re: C++ DsgeLikelihood >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi George, >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Should I suppose that the C++ DsgeLikelihood would also include >>>>>>>> > C++ > >>>>>>>> versions of: >>>>>>>> resol.m >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> yes, this mainly calls first order solution in dr1.m >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> kalman_transition_matrix.m >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> yes >>>>>>> >>>>>>> >>>>>>> >>>>>>>> and >>>>>>>> the 1st order part of the k-ord_pert version of dr1.m that will be >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> calling >>>>>> >>>>>> >>>>>> >>>>>>>> k-order_perturbation for 1st order only, either as a DLL (as it >>>>>>>> >>>>>>>> >>> does >>> >>> >>>>>> now) >>>>>> >>>>>> >>>>>> >>>>>>>> or incorporating it statically? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> first order solution should be linked statically >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> May I then also assume that >>>>>>>> >>>>>>>> a) set_state_space.m and the kstate preamble will in future be >>>>>>>> >>>>>>>> >>>> performed >>>> >>>> >>>>>>>> before calling DsgeLikelihood, and not repeatedly within dr1 and >>>>>>>> > its > >>>>>>>> >>>>>> future >>>>>> >>>>>> >>>>>> >>>>>>>> C++ version - as I remember has already been planned? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> yes, we will have to implement such a mechanism >>>>>>> >>>>>>> >>>>>>> >>>>>>>> b) Ramsey will not be part of it for now >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> correct >>>>>>> >>>>>>> >>>>>>> >>>>>>>> c) I need to check but I think I may not need to code >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> transition_matrix.m >>>>>> >>>>>> >>>>>> >>>>>>>> and use the info 3/4 test currently in dr1: >>>>>>>> if nba > nyf info(1) = 3; >>>>>>>> elseif nba < nyf info(1) = 4; >>>>>>>> as a similar test already exist in k-ord-pert. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> probably correct >>>>>>> >>>>>>> >>>>>>> >>>>>>>> d) Also, we seem to need a new algorithm to handle exogenous >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> deterministic >>>>>> >>>>>> >>>>>> >>>>>>>> variables i.e. when M_.exo_det_nbr > 0 ? They are not currently >>>>>>>> >>>>>>>> >>>> handled >>>> >>>> >>>>>> for >>>>>> >>>>>> >>>>>> >>>>>>>> k-order perturbation. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> no, there is no estimation with exogenous deterministic variables >>>>>>> >>>>>>> >>>>>>> Best >>>>>>> >>>>>>> Michel >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Best regards >>>>>>>> >>>>>>>> George >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Michel Juillard" <michel.juillard(a)ens.fr> >>>>>>>> To: "G. Perendia" <george(a)perendia.orangehome.co.uk>; "Joe >>>>>>>> > Pearlman" > >>>>>>>> <j.pearlman(a)londonmet.ac.uk> >>>>>>>> Sent: Friday, July 31, 2009 8:46 AM >>>>>>>> Subject: Re: lyapunov kalman filter options >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thanks George, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> .... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> For the next steps, I think that you have now all elements to code >>>>>>>>> >>>>>>>>> >>> a >>> >>> >>>>>> C++ >>>>>> >>>>>> >>>>>> >>>>>>>>> version of DsgeLikelihood.m Of course you should restrict it to >>>>>>>>> > the > >>>>>>>>> >>>>>> case >>>>>> >>>>>> >>>>>> >>>>>>>>> of stationary models. >>>>>>>>> >>>>>>>>> As we haven't solved yet the issue around computing the steady >>>>>>>>> >>>>>>>>> >>> state, >>> >>> >>>>>>>>> for the time being, limit yourself to the case where the steady >>>>>>>>> >>>>>>>>> >>> state >>> >>> >>>>>>>>> doesn't change throughout estimation. >>>>>>>>> >>>>>>>>> Best >>>>>>>>> >>>>>>>>> Michel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>> >>> >>> >>> >> > > > > >

3 17

[Trac] #41: bug in resid.m that reset initial values when used after ENDVAL
by Trac Dynare 29 Oct '09

29 Oct '09

#41: bug in resid.m that reset initial values when used after ENDVAL --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: critical | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- resid shouldn't modify oo_ or any global variables Maybe it should check against <fname>_static rather than <fname>_dynamic -- Ticket URL: <https://www.dynare.org/trac/ticket/41> Dynare <http://www.dynare.org> The Dynare project

1 2

Re: [DynareDev] [Trac] #29: bug with varexo_det
by Trac Dynare 28 Oct '09

28 Oct '09

#29: bug with varexo_det ---------------------------+------------------------------------------------ Reporter: michel | Owner: michel Type: bug | Status: closed Priority: major | Milestone: 4.1 Component: Core M-files | Version: 4.0.4 Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * status: accepted => closed * resolution: => fixed Comment: Fixed in r3093. -- Ticket URL: <https://www.dynare.org/trac/ticket/29#comment:5> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #1: Implement conditional forecasts
by Trac Dynare 23 Oct '09

23 Oct '09

#1: Implement conditional forecasts ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: stepan Type: feature | Status: closed Priority: major | Milestone: 4.1 Component: Core M-files | Version: Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * status: assigned => closed * resolution: => fixed -- Ticket URL: <https://www.dynare.org/trac/ticket/1#comment:3> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #6: Add interface to AIM solver
by Trac Dynare 20 Oct '09

20 Oct '09

#6: Add interface to AIM solver ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: sebastien Type: feature | Status: closed Priority: major | Milestone: 4.1 Component: Preprocessor | Version: Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * status: accepted => closed * resolution: => fixed Comment: Implemented in r3059. -- Ticket URL: <https://www.dynare.org/trac/ticket/6#comment:2> Dynare <http://www.dynare.org> The Dynare project

1 0

order of variables
by Michel Juillard 20 Oct '09

20 Oct '09

Stephane makes me remark that the introduction of auxiliary variables create problems for people who use Matlab syntax in Dynare and rely on global such as M_.endo_nbr It is important that we define clearly the position of auxiliary variables in the vectors of variables and that we commit to it. We had decided, to put auxiliary variables after all variables declared explicitly in the model. We can add that the Lagrange multipliers added by ramsey_policy will be added after the auxiliary variables. All the best, Michel

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev October 2009