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