Another Idea for Ada 20XX

Another Idea for Ada 20XX

[James Rogers]

In scientific terms a measurement is done in terms of some unit.
For instance, distance is in meters, microns, feet or furlongs.
Speed is then calculated as a distance per unit time. Acceleration
is the second derivative of speed.

I would like to have this notion of measurement units and their
relationships supported in a language. This would require the language
to perform unit analysis while performing static or run-time 
calculations. Because of the added computational overhead, there must
be a way to choose or reject unit analysis for defined types.

Perhaps a new keyword for unit-analyzed types could be introduced,
along the lines of the keyword "tagged" added to Ada 95. A unit-
analyzed type would carry its own unit description tag to 
facilitate unit analysis. Any numeric type without such a tag
would not be subject to unit analysis.

Possible declarative syntax might be:

type Meters is unit range (0.0..1.0E380);
type Hours is unit range (0.0..9.99E30);
type Speed is unit(Meters / Hours);

The advantage for the software developer is in the usage:

Vehicle_Speed : Speed;
Track_Distance : Meters;
Lap_Time : Hours;

Speed := Track_Distance / Lap_Time;

This approach would allow the appropriate mixing of data types, which
is currently forbidden by Ada, in a meaningful and correct manner.

I know this proposal places a heavy burden upon compiler writers.
I also suspect it would be very useful for ensuring the correctness
of programs, particularly in embedded systems. 

Note that a lot of the unit analysis could be performed statically.
This would allow minimal performance penalty at run time.

Jim Rogers
Colorado Springs, Colorado USA

Re: Another Idea for Ada 20XX

[Preben Randhol]

On Sun, 02 Dec 2001 16:01:22 GMT, James Rogers wrote:
> type Meters is unit range (0.0..1.0E380);
> type Hours is unit range (0.0..9.99E30);
> type Speed is unit(Meters / Hours);

Shouldn't these also be allowed to be negative?

Preben
-- 
 ()   Join the worldwide campaign to protect fundamental human rights.
'||}
{||'                                           http://www.amnesty.org/

Re: Another Idea for Ada 20XX

[Gautier Write-only-address]

>From: James Rogers

>In scientific terms a measurement is done in terms of some unit.
>For instance, distance is in meters, microns, feet or furlongs.
...
>calculations. Because of the added computational overhead, there must
>be a way to choose or reject unit analysis for defined types.

The overhead is not only computational, I fear: if programmers
are forced to specify the unit of each of their variables
with a possible physical meaning, they just won't program in
Ada...

Where is the problem, indeed ? Mixing feets and meters in a
program ? This is more a political or cultural problem, I
wouldn't wish to complicate Ada with it...

____________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/index.htm#Ada

NB: Do not answer to sender address, visit the Web site!


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Re: Another Idea for Ada 20XX

[Patrick Hohmeyer]

James Rogers wrote :

> In scientific terms a measurement is done in terms of some unit.
> For instance, distance is in meters, microns, feet or furlongs.
> Speed is then calculated as a distance per unit time. Acceleration
> is the second derivative of speed.

Acceleration is the second derivative of *distance*. ;-)

> The advantage for the software developer is in the usage:
> 
> Vehicle_Speed : Speed;
> Track_Distance : Meters;
> Lap_Time : Hours;
> 
> Speed := Track_Distance / Lap_Time;
> 
> This approach would allow the appropriate mixing of data types, which
> is currently forbidden by Ada, in a meaningful and correct manner.
> 

Hmm, this can very easly be achived with overloading of "/" :

function "/" (Dist : Meters; Time : Hours) return Speed is
--...

And I have a huge problem with the name of the type Speed.
Speed is not a unit, but an concept.

Would be more interesting :

type Distance is basic concept with basic unit Meters;
type Time is basic concept with basic unit Seconds;
type Speed is concept (Distance / Time);

Vehicle_Speed : Speed; -- ok
Track_Distance1 : Meters; -- ok
Track_Distance2 : Meters := 12.5; -- ok
Lap_Time1 : Time; -- ok
Lap_Time2 : Time := Seconds(34.3); -- ok

Lap_Time3 : Time := 34.3; 
-- 2 possibles reactions :
-- 1. won't compile as the unit isn't specified !!! (my favor)
-- 2. uses the basic unit for the concept (Seconds)
--     (but generates a compiler warning)

Vehicle_Speed := Track_Distance1 / Lap_Time1; --ok

Internally a concept type would be something as
record
  Value : Double;
  Unit : Unit_type;
end record;

Unit somehow describes how we can transform the value
into a value in the basic units. (an access to a function?)
and vice-versa.

The great part are unit extentions :

type Hours is Time unit 3600 Seconds;

S : Seconds := 3954.3;
H : Hours := S;

And the compiler would automagicly put 3954.3 / 3600 into H.
As would the cast Hours(S) return 3954.3 / 3600;

Especially for Space programs between US and Europe this would
be a *huge* benefit.
Just declare :

type Inchs is Distance unit x Meters;

and the compiler will do all unit conversions for you.

And of course :
type Temperature is basic concept with basic unit Kelvin;
type Celsius is Temperature unit 1 Kelvin + 273.15;

And a non-basic concept : 
type Mass is basic concept with basic unit Kilogram;
type Acceleration is concept Speed / Time;
type Force is concept Mass * Acceleration;

type Newton is Force unit 1 (Kilogram * Meters * Seconds**(-2)); 
(Note that :
  type Newton is Force unit 1
  (Kilogram * Meters * Seconds**(-1) * Hours**(-1));
would also be syntaxly correct, you can mix 2 time units in a
composed unit.)

I think that this could be fun, but may be to complicated to
implement and if you really need it, can already be done with
a record and an access to fonction for the unit type,
and a lot of overloaded functions.

But what do you think ?

-- 
Patrick Hohmeyer

Re: Another Idea for Ada 20XX

[Gautier Write-only-address]

>Especially for Space programs between US and Europe this would
>be a *huge* benefit.
>Just declare :
>
>type Inchs is Distance unit x Meters;
>
>and the compiler will do all unit conversions for you.
>
>And of course :
>type Temperature is basic concept with basic unit Kelvin;
>type Celsius is Temperature unit 1 Kelvin + 273.15;

Why not - but the more subtle you design the unit management,
the more subtle the mistakes will be...
The choice of *one* unit system should be made *before* any
programming, otherwise you don't get out of problems.
And in some applications (scientific programming) you can forget
these amusements about units, there are just too many variables.
____________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/index.htm#Ada

NB: Do not answer to sender address, visit the Web site!

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Re: Another Idea for Ada 20XX

[Lutz Donnerhacke]

* James Rogers wrote:
>In scientific terms a measurement is done in terms of some unit.
>For instance, distance is in meters, microns, feet or furlongs.
>Speed is then calculated as a distance per unit time. Acceleration
>is the second derivative of speed.

>Note that a lot of the unit analysis could be performed statically.
>This would allow minimal performance penalty at run time.

http://www.iks-jena.de/mitarb/lutz/ada/units/

I�m going to provide automatic unit optimization. Please stay tuned.

Re: Another Idea for Ada 20XX

[James Rogers]

Preben Randhol wrote:
> 
> On Sun, 02 Dec 2001 16:01:22 GMT, James Rogers wrote:
> > type Meters is unit range (0.0..1.0E380);
> > type Hours is unit range (0.0..9.99E30);
> > type Speed is unit(Meters / Hours);
> 
> Shouldn't these also be allowed to be negative?

Under certain circumstances units do make sense as negative values.

Sometimes they do not.

I simply tried to supply a possible syntax example, not all possible
examples.

Jim Rogers
Colorado Springs, Colorado USA

Re: Another Idea for Ada 20XX

[James Rogers]

Gautier Write-only-address wrote:
> 
> >From: James Rogers
> 
> >In scientific terms a measurement is done in terms of some unit.
> >For instance, distance is in meters, microns, feet or furlongs.
> ...
> >calculations. Because of the added computational overhead, there must
> >be a way to choose or reject unit analysis for defined types.
> 
> The overhead is not only computational, I fear: if programmers
> are forced to specify the unit of each of their variables
> with a possible physical meaning, they just won't program in
> Ada...
> 
> Where is the problem, indeed ? Mixing feets and meters in a
> program ? This is more a political or cultural problem, I
> wouldn't wish to complicate Ada with it...

