Torque not Work, Representing Kinds of Quantities
Steve McKeever
a
Department of Informatics and Media, Uppsala University, Sweden
Keywords:
Kind of Quantity, Dimensional Analysis, Units of Measurement, Unit Conversion.
Abstract:
A system of units, such as the SI system, will have a number of fundamental units representing observable phe-
nomena and a means of combining them to create compound units. In scientific and engineering disciplines, a
quantity would typically be a value with an associated unit. Managing quantities in software systems is often
left to the programmer, resulting in well-known failures when manipulated inappropriately. While there are a
large number of tools and libraries for validating expressions denoting units of measurement, none allow the
kind of quantity to be specified. In this paper we explore the problem of quantities that might share the same
units of measurement but denote different kinds of quantities, such as work and torque. We develop a data
type that represents compound units in a tree structure rather than as a tuple. When performing arithmetic, this
structure maintains the compound definition allowing for a richer static analysis, and a complete definition of
arithmetic on kinds of quantities.
1 INTRODUCTION
Humans have developed systems of measurement
since the early days of trade, enhanced over time to
fulfil the accuracy and interoperable needs of science
and technology. In the 19th century, James Clerk
Maxwell (Maxwell, 1873) introduced the concept of
a system of quantities with a corresponding system of
units. This generalisation allowed scientists working
with different measurement systems to communicate
more easily, as unit names (such as inch or metre) are
treated as numeric variables and can be interchanged
through multiplication.
Dimensions are physical quantities that can be
measured, while units are arbitrary labels that corre-
spond to a given dimension to make it relative. For
example a dimension is length, whereas a metre is
a relative unit that describes length. Units of mea-
surement (UoM) can be defined in the most generic
form as either base quantities or compound quanti-
ties. Fundamental physical quantities are the basic
quantities that require no other physical quantities to
express. Physical quantities that can be derived from
the combination of two or more fundamental physical
quantities are called compound physical quantities.
For instance, velocity (m/s or m · s
−1
) can be derived
from the base quantities of metre and second. The
International System of Units (SI) defines seven base
a
https://orcid.org/0000-0002-1970-2884
quantities (length, mass, time, electric current, ther-
modynamic temperature, amount of substance, and
luminous intensity) as well as a corresponding unit
for each quantity (Bureau International des Poids et
Mesures, 2019). It is common for quantities to be
declared as a number (the magnitude of the quantity)
with an associated UoM (NIST, 2015).
Two values that share the same UoM might not
represent the same kinds of quantities (KOQ) (Lodge,
1888; Foster and Tregeagle, 2018). The relationship
between quantities and unit names is many-to-one.
For example, torque is a rotational force which causes
an object to rotate about an axis while work is the re-
sult of a force acting over some distance. They both
share the same UoM, namely kg · m
2
· s
−2
, but torque
is usually written as N · m, while work is convention-
ally expressed as J. Other examples are heat capacity
and entropy (kg · m
2
· s
−2
· K
−1
), and electric current
and magnetomotive force.
With digitalisation affecting most facets of our
lives, the need to faithfully represent and manipu-
late quantities in physical systems is ever increas-
ing (Wilkinson et al., 2016). Popular programming
languages allow developers to describe how to eval-
uate numeric expressions but not how to detect inap-
propriate actions on quantities. Consequently there
have been infamous examples, such as the Mars Cli-
mate Orbiter (Stephenson et al., 1999), where UoM
conversion omissions led to dire outcomes. Develop-
McKeever, S.
Torque not Work, Representing Kinds of Quantities.
DOI: 10.5220/0012318900003645
Paper published under CC license (CC BY-NC-ND 4.0)
In Proceedings of the 12th International Conference on Model-Based Software and Systems Engineering (MODELSWARD 2024), pages 133-140
ISBN: 978-989-758-682-8; ISSN: 2184-4348
Proceedings Copyright © 2024 by SCITEPRESS – Science and Technology Publications, Lda.
133

