# Error with ifacconf.cls and subequations with more than twelve equations

I'm working on a paper for an IFAC conference for which you're supposed to use their ifacconf.cls, resulting in a fairly standard layout. However, you get an error when you use subequations (amsmath) with twelve or more equations (L is the twelfth letter). It turns out that the class file redefines the \alph output, so that \alph{12} returns \ell instead of l:

\def\@alph#1{\ifcase#1\or a\or b\or c\or d\or e\or f\or g\or h\or i\or j\or % line  1402
k\or \ell\or m\or n\or o\or p\or q\or r\or s\or t\or u\or v\or w\or x\or


[...]

et\or eu\or ew\or ex\or ey\or ez\else\@ctrerr\fi} % line 1414


I guess the motivation for this is to avoid confusion from the similarity of lowercase l, uppercase i, and the number 1. However, they can't have tested this very thoroughly, since \ell is a math-mode command; it's not very surprising this throws an error when used in an equation tag. Before taking the time to find the reason for this error I came up with a few workarounds. One obvious fix is of course to replace \ell with \ensuremath{ell} or simply l in the class file, but this will not get you very far if you collaborate with people who don't know how (or don't have the necessary admin rights) to modify the class file. How is this issue best solved? I'm answering my own "question" here (I figure one possible fix per answer is the best way to go --- please correct me if I'm wrong), but would be very interested if anyone has better suggestions.

Here's an MWE that throws the error:

\documentclass{ifacconf}
\usepackage{amsmath}
\usepackage{natbib} % required by ifacconf.cls?

\begin{document}

\begin{subequations}
\begin{gather}
a = 1  \\
b = 2  \\
c = 3  \\
d = 4  \\
e = 5  \\
f = 6  \\
g = 7  \\
h = 8  \\
i = 9  \\
j = 10 \\
k = 11
\\l = 12  % comment out this line to compile successfully
\end{gather}
\end{subequations}

\end{document}

• Is it necessary to provide two self-answers???? – user31729 Dec 29 '15 at 16:43
• @ChristianHupfer Not at all necessary, I just figured that would be tidier. I'd happily merge them if that's considered better. – tanh Dec 29 '15 at 16:47

\protected\edef\ell{\noexpand\ensuremath{{\mathchar\the\ell}}}


and you'll get \alph in the style they like (and no error when you go up to 12 items).

Full example:

\documentclass{ifacconf}
\usepackage{amsmath}
\usepackage{natbib}

\protected\edef\ell{\noexpand\ensuremath{{\mathchar\the\ell}}}

\begin{document}

\begin{subequations}
\begin{gather}
a = 1  \\
b = 2  \\
c = 3  \\
d = 4  \\
e = 5  \\
f = 6  \\
g = 7  \\
h = 8  \\
i = 9  \\
j = 10 \\
k = 11 \\
l = 12
\end{gather}
\end{subequations}

\end{document}


What are we doing? We have to fix the wrong redefinition of \@alph made by the class, which uses \ell in text mode, whereas it is legal only in math mode. One could simply take the code in the class and change \ell into $\ell$ throughout. But we can do it in a slicker way, changing the definition of \ell, instead.

So we need some care: first we must preserve the meaning of \ell somewhere else; second, we want that typing \ell in math mode will do the right thing; third, we have to ensure the redefinition will survive full expansion. A possible redefinition could be

\let\latexell\ell
\renewcommand{\ell}{\ensuremath{\latexell}}


If we do this and add \label{test} to the final row (the one that ends up numbered 1ℓ), we'll have, in the .aux file

\newlabel{test}{{1\ensuremath  {\latexell }}{1}}


and, while correct, it makes reference to \latexell that should better be avoided. One could use \DeclareRobustCommand instead of \renewcommand:

\let\latexell\ell
\let\ell\relax % to avoid a spurious warning
\DeclareRobustCommand{\ell}{\ensuremath{\latexell}}


and in this case the line in the .aux file would be

\newlabel{test}{{1\ell  }{1}}


The slicker way is using some low level tricks.

1. \the\ell expands to the math code assigned to \ell

2. \protected makes a control sequence that doesn't expand at all in “dangerous contexts”

3. \edef expands everything that's expandable

Thus we can do

\protected\edef\ell{\noexpand\ensuremath{{\mathchar\the\ell}}}


The \edef doesn't expand \ensuremath, because of \noexpand in front of it; it doesn't expand \mathchar, which is not expandable; but it expands \the\ell. So the redefined macro \ell will do

\ensuremath{{\mathchar<math code>}}


where <math code> is the right value we got from \the\ell. If we examine the macro with \show\ell, we are informed that

> \ell=\protected macro:
->\ensuremath {{\mathchar 352}}.


and the .aux file will have now

\newlabel{test}{{1\ell }{1}}


The advantage is not having a \latexell macro; we don't need to look up the math code assigned to \ell, either: we let TeX use what it already knows.

• That's a great solution, although difficult to parse with a skill level like mine (especially that tricky \edef-\noexpand combination). – tanh Dec 30 '15 at 11:31
• @tanh I added some explanations – egreg Dec 30 '15 at 11:55
• That's amazingly thorough, and very instructive. – tanh Dec 30 '15 at 13:02

The simplest solution is probably renewing \ell. \renewcommand{\ell}{l} in the preamble fixes numbering in subequations, but of course breaks \ell' if used elsewhere. You could do this locally instead:

\begin{subequations}
\renewcommand{\ell}{l}
\begin{gather}
[math]


However, you then can't use \ell in that equation set. If you add

\let\oldell\ell
\renewcommand{\ell}{\ensuremath{\oldell}}


to the preamble instead, you do not break \ell but the twelfth equation tag looks kind of off (the slanted ell after an upright k). This can be done locally too, of course. I personally don't like these fixes, as I prefer a normal l in the subequation label.

I have resorted to the following in any set of equations with twelve or more labels:

\begin{subequations}
\renewcommand{\theequation}{\theparentequation\MakeLowercase{\Alph{equation}}}
\begin{gather}
[math]


While not very elegant, it does the job (you get a normal l in your twelfth label and do not change ell). Note that

\renewcommand{\theequation}{\theparentequation\alph{equation}}


won't work, since it's the redefined alph` that's broken in the first place.