I have many LaTeX files that includes a common .tex file which has the preamble code.

In this include file I added, at the end, this


and then run make to build the whole tree. I see now new errors showing in files which compiled ok before.

One example was this question

Another example is below. The LaTeX code is auto-generated by SWP.

%\usepackage{breqn}  %uncomment this to see the error
\left(  X\circledast Y\right)  \circledast W={\displaystyle\sum\limits_{l=-\infty}^{\infty}}\left(  \overset{\left(  X\circledast Y\right)  \left(  l\right)}{\overbrace{{\displaystyle\sum\limits_{k=-\infty}^{\infty}}X\left(  k\right)  Y\left(  l-k\right)  }}\right)  W\left(  n-l\right)

enter image description here

uncommenting \usepackage{breqn} in the above, gives the error

>pdflatex foo.tex 
This is pdfTeX, Version 3.1415926-2.4-1.40.13 (TeX Live 2012/Debian)
 restricted \write18 enabled.

! Limit controls must follow a math operator.
<argument> {\displaystyle \sum \limits 
                                       _{k=-\infty }^{\infty }}X\left ( k\ri...
l.8 ...}X\left(  k\right)  Y\left(  l-k\right)  }}
                                                  \right)  W\left(  n-l\right)

I'd like to just understand what is going to help in managing this. I see the error message above, but if the LaTeX code was invalid, then how could it have compiled OK before adding breqn? Why is adding breqn causes some compile errors in some places that did not exist before?

Using TexLive 2012 debian original package. No changes/addition to it made on my Linux box.

  • 3
    breqn changes many things; mixing amsmath environments with breqn ones is not recommendable. Take or leave. I leave.
    – egreg
    Jun 15 '13 at 19:54
  • @egreg You mean one can't use \[ ... \] if they include the breqn package? I am trying to understand what you mean by mixing. I am newbie in Latex. thanks.
    – Nasser
    Jun 15 '13 at 19:57
  • 1
    If you use breqn, then do what the package wants. No \[...\], align, gather and so on. No \limits either. I find the deficiences of breqn much superior to its benefits, but it's just my opinion.
    – egreg
    Jun 15 '13 at 20:03

The breqn package changes the definition of \sum (and of almost all other commands for math mode). The definition it uses is (using the output of \show)

> \sum=\protected\long macro:
->\@sym \sum \math_sym_COs:Nn \mg@cop {50}.

The macro \@sym is the same as \@gobble, at least between \[ and \], so the first two tokens disappear. Now TeX finds \math_sym_COs:Nn

> \math_sym_COs:Nn=\long macro:
->\math_bsym_COs:Nn .

Uhm. Let's see \math_bsym_COs:Nn

> \math_bsym_COs:Nn=\long macro:
#1#2->\math_char:NNn 1#1{#2}\sumlimits .

So the tokens \mg@cop and {50} are the second and third arguments to \math_char:NNn

> \math_char:NNn=\protected\long macro:
#1#2#3->\tex_mathchar:D \__int_eval:w "#1#2#3\__int_eval_end: .

This simply produces


because \mg@cop expands to 3 (the number of the math extension font family). So the symbol is produced, but there's \sumlimits after it

> \sumlimits=\displaylimits.

Wait! This means that \sum\limits should be legal!

Indeed it is. But in some situations \@sym is not equivalent to \@gobble (and this is the reason why it's there). When the second argument to \overset is being processed, \@sym becomes equivalent to \binrel@sym

    \ifx\math_sym_Ord:Nn #2 \math_csym_Ord:Nn
    \else\ifx\math_sym_Var:Nn#2 \math_csym_Var:Nn
    \else\ifx\math_sym_COs:Nn#2 \math_csym_COs:Nn
    \else\ifx\math_sym_COi:Nn#2 \math_csym_COi:Nn
    \else\ifx\math_sym_Bin:Nn#2 \math_csym_Bin:Nn
    \else\ifx\math_sym_Rel:Nn#2 \math_csym_Rel:Nn
    \else\ifx\math_sym_Pun:Nn#2 \math_csym_Pun:Nn
    \else\exp_not:N\@symErr \fi\fi\fi\fi\fi\fi\fi

This is the cause of the error: \limits comes after nothing, because one of the workings of \overset is to examine its second argument in order to apply the correct spacing around the whole construction. Here breqn (more precisely flexisym.sty) tries to be clever and does a different test than amsmath. The failure is here: when \@sym is redefined, it absorbs four arguments using only the second one (\sum itself). And \limits remains alone in the input stream.

A minimal example showing the failure is

\usepackage{breqn}  %uncomment this to see the error

The (wrong) assumption made by flexisym is that the second argument of \overset contains a single token.

  • If you want to defy breqn's cleverness, use good old \stackrel, with a surrounding pair of braces.
    – egreg
    May 16 '16 at 8:57

To put stuff above an \overbrace simply use the construction \overbrace{-bottom-}^{-top-}, which works fine with breqn.

Your construction \overset{-top-}{\overbrace{-bottom-}} is an abuse of \overset, which as far as I can tell is meant for stacking single symbols or relations. Here you pile a whole formula atop another. One way around the error which egreg details is to save the primitive \let\orig@limits\limits and redefine \def\limits{\ifx\@sym\binrel@sym\else \orig@limits \fi}, so as to only call the primitive when in a normal mode. Alas! there is still a second error Limit controls must follow a math operator. And nothing can save us so easily, because this time \sum is really not typeset as an operator. Why? Well, breqn tries to find out what symbols you are trying to pile with \overset. It turns out that the last atom in the math list for the bottom is an ordinary symbol, so breqn considers the whole bottom stuff as a single ordinary symbol: everything in there is treated like ordinary symbols (\mathord). In particular the \sum becomes \mathord{\sum}, and that does not accept \limits controls.

Document that works:

\left(  X\circledast Y\right)  \circledast W
\sum\limits_{l=-\infty}^{\infty}} \left(
  \left(  k\right)  Y\left(  l-k\right)
  \left(  X\circledast Y\right)
  \left(  l\right)}
W\left(  n-l\right)

There are problems with breqn but this ain't one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.