Hi

I agree,

The initial design for k-ord-pert assumed resol.m to be used as the dispatch mechanism as it does for the dr1.m and dr1_sparse.m. but the path change was suggested then instead just as a temporary solution until dr1 is rewritten and factorized on the lines of what you also suggest.

Best regards George

----- Original Message ----- From: "Sébastien Villemot" sebastien.villemot@ens.fr To: dev@dynare.org Sent: Tuesday, June 30, 2009 9:03 AM Subject: Re: [DynareDev] Fw: 2nd and 3rd model derivatives + k-order

"G. Perendia" george@perendia.orangehome.co.uk a écrit :

What is the expected preprocessor mechanism to allow for k-ord-pert to be used (i.e. by setting matlab/kordpert directory on the top of search path) and when is it expected to be in place?

If there is none in place yet, what would be the best place (i.e. which .m file) to set path to kordpert/dr.1 when options_.use_k_order=1; is specified in the mod file, e.g. as per my earlier message below?

I don't think it is good practice to override matlab/dr1.m with matlab/kordpert/dr1.m through path manipulations.

I would rather dynamically select which version of dr1 to use. For example, dr1.m would be a dispatcher between the original dr1.m and the korder dr1.m (and possibly dr1_sparse.m added by Ferhat).

Code that can be factorized would go in top-level dr1.m, and specific code would go into dr1_original.m, dr1_korder.m and dr1_sparse.m.

Best,