The problem is not only political and cultural.

Take the situation of the NASA Mars probe that crashed because
of an improper mixture of British and Metric distance units.

If the programming language used had provided the ability to
perform unit analysis the mistake would have been caught by
the compiler.

What I am trying to express is an extension of strong typing.
This extension would allow specified mixing of types. The current
Ada model places a strong barrier between all type mixes. The
use of units will allow you to specify how and where certain
types can be mixed. I personally find the units idea easier to
understand than simply applying type coercion at various places
in code. The concept of units also allows careful checking by the
compiler, and secondary analysis (outside a compiler) of the code
to ensure algorithmic correctness.

Jim Rogers
Colorado Springs, Colorado USA

Re: Another Idea for Ada 20XX

[Patrick Hohmeyer]

And Lutz Donnerhacke has spoken :

> * James Rogers wrote:
> >In scientific terms a measurement is done in terms of some unit.
> >For instance, distance is in meters, microns, feet or furlongs.
> >Speed is then calculated as a distance per unit time. Acceleration
> >is the second derivative of speed.
> 
> >Note that a lot of the unit analysis could be performed statically.
> >This would allow minimal performance penalty at run time.
> 
> http://www.iks-jena.de/mitarb/lutz/ada/units/
> 
> I�m going to provide automatic unit optimization. Please stay tuned.

Interesting approach, but at first glance I dont see how 
you'll solve the Celsius = Kelvin + 273.15 problem.

This solution seams only to work with units where zero in one unit
equals zero in the other as well.

I think an approach :

type Conversion is access function(value : Accuracy) return Accuracy;

type Unit_Description is record
      toSI : Conversion;
      fromSI : Conversion;
      -- some text ???
end record;

type Quantity is tagged record
      value : Accuracy;
      Unit : Unit_Description;
end record;

offers more flexibility than your idea of a Dimension.

-- 
Patrick Hohmeyer

RE: Another Idea for Ada 20XX

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: James Rogers et al.
A package to do this, A Broad-Based Environment for Test (ABBET), was
created by William A Whitaker, Ph.D. There is also a collection of packages
by Dmitry A. Kazakov.

I believe that it might be possible to have either the compiler optimize
away the unit checking for objects where the units are constant and/or
create a class of assertions that are only checked at compile time. Fresh
ideas on this subject should have a high priority for Ada 200X.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of James Rogers
Sent: Sunday, December 02, 2001 8:01 AM
To: comp.lang.ada@ada.eu.org
Subject: Another Idea for Ada 20XX


In scientific terms a measurement is done in terms of some unit.
For instance, distance is in meters, microns, feet or furlongs.
Speed is then calculated as a distance per unit time. Acceleration
is the second derivative of speed.

I would like to have this notion of measurement units and their
relationships supported in a language. This would require the language
to perform unit analysis while performing static or run-time
calculations. Because of the added computational overhead, there must
be a way to choose or reject unit analysis for defined types.

Perhaps a new keyword for unit-analyzed types could be introduced,
along the lines of the keyword "tagged" added to Ada 95. A unit-
analyzed type would carry its own unit description tag to
facilitate unit analysis. Any numeric type without such a tag
would not be subject to unit analysis.

Possible declarative syntax might be:

type Meters is unit range (0.0..1.0E380);
type Hours is unit range (0.0..9.99E30);
type Speed is unit(Meters / Hours);

The advantage for the software developer is in the usage:

Vehicle_Speed : Speed;
Track_Distance : Meters;
Lap_Time : Hours;

Speed := Track_Distance / Lap_Time;

This approach would allow the appropriate mixing of data types, which
is currently forbidden by Ada, in a meaningful and correct manner.

I know this proposal places a heavy burden upon compiler writers.
I also suspect it would be very useful for ensuring the correctness
of programs, particularly in embedded systems.

Note that a lot of the unit analysis could be performed statically.
This would allow minimal performance penalty at run time.

Jim Rogers
Colorado Springs, Colorado USA

Re: Another Idea for Ada 20XX

[Robert Dewar]

James Rogers <jimmaureenrogers@worldnet.att.net> wrote in message news:<3C0A5054.E74A82E7@worldnet.att.net>...
> I would like to have this notion of measurement units and > their relationships supported in a language.

James, if you are interested in proposing something here,
you need first to do some homework. This subject has been
*extensively* discussed in the past, including the analysis
and discussion of several different schemes for getting units analysis
of the kind you are proposing within the
current language.

I suggest you study these existing schemes first, to see
whether

a) they meet your requirements
b) if they do not, exactly why not

There have also been proposals for language extensions
that have been thoroughly discussed in the past, and you
should dig up these discussions.

I realize that there are many new players on CLA who don't
necesarily have the history here, but this is definitely an area where
it makes no sense to start another discussion
from scratch.

Re: Another Idea for Ada 20XX

[James Rogers]

Robert Dewar wrote:
> 
> James, if you are interested in proposing something here,
> you need first to do some homework. This subject has been
> *extensively* discussed in the past, including the analysis
> and discussion of several different schemes for getting units analysis
> of the kind you are proposing within the
> current language.

Thank you for the notice. I hoped that someone had already done work
in this area. 

I will look into the histories as well as current language proposals.

Again, thank you.

> I realize that there are many new players on CLA who don't
> necesarily have the history here, but this is definitely an area where
> it makes no sense to start another discussion
> from scratch.

Jim Rogers
Colorado Springs, Colorado USA

Re: Another Idea for Ada 20XX

[Wilhelm Spickermann]

--On Sunday, December 02, 2001 18:49:24 -0500 Patrick Hohmeyer 
<pi3_1415926536@yahoo.ca> wrote:

> Interesting approach, but at first glance I dont see how
> you'll solve the Celsius = Kelvin + 273.15 problem.
>
> This solution seams only to work with units where zero in one
> unit equals zero in the other as well.

This problem is not a programming problem -- and it has been 
solved already.

Units in physics may not carry any offset information as they 
are not capable to do this. Doing it would destroy the 
fundamental concept of equality being a replacement permission: 
"The outside temperature is 10 degrees celsius, that´s 10 
degrees celsius less than the temperature of my room.". If 10 
Degrees Celsius would be equal to 283.15 Kelvin, it would have 
to be possible to replace *both* occurences. Giving: "The 
outside temperature is 283.15 Kelvin, that´s 283.15 Kelvin less 
than the temperature of my room." Wow, too hot for me.

The solution is (IFAIR it´s from the International Conference on 
Measurements and Units... in 1972): "The temperature is 10 
Degrees Celsius" is just a lax abbreviation for: "The 
celsiustemperature is 10 Kelvin". So it´s a different physical 
value with the same unit and not the same physical value with a 
different unit. Note that the conversion between celsius 
temperature and absolute temperature can now be expressed in a 
simple equation: TC = TA + 273.15 K

The same holds for pseudo units like the old german "atü" (car 
tires) and "Vss"(TV electronics).

So it´s not a problem of unit conversion, but a problem occuring 
in the user interface, where you will have to deal with pseudo 
units.

Wilhelm

Re: Another Idea for Ada 20XX

[Lutz Donnerhacke]

* Patrick Hohmeyer wrote:
>And Lutz Donnerhacke has spoken :
>> I�m going to provide automatic unit optimization. Please stay tuned.
>
>Interesting approach, but at first glance I dont see how 
>you'll solve the Celsius = Kelvin + 273.15 problem.

Calculation is only possible in SI.

>I think an approach :
[Conversion]

Work in progress. But using a sligthly different approach. A new html
version is only generated if the program runs all the tests successfully.

Re: Another Idea for Ada 20XX

[Dirk Dickmanns]

James Rogers schrieb:

> I will look into the histories as well as current language proposals.

Besides the work of Lutz, I have:
http://users.erols.com/whitaker/iss_418.htm
http://www.dmitry-kazakov.de/ada/units.htm

Regards,

Dirk

-- 
Dirk.Dickmanns@BMW.de, Dr.rer.nat. xx49-89-382-46422, Fax -44988
Computer Vision and Sensor Data Fusion
BMW Group, Vehicle Research, EV-20, D-80788 Munich

Re: Another Idea for Ada 20XX

[Marc A. Criley]

James Rogers wrote:
> 
> Take the situation of the NASA Mars probe that crashed because
> of an improper mixture of British and Metric distance units.
> 
> If the programming language used had provided the ability to
> perform unit analysis the mistake would have been caught by
> the compiler.

