Re: Dimensionality Checking (Ada 20XX)

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

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

> "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:
> > <snip>
> > 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.
> > <snip>
> 
> 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. 

Well, I would do unit testing of F with dimension checking "turned
on". The equations in F are dimensionally correct, just complex.

> Since you use radians throughout inside the function F, internal
> unit conversion (scaling) is also not required.

Not true; lengths of the robot arm parts in F are in meters, the
result position vector is meters.

> 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

Just a nit; I've learned to think in radians, so Degrees is not
needed. Actually, I require straight SI units, so scaling is _never_
required in my system, except to get from raw hardware readings to SI.

>    function F (A: Float) return Float; -- in radians
> 
>    A1, A2: Joint_Angle;
> 
>    ...
> 
>    Read(Detector(D),A1);
>    A2 := Joint_Angle( F( Float(A1) ) );

F returns a position vector (x, y, z), in meters. So I'm not clear
what this should be.

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

Well, if you want to have non-SI units, a standard scaling convention
would be useful. And you could have some types do dimension checking,
and others not. But tying that to the fixed-point/floating point
choice is not necessary; as someone else pointed out, these three
choices are orthogonal.

> > 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?)

That is true. Yet another reason to keep the choices orthogonal.

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

Ah. I haven't been paying attention to this thread; I missed that you
are talking about a language extension.

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

This sounds nice. I still think you'll get an explosion of types, like
Meters, Meters_Squared, Meters_Per_Second, Meters_Per_Second_Squared.
How else do you specify the dimensions? So you'll still have to define
all the inter-type operations. I suppose you define some sort of
automatic operator generation for this, but that's an even bigger change.

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

Well, you said you would convince me of that, but I don't see any
argument for making X a ratio. I defined it as meters. I could pick
some arbitrary length (say the length of the robot forearm), and
define all other lengths in terms of that. But that would be horribly
confusing! What's wrong with meters for X?

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

How is this different from Ada.Numerics.Generic_Elementary_Functions?
You can't apply scaling, since you have different powers of X involved.

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

If everything is dimensionless, what checking are you talking about?

> 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 they have scaling of other than 1.0, it's just plain wrong (and the
compiler should complain). And if it is 1.0, you have not added any
functionality over Ada.Numerics.Generic_Elementary_Functions. So I
still shudder :).

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

Well, yes, but I don't see how you accomplish that. You still need one
type per dimensionality, and one type per scaling. 

-- 
-- Stephe