Unit of measurement libraries, their popularity and suitability

Abstract

In scientific applications, physical quantities, and units of measurement are used regularly. If the inherent incompatibility between these units is not handled properly it can lead to potentially catastrophic problems. Although the risk of a miscalculation is high and the cost equally so, almost none of the major programming languages has support for physical quantities. We employed a systematic approach to examine and analyse available units of measurement (UoM) libraries. The search results were condensed into 38 libraries. These were the most comprehensive and well‐developed, open‐source libraries, chosen from approximately 3700 search results across seven repository hosting sites. Most libraries are implemented in a similar manner, but with varying features and evaluation strategies. Three developers and a scientist were interviewed and 91 practitioners of varying experiences from on‐line forums were surveyed to explain their impressions of UoM libraries and their suitability. Our findings show several reasons for nonadoption, including insufficient awareness of UoM libraries, cumbersome in practice, specific performance concerns, and usage of development processes that exclude unit information We conclude with recommendations to UoM library creators derived from these observations. We also argue that so long as units are not part of the language, or not supported through an IDE extension, their use will be limited. Native language support allows for efficient unit conversion and static checking. While lightweight methods provide many benefits of UoM libraries with minimal overheads. Libraries are perhaps best suited to applications in which unit of measurement checking is desirable at run‐time.

Managing Quantities and Units of Measurement in Code Bases

“…In this Section we shall look at the four practical methods that support unit checking of code basis. All implementation options are affected by the following three concerns [13]: lack of awareness, cumbersome implementations and lack of support from the given software eco-system. Software rarely lives in a vacuum so even if it has been designed and developed with one of these methods, associated components are unlikely to support UoM, such as legacy libraries, databases and spreadsheets.…”

“…Certain modern languages, such as Ruby, provide a special syntax for adding features to the language which exploit duck typing, enabling lightweight libraries to be built. The main conclusion is that for adoption to occur, UoM must be included in such a way that they are almost as easy to use as standard arithmetic types [13].…”

“…However UoM can be implemented through static overloading, or Java generic instantiations, ensuring compile-time checking. An example of both styles is shown in [13]. Merging the two techniques would double the amount of notation required and significantly add to the burden of adoption.…”

“…The aim of this chapter is to discuss the various ways in which quantity information can be transferred into software and errors detected either at compile-time or run-time. Motivated by a prior critique of UoM libraries and a survey of scientific coders [13], we assess various approaches based on their ease of use, execution speed, numeric accuracy, ease of integration and coverage of unit error detection capabilities.…”

SA4U: Practical Static Analysis for Unit Type Error Detection

“…(1) Work without developer annotations: research suggests annotation burden remains a dominant factor in the lack of adoption of existing work, despite the state-of-the-art's effort to reduce annotation burden [20]. (2) Check units: existing tools only analyze the dimension of a measurement, and not its specific unit.…”