Actually, no it would not have been caught by the compiler.  While
working on an article several months ago I exchanged some emails with an
individual at Malin Space Science Systems, who knew exactly what had
happened there--which is why I'd contacted him.

The problem was that one program wrote a file of floating point numbers
representing values in British units, which was then read by a program
that expected floating point numbers representing metric units.  No unit
information accompanied the values in the file, they were just numbers.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: Another Idea for Ada 20XX

[Thomas Koenig]

Patrick Hohmeyer  <pi3_1415926536@yahoo.ca> wrote:
>And Lutz Donnerhacke has spoken :

>> I�m going to provide automatic unit optimization. Please stay tuned.

>Interesting approach, but at first glance I dont see how 
>you'll solve the Celsius = Kelvin + 273.15 problem.

I don't think that this is a problem that wants solving as badly as
the case of normal units.

Define Celsius as a separate type, and provide conversion functions
to and from Kelvin.

Re: Another Idea for Ada 20XX

[Larry Kilgallen]

In article <3C0B65CB.8CDD7B31@earthlink.net>, "Marc A. Criley" <mcqada@earthlink.net> writes:

> The problem was that one program wrote a file of floating point numbers
> representing values in British units, which was then read by a program
> that expected floating point numbers representing metric units.  No unit
> information accompanied the values in the file, they were just numbers.

Do space probes include file systems and multiple programs ?

Or is this something in the build environment ?

If the latter, the problem could be solved by an old fashioned EDP
tool called a data dictionary.

Re: Another Idea for Ada 20XX

[Mark Lundquist]

Yes.  Units do need to be primitive.

I've been thinking about this for a while too, but haven't had the chance to
write it up.  The idea frankly never occurred to me until Ehud suggested it
in a post a few months back.  At first I thought "that's nuts".  But it
isn't :-)...

We now have type-safe programming in Ada.  But there are two things wanting:
(1) unit-safe programming, and (2) automatic unit conversion.  These cannot
be provided without augmenting the language.  (Note: "automatic" does not
mean "implicit", it means the compiler does the work for you).

This would really complete Ada's support for scalar abstraction.

"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:3C0A5054.E74A82E7@worldnet.att.net...
>
[snip...]
>
> Possible declarative syntax might be:
>
> type Meters is unit range (0.0..1.0E380);
> type Hours is unit range (0.0..9.99E30);

Something like that.  I don't think this is going to cut it, but you're on
the right track....  Unit declarations need to be independent of types.
Then a dimensioned type would be created by combining a unit with a
representation later on, in the type definition.  You need to defer the
"binding" of a type to a unit in order to achieve the right level of
abstraction.

> type Speed is unit(Meters / Hours);

I think the correct approach would involve declaring a unit (but not a type)
in terms of Meters and Hours (in your example).  The programmer would want
to call this unit "Meters_Per_Hour", not "Speed".

Mark Lundquist

Re: Another Idea for Ada 20XX

[Mark Lundquist]

"Gautier Write-only-address" <gautier_niouzes@hotmail.com> wrote in message
news:mailman.1007322723.31592.comp.lang.ada@ada.eu.org...
> >From: James Rogers
>
> >In scientific terms a measurement is done in terms of some unit.
> >For instance, distance is in meters, microns, feet or furlongs.

>
> The overhead is not only computational, I fear: if programmers
> are forced to specify the unit of each of their variables
> with a possible physical meaning, they just won't program in
> Ada...

Only if they have to give distance in "furlongs"! :-)

But seriously... no, the idea would not "force" programmers to do specify.
Units are unlike types in that they are optional (think about it, what units
would you give for Pi?).  What it would do is make it possible (but not
necessary) for you to write a subprogram that takes its inputs in certain
units.  Callers of the subprogram would then have to supply parameters of a
correctly dimensioned type, which might entail a unit conversion.  Note that
it is probably necessary to provide conversions to and from
dimensionlessness, so if the client wants to do everything without units
(keeping track of this manually just as we do today), they can still do that
(taking their life into their own hands) by applying a conversion at the
point of the call to your routine.

>
> Where is the problem, indeed ? Mixing feets and meters in a
> program ? This is more a political or cultural problem, I
> wouldn't wish to complicate Ada with it...

No, the idea does not complicate Ada with political/cultural problems.  I
don't Jim's suggestion extends to adding standardized physical units to the
language, only the ability to abstract unit relationships.  The language
would not care (nor do I) whether feet and meters are mixed in a program;
the point is that such a mixing (a) cannot be inadvertent, (b) is revealed
in the source text, and (c) cannot be a source of errors.

Really it would be quite a convenience and a savings of bother for the
programmer.  I don't know why anyone would not want it (OK, so maybe if I
were to actually write enough of a proposal... :-)

-- mark

Re: Another Idea for Ada 20XX

[Mark Lundquist]

"Gautier Write-only-address" <gautier_niouzes@hotmail.com> wrote in message
news:mailman.1007328304.17120.comp.lang.ada@ada.eu.org...
>
> Why not - but the more subtle you design the unit management,
> the more subtle the mistakes will be...

That's FUD.  The same arguments were invoked against inheritance and dynamic
polymorphism when OOP was invented.

I think units as primitive would make a language more robust.

> The choice of *one* unit system should be made *before* any
> programming, otherwise you don't get out of problems.

The main thrust of the idea is not conversion between unit systems.  That is
more of a secondary result.

The main point is that you can take the idea that a unit-area is
unit-length-squared, and abstract that across both measurement systems and
scalar representations.

-- mark

Re: Another Idea for Ada 20XX

[Lutz Donnerhacke]

* Mark Lundquist wrote:
>> type Speed is unit(Meters / Hours);
>
>I think the correct approach would involve declaring a unit (but not a type)
>in terms of Meters and Hours (in your example).  The programmer would want
>to call this unit "Meters_Per_Hour", not "Speed".

I beg to differ.

Re: Another Idea for Ada 20XX

[chris.danx]

"Mark Lundquist" <mlundquist2@attbi.com> wrote in message
news:KoMO7.2339$Px.45566@rwcrnsc54...
>
> Yes.  Units do need to be primitive.
>
> I've been thinking about this for a while too, but haven't had the chance
to
> write it up.  The idea frankly never occurred to me until Ehud suggested
it
> in a post a few months back.  At first I thought "that's nuts".  But it
> isn't :-)...
>
> We now have type-safe programming in Ada.  But there are two things
wanting:
> (1) unit-safe programming, and (2) automatic unit conversion.  These
cannot
> be provided without augmenting the language.  (Note: "automatic" does not
> mean "implicit", it means the compiler does the work for you).
>
> This would really complete Ada's support for scalar abstraction.
>
> "James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
> news:3C0A5054.E74A82E7@worldnet.att.net...
> >
> [snip...]
> >
> > Possible declarative syntax might be:
> >
> > type Meters is unit range (0.0..1.0E380);
> > type Hours is unit range (0.0..9.99E30);
>
> Something like that.  I don't think this is going to cut it, but you're on
> the right track....  Unit declarations need to be independent of types.



> Then a dimensioned type would be created by combining a unit with a
> representation later on, in the type definition.  You need to defer the
> "binding" of a type to a unit in order to achieve the right level of
> abstraction.

> > type Speed is unit(Meters / Hours);
>
> I think the correct approach would involve declaring a unit (but not a
type)
> in terms of Meters and Hours (in your example).  The programmer would want
> to call this unit "Meters_Per_Hour", not "Speed".

Dimensionality Checking (Ada 20XX)

[Nick Roberts]

I really like this idea. I'd like to throw in a suggestion.

I think probably the facility should only be applied to fixed-point types.
All floating-point types would remain 'undimensioned' and there would be
conversions and other operations between all floating-point, integer, and
fixed-point types as usual (whose results would be undimensioned).

There would be a new package, Ada.Physics, in which the following types and
constants would be declared:

   type Physical_Dimension is (Mass, Distance, Time);

   type Dimensionality is array (Physical_Dimension) of Integer;

   Meter_Dimensionality: constant Dimensionality := (1,0,0);
   Metre_Dimensionality: constant Dimensionality := (1,0,0);

   Second_Dimensionality: constant Dimensionality := (0,0,1);
   -- etc.

