Allow for expressions in _calibration-blocks

In statements like

irf_calibration(relative_irf);
y(1:4), e_ys, [0 10]; //[first year response, logical OR]
end;

we only allow for numbers. We should also allow e.g.

irf_calibration(relative_irf);
y(1:4), e_ys, [0 UB_1]; //[first year response, logical OR]
end;

where UB_1 is an interpretable expression like a parameter or a list element.

assigned to @houtanb

@JohannesPfeifer what do you mean by list element?

@JohannesPfeifer should a similar change be made for moment_calibration?

@houtanb I don't recall what I meant with "list element". Simply ignore it. And yes, the same should apply to moment_calibration

@JohannesPfeifer this is more complicated than initially thought. What is easy is to allow an expression for the upper bound. Unfortunately, allowing an expression in the lower bound is complicated for several reasons:

1. Parsing '[' expression expression ']' is not possible given the current state of the parser as it won't know how to parse something like 1 + 1; this could be parsed as one expression (1+1) or two (1 and 1). Matlab parses [1 + 1] as [2] while it parses [1 +1] as [1 1] and 1 +1 as 2. In short, how spaces are treated changes by context. Thus far we don't do that.
2. Having two rules for the upper/lower bound supporting separation by space or by a comma such as:

   '[' signed_number_w_inf signed_number_w_inf ']'
   '[' expression COMMA expression ']'

   poses a problem for the parser as it doesn't know whether to parse something like -3 as a signed_number_w_inf or as an expression. NB this would be a solution if we dropped support for specifying the lower/upper bound with spaces instead of commas, dropping backward compatibility.

So the question is:

1. Can we drop the syntax with a space between the upper/lower bound (I suppose not)
2. If not, should we introduce another syntax to hold the upper/lower bound? e.g. '<' expression COMMA expression '>'
3. Another simple thing to do would be to allow a simple symbol, as in your example '[' symbol symbol ']'

@houtanb I am agnostic here and could also live without the additional feature. I would forward the question to @rattoma @rattoma is pretty much the only user I have seen to use this feature. He could tell us whether he i) deems it sufficiently useful to worry about this and ii) whether breaking backward compatibility would be an issue. If we introduce breaking changes in 4.6, we could do this here as well-

Dear @houtanb @JohannesPfeifer, I think i) the issue is sufficiently useful to worry about; ii) the simple symbol compromise might be the solution, but I would have a question:

could the symbol be possibly also an element of an array, like

[lb(j) ub(j)]

or this would already configure as an expression, so calling for a new syntax?

then, using < > would be OK for me. Yet another breaking change in 4.6, not too difficult to adapt for.

thanks!

@rattoma just to be clear, using < > would not break the former syntax. However, as you have indicated it is not a problem to break the former syntax, what I propose is to drop the syntax with a space between the upper/lower bound. Thus,

[lb(j), ub(j)]
[-50, 50]

would work but

[lb(j) ub(j)]
[-50 50]

would be an error. Is this OK?

@houtanb even better. I am fine with this

sure.

mentioned in issue dynare#1656 (closed)

closed via commit 1fcd3050