Errors in Units and Dimensions

| SimCon Home | fpt Reference Manual Home |

Units and Dimensions

There are two possible approaches to the analysis of units and dimensions:

Static Analysis of Units and Dimensions

Suppose we have a statement in a program:

r = SQRT( x**2 + y**2 )

It is then possible, by static analysis, to infer that x, y and r have the same units and dimensions. If subsequently we find

a = x * y

we now know that a has dimensons of x**2. In this way, inferences may be propagated through the code. If two inferences conflict, the object to which they apply must be dimensionless. This can be reported. It may be untrue and if so, an error has occurred.

Note that this system of inference does not depend on any prior definition of the units of the variables. It is, of course, possible to provide users with a means to specify units, but it is not necessary to do so. For large programs the labour involved would be prohibitive.

There are three obvious complications. The first is that the same variable may be used to hold data for very different objects. This is overcome by a "life" analysis. Each assignment of a variable begins a life. If the program flow is such that two different lives can reach the left-hand-side of the same expression, the lives are the same. They must have the same units and dimensions. If this can never occur, the lives are different and no inference may be propagated between them. In the analysis, the symbols are replaced by symbol lives. The issue is explored in detail in Farrimond B.T and Collins J. 2007, "Dimensional Inference Using Symbol Lives", Paper presented at the 2007 International Conference: Software Engineering Theory and Practice, Orlando Florida

The second complication is that arrays may not be homogenous. One of the dimensions of a single array may contain several different measures of, for example, a medical patient, and these may have different units and dimensions. This is less common in modern code because users will use components of derived types for the different quantities, but it will happen.

The third complication is the use of sub-programs. Some of these will be generic mathematical functions which may be applied to different quantities. Many of the inferences here will provide relationships between the units and dimensions of the arguments and interface variables.

Dynamic, Run-time, Analysis

Suppose that we replace every real and complex object in a program by an object of a derived type, an emulated real or complex number. Let every emulated number have a component which is the index of its units and dimensions. As the program runs, the relationships between these units and dimensions components is inferred. Whenever an inference requires that a quantity is dimensionless, a report is recorded.

This procedure has the advantages that no assumption need be made about array dimensions. Every single element of an array is tagged separately. There is no problem in handling sub-programs. The specific object passed into a sub-program is tracked. The instrumented code will run very slowly, but hopefully we do not need to run very many times.

Progress in fpt

Progress in the first, static, approach has been:

Progress in the dynamic approach has been:

Copyright ©1995 to 2017 Software Validation Ltd. All rights reserved.