The Digital Library of Mathematical Functions (DLMF1) covers the de nitions and properties of a wide variety of special functions with applications in physics and engineering | several hundred, depending on how you count them. Although initially focused as a resource for human readers, the DLMF's long-term goal is to support machine-readable content to enable interoperability between other digital libraries, computer algebra and theorem proving systems. But, the long history of special functions across and among di erent communities of interest has led to the potential for confusion and error. When di erent practitioners speak about apparently the same function, their di erent histories and conventions may include di erent assumptions of scalings, arguments (order or de nition), branch cuts, assumed values in special cases, and so on. A simple example is the Jacobian elliptic function sn seen as a function either of the modulus k or the parameter m = k2; each form is preferred for certain purposes. While neither party is necessarily wrong, failure to account for their di erences in communications is guaranteed to lead to error. It is thus critical for interoperability between systems to establish each system's conventions and assumptions. This is true enough for a human reader transcribing DLMF's results into a computer algebra system, but all the more so when these processes are automated and hidden from view. Ideally these di erences can be formalized to the extent that enables automatic conversion of formula across the di erent views. Indeed, the World Digital Mathematics Library2 has founded an e ort to develop such a Special Function Concordance. Towards these ends, this note presents a proposed set of (virtual) OpenMath3 Content Dictionaries (CD) to characterize the choices made in the DLMF. An unexpected challenge was an organization and naming of the CDs and symbols in a fashion appropriate to OpenMath applications. The functions can be grouped according to mathematical or historical features, or applications. The proper names of functions can become quite verbose with strings of signi cant adjectives before they become su ciently unique. Consider \Legendre's incomplete elliptic integral of the rst kind" and then add modi ers such as \zeros of the derivatives of". Given that some functions are ubiquitous while others are truly esoteric, one would even hope for a Hu man-type encoding. Yet, the functions have already been grouped into chapters in a way appropriate for the DLMF's purposes. Moreover, each function has a unique LATEX macro de ned for it to simplify the markup and preserve the semantics during conversion to web formats 4. For example the two functions mentioned above have, macros \Jacobiellsnk (encoding \the Jacobian elliptic function sn, of modulus k") and \incellintFk (encoding \(Legendre's) incomplete elliptic integral (of the rst kind) of modulus k"; See Appendix A for details). While these
may not roll o the tongue, they are unique, reasonably type-able and blend with TEX's macro conventions. And while this organization and naming may not be optimized for OpenMath purposes, it seems better to reuse the one scheme than to introduce redundant ones.
We have therefore followed DLMF's organization for the primary grouping of functions. The most important functions in a chapter are covered in a base CD, such as DLMF BS (for Bessel functions). In most cases, progressively esoteric functions are grouped into subcategories according to: generalizations (DLMF BS gen), q-analogs (DLMF BS q), magnitudes, zeros, matrix argument and so on, as well as some special case such as DLMF GH Appell for Appell functions. 3
The more fundamental challenge is to properly characterize the functions. This, of course, is exactly what any proper `de nition' ought to be. But here the point is that the de nition be su ciently complete, explicit and formalized, to enable easily determining the equivalancy of functions from di erent systems. Ultimately, the goal would be to enable automatic conversion between, for example, the two di erent ` avors' of elliptic functions, sn.
At this stage of development, we are providing URLs as the de nitions of each function, being pointers into the DLMF where the de nition is to be found. This is obviously an informal de nition, and may require digging for some details. De nitions may be either explicit or implicit (such as a function de ned by a di erential equation along with boundary conditions).
Additionally, we have provided a simple type signature for each function to characterize its domain and range (See Table 1). Note that in many cases functions are unde ned for isolated values of some arguments, e.g. singularities; these cases are not always re ected in the current signatures. Other properties, such as branch cuts, multivaluedness, have not yet been made explicit. 4
We have provided here a catalog of the special functions covered by the DLMF | a set of informal, virtual Content Dictionaries. It should serve as a reasonable starting point for establishing a concordance between the sets of functions covered by the several interested parties. This is a continuing process; our CDs will continue to be re ned and gradually extended and formalized as needed.
The current status can be found at https://math.nist.gov/~BMiller/DLMF-CDS/, where also a JSON encoding of the data may be downloaded for processing.
We welcome suggestions about which features and characteristics function are important to the notion of a concordance, as well as how best to encode and formalize that information. Any other comments about the catalog are also welcome.
Acknowledgements: The author would like to thank Patrick Ion, Howard Cohl and Florian Rabe for constructive comments.
A
Brie y, the names of the various mathematical function macros are derived from the descriptive `Proper Name' of the function according to: macro
n pre x name class ? symbol ?su x
The name is the `conventional' name or based on the \inventor's" name. The class indicates function (generally omitted), integrals, polynomials, and so on. The symbol is the latinized form of the notation, upper or lower case as appropriate. The pre x modi er includes all signi cant characteristics that may distinguish functions (e.g. `modi ed Bessel' vs. simply `Bessel'). The su x generally indicates limitations or special cases regarding arguments. The abbreviations used for pre x , class and su x are given in Table 2. For predictability, we avoid abbreviating people's names. Meaning imaginary argument or order elliptic functions of k, modulus elliptic functions of parameter m = k2 matrix argument of real argument or order on invariants (Weierstrass) on lattice (Weierstrass) functions of q, nome functions of