Le jeudi 02 mai 2013 à 15:19 +0200, Michel Juillard a écrit :

When we use a Newton type numerical optimizer to find the mode of the posterior or of the likelihood or when we are searching for optimal parameters in OSR, using stiff penalties creates "cliffs" that the optimizer has difficulties to overcome.

To alleviate the problem, we have tried, whenever possible, to compute penalties commensurate with the violation (sum of square residuals when one can't find the steady state, norm of eigenvalues on the "wrong" side of one for BK violations, ...). These endogenous penalties have been put in info(2). Of course, it is not always possible to compute a commensurate penalty and we still have a few cliffs.

However, we have also used info(2), in a few cases (info(1)==8) to provide additional details about the nature of the error.

I think that we should refrain from using info(2) that way and probably change the handling of the cases that do that, because it leads to confusions. But, I would like to have your advice on that.

It may be the occasion of having a more general discussion on the handling of errors in Dynare. If I remember correclty, some of you would prefer using exceptions. We could also decide that we want to redesign the handling of errors in Dynare.

My personal opinion is that the "info" design is a very poor design, and essentially a legacy coming from languages (like Fortran) where exceptions don’t exist. The ideal design would be to throw exceptions (instead of using "info") and, depending on the exception type, possibly have an extra field containing the penalty (or other information).

Unfortunately, the MATLAB/Octave exception system is rather poor, because you cannot add such an extra field of information: you can only have a unique identifier for the exception type, and a user-friendly text message.

So it seems inevitable that in cases where we want to return extra information (like the penalty), we have to use an info-like structure (i.e. a boolean field saying if there is an error, and then a second field containing the penalty).

But most use cases of "info" look like a very poor design to me. In particular, the whole print_info.m thing should probably be removed. Most info values should in my opinion be replaced by normal MATLAB/Octave errors with a specific identifier and an associated text messages. When it is necessary, these errors can be caught with try/catch blocks; and when we want them to go back to the user, then there is nothing to do, since without a try/catch block they interrupt the computation and are sent back to the user.