Re: Another Idea for Ada 20XX

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

[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

[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

[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]

"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

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

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

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

[Mark Lundquist]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3C0EF0A0.9F42EDB4@adaworks.com...
>
> 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 have no idea what you're getting at with the "helper type to avoid
recursion"... :-)  But in any case, the "good old-fashioned encapsulation"
isn't enough (see below)...

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

I don't see how pre- and post-conditions are relevant... ???

But anyway...

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

(b) you cannot declare subtypes with range constraints.

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

(c) it's way labor-intensive

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

(e) the explosion continues if you want more than one unit per dimension.
It explodes in both new overloadings of the quasi-numeric operations, and
also in the unit conversions.

(f) all the unit types that you wish to be interoperable must be declared in
the same package, since they are private, and you can't use child packages
for this because then the operations are no longer primitive.  It requires
"prescience/ominiscience" on the part of the designer, so unless you are
really God but you just go by "Richard Riehle" on Usenet :-), it could only
be considered for self-contained software where you're "rolling your own"
and in complete control of all the code.

(g) if you wanted to have multiple types with the same unit relationships
but different representations, e.g. different delta, decimal or fixed-point
types, you are hosed -- the scheme becomes totally unmanageable at that
point.

Best Regards,
Mark

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

[Richard Riehle]

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

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

[Mark Lundquist]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3C118E95.B5F013C8@adaworks.com...
> Mark Lundquist wrote:
> >
> > 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.

Hmm, if I'm understanding this correctly, it's you always have this problem
when deriving privately and re-exporting the primitives of the base type
(it's not unique to numeric types and/or infix operators).  You can always
convert up to the base type and back down again in the body of the
primitive, right?  Anyway, this is OT from our dimensions discussion,
sorry...

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

That gives you something analogous to declaring a type whose first subtype
is constrained (in fact I guess that's just how you would write the full
type definition in your generic spec), where you do not intend to create any
other subtypes.  That's pretty limiting...  you get nowhere near the full
power of the subtyping system.

> In fact, I designed some generics to test this and found that the real
problems
> are: 1)  no notion of zero

I hadn't thought of that... yeah, that is a problem.

>
> > (e) , (f), and (g) from your posting.
>
> I give you the points on those.
>
> My suggestion, however, does work for some situations.

Sure, but it's survival, it's no way to live :-)

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

Sounds good :-)
-- Mark

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

[Matthew Heaney]

"Mark Lundquist" <mlundquist2@attbi.com> wrote in message
news:FxhQ7.15837$ER5.268492@rwcrnsc52...
>
> "Richard Riehle" <richard@adaworks.com> wrote in message
> news:3C118E95.B5F013C8@adaworks.com...
> > Mark Lundquist wrote:
> > >
> > > 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.
>
> Hmm, if I'm understanding this correctly, it's you always have this
problem
> when deriving privately and re-exporting the primitives of the base type
> (it's not unique to numeric types and/or infix operators).  You can always
> convert up to the base type and back down again in the body of the
> primitive, right?  Anyway, this is OT from our dimensions discussion,
> sorry...


This is an issue with the implementation of ADT's in Ada, that often trips
up the beginner.  It may seem perfectly reasonable to do this:

package P is
   type T is private;
   function "+" (L, R : T) return T;
private
   type T is new Integer;  --or whatever
end P;

package body P is
   function "+" (L, R : T) return T is
     Sum : T := L + R;  --oops
   begin
      if Sum > 100 then  --this type does "clamping"
        Sum := 100;
     end if;
    return Sum;
  end "+";
end P;

The problem is that with this type, externally you want "+" to have one
behavior, but internally you want "+" to have it's "normal" behavior.  But
in the implementation above, you have infinite recursion, because the
compiler doesn't make the same distinction you do.

There are a couple of ways to solve this problem.

I. Implement that ADT as a private derivation:

package P is
   type T is private;
   function "+" (L, R : T) return T;
private
   type T_Rep is new Integer;
   type T is new T_Rep;
end P;

Here is there is no problem, because the special "+" operation applies to T,
not T_Rep, so at least you now have a way to get back the "normal" behavior
of "+":

package body P is
   function "+" (L, R : T) return T is
     Sum : T_Rep := T_Rep (L) + T_Rep (R);
   begin
     if Sum > 100 then
       Sum := 100;
     end if;
     return T (Sum);
   end "+";
end P;

II. Implement the ADT as a record:

package P is
   type T is private;
   function "+" (L, R : T) return T;
private
   type T is record
      Rep : Integer;
   end record;
end P;

Now there is no comflict, because a record type doesn't already have a "+"
operator:

package body P is
   function "+" (L, R : T) return T is
      Sum : Integer := L.Rep + R.Rep;
   begin
      if Sum > 100 then
        Sum := 100;
      end if;
      return T'(Rep => Sum);
   end "+";
end P;

Ada83 probably would have been simpler had only records were allowed as
implementations of ADT's -- which is the case for Ada95 tagged types.  Oh
well, live and learn.

III.  For non-private ADT's

What I showed above (at least in I) applies when you have a private type
implemented as a scalar type.  If you don't need a private type, then you
have another option.  You're allowed to "squirral away" the predefined
operator, prior to overriding it:

package P is
   type T is new Integer;
   function Predefined_Add (L, R : T) return T renames "+";
   function "+" (L, R : T) return T;
end P;

Now you have an explicit way of getting back to the predefined operator:

package body P is
   function "+" (L, R : T) return T is
      Sum : T := Predefined_Add (L, R);
  begin
      if Sum > 100 then
        Sum := 100;
      end if;
      return Sum;
   end "+";
end P;

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

[Wes Groleau]

On another project, I implemented two variations of
dimensioned numbers.  package Units in the deliverable
code was several KSLOC.  It provided a ... is digits ...
for each unit of measure on the project's allowed units list,
all the conversion factors between them, and all the "legal"
operators we could think of.  There were two ways to create
"*" or "/" (1) a generic that would always raise an exception
or a generic that took left, right, and result types and a
multiplier (conversion factor).  It was a pain to write it
and check it, but it worked well as part of a five MegaSLOC
product.

package Unitized_Numbers in the testing software used a
private type with a Units discriminant and a value.
Much smaller, easier to write, but the loss of attributes
and other features of numeric types was a slight disadvantage.
It would have been a much bigger disadvantage if it had to be
used for any complicated algorithms.

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

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

[Robert C. Leif, Ph.D.]

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

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: Dimensions (was Re: Another Idea for Ada 20XX)

[Ian]

"Mark Lundquist" <mlundquist2@attbi.com> wrote in message news:<7KbQ7.13821$L51.28784@rwcrnsc54

> 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

Not if you define each only in terms of the nearest suitable type and
chain the conversions between them. Then you only have an O(N)
expansion where N is the number of unit types. If at compile time a
table is constructed with the conversions used in any builds then thes
will not be large in number.

E.g. 1 yard is 3 feet which is 3*12 inches which is 3*12*0.00254
metres.

I don't see any unsurmountable problem.

> (e) the explosion continues if you want more than one unit per dimension.
> It explodes in both new overloadings of the quasi-numeric operations, and
> also in the unit conversions.

See above. No explosion.
 
> Mark

Ian

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