Hi
I am scheduling some bug fixing changes to both the trunk and the branch DiffuseLikelihood1, H1, 1_Z and H1_Z.m routines and would like to avoid any potential edit conflicts.
Is anyone planning or doing work on those routines and is it ok to put a temporary Tortoise SVN lock on them, e.g. for today or tomorrow?
Best regards
George
Fine with me
michel
G. Perendia wrote:
Hi
I am scheduling some bug fixing changes to both the trunk and the branch DiffuseLikelihood1, H1, 1_Z and H1_Z.m routines and would like to avoid any potential edit conflicts.
Is anyone planning or doing work on those routines and is it ok to put a temporary Tortoise SVN lock on them, e.g. for today or tomorrow?
Best regards
George
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Le mercredi 08 juillet 2009 à 10:56 +0100, G. Perendia a écrit :
I am scheduling some bug fixing changes to both the trunk and the branch DiffuseLikelihood1, H1, 1_Z and H1_Z.m routines and would like to avoid any potential edit conflicts.
Just to mention that we have decided that there would be no more Dynare release in the 4.0.x. We are now focusing our energies on the next major release, 4.1, by the end of the summer if everything goes well.
So it's not necessary to fix the 4.0 branch.
Best,
I beg to disagree. It's not a good idea to leave bugs behind. I had already forgotten these ones when we decided to release 4.0.4 I don't think it is big changes either
Best
Michel
Sébastien Villemot wrote:
Le mercredi 08 juillet 2009 à 10:56 +0100, G. Perendia a écrit :
I am scheduling some bug fixing changes to both the trunk and the branch DiffuseLikelihood1, H1, 1_Z and H1_Z.m routines and would like to avoid any potential edit conflicts.
Just to mention that we have decided that there would be no more Dynare release in the 4.0.x. We are now focusing our energies on the next major release, 4.1, by the end of the summer if everything goes well.
So it's not necessary to fix the 4.0 branch.
Best,
Hi
The trunk ones are still being used by DsgeLikilihood_hh and will be needed for 4.1 and the branch ones appear to be just their identical copies (e.g. diff reports no differences), and so will they be fixed by mere copying - just in case.
If that is OK , I will lock them this afternoon and let you know when I finish and unlock them.
Regards George
----- Original Message ----- From: "Michel Juillard" michel.juillard@ens.fr To: "List for Dynare developers" dev@dynare.org Sent: Wednesday, July 08, 2009 12:08 PM Subject: Re: [DynareDev] DiffuseLikelihod kalman routines
I beg to disagree. It's not a good idea to leave bugs behind. I had already forgotten these ones when we decided to release 4.0.4 I don't think it is big changes either
Best
Michel
Sébastien Villemot wrote:
Le mercredi 08 juillet 2009 à 10:56 +0100, G. Perendia a écrit :
I am scheduling some bug fixing changes to both the trunk and the branch DiffuseLikelihood1, H1, 1_Z and H1_Z.m routines and would like to avoid any potential edit conflicts.
Just to mention that we have decided that there would be no more Dynare release in the 4.0.x. We are now focusing our energies on the next major release, 4.1, by the end of the summer if everything goes well.
So it's not necessary to fix the 4.0 branch.
Best,
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
OK, many thanks Marco
Hi
The trunk ones are still being used by DsgeLikilihood_hh and will be needed for 4.1 and the branch ones appear to be just their identical copies (e.g. diff reports no differences), and so will they be fixed by mere copying - just in case.
If that is OK , I will lock them this afternoon and let you know when I finish and unlock them.
Regards George
----- Original Message ----- From: "Michel Juillard" michel.juillard@ens.fr To: "List for Dynare developers" dev@dynare.org Sent: Wednesday, July 08, 2009 12:08 PM Subject: Re: [DynareDev] DiffuseLikelihod kalman routines
I beg to disagree. It's not a good idea to leave bugs behind. I had already forgotten these ones when we decided to release 4.0.4 I don't think it is big changes either
Best
Michel
Sébastien Villemot wrote:
Le mercredi 08 juillet 2009 à 10:56 +0100, G. Perendia a écrit :
I am scheduling some bug fixing changes to both the trunk and the branch DiffuseLikelihood1, H1, 1_Z and H1_Z.m routines and would like to avoid any potential edit conflicts.
Just to mention that we have decided that there would be no more Dynare release in the 4.0.x. We are now focusing our energies on the next major release, 4.1, by the end of the summer if everything goes well.
So it's not necessary to fix the 4.0 branch.
Best,
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Hi All (and Marco!)
1) I made and committed the changes to both the trunk and the branch versions of DiffuseLikelihood1, H1, 1_Z and H1_Z.m routines and released locked routines earlier today.
2) However, things are never so simple and the resulting chain reaction / snowball goes on:
Looking at the other DiffuseLikelihood* functions called within DsgeLikilihood_hh that initially did not need the bug fix:
DiffuseLikelihoodH3_Z DiffuseLikelihood3_Z DiffuseLikelihoodH3corr_Z
The first two use inherently correct but in the context of DsgeLikilihood_hh incompatible calculation of the lik array which contains all log(2*pi) in the last (sample+1) element i.e. lik(smpl+1) = smpl*pp*log(2*pi);
so that LIK :
LIK = .5*(sum(lik(start:end))-(start-1)*lik(smpl+1)/smpl);
is correctly calculated within the functions but that yields probably incorrect one for the llik returned from DsgeLikilihood_hh in its last line:
llik=[-lnprior; .5*lik(start:end)]
I.e. it will contain too many log(2*pi) 's when start>1.
3) Also, the new kalman_filter and corrected DiffuseLikelihood ones all have
lik = (lik + pp*log(2*pi))/2
so the lik is already multiplied with 0.5! and that is incompatible with the llik calculation in DsgeLikilihood_hh.
I guess, for consistency, I should make some of the changes to the other Diffuse functions now too, i.e. replace: lik(smpl+1) = smpl*pp*log(2*pi); with lik = (lik + pp*log(2*pi))/2 as in all other kalman_filter ones
and , in DsgeLikilihood_hh, probably replace
llik=[-lnprior; .5*lik(start:end)] with llik=[-lnprior; lik(start:end)]
This is even more urgent since the new version of kalman_filter.m, also called within DsgeLikilihood_hh, also pre- halves lik array!
3) The third called function does not exist in the matlab directory but DiffuseLikelihoodH3corr.m (without "_Z") does and that has the same compatibility problem.
Hence, DsgeLikilihood_hh also needs to be corrected to refer to an existing function (I guess it was a typo in DsgeLikilihood_hh) and I can make that correction too if that is OK.
Best regards
George
----- Original Message ----- From: "G. Perendia" george@perendia.orangehome.co.uk To: "List for Dynare developers" dev@dynare.org Sent: Wednesday, July 08, 2009 12:24 PM Subject: Re: [DynareDev] DiffuseLikelihod kalman routines
Hi
The trunk ones are still being used by DsgeLikilihood_hh and will be needed for 4.1 and the branch ones appear to be just their identical copies (e.g. diff reports no differences), and so will they be fixed by mere copying - just in case.
If that is OK , I will lock them this afternoon and let you know when I finish and unlock them.
Regards George
----- Original Message ----- From: "Michel Juillard" michel.juillard@ens.fr To: "List for Dynare developers" dev@dynare.org Sent: Wednesday, July 08, 2009 12:08 PM Subject: Re: [DynareDev] DiffuseLikelihod kalman routines
I beg to disagree. It's not a good idea to leave bugs behind. I had already forgotten these ones when we decided to release 4.0.4 I don't think it is big changes either
Best
Michel
Sébastien Villemot wrote:
Le mercredi 08 juillet 2009 à 10:56 +0100, G. Perendia a écrit :
I am scheduling some bug fixing changes to both the trunk and the branch DiffuseLikelihood1, H1, 1_Z and H1_Z.m routines and would like to avoid any potential edit conflicts.
Just to mention that we have decided that there would be no more Dynare release in the 4.0.x. We are now focusing our energies on the next major release, 4.1, by the end of the summer if everything goes well.
So it's not necessary to fix the 4.0 branch.
Best,
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev