Hello all, I have rewritten the macro processor from scratch on the `macroprocessor-rewrite` branch. This rewrite was necessary because we wanted to: 1) support user-defined functions; 2) support tuples, comprehensions, and arrays of arrays (changes that made the code harder to understand and maintain). NB: as Marco found during the summer school, the creation of arrays of arrays introduced a breaking change: in Dynare 4.5 `[1:3]` resulted in `[1,2,3]` whereas in 4.6 `[1:3]` results in `[[1,2,3]]`, that is to say an array of an array instead of just an array. The rewriting of the macro processor allows us to easily add more types and other functionalities. Accordingly, I have added a boolean type and would like to add a double type, which brings me to the point of this email. Adding a double type introduces another potential breaking change and we did not want to make this change without consulting you. Currently, as the macro processor only supports integers, integer division produces an integer. Hence, as with many typed programming languages, `@{1/2}` is replaced by `0`. The introduction of doubles in the macro language allows us to question if we want to maintain this functionality, or if we would prefer to have `@{1/2}` replaced by `0.5`. Note that to achieve the previous functionality, the user could write `@{floor(1/2)}`, as we plan to support all C++ math functions that are currently supported in the Dynare language. Further note that if we decide to keep the current functionality where `@{1/2}` is replaced by `0`, then to achieve a double result the user would have to type `@{1.0/2}`. Hence, the question we wanted to ask you is what should the action of the new macro processor be when it encounters integer division: 1) Integer output, i.e. `@{1/2}` -> `0`; 2) Double output, i.e. `@{1/2}` -> `0.5`? Best, Houtan
The Macro processor is going to be used by people who are used to Matlab so @(1/2) should return 0.5 I have a hard time imagining a case where I would want @(1/2) to return 0 and then @(floor(1/2)) is more explicit anyway. Best Michel Houtan Bastani writes:
Hello all,
I have rewritten the macro processor from scratch on the `macroprocessor-rewrite` branch.
This rewrite was necessary because we wanted to: 1) support user-defined functions; 2) support tuples, comprehensions, and arrays of arrays (changes that made the code harder to understand and maintain).
NB: as Marco found during the summer school, the creation of arrays of arrays introduced a breaking change: in Dynare 4.5 `[1:3]` resulted in `[1,2,3]` whereas in 4.6 `[1:3]` results in `[[1,2,3]]`, that is to say an array of an array instead of just an array.
The rewriting of the macro processor allows us to easily add more types and other functionalities. Accordingly, I have added a boolean type and would like to add a double type, which brings me to the point of this email.
Adding a double type introduces another potential breaking change and we did not want to make this change without consulting you.
Currently, as the macro processor only supports integers, integer division produces an integer. Hence, as with many typed programming languages, `@{1/2}` is replaced by `0`. The introduction of doubles in the macro language allows us to question if we want to maintain this functionality, or if we would prefer to have `@{1/2}` replaced by `0.5`.
Note that to achieve the previous functionality, the user could write `@{floor(1/2)}`, as we plan to support all C++ math functions that are currently supported in the Dynare language.
Further note that if we decide to keep the current functionality where `@{1/2}` is replaced by `0`, then to achieve a double result the user would have to type `@{1.0/2}`.
Hence, the question we wanted to ask you is what should the action of the new macro processor be when it encounters integer division: 1) Integer output, i.e. `@{1/2}` -> `0`; 2) Double output, i.e. `@{1/2}` -> `0.5`?
Best, Houtan _______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
-- Michel Juillard
I agree. In the past, implicit rounding in users' mod-files always introduced confusion due to type-casting -----Ursprüngliche Nachricht----- Von: Dev [mailto:dev-bounces@dynare.org] Im Auftrag von Michel Juillard Gesendet: Freitag, 14. Juni 2019 17:03 An: List for Dynare developers <dev@dynare.org> Betreff: Re: [DynareDev] macro processor changes and a question The Macro processor is going to be used by people who are used to Matlab so @(1/2) should return 0.5 I have a hard time imagining a case where I would want @(1/2) to return 0 and then @(floor(1/2)) is more explicit anyway. Best Michel Houtan Bastani writes:
Hello all,
I have rewritten the macro processor from scratch on the `macroprocessor-rewrite` branch.
This rewrite was necessary because we wanted to: 1) support user-defined functions; 2) support tuples, comprehensions, and arrays of arrays (changes that made the code harder to understand and maintain).
NB: as Marco found during the summer school, the creation of arrays of arrays introduced a breaking change: in Dynare 4.5 `[1:3]` resulted in `[1,2,3]` whereas in 4.6 `[1:3]` results in `[[1,2,3]]`, that is to say an array of an array instead of just an array.
The rewriting of the macro processor allows us to easily add more types and other functionalities. Accordingly, I have added a boolean type and would like to add a double type, which brings me to the point of this email.
Adding a double type introduces another potential breaking change and we did not want to make this change without consulting you.
Currently, as the macro processor only supports integers, integer division produces an integer. Hence, as with many typed programming languages, `@{1/2}` is replaced by `0`. The introduction of doubles in the macro language allows us to question if we want to maintain this functionality, or if we would prefer to have `@{1/2}` replaced by `0.5`.
Note that to achieve the previous functionality, the user could write `@{floor(1/2)}`, as we plan to support all C++ math functions that are currently supported in the Dynare language.
Further note that if we decide to keep the current functionality where `@{1/2}` is replaced by `0`, then to achieve a double result the user would have to type `@{1.0/2}`.
Hence, the question we wanted to ask you is what should the action of the new macro processor be when it encounters integer division: 1) Integer output, i.e. `@{1/2}` -> `0`; 2) Double output, i.e. `@{1/2}` -> `0.5`?
Best, Houtan _______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
-- Michel Juillard _______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
also agree. rounding always made lots of problems for me! --- Marco Ratto, Finance and Economy Joint Research Centre European Commission, TP 640, 21027 ISPRA(VA), ITALY Tel: +39 0332 78 3794 marco.ratto@ec.europa.eu ________________________________________ From: Dev <dev-bounces@dynare.org> on behalf of Johannes Pfeifer <jpfeifer@gmx.de> Sent: 14 June 2019 17:27 To: 'List for Dynare developers' Subject: Re: [DynareDev] macro processor changes and a question I agree. In the past, implicit rounding in users' mod-files always introduced confusion due to type-casting -----Ursprüngliche Nachricht----- Von: Dev [mailto:dev-bounces@dynare.org] Im Auftrag von Michel Juillard Gesendet: Freitag, 14. Juni 2019 17:03 An: List for Dynare developers <dev@dynare.org> Betreff: Re: [DynareDev] macro processor changes and a question The Macro processor is going to be used by people who are used to Matlab so @(1/2) should return 0.5 I have a hard time imagining a case where I would want @(1/2) to return 0 and then @(floor(1/2)) is more explicit anyway. Best Michel Houtan Bastani writes:
Hello all,
I have rewritten the macro processor from scratch on the `macroprocessor-rewrite` branch.
This rewrite was necessary because we wanted to: 1) support user-defined functions; 2) support tuples, comprehensions, and arrays of arrays (changes that made the code harder to understand and maintain).
NB: as Marco found during the summer school, the creation of arrays of arrays introduced a breaking change: in Dynare 4.5 `[1:3]` resulted in `[1,2,3]` whereas in 4.6 `[1:3]` results in `[[1,2,3]]`, that is to say an array of an array instead of just an array.
The rewriting of the macro processor allows us to easily add more types and other functionalities. Accordingly, I have added a boolean type and would like to add a double type, which brings me to the point of this email.
Adding a double type introduces another potential breaking change and we did not want to make this change without consulting you.
Currently, as the macro processor only supports integers, integer division produces an integer. Hence, as with many typed programming languages, `@{1/2}` is replaced by `0`. The introduction of doubles in the macro language allows us to question if we want to maintain this functionality, or if we would prefer to have `@{1/2}` replaced by `0.5`.
Note that to achieve the previous functionality, the user could write `@{floor(1/2)}`, as we plan to support all C++ math functions that are currently supported in the Dynare language.
Further note that if we decide to keep the current functionality where `@{1/2}` is replaced by `0`, then to achieve a double result the user would have to type `@{1.0/2}`.
Hence, the question we wanted to ask you is what should the action of the new macro processor be when it encounters integer division: 1) Integer output, i.e. `@{1/2}` -> `0`; 2) Double output, i.e. `@{1/2}` -> `0.5`?
Best, Houtan _______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
-- Michel Juillard _______________________________________________ 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
participants (4)
-
Houtan Bastani -
Johannes Pfeifer -
Marco.RATTO＠ec.europa.eu -
Michel Juillard