A programmer may then construct a package with unit declarations appropriate
to a specific application domain, e.g.:

   package My_Physics is

      Foot_Dimensionality:
         constant Ada.Physics.Dimensionality := (1,0,0);

      generic
         type Feet is delta <>;
         type Meters is delta <>;
      function Generic_Feet_to_Meters (X: in Feet) return Meters;
      pragma Inline(Generic_Feet_to_Meters);

      -- etc.

   end;

Then, in application code, the following could be used:

   -- TURD: Traditional Ultrasonic Ranging Device

   type TURD_Distance is delta 17.0/16200 range 1.0/12 .. 17.0;
   -- in feet

   pragma Dimensionality
      ( Type_Name  => TURD_Distance,
        Dimensions => My_Physics.Foot_Dimensionality );

By supplying a Dimensionality pragma for the type T, dimension checking
would then be applied to the "+", "-", "*", "/", and "**" operations of T as
appropriate. The dimensionality of the result would be checked against: in
an assignment, the target object; for an actual parameter, the corresponding
formal. Of these operations, if either actual parameter (apart from the
righthand one of "**") is undimensioned, no check would be applied (and the
result is undimensioned). The checks would be entirely static. The pragma
must occur before the type is frozen. The value of the Dimensions parameter
must be static, and of type Ada.Physics.Dimensionality.

These facilities could be defined in an optional annex. If a program which
uses dimensionality checking were to be ported to a compiler which doesn't
support it, the program should still compile and work as before, except only
that the dimensionality checking would not be done.

I would suggest that scaling and offset are done using existing Ada
facilities.

--
Nick Roberts

Re: Another Idea for Ada 20XX

[Marc A. Criley]

Larry Kilgallen wrote:
> 
> In article <3C0B65CB.8CDD7B31@earthlink.net>, "Marc A. Criley" <mcqada@earthlink.net> writes:
> 
> > The problem was that one program wrote a file of floating point numbers
> > representing values in British units, which was then read by a program
> > that expected floating point numbers representing metric units.  No unit
> > information accompanied the values in the file, they were just numbers.
> 
> Do space probes include file systems and multiple programs ?
> 
> Or is this something in the build environment ?
> 
> If the latter, the problem could be solved by an old fashioned EDP
> tool called a data dictionary.

The error occurred in the ground-based navigational processing, not
onboard the spacecraft.

And oh yes, there are many ways to avoid such a problem--any of the
assorted manifestations of interface control documents, for instance.

Re: Another Idea for Ada 20XX

[Adrian Hoe]

James Rogers <jimmaureenrogers@worldnet.att.net> wrote in message news:<3C0AACCE.329CFB60@worldnet.att.net>...
> Gautier Write-only-address wrote:
> > 
> > >From: James Rogers
>  
> > >In scientific terms a measurement is done in terms of some unit.
> > >For instance, distance is in meters, microns, feet or furlongs.
>  ...
> > >calculations. Because of the added computational overhead, there must
> > >be a way to choose or reject unit analysis for defined types.
> > 
> > The overhead is not only computational, I fear: if programmers
> > are forced to specify the unit of each of their variables
> > with a possible physical meaning, they just won't program in
> > Ada...
> > 
> > Where is the problem, indeed ? Mixing feets and meters in a
> > program ? This is more a political or cultural problem, I
> > wouldn't wish to complicate Ada with it...
> 
> The problem is not only political and cultural.
> 
> Take the situation of the NASA Mars probe that crashed because
> of an improper mixture of British and Metric distance units.
> 
> If the programming language used had provided the ability to
> perform unit analysis the mistake would have been caught by
> the compiler.
> 
> What I am trying to express is an extension of strong typing.
> This extension would allow specified mixing of types. The current
> Ada model places a strong barrier between all type mixes. The
> use of units will allow you to specify how and where certain
> types can be mixed. I personally find the units idea easier to
> understand than simply applying type coercion at various places
> in code. The concept of units also allows careful checking by the
> compiler, and secondary analysis (outside a compiler) of the code
> to ensure algorithmic correctness.
> 
> Jim Rogers
> Colorado Springs, Colorado USA


I missed the historic discussion on this matter too. Anyway, I don't
see the reason to mixing unit calculation. Why not standardised the
unit while designing and coding the software? It does not make good
sense if an area is 25cm x 6inches and this certainly create chaos.

The crash of NASA Mars probe proved the inability to communicate or to
standardize among those engineers. Wouldn't this be avoided if these
engineers agreed on a standardized unit of measurement? Again, will
the further augmentation of Ada (adding of units conversions and
checking) help to resolve this problem?

I do not against the motion but question it and if James or anyone
else can demonstarte the benefits of it with sample applications. This
could be of great help in fMRP, the MRP software for furniture
industry developed by my company.

Lutz and Dmitry implementations are very interesting and may help in
fMRP.

Just my 2 cents from my own pocket.

                                                    -- Adrian Hoe

Re: Another Idea for Ada 20XX

[Larry Kilgallen]

In article <45601fc.0112031740.3e217c8a@posting.google.com>, byhoe@users.sourceforge.net (Adrian Hoe) writes:

> The crash of NASA Mars probe proved the inability to communicate or to
> standardize among those engineers. Wouldn't this be avoided if these
> engineers agreed on a standardized unit of measurement? Again, will
> the further augmentation of Ada (adding of units conversions and
> checking) help to resolve this problem?

If they simply used common type declarations, a lot of errors would
be detected.  If Meters is a new type and is used throughout, and
Feet is another new type, it becomes difficult to add them.

Again, in cross-language environments this was done for subprograms
and records with a tool called a data dictionary -- years ago.

Re: Dimensionality Checking (Ada 20XX)

[Dmitry A. Kazakov]

On Mon, 3 Dec 2001 21:13:38 -0000, "Nick Roberts"
<nickroberts@adaos.worldonline.co.uk> wrote:

>I really like this idea. I'd like to throw in a suggestion.
>
>I think probably the facility should only be applied to fixed-point types.
>All floating-point types would remain 'undimensioned' and there would be
>conversions and other operations between all floating-point, integer, and
>fixed-point types as usual (whose results would be undimensioned).
>
>There would be a new package, Ada.Physics, in which the following types and
>constants would be declared:
>
>   type Physical_Dimension is (Mass, Distance, Time);
>
>   type Dimensionality is array (Physical_Dimension) of Integer;
>
>   Meter_Dimensionality: constant Dimensionality := (1,0,0);
>   Metre_Dimensionality: constant Dimensionality := (1,0,0);
>
>   Second_Dimensionality: constant Dimensionality := (0,0,1);
>   -- etc.
>
>A programmer may then construct a package with unit declarations appropriate
>to a specific application domain, e.g.:
>
>   package My_Physics is
>
>      Foot_Dimensionality:
>         constant Ada.Physics.Dimensionality := (1,0,0);
>
>      generic
>         type Feet is delta <>;
>         type Meters is delta <>;
>      function Generic_Feet_to_Meters (X: in Feet) return Meters;
>      pragma Inline(Generic_Feet_to_Meters);
>
>      -- etc.
>
>   end;
>
>Then, in application code, the following could be used:
>
>   -- TURD: Traditional Ultrasonic Ranging Device
>
>   type TURD_Distance is delta 17.0/16200 range 1.0/12 .. 17.0;
>   -- in feet
>
>   pragma Dimensionality
>      ( Type_Name  => TURD_Distance,
>        Dimensions => My_Physics.Foot_Dimensionality );
>
>By supplying a Dimensionality pragma for the type T, dimension checking
>would then be applied to the "+", "-", "*", "/", and "**" operations of T as
>appropriate. The dimensionality of the result would be checked against: in
>an assignment, the target object; for an actual parameter, the corresponding
>formal. Of these operations, if either actual parameter (apart from the
>righthand one of "**") is undimensioned, no check would be applied (and the
>result is undimensioned).

There are two different "undimensioned" in your system: a) ones with
no paragma Dimensionality applied and b) ones with

   pragma Dimensionality  (Dimensions=>(others=>0));

Then:
                 case b      case a
2*2m            4               4m
2+2m        illegal            4
2m**2        4sqm          4sqm
2**2m       illegal            4

Anyway you should invent some rules for literals of dimensioned types.
Will you apply pragma Dimensionality to literals depending on the
context?

>The checks would be entirely static. The pragma
>must occur before the type is frozen. The value of the Dimensions parameter
>must be static, and of type Ada.Physics.Dimensionality.

