Re: Dimensionality Checking (Ada 20XX)

["Nick Roberts" <nickroberts@adaos.worldonline.co.uk>]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:upu5ln22l.fsf@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.

This example, in fact, actually illustrates my point, I believe.

My point is that, because dimension checking could not be performed
statically inside the function F, and it would probably be unacceptably slow
to implement it dynamically, you lose nothing by not having the dimension
checking. Since you use radians throughout inside the function F, internal
unit conversion (scaling) is also not required.

Nevertheless, you get both dimension checking and unit conversion outside
function F. All non-unit-specific scalar types will be assumed to have a
scaling factor of 1.0. So, e.g.:


   type Joint_Angle is delta 0.001 range ... unit Angular_Degree;

   -- Angular_Degree has scaling factor pi/180

   function F (A: Float) return Float; -- in radians

   A1, A2: Joint_Angle;

   ...

   Read(Detector(D),A1);
   A2 := Joint_Angle( F( Float(A1) ) );


The conversion Float(A1) will multiply A1 by the scaling factor pi/180, thus
rendering it in radians, and the conversion Joint_Angle( ... ) will divide
the result by pi/180, hence converting it back into degrees. A1 and A2 will
both be specifically dimensionless (their dimensions are all 0), and for
calculations between them and other unit-specific (fixed point) types
dimension checking will be performed.

> 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.

But nothing prevents a compiler from implementing fixed point
operations/representations using the hardware's floating point unit/format.
(Am I wrong?)

> > 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.

I am suggesting that the proposed facility is designed so that most or all
checks could, in practice, be performed at compile-time. I suspect the
facility would have to be specified in the standard in terms of dynamic
semantics (because making it formally static would be just too nasty), but
this wouldn't prevent compilers from doing (most) things at compile-time in
practice.

Compilers should (be recommended to) provide a three-way switch, I suppose:
dimension checking off; dimension checking on (compile time if possible,
otherwise at run time); dimension checking only at compile time (run-time
checking simply removed, maybe with a warning).

> > 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.

Angles are dimensionless, as you correctly point out, but so is X (it is a
ratio). Hence, suppose we have a declaration such as this:


   generic
      type Ratio is delta <>;
      type Angle is delta <>;

   function Sin (X: in Ratio) return Angle;


Provided the types Ratio and Angle were both dimensionless, the internal
computations would all be dimensionless throughout (X**N is dimensionless,
for all N, if X is dimensionless). Hence the dimension checking would work
perfectly in this case (if either Ratio or Angle were not dimensionless, the
compiler should squeal). I believe it is likely a compiler would be able to
fully unroll the computation loop, and so do all the necessary checking at
compile-time. The instantiator of the function should choose a type for
Ratio which has a scaling factor of 1.0, and a type for Angle which
represents radians (and so also has a scaling factor of 1.0). So, shudder
not!

> 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.

The whole idea of what is being proposed is to do away with all that (or
much of it).

>
> --
> -- Stephe

--
Best wishes,
Nick Roberts


PS: I have quoted at length, as I thought it necessary. Hope nobody minds.