# Is this the best way to label the lanthanides using chemnum?

I want to label a series of compounds with the lanthanides, i.e. 10la and I'm using the chemnum package.

The manual gives some hints about this, saying you could do \newcmpdcounterformat{arabic}{\@arabic} but it uses \int_to_<...>. So after some looking around, I found interfaces3.pdf and copy and pasted some code from it, and then got help from the chat when it didn't work. However, I'm a bit worried by the manuals description of the function:

This is the low-level function for conversion of an integer expression into a symbolic form (often letters)

(emphasis mine)

Aren't low level things stuff that people like me are supposed to avoid? Is there a higher level way of doing this? Should I be using a more traditional method of making a list of things, like however \alpha was defined?

Here is the (working) code I came up with:

\documentclass{article}
\usepackage{chemnum}
\RequirePackage{expl3}

\ExplSyntaxOn
\cs_new:Npn \canageek_int_to_lanthanide:n #1
{
\int_to_symbols:nnn {#1} { 15 }
{
{ 1 } { La }
{ 2 } { Ce }
{ 3 } { Pr }
{ 4 } { Nd }
{ 5 } { Pm }
{ 6 } { Sm }
{ 7 } { Eu }
{ 8 } { Gd }
{ 9 } { Tb }
{ 10 } { Dy }
{ 11 } { Ho }
{ 12 } { Er }
{ 13 } { Tm }
{ 14 } { Yb }
{ 15 } { Lu }
}
}

\newcmpdcounterformat{lanthanide}{\canageek_int_to_lanthanide:n}

\ExplSyntaxOff

\labelcmpd[sub-counter-format=lanthanide]{lnwater.la,lnwater.ce,lnwater.pr,lnwater.nd,lnwater.pm,lnwater.sm,lnwater.eu,lnwater.gd,lnwater.tb,lnwater.dy,lnwater.ho,lnwater.er,lnwater.tm,lnwater.yb,lnwater.lu}

\begin{document}
\cmpd{peroxo.meoh}
\cmpd{DMSOcp}

\cmpd{lnwater.pr}
\cmpd{lnwater.{ce,la}}
\cmpd{lnwater.lu}

\end{document}

• I see nothing wrong with the code. The “low-level” refers to the fact that \int_to_alph:n is defined in terms of \int_to_symbols:nnn. All functions with no double underscore in their names are good to use. Nov 25, 2020 at 9:02

You're doing well. The examples in the code of chemnum are

\newcmpdcounterformat {arabic} { \int_to_arabic:n }
\newcmpdcounterformat {alph}   { \int_to_alph:n }
\newcmpdcounterformat {Alph}   { \int_to_Alph:n }
\newcmpdcounterformat {roman}  { \int_to_roman:n }
\newcmpdcounterformat {Roman}  { \int_to_Roman:n }
\newcmpdcounterformat {greek}  { \chemgreek_int_to_greek:n }
\newcmpdcounterformat {Greek}  { \chemgreek_int_to_Greek:n }


from which we deduce that the second argument should be a one-argument (expandable) function that transforms an abstract integer into something else. In the first five cases, a kernel expl3 function exists, for the other two cases something has been devised in chemgreek and, lo, here it is

\cs_new:Npn \chemgreek_int_to_greek:n #1
{
\int_to_symbols:nnn {#1} {24}
{
{  1 } { \chemgreek_alpha: }
{  2 } { \chemgreek_beta: }
{  3 } { \chemgreek_gamma: }
[...]
{ 23 } { \chemgreek_psi: }
{ 24 } { \chemgreek_omega: }
}
}


(some lines omitted). So your approach is very good and I see no issue.

The “low-level” you read refers to the fact that \int_to_symbols:nnn is the function actually used for defining \int_to_alph:n and \int_to_Alph:n and could be used for footnote symbols and so on.