Static unit checks would efficiently exclude "class-wide" operations
on dimensioned values like 'Value, 'Image, 'Read etc. There is IMO an
obvious analogy between dimensionality and both type tags and
discriminants. I think that there should be possible to have both
constrained (=fixed dimension) and unconstrained (class-wide) subtypes
and instances of dimensioned types. Constrained ones should be checked
at compile time the same way as String (1..3) is checked when "abc" is
assigned.

If Ada should support dimensioned types, then I think that it should
do it using the existing paradigms. As I see it there could be two
approaches: a hard-wired implementation of dimensioned units as many
have proposed and a more complicated way based on an ability to have
compile-time user-defined subroutines defined on type tags and/or
discriminants. I believe it is worth to think (for Ada 2100 (:-))
about the "more compilcated" approach because the pattern of
dimensioned units is quite wide spread. For instance, it could well be
used for matrix/vector types etc.

>These facilities could be defined in an optional annex. If a program which
>uses dimensionality checking were to be ported to a compiler which doesn't
>support it, the program should still compile and work as before, except only
>that the dimensionality checking would not be done.
>
>I would suggest that scaling and offset are done using existing Ada
>facilities.

To which of the following two types would you apply

pragma Dimensionality (Dimensions=>Second_Dimensionality);

1. Ada.Calendar.Time
2. Standard.Duration

(:-))

Regards,
Dmitry Kazakov

Re: Another Idea for Ada 20XX

[Wes Groleau]

Larry Kilgallen wrote:
> If they simply used common type declarations, a lot of errors would
> be detected.  If Meters is a new type and is used throughout, and
> Feet is another new type, it becomes difficult to add them.

But that's not enough to prevent 2 Meters * 2 Meters = 4 Meters
nor to allow 10 minutes * 5 KPH = 833 Meters

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Another Idea for Ada 20XX

[Larry Kilgallen]

In article <3C0CF4E3.A53D20A7@sparc01.ftw.rsc.raytheon.com>, Wes Groleau <wwgrol@sparc01.ftw.rsc.raytheon.com> writes:
> 
> 
> Larry Kilgallen wrote:
>> If they simply used common type declarations, a lot of errors would
>> be detected.  If Meters is a new type and is used throughout, and
>> Feet is another new type, it becomes difficult to add them.
> 
> But that's not enough to prevent 2 Meters * 2 Meters = 4 Meters

True.

> nor to allow 10 minutes * 5 KPH = 833 Meters

Are you saying that multiplying two different types (not subtypes
of the same type) works in Ada95 ?  My experience is mostly Ada83.

And exactly how would it decide that the resulting type is Meters ?

Obviously one could use conversion and unchecked conversion, but
those are supposed to be used with caution and serve as a red flag
in formal inspection.

Unit handling (was: Another Idea for Ada 20XX)

[Wilhelm Spickermann]

--On Monday, December 03, 2001 13:34:09 +0100 Dirk Dickmanns 
<Dirk.Dickmanns@BMW.de> wrote:

...
> Besides the work of Lutz, I have:
> http://users.erols.com/whitaker/iss_418.htm
> http://www.dmitry-kazakov.de/ada/units.htm
>

May I add some of my ideas here? They could be realized as an 
optional ASIS program checker or as a compiler component and 
would not have any execution time penalty or require the tools 
to be available to do the compilation. As unit consistency is a 
program property, it´s not really necessary to have the tool on 
every platform and every site.

The idea is to define the basic SI-Units as named numbers with 
value 1.0 and using values like "5.7 * meter / second" in the 
program. (The compiler can easily optimize such expressions.)

A pragma for use by ASIS (or the compiler) defines which Units 
are to be viewed as basic.

Every variable, constant, parameter or named number will be 
associated with a derived unit upon the first assignment seen, 
by tracking the operations down to the basic units and all 
following assignments will be required to lead to the same 
result. Additionally all operations will be checked for 
consistency. (As others have already pointed out, there are not 
too many operations to be considered, as operations like taking 
the logarithm of something can never be applied to something 
having a unit)

An additional ASIS-pragma can assign a derived unit to a 
variable or parameter where the unit is not associated 
implicitly by an initial or default value.

A first sketch using SI as an example:

package Units is
   --  The 7 SI units:
   Meter : constant := 1.0;
   ...
   pragma Define_Unit (Meter, Kilogram, Second, Ampere,
                       Kelvin, Candela, Mole);
   ...
   --  SI derived units:
   Newton : constant := Meter * Kilogram / Second**2;
   ...
   --  SI accepted derived units:
   Liter : constant := 1.0e-3 * Meter**3;
   ...
end Units;

(No special handling for the child units needed, they just 
collect some definitions and try to convince programmers, that 
that it´s a bad idea to define a factor "Billion" etc.)

package Units.More is
   --  Defined (not experimentally determined) units.
   Foot : constant := 0.3048 * Meter;
   Foot_US_Survey : constant := Foot / 0.999998;
   ...
   --  experimentally determined units / constants
   Electron_Volt : constant := 1.602_177_33e-19 * Joule;
   ...
end Units.More;

package Units.Factors is
   ...
   Kilo  : constant := 1.0E3;
   ...
   Billion_US_FR : constant := 1.0E9;
   Billion_OTH : constant  := 1.0E12;
   ...
   Kilo_Binary : constant := 2.0**10;
   ...
end Units.Factors;

I think this notation is readable and could be helpful even 
without any tool to do the checks. It does not create any 
runtime penalties. It should be possible to implement the 
checker in ASIS or as an additional compiler component which may 
be switched on or off. It´s not meant as a proposal for Ada 
20XX, but if someone  would like to view it as one: it would 
only introduce conflicts in the two new pragma names.

(It will however not be able to handle units like "decibels" or 
"degrees celsius". I view these as pseudo units which only make 
mathematical reasoning impossible. They should occur only in the 
user interface as common expressions, but I´ve written that in 
another mail.)

Wilhelm

Re: Another Idea for Ada 20XX

[Vincent Marciante]

"Wes Groleau" <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote in message
news:3C0CF4E3.A53D20A7@sparc01.ftw.rsc.raytheon.com...
>
>

> But that's not enough to prevent 2 Meters * 2 Meters = 4 Meters

You can _remove_ the meters*meters operation by declaring is as abstract,
something like:

function "*" (left,right: meters) return meters is abstract;

then meters*meters won't compile.

> nor to allow 10 minutes * 5 KPH = 833 Meters
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: Another Idea for Ada 20XX

[Wes Groleau]

Vincent Marciante wrote:
> You can _remove_ the meters*meters operation by declaring is as abstract,
> something like:

Yes.  My point was that the proposal
created such illegal operators without
taking action like this to compensate.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Another Idea for Ada 20XX

[Matthew Heaney]

"Wes Groleau" <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote in message
news:3C0CF4E3.A53D20A7@sparc01.ftw.rsc.raytheon.com...
>
>
> Larry Kilgallen wrote:
> > If they simply used common type declarations, a lot of errors would
> > be detected.  If Meters is a new type and is used throughout, and
> > Feet is another new type, it becomes difficult to add them.
>
> But that's not enough to prevent 2 Meters * 2 Meters = 4 Meters
> nor to allow 10 minutes * 5 KPH = 833 Meters

You can always take away multipication:

  type Length_In_Meters_Type is new Float; --or whatever

  function "*" (L, R : Length_In_Meters_Type) return Length_In_Meters_Type
is abstract;

Re: Another Idea for Ada 20XX

[Richard Riehle]

Wes Groleau wrote:

> Larry Kilgallen wrote:
> > If they simply used common type declarations, a lot of errors would
> > be detected.  If Meters is a new type and is used throughout, and
> > Feet is another new type, it becomes difficult to add them.
>
> But that's not enough to prevent 2 Meters * 2 Meters = 4 Meters
> nor to allow 10 minutes * 5 KPH = 833 Meters
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Correct.  However, a simple type declaration is just part of the
solution.
I don't believe it requires a change to the language.  Rather, it begs
for a
simple object-oriented programming solution, along with some
old-fashioned
encapsulation.

         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;

In this way, we can control the behavior of each function with some
exactness
instead of depending only on the predefined behavior of ALRM Chapter 4
for
numeric types.   Of course, if we also had pre- and post-conditions as
part of
the language, this contract could be made even more robust.   In that
case, there
would definitely be no need for a specialized language feature.

