Hi Jesus, thanks for the feedback. I know that Sébastien and a few others have looked into Julia and by and large like it. The main question is what could be Julia's role in a project like Dynare. Should we think about - a replacement for Matlab, users running Dynare models from within Julia? - keep Matlab as the main user interface but using Julia as a way to develop computing intensive parts of code that is more efficient than Matlab but easier to develop than C++? Then, can we call Julia easily from within Matlab? - make a separate Julia library of tools for DSGE modeling? Something like Dynare-julia for advanced users who don't mind switching from Matlab to Julia? By the way, I'm currently working on an extension of the Dynare preprocessor to provide a C++ versions of the functions describing a given model, a C++ equivalent to <modfile>.m, <modfile>_dynamic.m and <modfile>_static.m. I need it for a project using Cuda and another one on Markow-Switching models with Dan and Tao. I will make sure that these C++ objects load easily in Julia. I will let you know progress on this front. All the best, Michel Jesus Fernandez-Villaverde writes:
Hi Michel
I have kept working this summer in Julia.
I am actually quite happy with it.
For example, for a basic RBC model computed with VFI, I get a 400% speed up w.r.t my Matlab code (and that without trying to be "aggressive: in taking advantage of Julia features, it is really a nearly-literal translation of my Matlab code).
I do not know what you guys at the Dynare group are thinking about this, but I would be happy to talk more about the whole issue as a potential avenue of future development.
Please feel free to pass this email along
Jesus
-- Michel Juillard
Hi On 8/6/13 3:47 AM, Michel Juillard wrote:
Hi Jesus,
The main question is what could be Julia's role in a project like Dynare. Should we think about - a replacement for Matlab, users running Dynare models from within Julia? My first reaction would be that first option. Of course, given the base of Matlab users the transition will take quite a bit of time, but perhaps some of the basic dynare functions could be implemented in Julia as a package and see what happens.
I know that maintaining two parallel releases (Julia and Matlab) would be costly and that Julia's future is still unclear, so I am just proposing a prototype at this moment with a very basic functionality.
- keep Matlab as the main user interface but using Julia as a way to develop computing intensive parts of code that is more efficient than Matlab but easier to develop than C++? Then, can we call Julia easily from within Matlab? Yes, that is other alternative. I guess that would depend on how hard is to develop C++ from your side. If the team is comfortable with C++, then it may not be worthwhile.
On the interaction of julia and matlab https://github.com/timholy/julia-matlab
- make a separate Julia library of tools for DSGE modeling? Something like Dynare-julia for advanced users who don't mind switching from Matlab to Julia?
By the way, I'm currently working on an extension of the Dynare preprocessor to provide a C++ versions of the functions describing a given model, a C++ equivalent to <modfile>.m, <modfile>_dynamic.m and <modfile>_static.m. I need it for a project using Cuda and another one on Markow-Switching models with Dan and Tao. I will make sure that these C++ objects load easily in Julia. I will let you know progress on this front. Thanks! One of the advantages of julia is that it paralellizes much more easily than Matlab.....
J
All the best,
Michel
Jesus Fernandez-Villaverde writes:
Hi Michel
I have kept working this summer in Julia.
I am actually quite happy with it.
For example, for a basic RBC model computed with VFI, I get a 400% speed up w.r.t my Matlab code (and that without trying to be "aggressive: in taking advantage of Julia features, it is really a nearly-literal translation of my Matlab code).
I do not know what you guys at the Dynare group are thinking about this, but I would be happy to talk more about the whole issue as a potential avenue of future development.
Please feel free to pass this email along
Jesus
-- Jesús Fernández-Villaverde Economics-University of Pennsylvania www.econ.upenn.edu/~jesusfv
FYI, here is Sebastien's code Dynare for Julia code: https://github.com/DynareTeam/Dynare.jl Best, Houtan On 6 Aug 2013, at 7:00 AM, Jesus Fernandez-Villaverde wrote:
Hi
On 8/6/13 3:47 AM, Michel Juillard wrote:
Hi Jesus,
The main question is what could be Julia's role in a project like Dynare. Should we think about - a replacement for Matlab, users running Dynare models from within Julia? My first reaction would be that first option. Of course, given the base of Matlab users the transition will take quite a bit of time, but perhaps some of the basic dynare functions could be implemented in Julia as a package and see what happens.
I know that maintaining two parallel releases (Julia and Matlab) would be costly and that Julia's future is still unclear, so I am just proposing a prototype at this moment with a very basic functionality.
- keep Matlab as the main user interface but using Julia as a way to develop computing intensive parts of code that is more efficient than Matlab but easier to develop than C++? Then, can we call Julia easily from within Matlab? Yes, that is other alternative. I guess that would depend on how hard is to develop C++ from your side. If the team is comfortable with C++, then it may not be worthwhile.
On the interaction of julia and matlab
https://github.com/timholy/julia-matlab
- make a separate Julia library of tools for DSGE modeling? Something like Dynare-julia for advanced users who don't mind switching from Matlab to Julia?
By the way, I'm currently working on an extension of the Dynare preprocessor to provide a C++ versions of the functions describing a given model, a C++ equivalent to <modfile>.m, <modfile>_dynamic.m and <modfile>_static.m. I need it for a project using Cuda and another one on Markow-Switching models with Dan and Tao. I will make sure that these C++ objects load easily in Julia. I will let you know progress on this front. Thanks! One of the advantages of julia is that it paralellizes much more easily than Matlab.....
J
All the best,
Michel
Jesus Fernandez-Villaverde writes:
Hi Michel
I have kept working this summer in Julia.
I am actually quite happy with it.
For example, for a basic RBC model computed with VFI, I get a 400% speed up w.r.t my Matlab code (and that without trying to be "aggressive: in taking advantage of Julia features, it is really a nearly-literal translation of my Matlab code).
I do not know what you guys at the Dynare group are thinking about this, but I would be happy to talk more about the whole issue as a potential avenue of future development.
Please feel free to pass this email along
Jesus
-- Jesús Fernández-Villaverde Economics-University of Pennsylvania www.econ.upenn.edu/~jesusfv
_______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
where are you my friend? probably enjoying life in the streets of DC or Arlington I guess. On Tue, Aug 6, 2013 at 9:31 AM, Houtan Bastani <houtanb@gmail.com> wrote:
FYI, here is Sebastien's code Dynare for Julia code: https://github.com/DynareTeam/Dynare.jl
Best, Houtan
On 6 Aug 2013, at 7:00 AM, Jesus Fernandez-Villaverde wrote:
Hi
On 8/6/13 3:47 AM, Michel Juillard wrote:
Hi Jesus,
The main question is what could be Julia's role in a project like Dynare. Should we think about - a replacement for Matlab, users running Dynare models from within Julia? My first reaction would be that first option. Of course, given the base of Matlab users the transition will take quite a bit of time, but perhaps some of the basic dynare functions could be implemented in Julia as a package and see what happens.
I know that maintaining two parallel releases (Julia and Matlab) would be costly and that Julia's future is still unclear, so I am just proposing a prototype at this moment with a very basic functionality.
- keep Matlab as the main user interface but using Julia as a way to develop computing intensive parts of code that is more efficient than Matlab but easier to develop than C++? Then, can we call Julia easily from within Matlab? Yes, that is other alternative. I guess that would depend on how hard is to develop C++ from your side. If the team is comfortable with C++, then it may not be worthwhile.
On the interaction of julia and matlab
https://github.com/timholy/julia-matlab
- make a separate Julia library of tools for DSGE modeling? Something like Dynare-julia for advanced users who don't mind switching from Matlab to Julia?
By the way, I'm currently working on an extension of the Dynare preprocessor to provide a C++ versions of the functions describing a given model, a C++ equivalent to <modfile>.m, <modfile>_dynamic.m and <modfile>_static.m. I need it for a project using Cuda and another one on Markow-Switching models with Dan and Tao. I will make sure that these C++ objects load easily in Julia. I will let you know progress on this front. Thanks! One of the advantages of julia is that it paralellizes much more easily than Matlab.....
J
All the best,
Michel
Jesus Fernandez-Villaverde writes:
Hi Michel
I have kept working this summer in Julia.
I am actually quite happy with it.
For example, for a basic RBC model computed with VFI, I get a 400% speed up w.r.t my Matlab code (and that without trying to be "aggressive: in taking advantage of Julia features, it is really a nearly-literal translation of my Matlab code).
I do not know what you guys at the Dynare group are thinking about this, but I would be happy to talk more about the whole issue as a potential avenue of future development.
Please feel free to pass this email along
Jesus
-- Jesús Fernández-Villaverde Economics-University of Pennsylvania www.econ.upenn.edu/~jesusfv
_______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
_______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
-- "You can never know everything", Lan said quietly, "and part of what you know is always wrong. Perhaps even the most important part. A portion of wisdom lies in knowing that. A portion of courage lies in going on anyway." Robert Jordan, Winter's Heart, Book IX of the Wheel of Time. We have not succeeded in answering all of our problems. The answers we have found only serve to raise a whole set of new issues. In some ways we are as confused as ever, but we believe we are confused on a higher level and about more important things. (cited in Øksendal, 1985)
participants (4)
-
Houtan Bastani -
Jesus Fernandez-Villaverde -
Junior Maih -
Michel Juillard