breaking changes for stoch_simul and discretionary policy
Hello, Houtan's commit https://git.dynare.org/Dynare/preprocessor/commit/04b6a68aef1dea23f991e788af... alerts me to the fact that these changes break existing code where the Matlab function is called directly. Many people do that. I wonder if we should not instead rename the functions with the new interface and provide converted functions with the old interface Best -- Michel Juillard
Hi Michel, I don't see how that would be feasible. It's not about the interface, but about some variables being global. A backward-compatible interface would again work with a global variable, implying that we lose the intended benefit of controlling which function changes the former globals. Thus, I would live with break. 4.6 is going to break some existing code in any case. We moved from character arrays to cells. That will break many text operations used to select parameters and tables. Best, Johannes -----Ursprüngliche Nachricht----- Von: Dev [mailto:dev-bounces@dynare.org] Im Auftrag von Michel Juillard Gesendet: Donnerstag, 12. September 2019 18:53 An: List for Dynare developers <dev@dynare.org> Betreff: [DynareDev] breaking changes for stoch_simul and discretionary policy Hello, Houtan's commit https://git.dynare.org/Dynare/preprocessor/commit/04b6a68aef1dea23f991e788af 911781d41bb4ab alerts me to the fact that these changes break existing code where the Matlab function is called directly. Many people do that. I wonder if we should not instead rename the functions with the new interface and provide converted functions with the old interface Best -- Michel Juillard _______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
Hi, I suggest the following 1) rename the new stoch_simul(M_, options_, oo_, var_list_) to compute_perturbation(M_, options_, oo_, var_list_) 2) use compute_perturbation() in the parser 3) rewrite the old function as function info = stoch_simul(var_list) global M_ options_ oo_ var_list) info = compute_perturbation(M_, options_, oo_, var_list_) and store it in new directory backward_compatibility to be added to the path 4) idem for discretionary_policy() 5) to have a compatibility function 4.6_4.5() that convert back the new cellarrays to character arrays Best Michel Johannes Pfeifer writes:
Hi Michel, I don't see how that would be feasible. It's not about the interface, but about some variables being global. A backward-compatible interface would again work with a global variable, implying that we lose the intended benefit of controlling which function changes the former globals. Thus, I would live with break. 4.6 is going to break some existing code in any case. We moved from character arrays to cells. That will break many text operations used to select parameters and tables. Best, Johannes
-----Ursprüngliche Nachricht----- Von: Dev [mailto:dev-bounces@dynare.org] Im Auftrag von Michel Juillard Gesendet: Donnerstag, 12. September 2019 18:53 An: List for Dynare developers <dev@dynare.org> Betreff: [DynareDev] breaking changes for stoch_simul and discretionary policy
Hello,
Houtan's commit https://git.dynare.org/Dynare/preprocessor/commit/04b6a68aef1dea23f991e788af 911781d41bb4ab alerts me to the fact that these changes break existing code where the Matlab function is called directly. Many people do that.
I wonder if we should not instead rename the functions with the new interface and provide converted functions with the old interface
Best
-- Michel Juillard
Hi Michel, Le vendredi 13 septembre 2019 à 08:21 +0200, Michel Juillard a écrit :
5) to have a compatibility function 4.6_4.5()that convert back the new cellarrays to character arrays
Note that the usefulness of such a compatibility layer would be at best very limited. Basically the M_.endo_names and friends are now cell arrays, while they used to be character arrays. So, for example, people who access that structure from a steady state file will have to update that file, one way or another. At best, a compatibility layer can facilitate that updating; but even that is not obvious, because that layer can’t just convert back the global M_.endo_names to a character array without breaking everything else. -- Sébastien Villemot Economist at CEPREMAP Dynare developer http://sebastien.villemot.name
I have opened a Gitlab issue on this topic: https://git.dynare.org/Dynare/dynare/issues/1656 Let's continue the discussion there. Le vendredi 13 septembre 2019 à 09:49 +0200, Sébastien Villemot a écrit :
Hi Michel,
Le vendredi 13 septembre 2019 à 08:21 +0200, Michel Juillard a écrit :
5) to have a compatibility function 4.6_4.5()that convert back the new cellarrays to character arrays
Note that the usefulness of such a compatibility layer would be at best very limited.
Basically the M_.endo_names and friends are now cell arrays, while they used to be character arrays. So, for example, people who access that structure from a steady state file will have to update that file, one way or another. At best, a compatibility layer can facilitate that updating; but even that is not obvious, because that layer can’t just convert back the global M_.endo_names to a character array without breaking everything else.
-- Sébastien Villemot Economist at CEPREMAP Dynare developer http://sebastien.villemot.name
_______________________________________________Dev mailing listDev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev -- Sébastien Villemot Economist at CEPREMAP Dynare developer http://sebastien.villemot.name
participants (3)
-
Johannes Pfeifer -
Michel Juillard -
Sébastien Villemot