Richard Riehle

Re: Another Idea for Ada 20XX

[Philip Anderson]

Mark Lundquist wrote:
> 
<snip>
> Units are unlike types in that they are optional (think about it, what units
> would you give for Pi?).
<snap>

I don't think units are "optional", although they may be dimensionless,
ie just numbers like Pi.  Note that radians, being a ratio, are actually
dimensionless.


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: Another Idea for Ada 20XX

[Wes Groleau]

Richard Riehle wrote:

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

However, you have a proliferation of combination functions.

  function "*" (Left   : Some_Metric_Type;
                Right  : Another_Metric_Type)
                return : One_More_Metric_Type;

  function "/" (Left   : Some_Metric_Type;
                Right  : Another_Metric_Type)
                return : One_More_Metric_Type;

With a reasonably complete facility, the number of
left/right/return combinations is huge.  Especially
if you allow mixed unit addition:

  function "+" (Left   : Meters;
                Right  : Kilometers)
                return : Meters;

Also, this method does not allow attributes
and it makes literals slightly more clumsy at best,
worse if you consider all the possible ways you can
misspell a unit name or use an unrecognized abbreviation
for it.  (Of course the latter might also be a problem
in a "language feature.")

I once used an enumerated type for supported units,
another for all allowed ways of writing them,
a lookup table for standard_form (allowed_written_form),
and loads of lookup tables for conversion factors,
which type comes from what, etc.  That allowed having
only one actual type, and only one moderately sized
function per operator, but the tables took up a lot
of space.  Extension and inheritance might have helped
some but not a lot.  In that particular application,
the lack of attributes turned out to be only a minor
inconvenience, but I would think it would mean a lot
in other cases.

Defining a new metric type by inheritance would require
knowing all units in the inheritance tree that it could
interact with, and providing or overriding the operators
to work AND disabling all the operators that would make
illegal operations.

So I think it wouldn't help any over a non-inherited way.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Dimensionality Checking (Ada 20XX)

[Britt Snodgrass]

Perhaps this is not a new proposal but it seems to me that units
(dimensionality) in Ada code would be most naturally implemented as
attributes of objects or types.  The units of an object or type would
be specified with a representation clause.  If unspecified, the unit
attribute would default to "null" (no units).  The compiler could then
enforce unit consistency during compilation or generate runtime unit
checking code.

For example:

with Ada.Text_IO;

with Ada.Dimensionality.ISO_Metric_Units; 
-- predefined for kilograms, meters, etc.
 
with Ada.Dimensionality.My_User_Defined_Units
-- parsecs_per_picosecond, etc.

use  Ada.Dimensionality;

package body Proposed_Unit_Syntax_Example is

   type Magnitude is digits 15;

   Delta_Position : Magnitude;
   for Delta_Position'Unit use ISO_Metric_Units.Meter;

   Delta_Time : Magnitude;
   for Delta_Time'Unit use ISO_Metric_Units.Second;

   Current_Speed : Magnitude;
   for Current_Speed'Unit use 
     ISO_Metric_Units.Meter / ISO_Metric_Units.Second;

   Accel : Magnitude;
   for Accel'Unit use
     ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2;
     -- note use of operators in attribute definition.

begin

   Delta_Position := 500.0;  -- meters implied by unit attribute

   Delta_Interval := 10.0;  -- seconds implied by unit attribute

   Current_Speed := Delta_Position / Delta_Interval;
   -- OK, units match

   Current_Speed := Delta_Position / Delta_Interval**2;
   -- won't compile or raises a predefined Unit_Error exception;

exception

   when Unit_Error =>
      Ada.Text_IO.Put_Line
        ("Oops! I just passed Mars without stopping to orbit!");

end Proposed_Unit_Syntax_Example;


Since all of the variables in this example are of the same type, no
new arithmetic operators need to be defined.  However the compiler
would use the unit attributes to ensure that any resulting right-side
composite unit matches the left-side unit before allowing an
assignment to proceed.  Most unit inconsistencies would be caught
during compilation. If a unit mismatch can't be caught until runtime,
then a predefined Unit_Error exception would be raised (unless the
code had been compiled with Pragma Suppress (Unit_Checks) ).

Britt Snodgrass

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

In my post, I mentioned the idea of specifying units and their relationships
independent of types, then somehow "binding" units to types.  At first
glance, your idea seems promising for the "binding" part.  Very nice.  I
hadn't thought of using attributes for this, and as you say it is a natural
notation for Ada.

-- mark


"Britt Snodgrass" <britt@adapower.net> wrote in message
news:36c6f8dd.0112061152.333c9de@posting.google.com...
> Perhaps this is not a new proposal but it seems to me that units
> (dimensionality) in Ada code would be most naturally implemented as
> attributes of objects or types.  The units of an object or type would
> be specified with a representation clause.  If unspecified, the unit
> attribute would default to "null" (no units).  The compiler could then
> enforce unit consistency during compilation or generate runtime unit
> checking code.
>
> For example:
>
> with Ada.Text_IO;
>
> with Ada.Dimensionality.ISO_Metric_Units;
> -- predefined for kilograms, meters, etc.
>
> with Ada.Dimensionality.My_User_Defined_Units
> -- parsecs_per_picosecond, etc.
>
> use  Ada.Dimensionality;
>
> package body Proposed_Unit_Syntax_Example is
>
>    type Magnitude is digits 15;
>
>    Delta_Position : Magnitude;
>    for Delta_Position'Unit use ISO_Metric_Units.Meter;
>
>    Delta_Time : Magnitude;
>    for Delta_Time'Unit use ISO_Metric_Units.Second;
>
>    Current_Speed : Magnitude;
>    for Current_Speed'Unit use
>      ISO_Metric_Units.Meter / ISO_Metric_Units.Second;
>
>    Accel : Magnitude;
>    for Accel'Unit use
>      ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2;
>      -- note use of operators in attribute definition.
>
> begin
>
>    Delta_Position := 500.0;  -- meters implied by unit attribute
>
>    Delta_Interval := 10.0;  -- seconds implied by unit attribute
>
>    Current_Speed := Delta_Position / Delta_Interval;
>    -- OK, units match
>
>    Current_Speed := Delta_Position / Delta_Interval**2;
>    -- won't compile or raises a predefined Unit_Error exception;
>
> exception
>
>    when Unit_Error =>
>       Ada.Text_IO.Put_Line
>         ("Oops! I just passed Mars without stopping to orbit!");
>
> end Proposed_Unit_Syntax_Example;
>
>
> Since all of the variables in this example are of the same type, no
> new arithmetic operators need to be defined.  However the compiler
> would use the unit attributes to ensure that any resulting right-side
> composite unit matches the left-side unit before allowing an
> assignment to proceed.  Most unit inconsistencies would be caught
> during compilation. If a unit mismatch can't be caught until runtime,
> then a predefined Unit_Error exception would be raised (unless the
> code had been compiled with Pragma Suppress (Unit_Checks) ).
>
> Britt Snodgrass

Re: Dimensionality Checking (Ada 20XX)

[Wes Groleau]

Britt Snodgrass wrote:
> (dimensionality) in Ada code would be most naturally implemented as
> attributes of objects or types.  The units of an object or type would
> be specified with a representation clause.  If unspecified, the unit

I think this is a very good idea.  But now to nitpick:

>    Accel : Magnitude;
>    for Accel'Unit use
>      ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2;

In some cases, might there be multiple ways to describe
the units?   Speed is Acceleration * Time but it is also
Distance / Time.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Wes Groleau" <wgroleau@usa.com> wrote in message
news:3C0FF376.2DC0C3E4@usa.com...
>
>
> Britt Snodgrass wrote:
> > (dimensionality) in Ada code would be most naturally implemented as
> > attributes of objects or types.  The units of an object or type would
> > be specified with a representation clause.  If unspecified, the unit
>
> I think this is a very good idea.  But now to nitpick:
>
> >    Accel : Magnitude;
> >    for Accel'Unit use
> >      ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2;
>
> In some cases, might there be multiple ways to describe
> the units?   Speed is Acceleration * Time but it is also
> Distance / Time.

