Re: Dimensions (was: What's the difference between...)

Re: Dimensions (was: What's the difference between...)

[enterpoop.mit.edu!hri.com!noc.near.net!inmet!spock!stt]

In article <1993Feb13.232516.5229@seas.gwu.edu> 
  mfeldman@seas.gwu.edu (Michael Feldman) writes:

>In article <1993Feb13.191810.4452@inmet.camb.inmet.com> 
  stt@spock.camb.inmet.com (Tucker Taft) writes:

>> . . . Explicit type conversion is required (of course
>>that's a bit annoying for multiplication -- we never did get
>>around to putting full support for "units" into Ada).
>>
>You just hit a hot button of mine, Tucker. Explicit type conversion indeed
>will work for multiplication, so that D := R * T is OK. But it's
>worse than that: you have to hide the predefined multiplication.
>Otherwise if D, D1, and D2 are all Distance, D := D1 * D2 is legal.
>This is a disaster from a physical point of view.
> . . .
>"Never did get around to putting it in" was IMHO a mistake. Programming
>languages (should) provide a vocabulary for problem solving. Many programs
>in Ada's intended domain are simulations of physical phenomena that would
>benefit greatly from the ease of expression that dimensioned quantities
>would provide, withot the runtime overhead of the variant record solution.
>How seriously was it considered?

We tried various approaches.  One was to require support
for static calculations involving discriminants, plus an ability
to define assertions associated with parameters.  We even considered
allowing discriminants on numeric types, but could never work
out all of the details.  We also proposed "cheap" inline functions
whose body was a single expression, sort of like the statement
functions of Fortran.  These were *required* to be expanded
at compile-time, with full static calculation power brought
to bear.

Ultimately, it seemed like we were getting too much mechanism,
without sufficient proof that the solution would represent
a net productivity improvement for the "average" programmer.

The Ada-inspired hardware description language VHDL has an 
elegant "units" mechanism, but it is a major syntactic add-on.
We always hoped we could come up with some more general mechanism
which would allow someone to build up a statically-checked
"units" mechanism, without actually building it into the syntax
of the language.  None of our attempts were entirely satisfactory.

With the GNU NYU Ada9X Translator (GNAT) coming, we may have an excellent
test-bed for investigating tricky language design issues like
this one.  If someone comes up with a neat way of solving the
"units" problem with an elegant extension using GNAT, then
it could be ready for incorporation into the standard next time.
That's how other languages work, and it would be refreshing to
see Ada 9X be a bit more dynamic in communities where absolute
standardization is not such a huge requirement.

By the way, one idea that might be worth pursuing is to
define some subtype/object-specific attributes that represent units.
In Ada 9X, implementation may define their own attributes (that
was allowed in Ada 83 too), and then allow users to define their
values via the attribute-definition clause (a generalization of the
Ada 83 "length" clause).  You could then have a pragma which
would statically enforce units checking.  Such an approach would
be a "legal" extension of Ada 9X, and could even be 
de-facto-standardized through the Uniformity Rapporteur Group (URG)
of WG9.

For example, the following is "legal" Ada 9X provided the
implementation supports an appropriate implementation-defined 
attribute "Units" (of course it is not very portable, unless
such an attribute becomes widely supported):

     subtype Distance is Float;
     for Distance'Units use (1,0,0);  -- attribute-definition clause

     subtype Mass is Float;
     for Mass'Units use (0,1,0);

     subtype Time is Float;
     for Time'Units use (0,0,1);

     cm : constant Distance := 1.0;
     g : constant Mass := 1.0;
     s : constant Time := 1.0;
     pragma Check_Units;
  . . . 

     X : Distance := 1.0 * cm;  -- Compiler checks units
     Y : Float := X * X; -- Compiler determines Y'Units = (2,0,0)
     Z : Distance := Y / X; -- Compiler verifies units matching
     Q : Distance := Y / Y; -- Compile-time error -- "units mismatch"

     subtype Velocity is Float;
     for Velocity'Units use Distance'Units/Time'Units;
        -- This presumes that X'Units is of a type with appropriate
        -- operators, that have been made (use) visible.

     subtype Energy is Float;
     for Energy'Units use Mass'Units * Velocity'Units**2;

     E : Energy;
     function Kinetic_Energy(M : Mass; V : Velocity) return Energy is
     begin
         return 0.5 * M * V**2;    -- Compiler checks units
     end Kinetic_Energy;
  begin

     Y := 3.0 * cm**2;  -- Compiler checks units again
     E := Kinetic_Energy(2.0 * g, 7.0 * cm/s);  
       -- Compiler checks units on parameter passing and assignment

Actually, that doesn't look too bad.  Since it is all "legal"
Ada 9X, it is possible that some implementor (or GNAT enhancer)
could add it to a validated compiler as an experiment.  If
something like this becomes popular, then perhaps the URG might
later "bless" it somehow.

A slightly less elegant solution would use pragmas only.
(e.g. "pragma Units(Length, 1, 0, 0);").  This would have
the advantage that a compiler could just ignore all pragma Units
and the program would still be legal, even though less static checking
would have been performed.  Hence, the program would be more
portable.  Of course, the above program could be made portable
by simply deleting all of the attribute-definition clauses
for 'Units (presuming those are the only places the 'Units attribute
is referenced), once the program had been debugged.

In any case, this process of experimentation and then later 
de-facto-standardization is somewhat similar to the way that various 
packages supporting "unsigned" integers appeared for Ada 83.  Initial 
users had to live with the nonportability, but eventually the ARG 
and the URG got interested enough to begin work on defining 
a de-facto standard.

>Mike Feldman

S. Tucker Taft    stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge,  MA  02138

Re: Dimensions (was: What's the difference between...)

[Jorge Luis Diaz-Herrera]

In article <1993Feb15.151209.7531@inmet.camb.inmet.com>, stt@spock.camb.inmet.c
om (Tucker Taft) writes:
|> In article <1993Feb13.232516.5229@seas.gwu.edu> 
|>   mfeldman@seas.gwu.edu (Michael Feldman) writes:
|> 
|> >In article <1993Feb13.191810.4452@inmet.camb.inmet.com> 
|>   stt@spock.camb.inmet.com (Tucker Taft) writes:
|> 
|> >> . . . Explicit type conversion is required (of course
|> . . .
|> >Mike Feldman
|> 
|> S. Tucker Taft    stt@inmet.com
|> Ada 9X Mapping/Revision Team
|> Intermetrics, Inc.
|> Cambridge,  MA  02138

"Dimensions as types have no place in Ada because they are @definable in Ada
without extra language features" 
	Paul N. Hilfinger, UC Berkeley 
	"An Ada package for dimensional analysis" (AD-A169-223)

This report contains a nice description of the problem and examples.
jld-h
--..--

Re: Dimensions (was: What's the difference between...)

[cis.ohio-state.edu!news.sei.cmu.edu!ae]

Mike Feldman commented on support for dimensional analysis and Tucker
Taft replied.

I add: As I remember, dimensional analysis was solvable quite elegantly
in Red.

Art Evans

Re: Dimensions (was: What's the difference between...)

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!agate]

In article <1993Feb15.151209.7531@inmet.camb.inmet.com>,
stt@spock.camb.inmet.com (Tucker Taft) replies to:

In article <1993Feb13.232516.5229@seas.gwu.edu> 
   mfeldman@seas.gwu.edu (Michael Feldman) comments on support for
dimensional types:

> [discussion deleted}

One aspect of this problem that hasn't been mentioned and may greatly
affect the 
efficacy of some of the proposed solutions is that integer exponents aren't
enough!  At least some problems require that halves be expressable.

One of the first subprograms that I attempted to write (after the standard
one week "Intro to Ada" course) was Gauss's solution to the orbital
intercept problem.  In orbital mechanics,  the constant 1/SQRT(GM) occurs
fairly frequently.   The units of this quantity are sec/(km**3/2) !!  The
resulting package to define all the permutations of "unitary operations"
was so daunting that I reversed myself on advocating this type of checking.
 It requires support for SQRT in addition to "+", "-", "*", and "/".  I
commend the Gaussian intercept solution as a test case to those proposing
solutions for dimensional types.