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.
- 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.
- 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.
- 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
-
G. Perendia -
Joe Pearlman -
Michel Juillard -
Michel Juillard
-
Sébastien Villemot