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:u7krtl5u8.fsf@gsfc.nasa.gov...
> 
> > F returns a position vector (x, y, z), in meters. So I'm not clear
> > what this should be.
> 
> Something like:
> 
> 
>    V := F(...);
>    A := ( Joint_Angle(V.X), Joint_Angle(V.Y), Joint_Angle(V.Z) );
> 
> 
> That's all.

Well, V is _not_ a vector of "angles", it is a vector of "Cartesian
positions". I guess you should do:

V := F (...);
M := Cartesian_Position (V);

Where Cartesian_Position does some scaling. 

But I repeat, I see no advantage here. I can easily and efficiently
define F to return a vector of meters.

> > as someone else pointed out, these three choices are orthogonal.
> 
> I'm not arguing about that. It would be nice to provide the facility for
> floating point numbers, I don't deny it. I just think it would be hard,
> that's all. But if it's needed, then it's needed.

Huh? Why would it be harder for float than fixed?

> > 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?
> 
> This is correct (you'll get a lot of types, one for each unit, which
> encompases a dimensionality and a scaling factor).
> 
> > 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.
> 
> Many (most?) of the required inter-type operations will be provided as
> predefined operations. This in itself is not a big change, since Ada 95
> already provides it!

Um, no. In Ada 95, I can do:

type Meters is digits ...;
type Seconds is digits ...;
type Meters_Per_Second is digits ...;

Ada 95 does _not_ define the following, which is needed:

function "/" (Left : in Meters; Right in Seconds) return
Meters_Per_Second;

Ada 95 _does_ define the following, which is wrong:

function "*" (Left, Right : in Meters) return Meters;


Now, if you are defining a new language feature, it would be really
good to get this right. Maybe something like:

type Meters is units digits ...;
type Seconds is units digits ...;
type Meters_Per_Second is units compose Meters / Seconds;

Then the compiler will _not_ generate multiply and divide operations
for "units" types, but _will_ automatically generate the appropriate
ones for "units compose" types.

I just made this up, so there's probably lots of holes in it.

> > > 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?
> 
> See other posts in this thread. X must be 'dimensionless' in the sense of
> having dimensions of all 0.

If X is to be passed to a transcendental function, yes, it must be
dimensionless. But that's _not_ what I'm doing with X! I am _defining_
the position of the end of a robot arm to be V == (x, y, z). By
_definition_, x, y, and z are in meters. As such, it is _meaningless_
to pass x to a transcendental function. That's fine; the mathematical
meaninglessness simply reflects a physical meaninglessness. There is
no meaninful physical operation that corresponds to Sin (meters).

-- 
-- Stephe