latex variable with exponent causes compilation error

NB: {B_{t-1}}^{\rho} will not produce the ideal output (ie, just placing braces around a variable containing a lead/lag is more correct than the quick fix but not precisely the complete fix as described above)

Remaining to be done: search the tex name (provided by getTeXName(symb_id) for an underscore. We don't need to search for power because 17c1f528 already adds braces around the expression potentially containing the subscripted lag and a power and a lag are ok in tex. We have to search for the underscore because we add an underscore if the variable has a lag. Need to do a regex match for variables of the type:

C_a
C_\star
{C_a}_\star
{C_a}_{C_bc}
{{{C_a}_{C_bc}}_{abc}}

If an underscore is found that is not already contained in braces, we must put braces around the entire tex name.

We always add an underscore because even current variables have a 't' subscript in the Latex rendering

yes, you are right. I misspoke. But the change is the same.

@houtanb Does this also solve the issue with model-local variables? I have one defined as #log_R_bar=log(Pi_bar/betta); As far as I know, there is no way to manually specify a TeX-name for model local variables, but the name is literally put into the TeX-file, resulting in multiple subscripts.

@JohannesPfeifer no, yours is a separate issue which would require a new syntax

@houtanb I am not saying we need a way to specify TeX names for model-local variables. I just want the underscore be replaced by \_ for them.

@JohannesPfeifer this would still be a separate issue

@houtanb Ok. I opened a new issue.

@houtanb What exactly does https://github.com/DynareTeam/dynare/commit/17c1f5286804e1e0f53339b3bce51df802d0b977 entail? Because gy_obs $\Delta y_{obs}$ translates in write_latex_dynamic_model to {\Delta y_{obs}_{t}} while gp_obs ${\Delta m_{obs}}$ translates to {{\Delta m_{obs}}_{t}}. Only the latter with manually set brackets assures that you cannot have double subscripts. It seems that commit puts the brackets around expression after adding a t index

@JohannesPfeifer yes, this was the intention of the commit. See the problem from the forum referenced in the first comment

@houtanb I see. So the double subscript problem still remains. For that we need to check for underscores that are not prefaced by a slash, i.e. '(?<![\])[_]' in regex and need to find out whether all these underscores are contained in at least one curly bracket. If not, we need to add the brackets.

@JohannesPfeifer correct. This was the point of my comment above: https://github.com/DynareTeam/dynare/issues/263#issuecomment-138498467

@houtanb I see. I guess the Matlab code for this would be

underscore_indices=regexp(latex_string,'(?<![\])[_]');
underscore_iter=1;
add_brackets=0;
while underscore_iter<=length(underscore_indices) && ~add_brackets
    opening_brackets_indices_before=regexp(latex_string(1,1:underscore_indices(underscore_iter)),'(?<![\])[{]');
    closing_brackets_indices_before=regexp(latex_string(1,1:underscore_indices(underscore_iter)),'(?<![\])[}]');
    if (length(opening_brackets_indices_before)-length(closing_brackets_indices_before))==0
        add_brackets=1;
    end
    underscore_iter=underscore_iter+1;
end

That is: whenever we have as many opening as closing brackets (without text brackets like \{ ) before an underscore, we know that the underscore is not within brackets, so we must set them.

@JohannesPfeifer as I understand it, your algorithm would change:

{C_a}_{C_bc}
{{{C_a}_{C_bc}}_{abc}}

to

{{C_a}\_{C_bc}}
{{{C_a}_{C_bc}}_{abc}}

Neither of which compiles. This may have been why we abandoned this, leaving it to the user to correctly set subscripts.

@houtanb The first one should become {{C_a}_{C_bc}}, i.e. no slash should be introduced. Also, I don't see why this should not compile.

The second one is not supposed to compile. It is the user's duty to make sure that the LaTeX expression provided is a valid one. If the user provides an invalid expression that already has double subscripts as in the example,, we cannot fix this. We should only make sure that if there already is a proper subscript, we don't break compilation by adding another subscript

NB: {{C_a}_{C_bc}} does not compile.

@houtanb But why? What is the error message? Is this maybe a TeX-compilation issue? Because I don't see any faulty syntax and it works with MikTeX (of course you need to be in math mode, otherwise you cannot have an underscore that is not prefaced by a slash). There are as many opening as closing brackets and no double subscripts.

@JohannesPfeifer sorry, yes it works. And the second one compiles too.

@houtanb Is this TeX issue fixed?

latex variable with exponent causes compilation error

Designs

Child items ...

Activity