Dear George,

we need to rethink the organization of dr1.m and friends: we should factorize common code, move away initialization that should take place only once and probably split 1st and second order approximation (except for k_order_perturbation.DLL). We need also to plan for resolution by block along the line developed by Ferhat.

We don't need to implement all functionalities in all versions of the solver. In my opinion, k_order_perturbation should be used for regular stoch_simul and for estimation of forward looking models only. For backward models, only checking eigenvalues and mixing with deterministic shocks (varexo_det) we can rely on existing code.

As long as k_order_perturbation.DLL is in testing stage, we can leave the alternative dr1.m function in korderpert subdirectoy and call it for testing with appropriate addpath command

I would suggest to modify resol only when the reorganization of dr1.m has taken place.

For partial information, we need to pass additional information from the preprocessor and the exact requirements of that still need to be discussed with Joe and you.

All the best,

Michel

Quoting "G. Perendia" george@perendia.orangehome.co.uk:

Dear Michel

1. I am not sure we should have two version of dr1.m. My current design for

k_order (and partial info I started working on for Joe) assumes existence of two (or more) dr1_xx.m, all called from resol.m according to the option settings, on the line of how dr1_sparse.m is called whilst dr1.m will still be called if check_flag == 1, i.e.:

if(options_.model_mode==1) [dr,info,M_,options_,oo_] = dr1_sparse(dr,check_flag,M_,options_,oo_); elseif(options_.usePartInfo==1)&& (check_flag == 0) [dr,info,M_,options_,oo_] = dr1_PI(dr,check_flag,M_,options_,oo_); elseif(options_.use_k_order==1)&& (check_flag == 0) [dr,info,M_,options_,oo_] = dr1_k_order(dr,check_flag,M_,options_,oo_); else [dr,info,M_,options_,oo_] = dr1(dr,check_flag,M_,options_,oo_); end

dr1_k_order.m is not complete dr1 and by switching the option setting in the code (i.e. in case of any problem with the primary solver) we can make system switch from one solver to another in a smoother, more transparent way (like I did for AIM).

If you agree, I will upload resol.m which has switch for dr1_k_order on the lines of above.

PS: The new dr1_xx.m are prototypes and I should include check inside those alternative dr1_xxx.m later too.

2. Re: Extracting rules for deterministic exogenous vars

I was not suggesting of porting of deterministic exogenous vars rule to C++ but was suggesting using the existing dr1.m Matlab code to build that rule inside dr1_kordp.m as it is done at the moment in dr1.m.

However, I need hessian for those rules to be calculated and I will initially call <model>_dynamic.m/.dll to calculate it again which is straight forward to implement and does not require much more coding. Though slower, it is used only rarely when we have to deal with deterministic varexos,

At a later stage, if performance become an issue, I may retrieve the already pre-calculated hessian from the k_ordr_perturbation.dll which would then run faster but requires more work on C++ coding (in part due to reordering inside DLL).

Best regards

George Mob. +44(0)7951415480 artilogica@btconnect.com

----- Original Message ----- From: "Michel Juillard" michel.juillard@ens.fr To: "G. Perendia" george@perendia.orangehome.co.uk Sent: Monday, April 27, 2009 8:19 PM Subject: Re: reordering algorithm

...

Thanks George,

I fixed a few bugs and renamed the function kordpert/dr1.m so we can just access it by adding kordpert to Matlab path

I'm still not completely sure of what I have done. I still have problem with the DLL. For Judd example, it doesn't seem to return the right g_2 on my machine.

Best

Michel

G. Perendia wrote:

...

Dear Michel

Sorry, I should have given you more details rather than assumed you will understand. It is giving wrong results - I think it is to do with the symmetry handling in your algorithm.

While my results for Judd model (judd_gpdr.mat) match Dynare Matlab

results,

...

...

yours (judd_mjdr.mat) do not.

It is similar for the fs2000k... and portfolio_2 models - all enclosed.

( the enclosed <model>.mat files give you g_2)

Best regards

George Mob. +44(0)7951415480 artilogica@btconnect.com