"Johannes Pfeifer " jpfeifer@gmx.de writes:
I am not sure I understand what you are saying. Currently the preprocessor warns if parameters were not initialized. I conclude from this that we try to evaluate them and print a warning if they have not been initialized properly. My idea now was to try to evaluate the expressions in a similar way after we checked the parameter values and print a warning if this is not possible of the type:
Warning: Some of the expressions defined (psi) evaluated to NaN. Dynare may not be able to solve the model unless the parameters defining the expression are properly defined.
Because as far as I understand it, expressions can only depend on parameters and we already check if parameters are properly initialized.
Of course this is not a general solution as the preprocessor only runs once in the beginning. I am aware that expression can be altered in simulation or estimation as they depend on parameters that can change. But from what I have seen in user feedback, the issue we should try to filter out only occurs in the first run of check or stoch_simul where no changes to the expressions have been made. It is this step where most users fail. Estimation for example automatically catches cases where the likelihood cannot be computed. In contrast, check crashes with a cryptic message. Due to the problem mostly occurring at initialization, I am not sure we should aim for a general check or filter in the dynamic or static-files.
If you signal that it is not feasible to let the preprocessor initially check if the parameter and model declaration are sufficient to actually compute the expression, I will open a ticket.
I think that what you suggest is feasible, but it has a higher performance cost than the check for the parameters.
The reason is the following: we check for the parameters being NaN *outside* the _dynamic.m file; but that cannot be done for pound expressions, because they do not exist outside of the _dynamic.m file. Therefore the check for pound expressions would have to be implemented within the _dynamic.m file, and this has an obvious performance cost, though it may not be that high, we need to check. We can think about adding a flag to disable it, but this adds an extra argument to the _dynamic function, and I am not sure it is worth it.
If you think this feature is worthwile, please open a ticket, and we'll discuss there about its feasibility and implementation.
-----Ursprüngliche Nachricht----- Von: dev-bounces@dynare.org [mailto:dev-bounces@dynare.org] Im Auftrag von Sébastien Villemot Gesendet: Dienstag, 31. Juli 2012 12:26 An: List for Dynare developers Betreff: Re: [DynareDev] # operator
"Johannes Pfeifer " jpfeifer@gmx.de writes:
My question could be rephrased: in the preprocessor, do we only do text editing and write SIGMABAR__ = 1/(1-params(2)*params(6)); psi__ = (params(2)*(1-params(2))*params(6)^2/(params(2)*(params(2)*params(6)*S IGMABAR__)^2-(1-SIGMABAR__)^2))^0.5;
Or could we use the preprocessor mathematics routines to initially evaluate the said expressions (given that we already know params and check their validity)
The problem is that we don't always know the param values: in estimation they can be altered, and even in simulation they can be altered in a loop. So currently the preprocessor precomputes only expressions containing numerical constants, but not paramaters or other types of variables.
If this is not possible, we should make it optional in a way that does not affect performance. E.g. it could only be executed when using check. This would catch most of the problems.
I suggest that you open a ticket about this issue.
-----Ursprüngliche Nachricht----- Von: dev-bounces@dynare.org [mailto:dev-bounces@dynare.org] Im Auftrag von Sébastien Villemot Gesendet: Montag, 30. Juli 2012 15:45 An: List for Dynare developers Betreff: Re: [DynareDev] # operator
"Johannes Pfeifer " jpfeifer@gmx.de writes:
My idea was implementing a warning like the one for NaN parameters that is displayed after the preprocessor runs. Expressions are something like a shortcut for a parameter not explicitly defined. Hence, it would be helpful to say:
Warning: Some of the expressions defined (psi) evaluated to NaN. Dynare may not be able to solve the model...
The problem with this approach is that the warnings have to be emitted From the _static.m or _dynamic.m file. This means that the check has to be executed at every run of any of these file, and this can have a performance cost.
Maybe do you have something else in mind? Or we could make these checks optional, and not activated by default?
Currently it is very hard to debug the expressions defined by the pound operator, because they are substituted out and you cannot see to what they evaluated. Due to them being substituted out, complex expressions also do not necessarily get translated to NaN. In the specific example ppp.mod from the forum the expressions get written to the ppp_static.m file in the following way:
SIGMABAR__ = 1/(1-params(2)*params(6)); psi__ = (params(2)*(1-params(2))*params(6)^2/(params(2)*(params(2)*params(6)* S IGMABAR__)^2-(1-SIGMABAR__)^2))^0.5;
Hence, Matlab take the root of a negative number and evaluates psi__ to a complex number. Again the problem is that the preprocessor does not check whether expressions like SIGMABAR__ or psi__ evaluate to anything sensible at the start but rather substitutes them into Matlab code without evaluating them.
-----Ursprüngliche Nachricht----- Von: dev-bounces@dynare.org [mailto:dev-bounces@dynare.org] Im Auftrag von Sébastien Villemot Gesendet: Freitag, 6. Juli 2012 10:14 An: List for Dynare developers Betreff: Re: [DynareDev] # operator
"Johannes Pfeifer " jpfeifer@gmx.de writes:
as shown by the mod-file in http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3870, we don’t check whether expressions defined with the pound operator are complex or not. This may lead to cryptic error messages.
What do you think about adding such a check to the preprocessor. In this regard, checking for NaN might also be a good idea.
Actually complex expressions gets translated to NaN (since the preprocessor only knows real numbers). But we want to allow for NaN in some contexts. So it is not obvious how to deal with that.
-- Sébastien Villemot Researcher in Economics & Debian Maintainer http://www.dynare.org/sebastien Phone: +33-1-40-77-84-04 - GPG Key: 4096R/381A7594
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
-- Sébastien Villemot Researcher in Economics http://www.dynare.org/sebastien Phone: +33-1-40-77-84-04
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
-- Sébastien Villemot Researcher in Economics http://www.dynare.org/sebastien Phone: +33-1-40-77-84-04
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev