The SI Library of Unit-Based Computation

Contents

Abstract

We describe the general requirements, design, and usage of a C++ library based on the recognized international standard (SI) for describing measurable quantities and their units.

In their introductory text, Halliday and Resnick teach physicists to "... check the dimensions of all the equations you use." However, inspection of code samples reveals that scientific programmers typically make heavy use of a programming language's native numeric data types, thus obscuring the diverse intentions (e.g., distances, masses, energies, momenta, etc.) that any such purely numeric value could represent.

While limitations in programming language expressiveness and compiler technology have historically made such efforts difficult, the present project provides, in a modern programming language, a convenient means of expressing, computing with, and displaying numeric values with attached units. The fundamental requirements, (1) to apply compile-time type-checking while (2) avoiding time and space overhead at run-time, have been met. Thus, the Library enables automated (compile-time) checking of the dimensions of the numeric values within a computer program, and so provides the well-known benefits of type-safety to a new category of computing contexts.

In particular, this SI Library provides data types corresponding to all the base dimensions specified by SI. It also provides a mechanism to generate additional data types to describe and represent all derived dimensions in accordance with SI's provisions. Thus, for example, an object resulting from the product of two Length objects is automatically of type Area.

All the base and composite units specified by SI are provided as well, as are forms of the mandated prefixes for describing multiples and sub-multiples of the units. A significant number of additional standard values (any of which may be used as units), are also furnished within the Library. As additional features, the Library permits user specification, at compile time, of data representation, calibration, and models.

The following two lines of code suffice to access the Library's full capabilities:

    #include "SIunits/stdModel.h"
    using namespace si;    // optional

The Library itself is built from a relatively small amount of source code. This has been accomplished via extensive use of contemporary C++ technology, including namespaces and templates. Moreover, the byte-size of any object created via this Library is identical to the byte-size of an object of the native type having the identical data representation.

Introduction

Units-checking and type-safety

• "In carrying out any calculation, always remember to attach the proper units to the final result, for the result is meaningless without this...."
• "One way to spot an erroneous equation is to check the dimensions of all its terms...."
• "In any legitimate physical equation the dimensions of all the terms must be the same...."
• "You should check the dimensions of all the equations you use."

In modern digital computation, the analogous concept is known as static type-checking. This concept lies at the core of such object-oriented programming languages as C++, and yields among the most valuable benefits of such software methodology. To demonstrate the analogy's accuracy, we paraphrase Halliday and Resnick above:

• In programming any calculation, always remember to attach the proper data type to the final result, for the result is meaningless without this.
• One way to spot an erroneous program is to check the data types of all its objects.
• In any legitimate assignment statement the data types of both sides must be the same.
• You should check the data types of all the expressions you use.

As summarized by Fagan (pp. ii, 2), static typing provides:

• "... important feedback to the programmer by detecting a large class of program errors before execution."
• "... a succinct, intelligible form of program documentation, making programs easier to read and understand."
• "... information that a compiler can exploit to produce more efficient code."