ers can choose to use tools or libraries to ensure UoM
are managed correctly. However, KOQ analysis has
only recently been formalised (McKeever., 2022). In
this paper we present a more refined version that con-
nects both dimensional and kind of quantity analysis
through an alternative representation of UoM that al-
lows quantities in arithmetic expressions to be named
and handled safely. Explicitly naming quantities also
allows known conversions to be applied to particu-
lar values, such as a becquerel for measuring radioac-
tivity. In doing so we can ensure separate quantities
(such as torque and work) are not combined but also
that dimensionless quantities (such as radians or stera-
dians) are distinct.
The paper is structured as follows. In Section 2
we discuss efforts to include UoM into conventional
programming languages and modeling platforms. In
Section 3 we introduce a very simple assignment lan-
guage to show how values are defined and evaluated.
In Section 4 we describe how conventional dimen-
sional analysis would ensure that arithmetic proceeds
correctly. We introduce a notion of kinds of quantities
in Section 5, based on an algebraic data type that cap-
tures the structure of compound quantities and its op-
erations. In Section 6 we show how this data type can
detect errors that conventional UoM checkers cannot.
Finally, in Section 7 we summarise quantity valida-
tion and describe extensions of our approach.
2 BACKGROUND
To a physicist or applied mathematician, it is taken for
granted that a quantity is used in the same manner as
a unit-independent value, and that all arithmetic and
comparative operators can be applied to it. However,
it does not make sense to multiply scales of intelli-
gence or personality traits. Stevens (Stevens, 1946)
identified four categories of scale that places limits on
the type of measurement that can be used to construct
valid terms: nominal, ordinal, interval and ratio. We
shall focus on quantities that belong to the ratio scale
as these are used to model the physical world and in-
clude all the usual arithmetic operators.
Adding UoM to programming languages was
first undertaken in the 1970s (Karr and Loveman,
1978) and early 80s with proposals to extend For-
tran (Gehani, 1977) and Pascal (Dreiheller et al.,
1986). These efforts were mostly syntax based, re-
quiring modifications to the underlying languages,
reducing backwards compatibility and thus usage.
The operator overloading and type parameterisation
of Ada allowed for a more versatile approach (Hil-
finger, 1988) to labelling variables with UoM fea-
tures. As practical object oriented programming
languages started to emerge in the early 90s, such
as C++ and Java, developers began to implement
UoM via the Quantity pattern (Fowler, 1997). This
has led to a veritable explosion in the number of
UoM libraries available for all popular programming
languages (Bennich-Bj
¨
orkman and McKeever, 2018)
based on this pattern (McKeever et al., 2019). How-
ever, a survey of scientific coders (Salah and McK-
eever, 2020) revealed that these libraries have signif-
icant limitations that impedes their adoption. Even
C++ with a de facto UoM library based on the tem-
plate meta-programming feature, that ensures effi-
cient run-time computation, suffers from both accu-
racy and usability issues. The F# programming lan-
guage has excellent native support for UoM but lacks
popularity. An alternative compile-time approach is
to define UoM through comments or attributes and
to build a tool that attempts to perform as much in-
spection as possible (Jiang and Su, 2006; Xiang et al.,
2020; Hills M et al., 2012). These approaches are
lightweight and scalable but they need to be main-
tained.
It is customary for software development to begin
at a higher level of abstraction through diagrams and
rules that focus on the conceptual model that is to be
constructed. Adding UoM to software modeling lan-
guages has been successful but unless the workflow
has been created specifically, declaring quantities in
a system specification language offers no guarantee
that the UoM information is supported in the even-
tual implementation. Extensions to the Unified Mod-
eling Language (UML) have been proposed to sup-
port quantities. SysML
1
, for instance, is defined as
an extension of a subset of the UML to support sys-
tems engineering activities and has extensive support
for quantities. The Event-B modelling language (Gib-
son and M
´
ery, 2017) provides UoM and leverages the
Rodin theorem prover to detect errors before trans-
lating to Java. Comparable techniques have been pro-
posed for more formal notations such as Z (Hayes and
Mahony, 1995) and Maude (Chen et al., 2003). Unit
checking and conversion of UML can be undertaken
before code is generated, either through a compila-
tion workflow that leverages Object Constraint Lan-
guage (OCL) expressions (Mayerhofer et al., 2016)
or staged computation (Allen et al., 2004).
The key aspect of all these systems is that, by only
representing dimensions, they cannot coherently dis-
tinguish between kinds of quantities and units of mea-
sure. We lack a definitive understanding of how fre-
quently any form of quantity error occurs in practice:
be it a naming, dimensional or unit conversion error.
1
https://sysml.org
MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering
134