Right, which is why (a) the concepts of "unit" and of "dimension" need to be
loosely coupled (this is missing from the proposals I've seen so far), and
then (b) you have to distinguish between base and derived dimensions.

We normally think of Distance and Time as being "fundamental", so typically
we would declare these as base dimensions.  Then we declare the derived
dimension Rate = Distance / Time.  That's (a).

(b) says that Rate = Distance / Time no matter the units.

The dimensionality checking would be done in terms of base dimensions, so it
makes no difference "how you got there", e.g. in terms of derived
dimensions.

Best Regards,
Mark

Re: Another Idea for Ada 20XX

[Adrian Hoe]

Wes Groleau <wgroleau@usa.com> wrote in message news:<3C0FAD3D.64ACC870@usa.com>...
> 
>   function "+" (Left   : Meters;
>                 Right  : Kilometers)
>                 return : Meters;



Consider this:

function "+" (Left   : Meters;
              Right  : Inches)
              return Meters;

What kind of precision in the conversion of Inches to Meters if Unit
Checking and Conversion are to be part of Ada? Do I/we have the
liberty to select the precision I/we want?

How exactly this will be implemented by the new annex of Ada
(perhaps)?


                                                  -- Adrian Hoe


> Also, this method does not allow attributes
> and it makes literals slightly more clumsy at best,
> worse if you consider all the possible ways you can
> misspell a unit name or use an unrecognized abbreviation
> for it.  (Of course the latter might also be a problem
> in a "language feature.")
> 
> I once used an enumerated type for supported units,
> another for all allowed ways of writing them,
> a lookup table for standard_form (allowed_written_form),
> and loads of lookup tables for conversion factors,
> which type comes from what, etc.  That allowed having
> only one actual type, and only one moderately sized
> function per operator, but the tables took up a lot
> of space.  Extension and inheritance might have helped
> some but not a lot.  In that particular application,
> the lack of attributes turned out to be only a minor
> inconvenience, but I would think it would mean a lot
> in other cases.
> 
> Defining a new metric type by inheritance would require
> knowing all units in the inheritance tree that it could
> interact with, and providing or overriding the operators
> to work AND disabling all the operators that would make
> illegal operations.
> 
> So I think it wouldn't help any over a non-inherited way.

Re: Another Idea for Ada 20XX

[Dmitry A. Kazakov]

On 6 Dec 2001 16:55:38 -0800, byhoe@users.sourceforge.net (Adrian Hoe)
wrote:

>Wes Groleau <wgroleau@usa.com> wrote in message news:<3C0FAD3D.64ACC870@usa.com>...
>> 
>>   function "+" (Left   : Meters;
>>                 Right  : Kilometers)
>>                 return : Meters;
>
>Consider this:
>
>function "+" (Left   : Meters;
>              Right  : Inches)
>              return Meters;
>
>What kind of precision in the conversion of Inches to Meters if Unit
>Checking and Conversion are to be part of Ada? Do I/we have the
>liberty to select the precision I/we want?

A possible solution is that there should be same precision of Left,
Right and result. They should have exactly same representation [in
some unit system, like SI] and Inches would be just a view of some
length [which corresponds to the physical nature of meters and
inches]. So

    X : Inches := 5;  -- Means  X := 0.127 [m]

Unfortunately the price of this is that it will be impossible to have
precise computations in non-metric units and range problems [eV is
pretty small when compared with J].

However, it is thinkable [and preferable] that Ada would provide not
an implementation of some unit system, but rather facilities to do it.
Then of course, a user might just create its own unit system like
(foot, second, pound) and have meters as a view of feets. He would
also be able to create two different systems and define conversions
between them with necessary care of precision.

>How exactly this will be implemented by the new annex of Ada
>(perhaps)?

Regards,
Dmitry Kazakov

Re: Dimensionality Checking (Ada 20XX)

[Dmitry A. Kazakov]

On 6 Dec 2001 11:52:12 -0800, britt@adapower.net (Britt Snodgrass)
wrote:

>Perhaps this is not a new proposal but it seems to me that units
>(dimensionality) in Ada code would be most naturally implemented as
>attributes of objects or types.  The units of an object or type would
>be specified with a representation clause.  If unspecified, the unit
>attribute would default to "null" (no units).  The compiler could then
>enforce unit consistency during compilation or generate runtime unit
>checking code.
>
>For example:
>
>with Ada.Text_IO;
>
>with Ada.Dimensionality.ISO_Metric_Units; 
>-- predefined for kilograms, meters, etc.
> 
>with Ada.Dimensionality.My_User_Defined_Units
>-- parsecs_per_picosecond, etc.
>
>use  Ada.Dimensionality;
>
>package body Proposed_Unit_Syntax_Example is
>
>   type Magnitude is digits 15;
>
>   Delta_Position : Magnitude;
>   for Delta_Position'Unit use ISO_Metric_Units.Meter;
>
>   Delta_Time : Magnitude;
>   for Delta_Time'Unit use ISO_Metric_Units.Second;
>
>   Current_Speed : Magnitude;
>   for Current_Speed'Unit use 
>     ISO_Metric_Units.Meter / ISO_Metric_Units.Second;
>
>   Accel : Magnitude;
>   for Accel'Unit use
>     ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2;
>     -- note use of operators in attribute definition.
>
>begin
>
>   Delta_Position := 500.0;  -- meters implied by unit attribute
>
>   Delta_Interval := 10.0;  -- seconds implied by unit attribute
>
>   Current_Speed := Delta_Position / Delta_Interval;
>   -- OK, units match
>
>   Current_Speed := Delta_Position / Delta_Interval**2;
>   -- won't compile or raises a predefined Unit_Error exception;
>
>exception
>
>   when Unit_Error =>
>      Ada.Text_IO.Put_Line
>        ("Oops! I just passed Mars without stopping to orbit!");
>
>end Proposed_Unit_Syntax_Example;
>
>
>Since all of the variables in this example are of the same type, no
>new arithmetic operators need to be defined.  However the compiler
>would use the unit attributes to ensure that any resulting right-side
>composite unit matches the left-side unit before allowing an
>assignment to proceed.  Most unit inconsistencies would be caught
>during compilation. If a unit mismatch can't be caught until runtime,
>then a predefined Unit_Error exception would be raised (unless the
>code had been compiled with Pragma Suppress (Unit_Checks) ).

I would also prefer a representation clause over rather obscure
pragmas, but the question stands: how to do class-wide unit
programming? For instance, how to write [non-generic] subprogram
IntegrateTime which takes <unit>/s and returns <unit>? How to write a
subprogram that gets user input from a dialog field and returns some
dimensioned value?

Therefore I would prefer a solution based on discriminants or else
tags provided that the compiler will remove all extra data fields and
run-time checks in case when units are statically known.

Regards,
Dmitry Kazakov

Re: Another Idea for Ada 20XX

[Tarjei T. Jensen]

Richard Riehle wrote
>Correct.  However, a simple type declaration is just part of the
>solution.
>I don't believe it requires a change to the language.  Rather, it begs
>for a
>simple object-oriented programming solution, along with some
>old-fashioned
>encapsulation.
>
>         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 think my suggestion (long time ago) of having a "universe" where one
defines how the datatypes interact is a far better idea. The compiler would
know that multiplying meter by meter would result in meter squared and that
this would not be assignment compatible with meter. There would be no need
for units since one would be able to specify wheter an integer would have to
be typed in order to be used in an expression.


Greetings,

Re: Dimensionality Checking (Ada 20XX)

[Wes Groleau]

Mark Lundquist wrote:
> 
> "Wes Groleau" <wgroleau@usa.com> wrote ....
> > >    Accel : Magnitude;
> > >    for Accel'Unit use
> > >      ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2;
> >
> > In some cases, might there be multiple ways to describe
> > the units?   Speed is Acceleration * Time but it is also
> > Distance / Time.
> 
> Right, which is why (a) the concepts of "unit" and of "dimension" need to be
> loosely coupled (this is missing from the proposals I've seen so far), and
> then (b) you have to distinguish between base and derived dimensions.

I guess what I mean is that the compiler would have to have some smarts
to be able to figure out all the numerous ways of deriving a derived
dimension--including from other derived dimensions.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Another Idea for Ada 20XX

[Mark Lundquist]

"Philip Anderson" <phil.anderson@amsjv.com> wrote in message
news:3C0F8E75.4F5CB3B8@amsjv.com...
> Mark Lundquist wrote:
> >
> <snip>
> > Units are unlike types in that they are optional (think about it, what
units
> > would you give for Pi?).
> <snap>
>
> I don't think units are "optional", although they may be dimensionless,
> ie just numbers like Pi.

Eh?  OK, so I'll ask again, what units would you give for Pi?

>  Note that radians, being a ratio, are actually
> dimensionless.

No, they are not!

(BTW rate is also the ratio of distance/time, and of course rate isn't
dimensionless -- any more than radians are!)

The dimension of angle is distance/distance.  (I'm not making this up -- the
SI define radians in terms of meter*(meter**-1)).  That's why when you
multiply a distance by an angle, you get a distance.  But if you were to
multiply a mass by an angle, you do not get a mass (which would make it a
unit conversion), but something whose units would be "kg-radians".  (What
use would that have?  Beats me, for all I know there might be one... I'm a
physics 'tard, my wise-ass PhD little brother got all the physics genes :-)
:-)

Dimensionless numbers do not change the units when you multiply them, that's
the difference.  No measurement is dimensionless.

Cheers,
Mark

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Britt Snodgrass" <britt@adapower.net> wrote in message
news:36c6f8dd.0112061152.333c9de@posting.google.com...
>
> Most unit inconsistencies would be caught
> during compilation. If a unit mismatch can't be caught until runtime,
> then a predefined Unit_Error exception would be raised (unless the
> code had been compiled with Pragma Suppress (Unit_Checks) ).

Well, I would think that unit checking would be *entirely* a compile-time
phenomenon.  Can you think of any reason why it would not be?

Also... you want to set up the proposed feature so that it can be defined
without touching the conformance rules in any way, which means that at some
point you "bury" the units in the type and then don't think about them any
more.  That point is the application of the 'Unit representation clause in
your scheme.  Assuming this, then the check that actually takes place is
just the normal type check, which of course is fully static (except for
tagged types, but the reasons for that are completely unrelated and do not
apply to scalars).

Cheers,
Mark

Re: Another Idea for Ada 20XX

[Nick Roberts]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:C1UHcLPG$dZX@eisner.encompasserve.org...

> > nor to allow 10 minutes * 5 KPH = 833 Meters
>
> Are you saying that multiplying two different types (not subtypes
> of the same type) works in Ada95 ?  My experience is mostly Ada83.

If they are both fixed point types, I think the answer is 'yes', provided
it's in the context of a specific fixed point type (not universal fixed).
E.g.:

   D: Distance := Duration(10*60.0) * KPH(5.0);

--
Nick Roberts

Re: Another Idea for Ada 20XX

[Dmitry A. Kazakov]

On Fri, 07 Dec 2001 22:51:47 GMT, "Mark Lundquist"
<mlundquist2@attbi.com> wrote:

>
>"Philip Anderson" <phil.anderson@amsjv.com> wrote in message
>news:3C0F8E75.4F5CB3B8@amsjv.com...
>> Mark Lundquist wrote:
>> >
>> <snip>
>> > Units are unlike types in that they are optional (think about it, what
>units
>> > would you give for Pi?).
>> <snap>
>>
>> I don't think units are "optional", although they may be dimensionless,
>> ie just numbers like Pi.
>
>Eh?  OK, so I'll ask again, what units would you give for Pi?
>
>>  Note that radians, being a ratio, are actually
>> dimensionless.
>
>No, they are not!
>
>(BTW rate is also the ratio of distance/time, and of course rate isn't
>dimensionless -- any more than radians are!)
>
>The dimension of angle is distance/distance.  (I'm not making this up -- the
>SI define radians in terms of meter*(meter**-1)). 

There are lot of formulae involving Pi, which you can derive Pi units
from. Consider formula of volume, or better Euler's -1= exp (j*Pi)
(:-)).

>That's why when you
>multiply a distance by an angle, you get a distance.  But if you were to
>multiply a mass by an angle, you do not get a mass (which would make it a
>unit conversion), but something whose units would be "kg-radians".  (What
>use would that have?  Beats me, for all I know there might be one... I'm a
>physics 'tard, my wise-ass PhD little brother got all the physics genes :-)
>:-)
>
>Dimensionless numbers do not change the units when you multiply them, that's
>the difference.  No measurement is dimensionless.

This includes dimensionless numbers as well. For instance, when we
count, the result is measured in fingers (:-)).

