Dear Friends,
I have been using recently both the option language=julia that I started using some time ago in https://github.com/MichelJuillard/dynare.jl and the JSON representation of the *.mod file.
I feel that it is the moment to decide wether we adopt one or the other. My preference goes to the JSON interface for the following reasons: 1. It is a strain on resources to try to develop both 2. The JSON interface has potential usages outside of the Dynare in Julia project. 3. It is relatively straithforward to implement the JSON interace in the preprocessor with a few intuitive standard fields for the JSONs. 4. The Julia implementation can then be done entirely in Julia. 5. On the contrary, developing the option language=julia requires to develop in parallel the preprorcessor and the Julia implementation of Dynare commands.
If we go that way, I will make sure that the code in dynare.jl works, but I will stop developing that git project and start afresh in a new git project. I have created https://gitlab.com/dynare-julia as a group of projects. I want to develop separate packages for the low level code that isn't Dynare specific. These packages must go is separate git projects under the dynare-julia umbrella.
Please, tell me what you think.
All the best,
Hi Michel,
Le mardi 24 mars 2020 à 17:11 +0100, Michel Juillard a écrit :
Dear Friends, I have been using recently both the option language=julia that I startedusing some time ago in https://github.com/MichelJuillard/dynare.jl andthe JSON representation of the *.mod file. I feel that it is the moment to decide wether we adopt one or theother. My preference goes to the JSON interface for the followingreasons:1. It is a strain on resources to try to develop both2. The JSON interface has potential usages outside of the Dynare inJulia project.3. It is relatively straithforward to implement the JSON interace in thepreprocessor with a few intuitive standard fields for the JSONs.4. The Julia implementation can then be done entirely in Julia.5. On the contrary, developing the option language=julia requires todevelop in parallel the preprorcessor and the Julia implementation ofDynare commands.
Note that the JSON format is already used outside Julia (in particular by code for the ECB-MC model).
I don’t see the Julia and JSON backends as interchangeable, and I’m therefore not sure that we should drop either. But Stéphane and Houtan can probably better comment on that, since they designed both backends.
If we go that way, I will make sure that the code in dynare.jl works,but I will stop developing that git project and start afresh in a newgit project. I have created https://gitlab.com/dynare-julia as a groupof projects. I want to develop separate packages for the low levelcode that isn't Dynare specific. These packages must go is separategit projects under the dynare-julia umbrella.
If those packages are unrelated to Dynare, I’m afraid putting “dynare” in the name of the group will only confuse users.
On the other hand, if they are somewhat related to Dynare, I think they should rather be hosted on git.dynare.org (possibly in a new group there).
Best,
Hi Sebastien Sébastien Villemot writes:
Hi Michel,
Le mardi 24 mars 2020 à 17:11 +0100, Michel Juillard a écrit :
Dear Friends, I have been using recently both the option language=julia that I startedusing some time ago in https://github.com/MichelJuillard/dynare.jl andthe JSON representation of the *.mod file. I feel that it is the moment to decide wether we adopt one or theother. My preference goes to the JSON interface for the followingreasons:1. It is a strain on resources to try to develop both2. The JSON interface has potential usages outside of the Dynare inJulia project.3. It is relatively straithforward to implement the JSON interace in thepreprocessor with a few intuitive standard fields for the JSONs.4. The Julia implementation can then be done entirely in Julia.5. On the contrary, developing the option language=julia requires todevelop in parallel the preprorcessor and the Julia implementation ofDynare commands.
Note that the JSON format is already used outside Julia (in particular by code for the ECB-MC model).
I don’t see the Julia and JSON backends as interchangeable, and I’m therefore not sure that we should drop either. But Stéphane and Houtan can probably better comment on that, since they designed both backends.
You are right. language=julia (with in addition the output option) creates dynamic.jl and static.jl. My remark concerns indeed the <mod filename>.jl file. I believe it will be easier to develop Dynare in Julia if one uses the JSON file instead of the above file.
If we go that way, I will make sure that the code in dynare.jl works,but I will stop developing that git project and start afresh in a newgit project. I have created https://gitlab.com/dynare-julia as a groupof projects. I want to develop separate packages for the low levelcode that isn't Dynare specific. These packages must go is separategit projects under the dynare-julia umbrella.
If those packages are unrelated to Dynare, I’m afraid putting “dynare” in the name of the group will only confuse users.
On the other hand, if they are somewhat related to Dynare, I think they should rather be hosted on git.dynare.org (possibly in a new group there).
I will move these files to a different location without reference to the dynare name
Best,
Le mardi 24 mars 2020 à 18:39 +0100, Michel Juillard a écrit :
Sébastien Villemot writes:
If we go that way, I will make sure that the code in dynare.jlworks,but I will stop developing that git project and start afresh ina newgit project. I have created https://gitlab.com/dynare-julia as agroupof projects. I want to develop separate packages for the lowlevelcode that isn't Dynare specific. These packages must go isseparategit projects under the dynare-julia umbrella.
If those packages are unrelated to Dynare, I’m afraid putting “dynare”in the name of the group will only confuse users. On the other hand, if they are somewhat related to Dynare, I think theyshould rather be hosted on git.dynare.org (possibly in a new groupthere).
I will move these files to a different location without reference to thedynare name
Note that, even if those packages are not Dynare-specific, I still think it would make sense to host them on git.dynare.org, for several reasons: this makes us less dependent on 3rd-party infrastructure, this will facilitate contributions by other Dynare Team members, and it will give you more control over the CI runners. But of course this decision is up to you.
Hi Michel,
I am not sure I understand your point. Initially we developed the JSON output to play with Julia. We wanted to:
1. Avoid the cost of developping new outputs (JSON can be used from Python, Fortran, ...),
2. Do as much as possible with Julia except the parsing of the model (computing the derivatives in Julia and building the dynamic and static function from julia).
Our experience, is that building the dynamic and static routines from Julia was not a viable option (the preprocessor is much more efficient). Obviously this was two years ago... But even if, with a better undertsanding of Julia, or using other packages, or with Julia improvements, we could be as efficient in Julia as in the preprocessor I do not think that we want (can) make this job twice (in the preprocessor and in Julia)... So I think we should keep this part to the preprocessor. The same for the steady state file and other routines written by the preprocessor. I do not consider, because I think we do not have the ressources, the alternative of reimplementing the preprocessor in Julia.
Regarding the main (driver) file I tend to agree with you. I think it would be much simpler. Actually, I would go one step further and remove the Matlab output. We could also use the JSON output from matlab, the matlab driver function would then just read the content of the JSON file (JSON files would no more be optional). I think the first step is to agree on how we organise the data in this JSON file. And then we will see if it is feasible to also use this output in Dynare/Matlab.
Regarding where the development is done, I have no opinion. I would just like to know where I should look at... And where the Dynare/Julia has to be developed (I don't expect to do anything before August). As mentioned by Sébastien, the advantage of using git.dynare.org is that we would benefit from the gitlab-ci infrastructure. I suppose it's possible to do the same on a public instance of Gitlab, it's relatively simple if you do not have a dependance on matlab, but I do not see any advantage in replicating the maintenance cost. That said, I don't use it that much and often prefer to do the tests or builds on my server because it's usually much faster.
Best, Stéphane.
Michel Juillard writes:
Dear Friends,
I have been using recently both the option language=julia that I started using some time ago in https://github.com/MichelJuillard/dynare.jl and the JSON representation of the *.mod file.
I feel that it is the moment to decide wether we adopt one or the other. My preference goes to the JSON interface for the following reasons:
- It is a strain on resources to try to develop both
- The JSON interface has potential usages outside of the Dynare in
Julia project. 3. It is relatively straithforward to implement the JSON interace in the preprocessor with a few intuitive standard fields for the JSONs. 4. The Julia implementation can then be done entirely in Julia. 5. On the contrary, developing the option language=julia requires to develop in parallel the preprorcessor and the Julia implementation of Dynare commands.
If we go that way, I will make sure that the code in dynare.jl works, but I will stop developing that git project and start afresh in a new git project. I have created https://gitlab.com/dynare-julia as a group of projects. I want to develop separate packages for the low level code that isn't Dynare specific. These packages must go is separate git projects under the dynare-julia umbrella.
Please, tell me what you think.
All the best,
Hi Stephane,
my main point I guess was to agree to stop putting efforts in developing/maintaining in the preprocessor the writing of the driver file (currently written as <mod filename>.jl) and use the JSON file instead. I understand that we agree on that.
Best
Michel
Stéphane Adjemian writes:
Hi Michel,
I am not sure I understand your point. Initially we developed the JSON output to play with Julia. We wanted to:
Avoid the cost of developping new outputs (JSON can be used from Python, Fortran, ...),
Do as much as possible with Julia except the parsing of the model (computing the derivatives in Julia and building the dynamic and static function from julia).
Our experience, is that building the dynamic and static routines from Julia was not a viable option (the preprocessor is much more efficient). Obviously this was two years ago... But even if, with a better undertsanding of Julia, or using other packages, or with Julia improvements, we could be as efficient in Julia as in the preprocessor I do not think that we want (can) make this job twice (in the preprocessor and in Julia)... So I think we should keep this part to the preprocessor. The same for the steady state file and other routines written by the preprocessor. I do not consider, because I think we do not have the ressources, the alternative of reimplementing the preprocessor in Julia.
Regarding the main (driver) file I tend to agree with you. I think it would be much simpler. Actually, I would go one step further and remove the Matlab output. We could also use the JSON output from matlab, the matlab driver function would then just read the content of the JSON file (JSON files would no more be optional). I think the first step is to agree on how we organise the data in this JSON file. And then we will see if it is feasible to also use this output in Dynare/Matlab.
Regarding where the development is done, I have no opinion. I would just like to know where I should look at... And where the Dynare/Julia has to be developed (I don't expect to do anything before August). As mentioned by Sébastien, the advantage of using git.dynare.org is that we would benefit from the gitlab-ci infrastructure. I suppose it's possible to do the same on a public instance of Gitlab, it's relatively simple if you do not have a dependance on matlab, but I do not see any advantage in replicating the maintenance cost. That said, I don't use it that much and often prefer to do the tests or builds on my server because it's usually much faster.
Best, Stéphane.
Michel Juillard writes:
Dear Friends,
I have been using recently both the option language=julia that I started using some time ago in https://github.com/MichelJuillard/dynare.jl and the JSON representation of the *.mod file.
I feel that it is the moment to decide wether we adopt one or the other. My preference goes to the JSON interface for the following reasons:
- It is a strain on resources to try to develop both
- The JSON interface has potential usages outside of the Dynare in
Julia project. 3. It is relatively straithforward to implement the JSON interace in the preprocessor with a few intuitive standard fields for the JSONs. 4. The Julia implementation can then be done entirely in Julia. 5. On the contrary, developing the option language=julia requires to develop in parallel the preprorcessor and the Julia implementation of Dynare commands.
If we go that way, I will make sure that the code in dynare.jl works, but I will stop developing that git project and start afresh in a new git project. I have created https://gitlab.com/dynare-julia as a group of projects. I want to develop separate packages for the low level code that isn't Dynare specific. These packages must go is separate git projects under the dynare-julia umbrella.
Please, tell me what you think.
All the best,
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
-
Michel Juillard -
Stéphane Adjemian -
Sébastien Villemot