Re: [DynareDev] integratio of Partial information and current expectations into Dynare
Hi there, the guiding principle should be to do the integration right from the start and commit the necessary resources rather than having to do it over later. 1) to you have a write-up with the algebra that needs to be performed for partial information inside Dynare? 2) we have first to decide whether it is best to treat expectations as different (auxiliary) endogenous variables or to define a 4th type. - Currently, in full information, if we want E_{t-1} y_t, one needs to create an auxiliary variable and an auxiliary equation ey = y(+1) and use ey(-1) instead of E_{t-1} y_t. If we are to provide an explicit operator E{i}{y}, the preprocessor would need to create the auxiliary variable, add the equation to the model, and perform the substitution as needed. We would need to keep a table of these auxiliary variables, but it doesn't seem necessary or desirable to create a 4th type of variable because the rules for output would be the same as for regular endogenous variables [Currently, I have also doubt about the distinction endogenous/exogenous, but this is another story...] Are there reasons to believe this would be different with partial information? Best Michel Quoting "G. Perendia" <george@perendia.orangehome.co.uk>:
Dear Joe
I have been thinking about the integration of the Partial information and current expectations into Dynare as you asked me to and I have some ideas but no easy solutions.
As I mentioned, a shortcut solution may require additional proxy variables for contemporary expectations such as ETYT_t = Et[y_t].
I expect an additional expectation error equations will be required that should avoid determinacy issues with the additional variable and the possible problems when solved, e,g, for steady state, poss on the lines of:
y_t = ETYT_t + e_t
Using then an additional structure (e.g. set inside the M_ or options_ structures) that is mapping expectations to their bases on the lines of:
['YTT' 'Y_t'; ......]
the Part info solver will be able to identify which of the relations are "dummy" and then transform and solve the model for decision rule using its own solver.
This solution however may become rather tedious to model from the user perspective, that is, if at all plausible - so, please let me know what you think. It will also require some parsing of the model within PI module to map-in expectations.
Alternatively, the proper integration would require changing start-to-end Dynare pipeline, from the parser/prerpocessor to KF estimation. It may then require adding 4th type of variable: expectation in addition to the existing: predetermined, forward and static variables, and, thus, changes to the numerous internal structures and functions.
This will, however, probably introduce an additional burden on the design and development resources, rather more than initially envisaged.
Best regards
George Mob. +44(0)7951415480 artilogica@btconnect.com
--
Hi I believe (but may be wrong) that the "short-cut" does not mean we need to do it "properly" later (unless e.g. we want to introduce explicitly the expectation operator into Dynare model syntax) I think I was setting the auxiliary (which I refer to as proxy) variable and its equation for the contemporary expectations on similar lines to those for E_{t-1}y_t, except that I used also the contemporary expectation error e_t which I thought was necessary. However, I have to say that the "short" solution so far still does not yet answer how to deal with what in partial information we tend to call "auxiliary" variables (but may be called proxy instead if you like) - i.e. any of the noisy, optional, additional observations in the observation vector which (so far) are not deemed to be part of the core model's either endogenous or its exogenous sets, such as consumer's satisfaction index (obsCSX) or RPI based inflation measure. They are related to one or more of the core model's endogenous variables by auxiliary linear equation(s) which are not part of the main, core model and not directly part of the core model transition state matrix, but part of the part-info extended state space observation equation set W, e.g.: obsY_t = y_t - the usual observation of y_t, and, .... obsRPI_t = PI_t [+ ep_t] and obsCSX_t = a*C_t +b*W_t + c*y_t [+ ec_t ] where a, b and c can be either estimated or precalibrated parameters and e*_t are [optional] observation errors. Those "auxiliary" observations and their relations will also need to be specified somewhere in the model but that can be in the 2nd stage of implementation. Best regards George ----- Original Message ----- From: "Michel Juillard" <Michel.Juillard@ens.fr> To: <dev@dynare.org> Cc: "joe pearlman" <j.pearlman@londonmet.ac.uk> Sent: Monday, November 24, 2008 12:10 PM Subject: Re: [DynareDev] integratio of Partial information and currentexpectations into Dynare
Hi there,
the guiding principle should be to do the integration right from the start and commit the necessary resources rather than having to do it over later.
1) to you have a write-up with the algebra that needs to be performed for partial information inside Dynare? 2) we have first to decide whether it is best to treat expectations as different (auxiliary) endogenous variables or to define a 4th type. - Currently, in full information, if we want E_{t-1} y_t, one needs to create an auxiliary variable and an auxiliary equation ey = y(+1) and use ey(-1) instead of E_{t-1} y_t. If we are to provide an explicit operator E{i}{y}, the preprocessor would need to create the auxiliary variable, add the equation to the model, and perform the substitution as needed. We would need to keep a table of these auxiliary variables, but it doesn't seem necessary or desirable to create a 4th type of variable because the rules for output would be the same as for regular endogenous variables [Currently, I have also doubt about the distinction endogenous/exogenous, but this is another story...] Are there reasons to believe this would be different with partial information?
Best
Michel
Quoting "G. Perendia" <george@perendia.orangehome.co.uk>:
Dear Joe
I have been thinking about the integration of the Partial information and current expectations into Dynare as you asked me to and I have some ideas but no easy solutions.
As I mentioned, a shortcut solution may require additional proxy variables for contemporary expectations such as ETYT_t = Et[y_t].
I expect an additional expectation error equations will be required that should avoid determinacy issues with the additional variable and the possible problems when solved, e,g, for steady state, poss on the lines of:
y_t = ETYT_t + e_t
Using then an additional structure (e.g. set inside the M_ or options_ structures) that is mapping expectations to their bases on the lines of:
['YTT' 'Y_t'; ......]
the Part info solver will be able to identify which of the relations are "dummy" and then transform and solve the model for decision rule using its own solver.
This solution however may become rather tedious to model from the user perspective, that is, if at all plausible - so, please let me know what you think. It will also require some parsing of the model within PI module to map-in expectations.
Alternatively, the proper integration would require changing start-to-end Dynare pipeline, from the parser/prerpocessor to KF estimation. It may then require adding 4th type of variable: expectation in addition to the existing: predetermined, forward and static variables, and, thus, changes to the numerous internal structures and functions.
This will, however, probably introduce an additional burden on the design and development resources, rather more than initially envisaged.
Best regards
George
--
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Thanks George. I guess that we can make a decision when we get a complete description of your algorithm. I guess examples that would cover typical case/use of partial information would be also helpful. Best Michel G. Perendia wrote:
Hi
I believe (but may be wrong) that the "short-cut" does not mean we need to do it "properly" later (unless e.g. we want to introduce explicitly the expectation operator into Dynare model syntax)
I think I was setting the auxiliary (which I refer to as proxy) variable and its equation for the contemporary expectations on similar lines to those for E_{t-1}y_t, except that I used also the contemporary expectation error e_t which I thought was necessary.
However, I have to say that the "short" solution so far still does not yet answer how to deal with what in partial information we tend to call "auxiliary" variables (but may be called proxy instead if you like) - i.e. any of the noisy, optional, additional observations in the observation vector which (so far) are not deemed to be part of the core model's either endogenous or its exogenous sets, such as consumer's satisfaction index (obsCSX) or RPI based inflation measure. They are related to one or more of the core model's endogenous variables by auxiliary linear equation(s) which are not part of the main, core model and not directly part of the core model transition state matrix, but part of the part-info extended state space observation equation set W, e.g.:
obsY_t = y_t - the usual observation of y_t, and, .... obsRPI_t = PI_t [+ ep_t] and obsCSX_t = a*C_t +b*W_t + c*y_t [+ ec_t ]
where a, b and c can be either estimated or precalibrated parameters and e*_t are [optional] observation errors.
Those "auxiliary" observations and their relations will also need to be specified somewhere in the model but that can be in the 2nd stage of implementation.
Best regards
George
----- Original Message ----- From: "Michel Juillard" <Michel.Juillard@ens.fr> To: <dev@dynare.org> Cc: "joe pearlman" <j.pearlman@londonmet.ac.uk> Sent: Monday, November 24, 2008 12:10 PM Subject: Re: [DynareDev] integratio of Partial information and currentexpectations into Dynare
Hi there,
the guiding principle should be to do the integration right from the start
and
commit the necessary resources rather than having to do it over later.
1) to you have a write-up with the algebra that needs to be performed for partial information inside Dynare? 2) we have first to decide whether it is best to treat expectations as
different
(auxiliary) endogenous variables or to define a 4th type. - Currently, in full information, if we want E_{t-1} y_t, one needs to
create an
auxiliary variable and an auxiliary equation ey = y(+1) and use ey(-1) instead of E_{t-1} y_t. If we are to provide an explicit operator E{i}{y}, the preprocessor would
need
to create the auxiliary variable, add the equation to the model, and
perform
the substitution as needed. We would need to keep a table of these auxiliary variables, but it doesn't
seem
necessary or desirable to create a 4th type of variable because the rules
for
output would be the same as for regular endogenous variables [Currently, I have also doubt about the distinction endogenous/exogenous,
but
this is another story...] Are there reasons to believe this would be different with partial
information?
Best
Michel
Quoting "G. Perendia" <george@perendia.orangehome.co.uk>:
Dear Joe
I have been thinking about the integration of the Partial information
and
current expectations into Dynare as you asked me to and I have some
ideas but
no easy solutions.
As I mentioned, a shortcut solution may require additional proxy
variables
for contemporary expectations such as ETYT_t = Et[y_t].
I expect an additional expectation error equations will be required that should avoid determinacy issues with the additional variable and the
possible
problems when solved, e,g, for steady state, poss on the lines of:
y_t = ETYT_t + e_t
Using then an additional structure (e.g. set inside the M_ or options_ structures) that is mapping expectations to their bases on the lines of:
['YTT' 'Y_t'; ......]
the Part info solver will be able to identify which of the relations are "dummy" and then transform and solve the model for decision rule using
its
own solver.
This solution however may become rather tedious to model from the user perspective, that is, if at all plausible - so, please let me know what
you
think. It will also require some parsing of the model within PI module
to
map-in expectations.
Alternatively, the proper integration would require changing
start-to-end
Dynare pipeline, from the parser/prerpocessor to KF estimation. It may
then
require adding 4th type of variable: expectation in addition to the
existing:
predetermined, forward and static variables, and, thus, changes to the numerous internal structures and functions.
This will, however, probably introduce an additional burden on the
design and
development resources, rather more than initially envisaged.
Best regards
George
--
_______________________________________________ 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
Dear all I'll send something out this week Joe
Thanks George. I guess that we can make a decision when we get a complete description of your algorithm. I guess examples that would cover typical case/use of partial information would be also helpful.
Best
Michel
G. Perendia wrote:
Hi
I believe (but may be wrong) that the "short-cut" does not mean we need to do it "properly" later (unless e.g. we want to introduce explicitly the expectation operator into Dynare model syntax)
I think I was setting the auxiliary (which I refer to as proxy) variable and its equation for the contemporary expectations on similar lines to those for E_{t-1}y_t, except that I used also the contemporary expectation error e_t which I thought was necessary.
However, I have to say that the "short" solution so far still does not yet answer how to deal with what in partial information we tend to call "auxiliary" variables (but may be called proxy instead if you like) - i.e. any of the noisy, optional, additional observations in the observation vector which (so far) are not deemed to be part of the core model's either endogenous or its exogenous sets, such as consumer's satisfaction index (obsCSX) or RPI based inflation measure. They are related to one or more of the core model's endogenous variables by auxiliary linear equation(s) which are not part of the main, core model and not directly part of the core model transition state matrix, but part of the part-info extended state space observation equation set W, e.g.:
obsY_t = y_t - the usual observation of y_t, and, .... obsRPI_t = PI_t [+ ep_t] and obsCSX_t = a*C_t +b*W_t + c*y_t [+ ec_t ]
where a, b and c can be either estimated or precalibrated parameters and e*_t are [optional] observation errors.
Those "auxiliary" observations and their relations will also need to be specified somewhere in the model but that can be in the 2nd stage of implementation.
Best regards
George
----- Original Message ----- From: "Michel Juillard" <Michel.Juillard@ens.fr> To: <dev@dynare.org> Cc: "joe pearlman" <j.pearlman@londonmet.ac.uk> Sent: Monday, November 24, 2008 12:10 PM Subject: Re: [DynareDev] integratio of Partial information and currentexpectations into Dynare
Hi there,
the guiding principle should be to do the integration right from the start
and
commit the necessary resources rather than having to do it over later.
1) to you have a write-up with the algebra that needs to be performed for partial information inside Dynare? 2) we have first to decide whether it is best to treat expectations as
different
(auxiliary) endogenous variables or to define a 4th type. - Currently, in full information, if we want E_{t-1} y_t, one needs to
create an
auxiliary variable and an auxiliary equation ey = y(+1) and use ey(-1) instead of E_{t-1} y_t. If we are to provide an explicit operator E{i}{y}, the preprocessor would
need
to create the auxiliary variable, add the equation to the model, and
perform
the substitution as needed. We would need to keep a table of these auxiliary variables, but it doesn't
seem
necessary or desirable to create a 4th type of variable because the rules
for
output would be the same as for regular endogenous variables [Currently, I have also doubt about the distinction endogenous/exogenous,
but
this is another story...] Are there reasons to believe this would be different with partial
information?
Best
Michel
Quoting "G. Perendia" <george@perendia.orangehome.co.uk>:
Dear Joe
I have been thinking about the integration of the Partial information
and
current expectations into Dynare as you asked me to and I have some
ideas but
no easy solutions.
As I mentioned, a shortcut solution may require additional proxy
variables
for contemporary expectations such as ETYT_t = Et[y_t].
I expect an additional expectation error equations will be required that should avoid determinacy issues with the additional variable and the
possible
problems when solved, e,g, for steady state, poss on the lines of:
y_t = ETYT_t + e_t
Using then an additional structure (e.g. set inside the M_ or options_ structures) that is mapping expectations to their bases on the lines of:
['YTT' 'Y_t'; ......]
the Part info solver will be able to identify which of the relations are "dummy" and then transform and solve the model for decision rule using
its
own solver.
This solution however may become rather tedious to model from the user perspective, that is, if at all plausible - so, please let me know what
you
think. It will also require some parsing of the model within PI module
to
map-in expectations.
Alternatively, the proper integration would require changing
start-to-end
Dynare pipeline, from the parser/prerpocessor to KF estimation. It may
then
require adding 4th type of variable: expectation in addition to the
existing:
predetermined, forward and static variables, and, thus, changes to the numerous internal structures and functions.
This will, however, probably introduce an additional burden on the
design and
development resources, rather more than initially envisaged.
Best regards
George
--
_______________________________________________ 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 I noticed dynare_m.exe is currently missing in v4 SVN - has it gone "under a repair"? Best regards George
Hi George, we aren't distributing dynare_m.exe by SVN anymore. In fact the one that was still there hadn't been updated for a while. You should recompile the preprocessor after a SVN update. Alternatively, you can obtain the last version of dynare_m.exe from the current snapshot for version 4. I should put a warning on the web site. All the best, Michel Quoting "G. Perendia" <george@perendia.orangehome.co.uk>:
Hi
I noticed dynare_m.exe is currently missing in v4 SVN - has it gone "under a repair"?
Best regards George
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
--
Hi Do you think that by the way we could also remove DLL binaries from the SVN ? Thanks Sébastien Le mercredi 03 décembre 2008 à 12:06 +0100, Michel Juillard a écrit :
Hi George,
we aren't distributing dynare_m.exe by SVN anymore. In fact the one that was still there hadn't been updated for a while. You should recompile the preprocessor after a SVN update. Alternatively, you can obtain the last version of dynare_m.exe from the current snapshot for version 4.
I should put a warning on the web site.
All the best,
Michel
Quoting "G. Perendia" <george@perendia.orangehome.co.uk>:
Hi
I noticed dynare_m.exe is currently missing in v4 SVN - has it gone "under a repair"?
Best regards George
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Not without writing an alternative procedure to build the snapshots and constructing a depository for binary DLLs on Kirikou. Best Michel Quoting Sébastien Villemot <sebastien.villemot@ens.fr>:
Hi
Do you think that by the way we could also remove DLL binaries from the SVN ?
Thanks
Sébastien
Le mercredi 03 décembre 2008 à 12:06 +0100, Michel Juillard a écrit :
Hi George,
we aren't distributing dynare_m.exe by SVN anymore. In fact the one that was still there hadn't been updated for a while. You should recompile the preprocessor after a SVN update. Alternatively, you can obtain the last version of dynare_m.exe from the current snapshot for version 4.
I should put a warning on the web site.
All the best,
Michel
Quoting "G. Perendia" <george@perendia.orangehome.co.uk>:
Hi
I noticed dynare_m.exe is currently missing in v4 SVN - has it gone "under a repair"?
Best regards George
_______________________________________________ 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 I think that offloading the compilation and linking to the "users" of SVN does not save our time but, on the contrary: i..e. each user then has to do his/her own build including each of us, the developers. On the other hand, who ever changed the original source code most likely had to do the build anyway to test it. Why not just putting it into SVN then and save time to the dev team as well as any potential users. And, whoever needs or wants to rebuild it then can do so too. Best regards George ----- Original Message ----- From: "Sébastien Villemot" <sebastien.villemot@ens.fr> To: "List for Dynare developers" <dev@dynare.org> Sent: Wednesday, December 03, 2008 1:36 PM Subject: Re: [DynareDev] Dynare_m. exe missing in SVN
Hi
Do you think that by the way we could also remove DLL binaries from the SVN ?
Thanks
Sébastien
Le mercredi 03 décembre 2008 à 12:06 +0100, Michel Juillard a écrit :
Hi George,
we aren't distributing dynare_m.exe by SVN anymore. In fact the one that was still there hadn't been updated for a while. You should recompile the preprocessor after a SVN update. Alternatively, you can obtain the last version of dynare_m.exe from the current snapshot for version 4.
I should put a warning on the web site.
All the best,
Michel
Quoting "G. Perendia" <george@perendia.orangehome.co.uk>:
Hi
I noticed dynare_m.exe is currently missing in v4 SVN - has it gone "under a repair"?
Best regards George
_______________________________________________ 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
Michel: ok, I will think about that procedure. George: basically, SVN is not a made for exchanging binaries, although it is able to do so. The main reason not to put binaries in the SVN is that it often creates conflicts on local copies: if someones updates the binary in the SVN, and if you have recompiled it on your own machine, you will get a conflict when doing SVN update, since SVN is unable to merge changes in binary files. This occurs even if you compile the same code, because often the compiler is different. Another reason is that putting binaries in the SVN creates a huge repository on the server (all the historical versions of all the binaries are kept on the server). Downloading Dynare through SVN is only for experienced users who know how to recompile the code. For others we provide a stable distribution with binaries, and a snapshot of the SVN (unstable version) also containing the binaries. Best Sébasitien Le mercredi 03 décembre 2008 à 13:50 +0000, G. Perendia a écrit :
Hi
I think that offloading the compilation and linking to the "users" of SVN does not save our time but, on the contrary: i..e. each user then has to do his/her own build including each of us, the developers.
On the other hand, who ever changed the original source code most likely had to do the build anyway to test it. Why not just putting it into SVN then and save time to the dev team as well as any potential users. And, whoever needs or wants to rebuild it then can do so too.
Best regards
George ----- Original Message ----- From: "Sébastien Villemot" <sebastien.villemot@ens.fr> To: "List for Dynare developers" <dev@dynare.org> Sent: Wednesday, December 03, 2008 1:36 PM Subject: Re: [DynareDev] Dynare_m. exe missing in SVN
Hi
Do you think that by the way we could also remove DLL binaries from the SVN ?
Thanks
Sébastien
Le mercredi 03 décembre 2008 à 12:06 +0100, Michel Juillard a écrit :
Hi George,
we aren't distributing dynare_m.exe by SVN anymore. In fact the one that was still there hadn't been updated for a while. You should recompile the preprocessor after a SVN update. Alternatively, you can obtain the last version of dynare_m.exe from the current snapshot for version 4.
I should put a warning on the web site.
All the best,
Michel
Quoting "G. Perendia" <george@perendia.orangehome.co.uk>:
Hi
I noticed dynare_m.exe is currently missing in v4 SVN - has it gone "under a repair"?
Best regards George
_______________________________________________ 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
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Hi George, one of the problems is that we have now too many target architectures: -Windows 32 bit Windows 64 bit Linux 32 bit Linux 64 bit -Matlab and Octave -The problem under Linux is multiplied by the presence of different versions of libc.so -For the DLL you need to multiply by the different versions of Matlab. Until now, we were only putting the binary for Windows 32 bit. This is what is discountinued. Actually, Sebastien and Stephane who develop under Linux, don't have an immediate way (or need) to build the Windows binary. For my part, I must admit that I very frequently just forgot to update dynare_m.exe on SVN. The idea is to direct the users towards the numbered versions or the snapshot is they really need the very last version. For the developers, I think that we can live with recompiling when we need the last version. In the future, I would like us to offer a dynare_update procedure that let a user update automatically to the last version. It could maybe be a solution to the problem of adapting the binaries to the installation of the user rather that giving him/her all versions of the binaries. Best Michel Quoting "G. Perendia" <george@perendia.orangehome.co.uk>:
Hi
I think that offloading the compilation and linking to the "users" of SVN does not save our time but, on the contrary: i..e. each user then has to do his/her own build including each of us, the developers.
On the other hand, who ever changed the original source code most likely had to do the build anyway to test it. Why not just putting it into SVN then and save time to the dev team as well as any potential users. And, whoever needs or wants to rebuild it then can do so too.
Best regards
George ----- Original Message ----- From: "Sébastien Villemot" <sebastien.villemot@ens.fr> To: "List for Dynare developers" <dev@dynare.org> Sent: Wednesday, December 03, 2008 1:36 PM Subject: Re: [DynareDev] Dynare_m. exe missing in SVN
Hi
Do you think that by the way we could also remove DLL binaries from the SVN ?
Thanks
Sébastien
Le mercredi 03 décembre 2008 à 12:06 +0100, Michel Juillard a écrit :
Hi George,
we aren't distributing dynare_m.exe by SVN anymore. In fact the one that was still there hadn't been updated for a while. You should recompile the preprocessor after a SVN update. Alternatively, you can obtain the last version of dynare_m.exe from the current snapshot for version 4.
I should put a warning on the web site.
All the best,
Michel
Quoting "G. Perendia" <george@perendia.orangehome.co.uk>:
Hi
I noticed dynare_m.exe is currently missing in v4 SVN - has it gone "under a repair"?
Best regards George
_______________________________________________ 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
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
--
Hi, thanks for all your explanations, I was obviously not aware of all those difficulties associated with maintaining the DLLs in SVN. Best regards George ----- Original Message ----- From: "Michel Juillard" <Michel.Juillard@ens.fr> To: "List for Dynare developers" <dev@dynare.org> Sent: Wednesday, December 03, 2008 2:11 PM Subject: Re: [DynareDev] Dynare_m. exe missing in SVN Hi George, one of the problems is that we have now too many target architectures: -Windows 32 bit Windows 64 bit Linux 32 bit Linux 64 bit -Matlab and Octave -The problem under Linux is multiplied by the presence of different versions of libc.so -For the DLL you need to multiply by the different versions of Matlab. Until now, we were only putting the binary for Windows 32 bit. This is what is discountinued. Actually, Sebastien and Stephane who develop under Linux, don't have an immediate way (or need) to build the Windows binary. For my part, I must admit that I very frequently just forgot to update dynare_m.exe on SVN. The idea is to direct the users towards the numbered versions or the snapshot is they really need the very last version. For the developers, I think that we can live with recompiling when we need the last version. In the future, I would like us to offer a dynare_update procedure that let a user update automatically to the last version. It could maybe be a solution to the problem of adapting the binaries to the installation of the user rather that giving him/her all versions of the binaries. Best Michel Quoting "G. Perendia" <george@perendia.orangehome.co.uk>:
Hi
I think that offloading the compilation and linking to the "users" of SVN does not save our time but, on the contrary: i..e. each user then has to do his/her own build including each of us, the developers.
On the other hand, who ever changed the original source code most likely had to do the build anyway to test it. Why not just putting it into SVN then and save time to the dev team as well as any potential users. And, whoever needs or wants to rebuild it then can do so too.
Best regards
George ----- Original Message ----- From: "Sébastien Villemot" <sebastien.villemot@ens.fr> To: "List for Dynare developers" <dev@dynare.org> Sent: Wednesday, December 03, 2008 1:36 PM Subject: Re: [DynareDev] Dynare_m. exe missing in SVN
Hi
Do you think that by the way we could also remove DLL binaries from the SVN ?
Thanks
Sébastien
Le mercredi 03 décembre 2008 à 12:06 +0100, Michel Juillard a écrit :
Hi George,
we aren't distributing dynare_m.exe by SVN anymore. In fact the one that was still there hadn't been updated for a while. You should recompile the preprocessor after a SVN update. Alternatively, you can obtain the last version of dynare_m.exe from the current snapshot for version 4.
I should put a warning on the web site.
All the best,
Michel
Quoting "G. Perendia" <george@perendia.orangehome.co.uk>:
Hi
I noticed dynare_m.exe is currently missing in v4 SVN - has it gone "under a repair"?
Best regards George
_______________________________________________ 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
_______________________________________________ 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
participants (5)
-
G. Perendia -
Joe Pearlman -
Michel Juillard -
Michel Juillard
-
Sébastien Villemot