However, it would seem careless in the current soft-
ware development context to model complex systems
in terms of floating point numbers without further de-
lineation or annotation.
3 EVALUATING EXPRESSIONS
Performing calculations in relation to quantities, di-
mensions and units is subtle and can easily lead to
mistakes. We shall begin by looking at a very sim-
ple language of declarations and assignments so that
we can focus on the key aspects involved in managing
quantities correctly. A program is a block, namely one
or more quantity variable declarations, udec, followed
by one or more statements, ustmt. Unit variables, uv,
are represented as floating-point numbers, float. En-
riching the language with more structure such as con-
ditionals, while-loops and function calls does not af-
fect the core of the analysis. Unit arithmetic expres-
sions, uexp, impose syntactic restrictions so that their
soundness can be inferred using the algebra of quan-
tities.
E : uexp → (uv → value) → value
E[[uv]]
ρ
= ρ uv
E[[r ∗ uexp]]
ρ
= r × E [[uexp]]
ρ
E[[uexp
1
+ uexp
2
]]
ρ
= E[[uexp
1
]]
ρ
+ E[[uexp
2
]]
ρ
E[[uexp
1
− uexp
2
]]
ρ
= E[[uexp
1
]]
ρ
− E[[uexp
2
]]
ρ
E[[uexp
1
∗ uexp
2
]]
ρ
= E[[uexp
1
]]
ρ
× E[[uexp
2
]]
ρ
E[[uexp
1
/ uexp
2
]]
ρ
= E[[uexp
1
]]
ρ
÷ E[[uexp
2
]]
ρ
Figure 1: Rules for evaluating expressions.
block ::= begin udec in ustmt end
udec ::= uv : float | uv : float is f
| udec
1
;udec
2
ustmt ::= uv := uexp
uexp ::= uv | r ∗ uexp
| uexp
1
+ uexp
2
| uexp
1
− uexp
2
| uexp
1
∗ uexp
2
| uexp
1
/ uexp
2
By creating a separate syntax for unit expressions we
can distinguish between scalar values, such as r, and
unitless quantities in which all the dimensions are
zero, such as moisture content. Consider a simple
program to calculate Newton’s second law of motion:
begin
f : float;
m : float is 5.7;
a : float is 3.2
in
f := m * a
end
We can use the evaluate function, E of Figure 1,
with an environment consisting of values for m and a
to calculate f.
4 DIMENSIONAL ANALYSIS AND
UNIT CONVERSION
As is the case in nearly all programming languages,
users have to assume that the mass (m) is given in kilo-
grams, and the acceleration (a) is given in metres per
second per second for the assignment to be correct.
D : uexp → (uv → dims) → dims
D[[uv]]
σ
= σ uv
D[[r ∗ uexp]]
σ
= D[[uexp]]
σ
D[[uexp
1
+ uexp
2
]]
σ
= D[[uexp
1
]]
σ
∼
=
D[[uexp
2
]]
σ
D[[uexp
1
− uexp
2
]]
σ
= D[[uexp
1
]]
σ
∼
=
D[[uexp
2
]]
σ
D[[uexp
1
∗ uexp
2
]]
σ
= D[[uexp
1
]]
σ
ˆ
× D[[uexp
2
]]
σ
D[[uexp
1
/ uexp
2
]]
σ
= D[[uexp
1
]]
σ
ˆ
÷ D[[uexp
2
]]
σ
Figure 2: Dimensional Analysis rules for Expressions.
A dimensional analysis needs to ensure that (1)
two physical quantities can only be equated if they
have the same dimensions; (2) two physical quantities
can only be added if they have the same dimensions
(known as the Principle of Dimensional Homogene-
ity); (3) the dimensions of the multiplication of two
quantities is given by the addition of the dimensions
of the two quantities. If we only consider the three
common dimensions of length, mass and time, a tuple
of integers can be used to represent these dimensions.
udec ::= uv : float of dims | udec
1
;udec
2
dims ::= (int, int, int)
Dimensional homogeneity can be used to check
for equality:
(l
1
,m
1
,t
1
)
∼
=
(l
2
,m
2
,t
2
)
= (l
1
,m
1
,t
1
), if l
1
= l
2
∧ m
1
= m
2
∧t
1
= t
2
While the rules for multiplication and division on as
follows:
(l
1
,m
1
,t
1
)
ˆ
× (l
2
,m
2
,t
2
) = (l
1
+ l
2
,m
1
+ m
2
,t
1
+t
2
)
(l
1
,m
1
,t
1
)
ˆ
÷ (l
2
,m
2
,t
2
) = (l
1
− l
2
,m
1
− m
2
,t
1
−t
2
)
This allows us to rewrite the rules of Figure 1 by re-
placing the arithmetic operators to create a dimen-
sional checker, shown in Figure 2. Scalar multipli-
cation does not affect the dimensions of a quantity.
The dimension of mass, m, is described as (0,1,0),
while acceleration, a, is m · s
−2
or (1,0,-2) as a tu-
ple. Our dimensional checker will compute with di-
mensions and attempt to ensure all assignments are
correct. Consider our example program:
Torque not Work, Representing Kinds of Quantities
135

