Re: Dimensionality Checking (Ada 20XX)

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> It's easier to demonstrate than to actually explain. Show me a piece of
> (genuine) Ada code that uses a floating point type to hold values that would
> be usefully made unit-specific, and I'll show you how they certainly could,
> and probably should, be held by a fixed point type instead.

http://users.erols.com/leakstan/Stephe/Ada/Sal_Packages/index.htm,
file sal-gen_math-gen_dof_6.ads

This is part of the math library I used to implement robotics control
systems and satellite simulators.

The core type is a 6 dimensional "pose", consisting of a 3 dimensional
position vector (x, y, z) and a 3 dimensional rotation, represented by
a unit quaternion. The position vector should be in meters (or feet,
if you are a barbarian :), the quaternion is unitless.

For robotics, the position is computed by the forward kinematics
function; V = F (theta), where V is the (x, y, z) vector, and 'theta'
is the vector of joint angles.

The joint angles are properly represented by fixed point numbers,
since they have constant error. A joint angle is measured by hardware
with a fixed precision; the value is known to plus or minus 0.001
radians, for example. When you run that thru the function F, which
contains Sin, Cos, multiply, and add, you get a relative error; 'x' is
known to 1 percent. Thus x is properly represented by floating point.

More practically, most computers used for robotics and satellite
simulations support fast floating point, often faster and more precise
than integer. So there is no reason to use fixed point.

> I'm not actually trying to argue that floating point types should
> never be used for non-unitless quantities. 

Good

> All I'm suggesting is that there is no practical need to add the
> unit-specific facility to floating point types. 

I disagree. I started one, and gave up when I hit the combinatorial
explosion others have alluded to. It would be useful to find bugs
during unit test. 

The most practical implementation I've seen stores a count of the
order of the three basic dimensions (mass, length, time) with each
value. Multiply and divide add and subtract those counts; addition and
assignment check them. This is good for finding bugs, but it is too
much overhead for bug-free real-time execution.

> Furthermore, I think it would be horribly painful trying to do so
> (consider Ada.Numerics).

It is horribly painful, but not because of Ada.Numerics.

It is simply wrong to try to define units for trig and exponential
functions. Remember the Taylor expansion for Sin:

Sin (x) = x - 1/6 x**3 ...

If x has dimensions of meters (shudder :), then what are the
dimensions of Sin (x)? This is why angles must be dimensionless, as
radians are.

If you don't take the stored counts approach, you have zillions of
routines to write just sticking with SI units (meters * time,
meters**2 * time, (meters**2 * kg) * time**2, etc). Adding unit
conversion makes it far worse.

-- 
-- Stephe