Fagan further notes that "simple conceptual errors" often manifest as type errors, that these are detectable by type-checking software (such as a compiler) used to ensure "... the type documentation is consistent," and (citing Gannon's study) that "[e]xperimental results estimate the number of errors due to detectable [sic] type faults as something between 30% and 80% of all program errors." The importance of type-checking to successful computing is validated by the substantial body of computing research devoted to the topic. For these and related reasons, programmers have long been taught to employ and rely on type-checking.

Starting circa 1957, early high-level programming languages such as Fortran (and, later, C) followed the model of machine and assembly languages in allowing a programmer access to only a very few data types of general utility and applicability. Some twelve years later, such programming languages as Simula 67 and Pascal enabled use of data abstraction methodology by augmenting their native data types with relatively simple facilities for programmer-defined data types. According to Stroustrup, what we know as C++ classes evolved around 1980, while parameterized classes (now known as templates) provided even more powerful expressive capability ("parametric polymorphism") beginning around 1988.

Programmers are thus now able to use all these expressive capabilities to design data types and families of data types tailored to the problem domain at hand, and to apply such types conveniently and routinely. Given the recent official international C++ standard, and given modern compiler technology (such as that available from Kuck and Associates) to support the bulk of this standard, we clearly have both ample motivation and ample technology to embrace type-safe object-oriented techniques in all contemporary applications of computer programming.

Prior work

There have been several earlier efforts to attain these benefits. Perhaps the most useful to scientific programmers is currently found in the Units subdirectory of the CLHEP library. In their latest incarnations (originally authored by Maire and most recently modified by Tcherniaev in response to criticism by Lasiuk and Ullrich, among others), two files, PhysicalConstants.h and SystemOfUnits.h, define symbols for those units and important constants that are in common use by the high-energy physics community.

The use of these and similar symbols provides, of course, an important boost to code readability and correctness. However, CLHEP's Units files provide neither symbols nor mechanisms to express the concepts of the various intended dimensions to which these symbols belong. Ultimately, all symbols are of type HepDouble, which is usually a synonym for the native C++ double data type. Only in a relativistic model where the speed of light is one should it be possible to add meters to seconds; it is otherwise highly unlikely to be a meaningful expression, and therefore highly likely to reflect a conceptual and attendant computational error.

Oliver has proposed a different approach. While his outline appears to provide the benefits of type-safety, his main objective seems to concentrate on "Metric and English Units conversion/formatting" aspects. There is no mention of arithmetic in his sample code; indeed, he writes that "[he has] not yet solved the problem of multiplying/dividing mixed units."

Outside the realm of programming libraries, Converter Pro and similar software products and projects have dealt with the problems of converting values among units of like dimension. Such software is only of tangential interest to the present effort, for they do not address issues of general-purpose programming. They are, in effect, merely special-purpose calculators.

Finally, and perhaps most interesting, Wolfram's Mathematica system of mathematical computation supports symbolic tags (pp. 64, 538) and provides sufficient expressive power to employ such tags as unit markers during programmed computations. Tags can be attached to quantities and such tagged quantities can be combined in expressions. Via supplied databases, tagged values can be explicitly converted to yield equivalent values with different attached symbols.

However, from the limited available documentation on this subject, it appears that implicit conversion (e.g., 1 foot + 1 inch) is not supported. We infer from this that Mathematica does not support expression of the general concept of a dimension of measurement (e.g., length). Further, the software's furnished databases seem to support only a single model; no database conversions were found to allow a relativist, for example, to write code that adds distance and time units.

Current programming practice

Alas, in computer programming as practiced today, despite contemporary software technology, the standard of care recommended above seems only rarely applied to numeric quantities. Perhaps this prevailing attitude toward numeric computing is a lingering relic of the Fortran programming era's limitations; regardless, informal inspection of contemporary code samples revealed that programmers continue to make heavy use of a language's native numeric types (e.g., double) to the exclusion of customized numeric types (e.g., Velocity). A search of representative on-line archives did not even find any queries on the subject, suggesting little or no interest in, or knowledge of, alternatives.

Given prior software art, this finding is not surprising. However, such overly-general practice is a common source of errors, for it fails to distinguish (and it even obscures!) the diverse intentions (e.g., distances, masses, energies, momenta, etc.) that any such purely numeric value can represent.

Were such intentions routinely expressed in our computer programs, application of contemporary compiler technology would routinely provide us the benefits of type-safety in our numeric computations as a by-product of the translation process. This benefit is consistent with the unit-based approach so strongly advised by Halliday and Resnick, among many others.

Scope of current project

Given (1) recommended unit-based practices of long standing, (2) the demonstrated utility of computer-based type-checking, (3) currently-available programming language and compiler technologies, yet (4) current deplorable practices in numeric computation, we set out to develop a software subsystem to provide a convenient means of expressing, computing with, and displaying numeric values with attached units, thus attaining the well-known benefits of type safety. An additional requirement of this project was to ensure strict compile-time type-checking without run-time overhead (i.e., at no run-time cost in time or in space).

More specifically, we sought

1. the application of contemporary software technology to numeric physical concepts,
2. convenience of expression in such application,
3. general utility rooted in existing standards,
4. use of nomenclature from our problem domain, and
5. no attendant performance penalties!

The present project, known as The SI Library of Unit-based Computation, has succeeded in addressing these requirements. The resulting software module (known hereinafter as the SI Library or, simply, the Library) meets (and, in many respects, greatly exceeds!) all its goals and is intended for contribution (for non-commercial use) to the FPCLTF ("Zoom") project library at Fermilab.

Underpinnings and Basic Features

International Standard of Units

Le Système Internationale d'Unités (SI) is the recognized international standard for describing measurable quantities and their units. SI specifies seven mutually independent base quantities (dimensions): length, mass, time, electric current, thermodynamic temperature, amount of substance, and luminous intensity. The base units for describing amounts of these are specified, respectively, as the meter, kilogram, second, ampere, kelvin, mole, and candela.

In addition, SI describes a consistent system for expressing new dimensions (e.g., energy) in terms of the seven base dimensions. In particular, it includes a list of 21 such derived dimensions whose amounts are described in specially-named composites (e.g., joule) of the base units. Finally, SI provides a list of prefixes for forming units' decimal multiples and sub-multiples.

Library basics

In its most basic form, The SI Library of Unit-based Computation provides, in the form of data types, all the base dimensions specified by SI. Further, it provides the ability to declare additional data types to represent derived dimensions, also as specified.

For programming convenience, a very significant number of derived dimensions have been included in the Library. In particular, virtually all the dimensions described by Horvath and by Pennycuick are provided. (See the "Tables of Predeclared Types" below for details.) A programmer is free to use, ignore, or add to these as may be convenient.

Similarly, all the base and composite units specified by SI are provided in the Library, as are forms of the SI-mandated prefixes. Finally, an extensive collection of diverse units from published sources (including Horvath's, Pennycuick's, and the Particle Data Group's publications, as well as the CLHEP Units files) have also been included in the module. These encompass traditional MKS, CGS, UK, and US units, as well as a significant collection of constants of nature. Further, many units not in common use have also been provided in order to demonstrate both the diversity and the flexibility that the Library enables.

As before, the programmer may use, ignore, or extend this list of units. We note that any amount may be used as a unit for a quantity of appropriate type; thus, both traditional units and standard values are combined in the "Tables of Predefined Units, Prefixes, and Constants" below.

All the necessary infrastructure to take advantage of the SI Library is made available to a user program in the form of header files; in simplest form, the programmer merely inserts the following:

    #include "SIunits/stdModel.h"
    using namespace si;    // optional

All the data types (technically, classes), units, and other values provided by the SI Library are thereby made available for subsequent use. However, all the Library's identifiers are declared within a C++ namespace so as to avoid introducing extraneous symbols; in consequence, one or more using statements are also required.

The mechanisms for accessing and employing the Library's symbols are illustrated in the next section. Note that, by convention, most identifiers beginning with a capital letter represent data types. a very few such are, however, conventional names for standard constants (e.g., N_A for Avogadro's number, as shown in the Particle Data Book).

Tutorial Examples

Instantiating and initializing

We first illustrate the fundamentals of instantiating SI Library objects in connection with SI's basic Length dimension. Note that, in the absence of any explicit units, the appropriate base unit (or combination of base units) will be assumed. Further note that any mismatch between units and dimensions will produce a compile-time error.

    // -------------------------------------------------------
    //
    // Example 1: fundamentals of instantiation/initialization
    //
    // -------------------------------------------------------

    #include "SIunits/stdModel.h"
    using namespace si;       // make most si:: symbols available
    using namespace si::abbreviations;

    int main()  {

      // Successful instantiations:
      //
      Length d;               // initialized to 0 meters by default
      Length d2( 2.5 );       // 2.5 meters; same as 2.5 * m
      Length d3( 1.2 * cm );  // 1.2 centimeters; recorded as .012 * m
      Length d4( 5 * d3 );    // equivalent to 6.0 centimeters
      Length d5( 1.23 * pico_ * meter ); // 1.23e-12 * m
      Length d6( d2 + d3 );   // all dimensions match

      // Bad instantiation attempts; all detected at compile-time:
      //
      Length d7( d2 * d3 );   // oops: an Area can't initialize a Length
      Length d8 = 3.5;        // oops: 3.5 is not a Length
      Length d9;              // so far so good, ...
        d9 = 3.5;             // ... oops: 3.5 is still not a Length

      return 0;

    }  // main()

Computing and output

We next illustrate some additional computation and output with Length and Length-related dimensions. Note in particular that the units in which values are displayed may be changed dynamically at will; however, no such change affects the internal representation of the value.

    // ----------------------------------
    //
    // Example 2:  computation and output
    //
    // ----------------------------------

    #include "SIunits/stdModel.h"
    using namespace si;               // get most si:: symbols
    using namespace si::abbreviations;

    #include <iostream>
    using namespace std;              // get all std:: symbols

    int main()  {

      // Display with default labels:
      //
      cout << inch << endl;           // display "0.0254 m"

      // Prefer centimeter labels from now on:
      //
      Length::showAs( cm, "cm" );     // set default display units
      cout << inch << endl;           // display "2.54 cm"

      // Compute/display:
      //
      Length len( 2*cm );
      Width  wid( 3*cm );             // Width is a synonym for Length
      Area   a( len * wid );
      cout << a << endl;              // display "6 cm^2"

      // Prefer to label Area in square meters:
      //
      Area::showAs( m*m, "m2" );      // set default display units
      cout << a << endl;              // display "0.0006 m2"
      cout << a*4 << endl;            // display "0.0024 m2"

      // But a volume reverts:
      //
      cout << a * 4*cm << endl;       // display "24 cm^3"

      return 0;

    }  // main()

Roots and powers

We next demonstrate some of the additional available functionality, primarily involving roots and powers of SI units. Only constant integral powers and roots are directly supported. Additionally, the dimensions involved must be appropriate to the operation. Thus, the cube root of a Volume's value will yield a value of type Length; however, the cube root of an Area is deemed meaningless and will prevent compilation. (If there is sufficient demand, a future enhancement to the Library may remove these limitations in favor of constant rational powers and roots.)

    // ----------------------------
    //
    // Example 3:  powers and roots
    //
    // ----------------------------

    #include "SIunits/stdModel.h"
    using namespace si;                      // get most si:: symbols
    using namespace si::abbreviations;

    #include <iostream>
    using namespace std;                     // get all std:: symbols

    int main()  {

      Length::showAs( cm, "cm" );            // set default display units

      Length    edge( 2*cm );
      cout << Nth<3>::pow( edge ) << endl;   // display "8 cm^3"

      Volume    cube( 27*meter );
      cout << Nth<3>::root( cube ) << endl;  // display "300 cm"

      Radius    r( 2*in );                   // Radius is Length
      Perimeter p( 2 * pi * r );             // Perimeter is Length
      Area      c( pi * sqr(r) );            // a square Radius is an Area
      Diameter  d( sqrt(c/ pi) );            // sqrt of an Area is OK
      Length    huh( Nth<3>::root(c) );      // but cube root is not

      return 0;

    }  // main()

Other Features

Choice of data representation

By default, the Library employs the C++ native double data type as its underlying representation. Recognizing, however, that different programming projects may require different underlying data representations (e.g., float, long double, complex<float>, etc.), C++'s template mechanism was used throughout this Library's implementation. This allows a knowledgeable programmer to specify the data representation desired. The memory requirement for each object of an si type is exactly the same memory amount that would be required for an object of the underlying native type.

A member function, pure(), is available to provide an SI Library object's value as the equivalent value of the underlying type; a second member function, measuredIn(), yields an SI Library object's value in multiples of a second (type-compatible) SI Library object's value. Use of these functions should, however, seldom be necessary.

No run-time overhead

Because all type-checking is handled at compile-time and because of heavy use of inlining, there is no run-time computational overhead beyond the time taken for the necessary arithmetic. Thus, use of the SI Library incurs no performance penalty over computation on the native type.

Choice of calibration

Because different users work with radically different magnitudes of values, the SI Library allows for certain user calibration. By default, each of the seven base units (meter, kilogram, second, etc.) is calibrated to a value of 1. However, for users who customarily work, say, in microns and nanoseconds, it is possible to calibrate the Library to treat these units as the base units instead. Such calibration, however, must be taken into account at the time the Library is built; dynamic recalibration is neither currently possible nor envisioned as a future enhancement of the Library.

Choice of model

Finally, different programming projects may use different models of the universe. For example, to simplify certain computations, high-energy physics calculations often assume the speed of light to be 1. Such assumptions are also possible within the SI Library, and all consequences of such assumptions (e.g., the merging of the Length and Time dimensions) can be accurately modeled.

The Library is supplied with five models; these are known, respectively, as the standard, relativistic, high-energy physics, quantum, and natural models. An application program selects the desired model via an #include "..." directive; details are provided in the "Table of Predefined World Views" below. A programmer pays no price for the availability of multiple models; only the code associated with the chosen model need be linked with application code. Additional models may, of course, be added to the Library by a knowledgeable programmer.

The World View

As described above, the SI Library may be tailored to a programmer's preferences as to:

• its underlying data representation,
• the magnitude of its base units, and
• its model of the universe.

These aspects are encompassed by a templated class, wv, known as the world view. While multiple world views may coexist within the Library, only one may be in use within a single program. Extending the Library with additional dimensions (types), constants, units, and world views is discussed below. Such extensions will smoothly coexist with existing Library features.

Compatibility

In the main, the names chosen for use in the SI Library's repository of constants and units are identical to the comparable names in CLHEP's Units files. (Many of the Library's names, however, are absent from CLHEP, and are adapted from other sources, such as Mathematica.) To this extent, therefore, the SI Library is name-compatible with this aspect of CLHEP, thus easing a transition.

The SI Library is not, however, strictly type-compatible with CLHEP. Because the unique feature of the SI Library is its type-safety, and because software using the SI Library will, by definition, be more type-conscious than other software, the two can not be directly combined.

However, it is possible for SI-aware software to call routines from another library such as CLHEP. This is accomplished via two features of the SI Library. First, the member functions pure() and measuredIn(), described earlier, can be used to pass a numeric parameter (by value or by constant reference) to a non-SI function. Second, a numeric result returned by a non-SI function can be given the appropriate type by application of the type's constructor.

Extensibility

More constants

To instantiate new constants in an application program, statements such as shown in the following examples are used:

  const Time       solarDay     ( 24 * hour );
  const Time       sideralSecond( 0.99726956 * second );
  const SolidAngle squareDegree ( 3.046174e-4 * steradian );

Note that these examples apply the usual C++ syntax for defining any object, constant or not, giving the object's type, its name, and its initial value. A constant object is distinguished only by the presence of the const keyword.

To augment the Library with a new constant of interest, or to update a value of an existing constant, it is necessary to edit a single data file. Provide, for each new constant, its type, name, abbreviation (if any), and value. In particular, the file consts.dat is the Library's repository of such values; the interested reader is advised to inspect this file to learn the appropriate format. It will be necessary to rebuild the Library in order that the changes take effect.

More units

Since any constant may function as a unit of measurement (for the corresponding dimension), the instructions in the previous sections serve equally well for augmenting the Library with new units as for augmenting with new constants.

More dimensions

This section is largely unnecessary, as the Library already provides for all possible dimensions. In particular, as previously noted, all base dimensions mandated by SI are explicitly present. Further, all the SI derived dimensions are implicitly present in the Library in the form of code for their instantiation as needed.

Technically, all dimensions have names of the form Dim<...>. In addition, also as previously described, a generous number of these dimensions have alternate names that are both more common and more convenient to use. These names are provided via the C++ typedef mechanism; this mechanism may also be used if any additional alternate names are desired. The interested reader is advised to inspect the Library file dims.dat to learn the appropriate format. If any changes are made to this file, it will be necessary to rebuild the Library in order that such changes take effect.

More world views

As described above, a world view encompasses a desired data representation, model, and calibration. The information constituting a world view is currently spread among several Library files; as a result, augmenting the SI Library with a new world view is a meticulous process. However, once completed and built, a new or adapted world view is made available to future users indefinitely.

Of the information provided by a world view, it is simplest to adjust the data representation, for it is merely a parameter to the world view template. The calibration is next easiest to change; but it involves updating a program (calibrate) that calculates the desired values as part of the build process. Most intensive in effort (because it requires the most planning) is to provide a new model.

A short paper written by Fischler describes his methodology and its application to the specification of the Library's non-standard models. While his note provides considerable guidance in undertaking a new model, it may also be possible to create a new world view based on an existing one. Accordingly, the interested reader is advised to inspect wv.h, calibrate.cc, and one or more of the model-specific header and implementation files for appropriate examples.

Caveats and Future Work

Naming

Due to historical accident, several units used in measuring diverse dimensions share identical or similar names and/or abbreviations. For example, rad is the common abbreviation for a radian while, at the same time, a rad is an accepted unit of measure of specific energy (having been shortened from radiation dose). Similarly, a gal stands for a gallon, while a Gal abbreviates a Galileo.

As a related problem, some units (e.g., calorie) have several accepted values, depending on their context (e.g., the international calorie, the mean calorie, the thermochemical calorie, etc.). This is true even though they share a common dimension of measurement (e.g., Energy). Similarly, such physical constants as the speed of sound have several values depending on both the medium (air, water, etc.) and the medium's temperature. For the sake of completeness, let us note that there are also historical variants of many quantities, although these can likely be ignored for most current purposes.

While not technically within the domain of this Library, these problems are exacerbated in that the Library attempts to provide as comprehensive as possible a collection of units and physical constants. Accordingly, some policies should be formulated to govern the inclusion and exclusion of such overlapping unit names and values.

As a starting point toward such standardization, we note that Lasiuk and Thomas have mandated the exclusion of all units' abbreviations from their STAR project's source code. Further, this policy has, as of this writing, been integrated into the pre-release of the CLHEP v1.3 Units files. However, others do find that many useful constants (e.g., c [the speed of light]) are commonly used as units in their abbreviated notations. Clearly, this issue is in need of further discussion to reach final consensus. In the interim, we have opted to put abbreviations into a sub-namespace.

Input

User input of unit-based values has not yet been addressed. For example, such seemingly-innocent code as:

    Distance d
    cin >> d;

Related issues include input notations for, say, units of Area, units of Velocity, and other composite units. We may also consider providing all I/O via the standard C++ library iostream facet mechanisms.

Unit conversions

At present, the Library assumes that all unit conversions between values of like types can be carried out via simple multiplication. While this assumption does hold in the overwhelming majority of cases, it is not universally true. For example, the conversions between degrees Kelvin and degrees Celsius require addition, not multiplication. Similarly, the conversions between degrees Kelvin and degrees Fahrenheit involve both multiplication and addition. Because such conversions violate the assumption stated above, they are unsupported at present.

Conversions to constrained values are also presently unsupported. For example, it may be necessary, in certain applications, to require that a PlaneAngle measured in radians lie in the range (-pi, +pi], while other applications may require the range [0, 2 pi) instead. This and similar conversion-related issues ought be further considered.

Numerical accuracy and representations

At present, the Library takes no special precautions to maximize numerical accuracy during its calculations. While we have encountered no specific problems caused by, say, rounding errors or the like, it can clearly become a source of concern. Since a user can tailor the underlying base representation via the world view, this problem may not be solvable in the most general case. However, some thought should be given to determine the most appropriate numerical methods.

In addition, it has been suggested that, in some contexts, the underlying representation (e.g., double) might need to vary from dimension to dimension. For example, the BaBar experiment has mandated (Porter and Jacobsen, p. 1) that "[t]imes shall be stored as fixed point numbers ...." and goes on to discuss, in a very brief footnote, the merits of "a 31 [sic] bit signed integer" representation. It is unclear whether the current implementation of the Library can be adapted to permit such integral Times while maintaining, say, Lengths as doubles.

Finally, a correspondent (Ottinger) has expressed a desire to track a value's "quality" as it evolves numerically. While not specified in complete detail, this appears to be somewhat similar to the concept of attaching an error estimate to each calculated value. This request appears to be a problem arising independently of this Library. If solved in a general (perhaps templatized) way, the solution can likely be applied to the objects created and supported by the Library. An assessment of this ought be performed.

Databases

Certainly, adding more units and other useful constants to the Library's will be an on-going process for some time. It is, in fact, probable that significant such additions will have taken place since this paper was written.

There is some interest in augmenting the Library by establishing one or more databases of useful physical constants. Constants of interest to be pursued heavily depend, of course, on the applications to be made of the Library. Possibilities already suggested include selected properties of the chemical elements, properties of various atomic particles, and the like.

Concluding Remarks

This paper has presented the concept of type-checking as the computer analog of manual calculation with units. The benefits of type-checking have been set forth, together with empirical evidence that programmers do not today apply type-checking to its fullest potential in numeric computation.

The thrust of the paper has been the general description of the project known as The SI Library of Unit-based Computation, a software subsystem intended to apply the documented benefits of type-checking to numeric computation with no run-time overhead in either time or space. Convenience of use, economy of application, and ease of extensibility were primary objectives of the project.

All major features of the SI Library have been discussed, and examples of its utility have been presented. User extensions have been described, as have certain options for future enhancement of the project.

We conclude that the SI Library software project has met each of its objectives, and has exceeded many of them. To quote sample user reaction to date, "[the SI Library] is the first really good reason I've seen to switch from Fortran to C++." (Thank you!)

Acknowledgements

I extend grateful thanks to the following individuals for their contributions as noted below. Their efforts helped significantly in advancing this project, and are greatly appreciated.

In addition to his general support as chair of the Fermi Physics Class Library Task Force, Mark Fischler first suggested applying the core of the SI Library to additional models, leading to the world view concept. He also defined the desired properties of the advanced physics models and assisted materially in validating the Library's behavior in these models. Isi Dunietz also assisted with some of this validation and with proofing.

Valerie, Leo, and Richard Brown helped to proofread the Library's units and other constants. In addition, Valerie Brown proofread numerous drafts of this paper; her comments were instrumental in materially improving the exposition.

Finally, Carol Brown made it possible for me to spend significant time to work on this project at home. Her support and her love are appreciated above all.

Bibliography

Aus der Au, Willy R.:

"Converter Pro (16-bit) for Windows 3.1 and Converter Pro (32-bit) for Windows 95/98/NT." Internet: http://www.accsoft-ch.com/co102.htm, AccSoft Shareware: Staefa, Switzerland.

Caso, Carlo, et al.:

"Review of Particle Physics." The European Physical Journal, C3 (1998) pp. 69-70, 73.

Fagan, Mike:

Soft Typing: An Approach to Type Checking for Dynamically Typed Languages. Technical Report 92-184, Rice University, March 31, 1992.

Fischler, Mark S.:

units.note. Unpublished, updated August 14, 1998.

Gannon, John D.:

"An Experimental Evaluation of Data Type Conventions." Communications of the ACM, 20:8 (August, 1977), pp. 584-595.

Halliday, David and Robert Resnick:

Fundamentals of Physics. John Wiley & Sons, Inc., 1970. SBN 471 34430 3.

Horvath, Ari L.:

Conversion Tables of Units in Science & Engineering. The Macmillan Press Ltd., 1986. ISBN 0-444-01150-1.

International Standards Organization, JTC1/SC22:

Programming Languages -- C++. ISO/IEC FDIS 14882, 1998.

Lasiuk, Brian and Thomas Ullrich:

Comments on the Use of CLHEP for STAR. Internet: http://star.physics.yale.edu/preprint/papers/clhep.ps, STAR note 329, YRHI-98-08.

Maire, Michel and Evgueni Tcherniaev:

Units/PhysicalConstants.h. In CLHEP v1.3, CERN, 1998.

Maire, Michel and Evgueni Tcherniaev:

Units/SystemOfUnits.h. In CLHEP v1.3, CERN, 1998.

Montanet, L., et al.:

"Review of Particle Properties." Physical Review, D50 (1994), pp. 1233-4.

Oliver, Robert:

"Re: Metric and English Units conversion/formatting?" Newsgroup comp.lang.c++.moderated, June 18, 1998.

Ottinger, Tim:

Private communication. June 17, 1998.

Pennycuick, Colin J.:

Conversion Factors: S. I. Units and Many Others. Univ. of Chicago Press, 1988. ISBN 0-226-65507-5.

Porter, Frank and Bob Jacobsen:

Preferred Units for BaBar Software. Internet: http://hepunx.rl.ac.uk/BFROOT/doc/Computing/Standards/Units.ps, Oct. 14, 1995.

Stroustrup, Bjarne:

The Design and Evolution of C++. Addison-Wesley Publishing Co., 1994. ISBN 0-201-54330-3.

Wolfram, Stephen:

Mathematica: A System for Doing Mathematics by Computer. Addison-Wesley Publishing Co., Inc., 1988. ISBN 0-201-19334-5.

Tables of Predeclared Types

In the following tables, the name of each data type is followed by seven numbers, one for each base dimension, that together specify the dimensionality of the data type. Remarks are used to suggest the dimensions' definitions or to provide typical units of measurements. Units preceded by an asterisk are fundamental to SI.

Single dimensions

Pairs of dimensions

Dimension triples

Dimension 4-tuples

Dimension 5-tuples

Tables of Predefined Units, Prefixes, and Constants

Standard SI prefixes (dimensionless)

Prefixes to form multiples of SI units:

Prefixes to form submultiples of SI units:

Base (default) SI units

The values shown for these units are those in the standard world view. Other world views can recalibrate these values, if desired.

Data Type	Name	Abbr.	Value
Length	meter	m	1
Mass	kilogram	kg	1
Time	second	s	1
Current	ampere	A, amp	1
Temperature	kelvin	K	1
AmountOfSubstance	mole	mol	1
LuminousIntensity	candela	cd	1

Derived and supplementary SI units having special symbols

Dimensionless constants and units

Fractions:

Numerical constants:

Angle units:

Single-dimension constants and units

Linear measure (metric):

Linear measure (English):

Quadratic measure (metric):

Quadratic measure (English):

Cubic measure (metric):

Cubic measure (English):

Mass measure (metric):

Mass measure (English):

Time measure:

Dimension-pair constants and units

Length-Mass measure:

Length-Time measure:

Time-Current measure:

Length-LuminousIntensity measure:

Dimension-triple constants and units

Length-Mass-Time measure:

Mass-Time-Current measure:

Dimension-4tuple constants and units

Length-Mass-Time-Current measure:

Dimension-5tuple constants and units

Length-Mass-Time-Temp.-AmtOfSubst. measure:

HEP-specific constants and units

Table of Predefined World Views