begin
f : float of (1,1,-2);
m : float of (0,1,0);
a : float of (1,0,-2)
in
f := m * a
end
The assignment is safe as (0,1,0)
ˆ
× (1,0,-2)
yields (1,1,-2). Most UoM checkers adopt this ap-
proach, extending the checking into the statements
and function calls of typical programming language
constructs. For instance, all branches of conditionals
and case statements must have the same dimensions,
while comparison operators can only operate on quan-
tities of the same dimension. If the dimensions of all
variables are known at compile-time then this check-
ing can be undertaken before the program is executed,
incurring no run-time cost. Furthermore, if UoM an-
notations are used then unit conversions can be in-
serted into the run-time code (Cooper and McKeever,
2008; McKeever, 2023).
5 KINDS OF QUANTITIES
Using a tuple representation of dimensions, torque
and work are both encoded as (1,2,-2). In order
to distinguish them we need a richer datatype to rep-
resent units of measure, a table that maps quantity
names onto their compound representations, and a
means of equating them. Using an algebraic data type,
we define named quantities as follows:
type quant = Name of string | Dimless
| Qmul of (quant * quant)
| Qdiv of (quant * quant)
Base quantities are represented as a unit name,
for instance a length quantity can be represented
as Name "metre", while velocity would be described
as Qdiv (Name "metre",Name "sec"). Dimension-
less quantities, Dimless, have no physical dimension.
They are often obtained as ratios resulting from the
division of quantities of the same kind.
Definition 5.1 (Converting KOQ into UoM). A com-
pound quantity can be converted into the length, mass
and time form as follows:
C : quant → dims
C (Name "metre") = (1,0,0)
C (Name "kg") = (0, 1,0)
C (Name "sec") = (0, 0,1)
C Dimless = (0, 0,0)
C (Qmul(p,q)) = (C p)
ˆ
× (C q)
C (Qdiv(p,q)) = (C p)
ˆ
÷ (C q)
Qmul(p,Dimless) ⇒ p
Qmul(Dimless, p) ⇒ p
Qdiv(p,Dimless) ⇒ p
Qdiv(Dimless, p) ⇒ p
Qmul(p,q) ⇒ Qmul(q, p)
Qmul(Qmul(p,q),r)) ⇒ Qmul(p,Qmul(q,r))
Qmul(p,Qmul(q,r)) ⇒ Qmul(Qmul(p,q),r))
Qmul(Qdiv(p,q),q)) ⇒ p
Qmul(p,Qdiv (q, p)) ⇒ q
Qdiv(Qmul(p,q),q) ⇒ p
Qdiv(Qmul(p,q), p) ⇒ q
Qdiv(p, p) ⇒ Dimless
Figure 3: Named Quantity Expression Simplification.
Owing to the properties of the tuple arithmetic op-
erators (identity, associative, commutative) there are
many ways of describing the same compound quan-
tity using the quant data type.
Proposition 5.2 (UoM Preserving Simplification).
For given quantities p and q, the rules of Figures 3
maintain the UoM of a given compound quantity.
Proof. By structural induction on p and q. We as-
sume p and q can be safely simplified, and apply the
tuple conversion function C to both sides of the ⇒
arrow, resulting in equivalent tuples for all cases.
In order to construct named compound quantities
we create a pair binding the name of a compound
quantity to its quant form:
("metre_per_sec",
[Qdiv (Name "metre", Name "sec")])
The quant form is modelled as a list because some
quantities have more than one compound form. Con-
sider the quantity joule that has two compound
forms:
("joule",
[Qmul (Name "metre", Name "newton");
Qmul (Name "watt", Name "sec")])
A system of kinds of quantities can be created by
building a table τ that maps names to their equivalent
compound forms.
τ = { ("meter_per_sec",
[Qdiv(Name "metre",Name "sec")]);
("acc",[Qdiv(Name "metre",
Qmul(Name "sec",Name "sec"))]);
("newton",
[Qmul(Name "kg",Name "acc")]);
("joule",
[Qmul (Name "metre", Name "newton");
Qmul (Name "watt",Name "sec")]);
("watt",[Qdiv(Name "joule",Name "sec")]);
("rad",[Qdiv(Name "metre",Name "metre"]);
("newton_metre",
[Qmul (Name "newton",Name "metre")]);
... }
MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering
136

A named quantity can be expanded through re-
peated lookups in the table. However, the table can
be cyclic so we need to be careful when accessing a
name not to end up in an infinite loop. While replac-
ing compound names one can also apply the simplifi-
cation rules of Figure 3 such that there may be many
more ways of representing a compound quantity than
just those in the table. For instance, a watt has 18
representations:
Name "watt"
⇒ Qdiv(Name "joule",Name "sec")
⇒ Qdiv(Qmul(Name "newton",Name "metre"),
Name "sec")
⇒ Qdiv(Qmul(Name "metre",Name "newton"),
Name "sec")
⇒ Qdiv(Qmul(Qmul (Name "kg",Name "metre"),
Qdiv(Name "metre",
Qmul(Name "sec",Name "sec"))),Name "sec")
.
.
.
Even though all the representations denote the same
UoM, there is a hierarchy. We therefore need a way
of capturing the representation that is closest to the
conceptual description of the quantity.
Proposition 5.3 (Most Abstract Named Quan-
tity). If we have two quant trees denoting the
same UoM, then the one with the shortest height,
min (height p, height q), will be the most abstract
named quantity, which we shall write as maq (p,q).
Proof. A named quant entity is the most abstract as
it describes explicitly what kind of quantity the entity
is, and is unique. A table lookup will replace a Name
by a compound quant with greater complexity, and a
greater height. Thus, the quant tree with the shortest
height will represent the most concise version of the
given entity. It will denote the quantity whose names
can be retrieved and simplified to the greatest number
of representations.
Definition 5.4 (Structural Equality of Named Quan-
tities). Two quantities, p and q are considered struc-
turally equal if they have the same representation in
terms of the algebraic data type quant. If the two
quantities are structurally equal then p , q holds:
Name n , Name m = (n = m)
Dimless , Dimless = true
Qmul(p
1
,q
1
) , Qmul( p
2
,q
2
) = (p
1
, p
2
) ∧ (q
1
, q
2
)
Qdiv(p
1
,q
1
) , Qdiv( p
2
,q
2
) = (p
1
, p
2
) ∧ (q
1
, q
2
)
, = false
Definition 5.5 (Equality of Named Quantities).
Given a system of kinds τ, two quantities p and q are
considered equal, if they share a representation. This
is achieved by expanding and simplifying p into the
set of forms {p
1
,.. ., p
n
} and q into the set of forms
{q
1
,.. ., q
m
}, performing the cartesian product of both
sets and comparing the pairs for structural equality,
p
i
, q
j
. If there is at least one identical pair then we
say that p =
τ
q holds.
For example:
Name "newton" =
τ
Qmul(Name "acc",Name "kg")
When we expand Name "newton", we have the follow-
ing forms:
Name "newton"
⇒ Qmul(Name "kg",Name "acc")
⇒ Qmul(Name "kg",Qdiv(Name "metre",
Qmul(Name "sec",Name "sec")))
⇒ Qmul(Qdiv(Name "metre",
Qmul(Name "sec",Name "sec")),Name "kg")
⇒ Qmul(Name "acc",Name "kg")
while expanding Qmul(Name "acc",Name "kg") cre-
ates the forms:
Qmul(Name "acc",Name "kg")
⇒ Qmul(Qdiv(Name "metre",
Qmul(Name "sec",Name "sec")),Name "kg")
⇒ Qmul(Name "kg",Qdiv(Name "metre",
Qmul(Name "sec",Name "sec")))
⇒ Qmul(Name "kg",Name "acc")
The cartesian product of both simplifications has at
least one identical pair, shown as underlined. Thus,
the two named quantities are equal (dimensionally).
This will yield the same result as expanding p to
create p
0
, expanding q to create q
0
, and performing
C p
0
∼
=
C q
0
.
Definition 5.6 (Homogeneity of Named Quantities).
Given a system of kinds τ, two quantities, p and q
are considered to represent the same named quan-
tity if they share the same name, or if they they are
equal. The operator p ≡
τ
q will return the most ab-
stract quant representation of two equal named quan-
tities. It is defined as follows:
Name n ≡
τ
Name m = Name n, if n = m
Name n ≡
τ
q = Name n, if Name n =
τ
q
p ≡
τ
Name m = Name m, if p =
τ
Name m
p ≡
τ
q = maq (p,q) if p =
τ
q
Using our previous example:
Name "newton" ≡
τ
Qmul(Name "acc",Name "kg")
will return Name "newton", as both quantities are
equal and a newton represents the most abstract rep-
resentation of the two. However, attempting to equate
work and watt will not succeed:
Name "joule" ≡
τ
/ Name "newton_metre"
as even though they are dimensionally equal, they do
not share the same name.
Torque not Work, Representing Kinds of Quantities
137

6 KIND OF QUANTITY
ANALYSIS
We are now in a position to define the arithmetic rules
for named quantities. We extend our definition of
udec to include names rather than dimensions:
udec ::= uv : float called string | ···
The rules of Figure 4 calculate the quant repre-
sentation of an arithmetic expression given an envi-
ronment γ mapping variables to their named quanti-
ties. The rules for multiplication and division build
compound quantities, while the rules for addition
and subtraction will check the homogeneity of both
operands. In other words, only quantities that have
the same dimensions can be added or subtracted. The
rules of K will return the most abstract quant repre-
sentation for the given expression.
To ensure the rules for addition and subtraction are
safe in terms of named quantity arithmetic, we need
to demonstrate that the ≡
τ
operator is both commuta-
tive and associative. This is necessary to show that the
KOQ of subexpressions are not subsequently overrid-
den when applying K .
Proposition 6.1 (Commutativity of ≡
τ
). For given
quantities p and q that represent equal quantities,
p ≡
τ
q yields the same result as q ≡
τ
p.
Proof. By case analysis of the function ≡
τ
, the first
case will hold as string equality is commutative, case
two and three can be reordered, while the min func-
tion is independent on the ordering of the arguments.
Hence, changing the order of the operands of the ho-
mogeneity operator does not change the result.
Proposition 6.2 (Associativity of ≡
τ
). For given
quantities p, q and r that represent equal quantities,
we need to show that (p ≡
τ
q) ≡
τ
r , p ≡
τ
(q ≡
τ
r).
Proof. By structural induction on quant entities that
are either named or unnamed, resulting in 8 cases
which all hold true.
The proof ensures that addition and subtraction main-
tains the property that named subexpressions must
represent the same entity for evaluation to succeed.
In essence, one always casts upwards from unnamed
entities to known named ones.
As homogeneity does not guarantee structural
equality we provide a second assignment operator that
allows one to match on a given compound quantity:
ustmt ::= uv := uexp
| uv := uexp of quant
Assignments either succeed or fail depending on
whether the expression derives a quantity that
matches the variable being assigned to. Thus, named
quantity rules for assignments will return a status tag:
type stmtstate = Succeed | Fail
The rules of Figure 5 allow the user to describe two
forms of assignment. In the first instance we check
that the expression can be assigned to the named
quantity variable, and in the second we perform an
additional check to make sure it has a specified com-
pound form.
Using our motivating example of wanting to prohibit
the addition of a torque value to that of a work value,
consider the following program segment:
begin
wk : float called "joule";
tq : float called "newton_metre"
in
wk := tq + wk
end
We can check the assignment as follows:
S [[wk:=tq+wk]]
{wk7→Name”joule”,tq7→Name”newton metre”}
.
⇒ Success,if Name "joule" ≡
τ
K [[tq+wk]]
{...}
Fail, otherwise
⇒ Success,if Name "joule" ≡
τ
(K [[tq]]
{...}
≡
τ
K [[wk]]
{...}
)
Fail, otherwise
⇒ Success,if Name "joule" ≡
τ
(Name "newton_metre" ≡
τ
Name "joule")
Fail, otherwise
⇒ Fail
Resulting in our system not allowing the assignment
to take place.
However, the analysis is not able to recognise in-
correct unnamed multiplication. Our solution is to
break the calculation into smaller parts and struc-
turally examine the quantity using the of keyword:
begin
n : float called "newton";
m : float called "metre";
tq : float called "newton_metre"
in
tq := m * n of Qmul(Name "newton",
Name "metre")
end
In this case, we will be checking:
K [[m*n]]
γ
, Qmul(Name "newton",Name "metre")
which will not succeed as the multiplication expected
is n*m. Finally, our system is able to manipulate di-
mensionless quantities whereas a tuple representation
treats all dimensionless quantities as identical.
MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering
138

K : uexp → (uv → quant) → quant
K [[uv]]
γ
= γ uv
K [[r ∗ uexp]]
γ
= K [[uexp]]
γ
K [[uexp
1
+ uexp
2
]]
γ
= K [[uexp
1
]]
γ
≡
τ
K [[uexp
2
]]
γ
K [[uexp
1
− uexp
2
]]
γ
= K [[uexp
1
]]
γ
≡
τ
K [[uexp
2
]]
γ
K [[uexp
1
∗ uexp
2
]]
γ
= Qmul (K [[uexp
1
]]
γ
,K [[uexp
2
]]
γ
)
K [[uexp
1
/ uexp
2
]]
γ
= Qdiv (K [[uexp
1
]]
γ
,K [[uexp
2
]]
γ
)
Figure 4: Named Quantity rules for Expressions.
S : ustmt → (uv → quant) → stmtstate
S [[uv := uexp]]
γ
= Succeed, if (γ uv) ≡
τ
K [[uexp]]
γ
= Fail, otherwise
S [[uv := uexp of q]]
γ
= Succeed, if (γ uv) ≡
τ
K [[uexp]]
γ
∧ K [[uexp]]
γ
, q
= Fail, otherwise
Figure 5: Named Quantity rules for Statements.
7 SUMMARY
Global and existential challenges, from infectious
diseases to environmental breakdown, require high-
quality data (Hanisch. et al., 2022). Ensuring soft-
ware systems support quantities explicitly is becom-
ing ever more important. While there are solutions
that allow UoM to be specified at both the model and
code level, adoption is challenging due to the annota-
tion burden and also the lack of perceived benefits.
We have presented a conceptual model for kinds
of quantities, and a means of ensuring safe expression
evaluation, that extends the traditional dimensional
analysis through the use of a recursive data type. Our
model allows compound units to be constructed, and
a table which enables named quantities to be mapped
to one or more compound forms. We provide ways of
comparing and constructing such quantities to ensure
that (1) only values of the same kind can be added
or subtracted; and (2) that multiplication and divi-
sion create new compound forms that represent the
addition or subtraction of their dimensions. As unit
variables are all assigned a named quantity, our cur-
rent system effectively combines dimensional analy-
sis with the naming scheme presented in (McKeever.,
2022), and formalises the quantity calculus presented
by Lodge (Lodge, 1888). It allows us to distinguish
between quantities that share the same UoM, even if
that UoM denotes a dimensionless entity, and subse-
quently apply conversions that only apply to that par-
ticular kind.
Hall (Hall, 2022; Hall, 2023) has developed a
more comprehensive notation for modeling quantities
that includes both scale and aspect. The notion of as-
pect is more general than our formulation of KOQ as
it can be used to denote measurable properties. How-
ever, the intention of Hall is to enable effective ex-
change of information, where aspect and scale tables
are stored in a central register, rather than the robust
evaluation of numeric expressions.
Our methodology can be implemented natively or
as a pluggable-type system for modeling or program-
ming languages. It allows for a richer static analysis
than dimensional analysis, and a complete definition
of arithmetic on kinds of quantities. It is less suited to
run-time checking due to the additional overhead of
supporting the quant data type. Quantity annotations
are initially costly for the developer but relatively sta-
ble to program evolution. Therefore scalability and
maintainability within potentially safety-critical code
is assured. Moreover, the cost of our KOQ annota-
tions is equivalent to most UoM annotations as they
are both written in terms of multiplication on base
units and then converted into internal representations.
Our naming scheme improves the scope of existing
dimensional analysis.
At present, our system lacks two essential fea-
tures. It needs to support synonyms that allow com-
pound quantities to have the same status as their
named counterpart. Synonyms would allow users to
replace particular compound forms by their names,
such as newton_metre, if required. More impor-
tantly, the addition of quantity variables to the quant
data type is pivotal in order to support polymorphic
functions, and also variables whose units are un-
known, or that represent values of intermediate cal-
Torque not Work, Representing Kinds of Quantities
139

culations. Thereby reducing the annotation burden.
Polymorphic quantity variables incur an additional
computational overhead as many quant forms will be
assignable for a given scope within a program.
REFERENCES
Allen, E., Chase, D., Luchangco, V., Maessen, J.-W., and
Steele, Jr., G. L. (2004). Object-oriented units of
measurement. In Proceedings of Object-oriented Pro-
gramming, Systems, Languages, and Applications,
OOPSLA ’04, pages 384–403, NY, USA. ACM.
Bennich-Bj
¨
orkman, O. and McKeever, S. (2018). The next
700 Unit of Measurement Checkers. In Proceedings
of Software Language Engineering, SLE 2018, page
121–132, NY, USA. Association for Computing Ma-
chinery.
Bureau International des Poids et Mesures (2019). SI
Brochure: The International System of Units (SI), 9th
Edition, Dimensions of Quantities. Last Accessed
19th May, 2022.
Chen, F., Rosu, G., and Venkatesan, R. P. (2003). Rule-
Based Analysis of Dimensional Safety. In RTA.
Cooper, J. and McKeever, S. (2008). A Model-Driven Ap-
proach to Automatic Conversion of Physical Units.
Software: Practice and Experience, 38(4):337–359.
Dreiheller, A., Mohr, B., and Moerschbacher, M. (1986).
Programming pascal with physical units. SIGPLAN
Notes, 21(12):114–123.
Foster, M. and Tregeagle, S. (2018). Physical-type correct-
ness in scientific python.
Fowler, M. (1997). Analysis Patterns: Reusable Objects
Models. Addison-Wesley Longman Publishing Co.,
Inc., Boston, MA, USA.
Gehani, N. (1977). Units of measure as a data attribute.
Computer Languages, 2(3):93 – 111.
Gibson, J. P. and M
´
ery, D. (2017). Explicit modelling of
physical measures: from Event-B to Java. In Interna-
tional Workshop on Handling IMPlicit and EXplicit
knowledge in formal system development.
Hall, B. (2022). The problem with ‘dimensionless quanti-
ties’. In Proceedings of the 10th International Confer-
ence on Model-Driven Engineering and Software De-
velopment - MODELSWARD,, pages 116–125, Portu-
gal. INSTICC, SciTePress.
Hall, B. (2023). Modelling expressions of physical quan-
tities. In Proceedings of the 15th International Joint
Conference on Knowledge Discovery, Knowledge En-
gineering and Knowledge Management IC3K, Portu-
gal. INSTICC, SciTePress.
Hanisch., R. et al. (2022). Stop squandering data: make
units of measurement machine-readable. Nature,
605:222–224.
Hayes, I. J. and Mahony, B. P. (1995). Using Units of Mea-
surement in Formal Specifications. Formal Aspects of
Computing, 7(3):329–347.
Hilfinger, P. N. (1988). An Ada Package for Dimen-
sional Analysis. ACM Trans. Program. Lang. Syst.,
10(2):189–203.
Hills M, Chen Feng, and Ros¸u Grigore (2012). A Rewriting
Logic Approach to Static Checking of Units of Mea-
surement in C. Electronic Notes in Theoretical Com-
puter Science, 290:51–67.
Jiang, L. and Su, Z. (2006). Osprey: A Practical Type Sys-
tem for Validating Dimensional Unit Correctness of
C Programs. In Proceedings of the 28th International
Conference on Software Engineering, ICSE ’06, pages
262–271, New York, NY, USA. ACM.
Karr, M. and Loveman, D. B. (1978). Incorporation of
Units into Programming Languages. Commun. ACM,
21(5):385–391.
Lodge, A. (1888). The Multiplication and Division of Con-
crete Quantities. General Report (Association for the
Improvement of Geometrical Teaching), 14:47–70.
Maxwell, J. C. (1873). A treatise on electricity and mag-
netism, volume 1. Oxford: Clarendon Press.
Mayerhofer, T., Wimmer, M., and Vallecillo, A. (2016).
Adding uncertainty and units to quantity types in soft-
ware models. In Software Language Engineering,
SLE 2016, pages 118–131, NY, USA. ACM.
McKeever., S. (2022). Discerning Quantities from Units
of Measurement. In Proceedings of the 10th Inter-
national Conference on Model-Driven Engineering
and Software Development - MODELSWARD,, pages
105–115, Portugal. INSTICC, SciTePress.
McKeever, S. (2023). Acknowledging implementation
trade-offs when developing with units of measure-
ment. In Pires, L. F., Hammoudi, S., and Seidewitz,
E., editors, Model-Driven Engineering and Software
Development, pages 25–47, Switzerland. Springer Na-
ture.
McKeever, S., Pac¸aci, G., and Bennich-Bj
¨
orkman, O.
(2019). Quantity Checking through Unit of Measure-
ment Libraries, Current Status and Future Directions.
In Model-Driven Engineering and Software Develop-
ment, MODELSWARD.
NIST (2015). International System of Units (SI): Base and
Derived. Last Accessed May 19th, 2022.
Salah, O.-A. and McKeever, S. (2020). Lack of Adop-
tion of Units of Measurement Libraries: Survey and
Anecdotes. In Proceedings of Software Engineering
in Practice, ICSE-SEIP ’20, NY, USA. ACM.
Stephenson, A., LaPiana, L., Mulville, D., Peter Rutledge,
F. B., Folta, D., Dukeman, G., Sackheim, R., and
Norvig, P. (1999). Mars Climate Orbiter Mishap In-
vestigation Board Phase 1 Report. Last Accessed on
May 19th, 2022.
Stevens, S. S. (1946). On the theory of scales of measure-
ment. Science, 103(2684):677–680.
Wilkinson, M. D., Dumontier, M., Aalbersberg, I. J., Apple-
ton, G., Axton, M., Baak, A., Blomberg, N., Boiten,
J.-W., da Silva Santos, L. B., Bourne, P. E., et al.
(2016). The fair guiding principles for scientific data
management and stewardship. Scientific data, 3.
Xiang, T., Luo, J. Y., and Dietl, W. (2020). Precise In-
ference of Expressive Units of Measurement Types.
Proc. ACM Program. Lang., 4(OOPSLA).
MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering
140