... | ... | @@ -32,23 +32,19 @@ Either |
|
|
Once these new enums are in place, they should be handled throughout the expression writing engine, in particular:
|
|
|
- within the helpers `isSteadyStateOperatorOutput()`, `isSparseModelOutput()` (should always return `true` for Python), `ARRAY_SUBSCRIPT_OFFSET()` (array indexing is 0-based in Python); a new `isPythonOutput()` helper should also be created; NB: `LEFT_ARRAY_SUBSCRIPT()` and `RIGHT_ARRAY_SUBSCRIPT()` need no adjustment since Python uses brackets for array-indexing;
|
|
|
- in the `writeOutput()` methods of the various classes, so as to write use the correct objects and mathematical function names for the Python context
|
|
|
- maybe also adapt the `cost()` methods
|
|
|
- maybe also adapt the `cost()` methods (note that they currently don’t treat Julia separately, which is thus treated as MATLAB/Octave)
|
|
|
|
|
|
|
|
|
- Adapt the Julia specific code for Python in
|
|
|
* `ModelTree.hh`
|
|
|
* `DynamicModel.cc` and `DynamicModel.hh`
|
|
|
* `StaticModel.cc` and `StaticModel.hh`
|
|
|
* `ModelEquationBlock.cc` and `ModelEquationsBlock.hh`
|
|
|
* the main differences between Python code and Julia code relevant here are
|
|
|
- Finally, top-level methods for writing Python files should be implemented
|
|
|
- Methods for generating the different files should be implemented in the `ModelTree`, `StaticModel`, `DynamicModel` and `SteadyStateModel` classes (the latter class is in the `ModelEquationBlock.{cc,hh}` source files)
|
|
|
- A possibility is to take inspiration from the Julia methods. Ideally, things should be factorized as much as possible with other existing methods, possibly using template functions. Note that the main differences between Python code and Julia code relevant here are:
|
|
|
- `def` instead of `function`
|
|
|
- array indexing starts with 0 instead of 1
|
|
|
- array indexing starts with 0 instead of 1 (already handled by the `ARRAY_SUBSCRIPT_OFFSET()` helper)
|
|
|
- Python functions don't terminate with `end`
|
|
|
- maybe it is possible to generalize the existing code for Julia
|
|
|
* in `ModelTree.hh` creates `dynamic_set_auxiliary_series()` that manipulates time series with `lag` and `lead` functions. We need to choose a time series representation in Python.
|
|
|
- In particular, note that `ModelTree.hh` creates `dynamic_set_auxiliary_series()` that manipulates time series with `lag` and `lead` functions. We need to choose a time series representation in Python (in relation with the `ExprNodeOutputType` enum discussion above)
|
|
|
- Finally, a new top-level method `ModFile::writePythonOutput()` should be created. It should generate all the `*.py` files, and be called from the `main()` function in `DynareMain.cc` (similarly to what is done for MATLAB/Octave and Julia).
|
|
|
|
|
|
#### calling the bytecode library generated by the preprocessor
|
|
|
- the code for `bytecode` `mex` file needs to separated between a `mex` wrapper and a standard `C` library
|
|
|
#### calling the bytecode representation generated by the preprocessor
|
|
|
- the code for `bytecode` MEX file needs to separated between a MEX wrapper and a standard `C` library
|
|
|
|
|
|
### Parse the JSON file `<modfilename>/model/json/modfile.json`
|
|
|
- This file contains `statementName` keys that describe computing tasks requested by the user
|
... | ... | |