Regards,
Dmitry Kazakov

Re: Another Idea for Ada 20XX

[Stephen Leake]

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

> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> news:C1UHcLPG$dZX@eisner.encompasserve.org...
> 
> > > nor to allow 10 minutes * 5 KPH = 833 Meters
> >
> > Are you saying that multiplying two different types (not subtypes
> > of the same type) works in Ada95 ?  My experience is mostly Ada83.
> 
> If they are both fixed point types, I think the answer is 'yes', provided
> it's in the context of a specific fixed point type (not universal fixed).
> E.g.:
> 
>    D: Distance := Duration(10*60.0) * KPH(5.0);

Umm, surely there must somewhere be defined a "conversion multiplier",
and it must be visible:

function "*" (left : in duration; right : in KPH) return Distance;

otherwise the above statement is not legal, in Ada 83 or 95.

Defining _all_ of these required conversion multipliers is the killer
for this concept.

-- 
-- Stephe

Re: Another Idea for Ada 20XX

[Wes Groleau]

> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote ....
> 
> > > nor to allow 10 minutes * 5 KPH = 833 Meters
> >
> > Are you saying that multiplying two different types (not subtypes
> > of the same type) works in Ada95 ?  My experience is mostly Ada83.

No, I'm saying it doesn't.  So making derived types for
Minutes, KPH, and Meters is not sufficient to make the
example work.  You have to also define the operator.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Another Idea for Ada 20XX

[Wes Groleau]

Stephen Leake wrote:
> Defining _all_ of these required conversion multipliers is the killer
> for this concept.

When I did it, it was a temporary pain, but once it was done.....
(generics helped a lot).

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Another Idea for Ada 20XX

[Larry Kilgallen]

In article <3C14EC43.67FD5082@sparc01.ftw.rsc.raytheon.com>, Wes Groleau <wwgrol@sparc01.ftw.rsc.raytheon.com> writes:
> 
>> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote ....
>> 
>> > > nor to allow 10 minutes * 5 KPH = 833 Meters
>> >
>> > Are you saying that multiplying two different types (not subtypes
>> > of the same type) works in Ada95 ?  My experience is mostly Ada83.
> 
> No, I'm saying it doesn't.  So making derived types for
> Minutes, KPH, and Meters is not sufficient to make the
> example work.  You have to also define the operator.

My point was that "accidental" multiplication will not be allowed
if one uses individual types (not subtypes).

RE: Another Idea for Ada 20XX

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Stephen Leake et al.
"Defining _all_ of these required conversion multipliers is the killer
for this concept."

This is particularly true since they are NOT needed! In fact, the actual
combinations of units in physics and chemistry formulas is very large. What
has to be done is a check that the exponents of the units are the same for
addition-subtraction. Of course the data that is an input, an output, or a
check-point must have the exponents of their units being constants.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Stephen Leake
Sent: Monday, December 10, 2001 8:22 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Another Idea for Ada 20XX


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

> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> news:C1UHcLPG$dZX@eisner.encompasserve.org...
>
> > > nor to allow 10 minutes * 5 KPH = 833 Meters
> >
> > Are you saying that multiplying two different types (not subtypes
> > of the same type) works in Ada95 ?  My experience is mostly Ada83.
>
> If they are both fixed point types, I think the answer is 'yes', provided
> it's in the context of a specific fixed point type (not universal fixed).
> E.g.:
>
>    D: Distance := Duration(10*60.0) * KPH(5.0);

Umm, surely there must somewhere be defined a "conversion multiplier",
and it must be visible:

function "*" (left : in duration; right : in KPH) return Distance;

otherwise the above statement is not legal, in Ada 83 or 95.

Defining _all_ of these required conversion multipliers is the killer
for this concept.

--
-- Stephe

Re: Another Idea for Ada 20XX

[Wes Groleau]

"Robert C. Leif, Ph.D." wrote:
> 
> From: Bob Leif
> To: Stephen Leake et al.
> "Defining _all_ of these required conversion multipliers is the killer
> for this concept."
> 
> This is particularly true since they are NOT needed! In fact, the actual

In the concept he was talking about, they ARE needed.
In the exponent/record concept they are not.  Instead,
there one has to define all the conversion and IO operations
and attributes.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau