RE: Dimensions (was Re: Another Idea for Ada 20XX)

["Robert C. Leif, Ph.D." <rleif@rleif.com>]

From: Bob Leif
To: Richard Riehle, Nick Roberts et al.
I am trying to find a free version of ABBET. ABETT has an approach to
dimensions. The IEEE charges for a standard that they do not support and
ship it as paper. I believe that this work was primarily done by Bill
Whitaker.

1226.1-1993 IEEE ABBETa Trial-Use Standard for Common Ada Packages for A
Broad-Based Environment for Test (ABBETa) 1993

1993/ Softcover /104pp
  List Price:$76.00
  IEEE Member Price:$61.00
  ISBN 1-5593-7360-1
  IEEE Product No. SH16709-TBR
  Product Size: 8.5 x 11
  IEEE Standard No.:1226.1-1993
  Availability: Available to Ship

I hope that in Richard Riehle's generic approach, that the Metric_Number
into a record containing a into a Quantity and Units_Type. One approach is
to declare the types of the acceptable units in terms of their exponents.
Then addition-subtraction requires that the exponents match; and
multiplication-division only adds or subtracts the exponents. The input,
output, and checkpoints could be strongly typed to only include allowable
combinations of the individual Unit_Exponents and quantities. Assertions
could possibly be used for this checking. The hard part is to eliminate as
much as is prudent of the exponent run-time type checking of the Units.

Type Units_Exponents_Type is record
Current_Exponent      : Unit_Exponent_Type;
Luminescense_Exponent : Unit_Exponent_Type;
Temperature_Exponent  : Unit_Exponent_Type;
Mass_Exponent         : Unit_Exponent_Type;
Moles_Exponent        : Unit_Exponent_Type;
Length_Exponent       : Unit_Exponent_Type;
Time_Exponent         : Unit_Exponent_Type;
End Record;

I might note that I would like to be able to make the quantity base 10. One
can not easily do the equivalent of a decimal floating point type with type
decimal. It is simpler to use units that have not be scaled for internal
calculations. I wrote a package to use the correct prefix for output.

type Prefix_Type is
    (Yotta, Zetta, Exa, Peta, Tera, Giga, Mega, Kilo,
    Hecto, Deka, No_Exp, Deci, Centi,  Milli, Micro, Nano, Pico , Femto,
    Atto, Zepto, Yocto);

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Richard Riehle
Sent: Friday, December 07, 2001 7:53 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Dimensions (was Re: Another Idea for Ada 20XX)


Mark Lundquist wrote:

> "Richard Riehle" <richard@adaworks.com> wrote in message
> news:3C0EF0A0.9F42EDB4@adaworks.com...
>
> >
> >          package Metric_Number is
> >               type Metric_Type is private;
> >               -- export services for arithmetic on this type
> >               function "+"(L,  R : Metric_Type) return Metric_Type;
> >               -- more arithmetic and boolean functions
> >          private
> >               -- full definition for the Metric_Type;
> >               -- helper type to avoid recursion during implementation
> >          end Metric_Number;
>
> I have no idea what you're getting at with the "helper type to avoid
> recursion"... :-)

In implementing the infix operators for an experimental version of this
package, I found myself having to solve the problem of having the
full definition of the type as a numeric type itself.

> But in any case, the "good old-fashioned encapsulation"
> isn't enough (see below)...

> All these schemes that rely on hiding the representation have some serious
> weaknesses.  First of all, the public view is not scalar.  So
>
> (a) your type is not compatible with generics that take scalar formals --
> you are limited to formal private types; and

Granted.  One would be required to write one's own versions of the generics
and that would be a really bad idea.   Once again, I experimented with this
and ended up with some truly baroque code; workable but baroque.

> (b) you cannot declare subtypes with range constraints.

> (In my opinion (b) is by far the worse of these).

Actually, I think (a) is worse than (b).   One could define the package
as generic and include generic formal parameters for the range constraints.

> (c) it's way labor-intensive

In experimenting with this idea, I found that I could factor out some
properties

to make it less labor-intensive than it might seem to be at first glance.
Nevertheless,
you are correct that it is more labor intensive than the more
straigthforward
approach
orginally suggested.

> But the worst is still to come :-).  These schemes are quite brittle and
> unscalable, because:
>
> (d) you have to define all your visibly quasi-numeric operations on every
> combination of types for base and derived units, so you have a
> multiplicative explosion on your hands

In fact, I designed some generics to test this and found that the real
problems
are: 1)  no notion of zero,  2) difficult to determine the 'Last and 'First,
and

3) most other normally available attributes are not available.

> (e) , (f), and (g) from your posting.

I give you the points on those.

My suggestion, however, does work for some situations.  In experimenting
with
this
idea, I decided to export the appropriate mathematical functions after
instantiating
the generic elementary functions within the body for the abstract number.
I
agree
that the final numeric package is very specialized but it seems to have a
small
range of applicability for some circumstances.

Meanwhile, I am experimenting with other options that might permit a
solution
without new language features.   I will report on my findings if they are at
all

interesting.

Richard Riehle