RE: Dimensionality Checking (Ada 20XX)

RE: Dimensionality Checking (Ada 20XX)

[Snodgrass, Britt (NM75)]

> -----Original Message-----
> From: Wes Groleau [mailto:wgroleau@usa.com]
> Sent: Thursday, December 06, 2001 3:39 PM
> To: comp.lang.ada@ada.eu.org
> Subject: Re: Dimensionality Checking (Ada 20XX)
> 
> 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.

Yes, but the compiler would resolve both of these to a canonical form such
as Distance_Unit**(1)*Time_Unit**(-1) and know that they both represent the
same composite unit.

I am also thinking that unit conversions could be accomplished using syntax
similar to the following example:

      type Magnitude is digits 15;

      Accel_FPS2 : Magnitude;
      for Accel_FPS2'Unit use
        Goofy_Old_Units.Foot / ISO_Metric_Units.Second**2;
        -- feet per second per second

      Accel_MPS2 : Magnitude;
      for Accel_MPS2'Unit use
        ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2;
        -- meters per second per second

   begin

       Accel_FPS2 := 32.0  -- "Feet per second squared" implied

        -- now convert units like this:
       Accel_MPS2 := Accel_FPS2 * Accel_MPS2'Unit / Accel_FPS2'Unit;

       -- or this:
       Accel_MPS2 :=
         Accel_FPS2 * ISO_Metric_Units.Meter / Goofy_Old_Units.Foot;


provided that every base unit (distance, mass, time, charge, etc.) attribute
had a corresponding named number whose value was the ratio of the named unit
to the ISO base unit.  For example:

   ISO_Metric_Units.Meter     :=    1.0;     -- value in meters
   ISO_Metric_Units.Kilometer := 1000.0;     -- value in meters
   Goofy_Old_Units.Foot       :=    0.3048;  -- value in meters

This idea is still half-baked but I'll keep thinking about it.  It would be
nice to have some type of dimensional unit support specified in an optional
Annex for Ada 200X.

Britt

   P.S.  The example in my first post should have been a "procedure", not a
"package body"



 

Re: Dimensionality Checking (Ada 20XX)

[Ian]

"Snodgrass, Britt (NM75)" <Britt.Snodgrass@honeywell.com> wrote in message news:<mailman.1007683804.26935.comp.lang.ada@ada.eu.org>...
> > -----Original Message-----
> > From: Wes Groleau [mailto:wgroleau@usa.com]
> > Sent: Thursday, December 06, 2001 3:39 PM
> > To: comp.lang.ada@ada.eu.org
> > Subject: Re: Dimensionality Checking (Ada 20XX)

> I am also thinking that unit conversions could be accomplished using syntax
> similar to the following example:

I implemented a module in PROLOG to do automatic conversions and
although the language does not have in built type checking I used
constant strings.

I would like to separate out the requirement needed from how Ada will
impliment it.

My requirement was to convert a scalar (physical quantity implemented
as the product of a real number and a physical unit type). I defined
this as a
predicate which would return when true the same scalar in the before
and after representations.
 
e.g., 
:- convert(1, inch, 0.00254, metre).
yes

The way this was used in an algorithm was when an expression was to be
evaluated the units used to define the expression were compared with
the input
parameter units and converted to the required type. After the
expression was evaluated the units could be converted back to the
original type.

A typical program would be 
a) read inputs in arbitrary but defined units
b) execute algorithms in preferred units
c) convert back to original units for the user 

I did think of analysing the units into powers of Mass Length and Time
to convert to say SI for computations, but I settled on chaining
convertions using predefined conversion factors to avoid listing all
the possible pairs of single step conversions. E.g. I would convert
yards to feet then inches then metres.


> provided that every base unit (distance, mass, time, charge, etc.) attribute
> had a corresponding named number whose value was the ratio of the named unit
> to the ISO base unit.  For example:
> 
>    ISO_Metric_Units.Meter     :=    1.0;     -- value in meters
>    ISO_Metric_Units.Kilometer := 1000.0;     -- value in meters
>    Goofy_Old_Units.Foot       :=    0.3048;  -- value in meters
> 
> This idea is still half-baked but I'll keep thinking about it.  It would be
> nice to have some type of dimensional unit support specified in an optional
> Annex for Ada 200X.
 
> Britt

I used the module expensively in aerodynamic modelling with complete
success.
The use of Celsius to Kelvin was no problem and as the SI system is an
ISO standard it could be linked into the Ada standard. We would then
like to have a way of extending scalar types to
national/industry/traditional units.

May be something like
type inches is metres tagged .....
but that is only an implementation idea.


The challenge would be to mould this into the Ada style.
I am looking forward to see how easy this is.

Ian

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

I'm liking this idea a lot!

Supposing the revision adds a package:


   package Ada.Units

      type Unit_Type is private;

      Unitless : constant Unit_Type;

      Meter    : constant Unit_Type;
      Kilogram : constant Unit_Type;
      Second   : constant Unit_Type;
      Ampere   : constant Unit_Type;
      Kelvin   : constant Unit_Type;
      Mole     : constant Unit_Type;
      Candela  : constant Unit_Type;

      function Is_Unitless (The_Unit: in Unit_Type) return Boolean;

      function "*" (Left, Right: Unit_Type) return Unit_Type;
      function "/" (Left, Right: Unit_Type) return Unit_Type;

      function "**" (Left: Unit_Type; Right: Integer) return Unit_Type;

      function "*" (Left: Unit_Type; Right: universal_real) return
Unit_Type;
      function "*" (Left: universal_real; Right: Unit_Type) return
Unit_Type;
      function "/" (Left: Unit_Type; Right: universal_real) return
Unit_Type;
      function "/" (Left: universal_real; Right: Unit_Type) return
Unit_Type;

   end Ada.Units;


We can declare our own units, e.g.:


   Foot: constant Ada.Units.Unit_Type := Meter * 0.3048;


Then we can declare a 'unit-specific' (fixed-point) type:


   type Accelerometer_Reading is
      delta 0.02 range -4.7 .. +4.7 unit Foot/Second**2;


This form has the problem of introducing a new reserved word ("unit"), but I
feel this is more appropriate, since the unit is an aspect of the 'key
abstraction' of the type (rather than just a matter of implementation or
checking). Fixed-point types could nevertheless have an attribute Unit (with
the special dispensation for reserved words accorded Range etc).

If we then declared e.g.:


   type Acceleration is
      delta 0.01 range -50.0 .. +50.0 unit Meter/Second**2;

   Reading: Accelerometer_Reading;
   Rate_of_Ascent: Acceleration;


we could convert from one type to another the normal way:


   Rate_of_Ascent := Acceleration(Reading);


which would cause a scaling multiplication (if necessary). Furthermore, view
conversions work perfectly:


   procedure Adjust_for_Wind (RoA: in out Acceleration);

   ...

   Adjust_for_Wind(Acceleration(Reading));


The appropriate scaling is performed for the variable Reading on the way in
and (the inverse scaling) on the way out.

Possibly one advantage of this scheme is that a compiler could opt out of
doing the dimension checking without causing any problem (other than the
actual lack of checking, of course!).

The standard type Duration could be declared:


   type Duration is delta ... range ... unit Ada.Units.Second;


Fixed-point types without the 'unit' part in the declaration would default
to being 'unitless'. Predefined operations between a unitless fixed-point
type and a unit-specific one would work as currently, with no dimension
checking, and the reult would also be unitless. This would be vital for
maintaining code continuity, of course, but also I suspect that unitless
fixed-point types would continue to have a vital role as intermediary types
for calculation and other processing.

I don't believe unit specification (and therefore dimension checking) is
applicable to floating-point types. They may be used for various purposes
(perhaps often when a fixed-point type ought to be used), but a
floating-point number is conceptually a ratio, and therefore implicitly
unitless (and dimension-indeterminate). If they are used for intermediate
calculations, that's too bad (a good programmer will take extra precautions
if practicable).

There's the question of private types. I feel that the requisite conversions
and other mixed operations should be provided for a private type explicitly
(in its package spec), and that these operations should do the requisite
conversion and checking, which may well be more complicated than mere
scaling and dimensionality. The unit facilities would, of course, be
applicable to those components which were of unit-specific (fixed-point)
types.

Three further notes need to be made.

(1) I am not sure if the (seven) SI units I have presented are the complete
set of basic units required in reality.

(2) Dimensional analysis could extend (from the basic MLT) to temperature,
amount of matter, and electrical current. But I don't know if it would be
practical for these 'extra' dimensions (or any others) to be included in the
checking.

(3) I have not provided for units that are offset from the SI units' zero
points (which are presumably all at the corresponding 'physical' zero
point). I believe some other post suggested that this tends to be a fairly
cosmetic matter anyway.

--
Best wishes,
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

Some details.

Fixed point types and objects would have the attribute Unit, of type
Ada.Units.Unit_Type. A 'unit' (a value of this type) has two (notional or
actual) components: its 'dimensionality', of type Ada.Units.Dimensionality,
obtainable by the function Dim; and its 'scaling', of type universal_real,
obtainable by the function Scaling.

The types Ada.Units.Unit_Type and Ada.Units.Dimensionality would be 'static'
subtypes: a constant of such a subtype whose initial value is static, is
itself static.

The Ada.Units package would include (in addition to what I said in my
previous post):


   function "*" (Left: Unit_Type; Right: universal_integer) return
Unit_Type;
   function "*" (Left: universal_integer; Right: Unit_Type) return
Unit_Type;
   function "/" (Left: Unit_Type; Right: universal_integer) return
Unit_Type;
   function "/" (Left: universal_integer; Right: Unit_Type) return
Unit_Type;

   function "**" (Left: Unit_Type; Right: universal_integer) return
Unit_Type;

   function Scaling (The_Unit: in Unit_Type) return universal_real;

   type Dimensionality is private;

   function Dim (The_Unit: in Unit_Type) return Dimensionality;


For the (explicit) conversion between two unit-specific (fixed point) types,
their dimensionalities must be the same. Conversion between a unit-specific
and a non-unit-specific type entails no dimensionality check.

The value of Scaling(T'Unit) for any non-unit-specific fixed point type T is
always 1.0.

For the value conversion:


   T1(X)


where X is of type T2, where T1 and T2 are both fixed point, the value of
the result would be the value of X*Scaling(T1'Unit)/Scaling(T2'Unit).

For the view conversion (an actual parameter):


   T1(X)


where X is of type T2, where T1 and T2 are both fixed point, the value
passed in (to the subprogram being called) would be the value of
X*Scaling(T1'Unit)/Scaling(T2'Unit), and the value passed out (back into X)
would be the value of X*Scaling(T2'Unit)/Scaling(T1'Unit).


There would be the following extra rules for the predefined multiplication
and division operations. For multiplication:


   function "*"(Left:  in universal_fixed;
                Right: in universal_fixed) return universal_fixed;


the value of the result is the value of
(Left*Scaling(Left'Unit))*(Right*Scaling(Right'Unit)), and, if the expected
type is unit-specific, it must have the same dimensions as
Dim(Left'Unit*Right'Unit).

For division:


   function "/"(Left:  in universal_fixed;
                Right: in universal_fixed) return universal_fixed;



the value of the result is the value of
(Left*Scaling(Left'Unit))/(Right*Scaling(Right'Unit)), and, if the expected
type is unit-specific, it must have the same dimensions as
Dim(Left'Unit/Right'Unit).


For predefined exponentiation of any fixed point type T1, the function
declaration becomes:


   function "**"(Left:  in T1;
                 Right: in Integer'Base) return T2;



the value of the result is the value of (Left*Scaling(Left'Unit))**Right,
and, if the type T1 is unit-specific, T2 is an anonymous fixed point type
which is the same as T1 except that it has the dimensions of
Left'Dimensionality**Right (otherwise T2 is identical to T1).

In all other cases the semantics are as in Ada 95.

--
Best wishes,
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message

news:9v0crt$bo2bi$1@ID-25716.news.dfncis.de...
> I'm liking this idea a lot!
>
> Supposing the revision adds a package:
[snip]

Would you not prefer a solution in which no particular set of units was
built in to the core language?  That is, I think it would be fine if the
standard library had a package Ada.SI_Units or whatever, written in ordinary
Ada 20xx (a unit-aware language), just to save everyone the trouble of
writing it themselves, but I don't think that the core language itself
should have any intrinsic units.  Please comment!

>
>
> We can declare our own units, e.g.:
>
>
>    Foot: constant Ada.Units.Unit_Type := Meter * 0.3048;
>

I think that units should be their own entity in the language, not fudged up
with a magic type and magic quasi-values.  The language in the RM defining
the semantics of names, values, types and objects is pretty carefully
constructed, and it seems like your syntax would really gum it up :-).  That
is, he definitions of type, value, and constant object, and just about
everything else in the RM that these things touch, would all have to be
qualified and special-cased to accomodate the quasi-type, quasi-values and
quasi-constant-objects that support your magic.

You'd rather want to write something like this:

    unit Meter;    -- a base unit

    unit Meters_Squared is Meter ** 2;    -- a derived unit

(Of course the names there are not the point).  But, you get the idea,
right?

Then,

    type Length is range 0.0 .. whatever;
    for Length'Units use Meter;

The declaration of Length is an ordinary type definition (and it's my very
own type so I can call it whatever sucky name I want -- the name here is not
the point, it's just an example).

>
> I don't believe unit specification (and therefore dimension checking) is
> applicable to floating-point types.

Why in the world not?

> They may be used for various purposes
> (perhaps often when a fixed-point type ought to be used), but a
> floating-point number is conceptually a ratio, and therefore implicitly
> unitless (and dimension-indeterminate).

whaaaaaaahhhh?

Nick, did you drop a little too much acid, back in the hippie days? :-)

Bet seriously... you're gonna have to explain that one to me (your theory
about numbers -- not about the acid! :-)

>
> There's the question of private types. I feel that the requisite
conversions
> and other mixed operations should be provided for a private type
explicitly
> (in its package spec), and that these operations should do the requisite
> conversion and checking, which may well be more complicated than mere
> scaling and dimensionality. The unit facilities would, of course, be
> applicable to those components which were of unit-specific (fixed-point)
> types.

I'm not sure quite what you're getting at there, but it sounds like it might
be related to an issue I've been thinking about, which is that these units
currently would not be able to work with "quasi-numeric" abstractions such
as people define for things like rational numbers, infinite-precision
arithmetic, etc.  However, fixing only that would be gold-plating the turd,
since these types would still have all the current problems of quasi-numeric
types as I summarized in a recent post (in response to Richard Reihle).  It
seems like the complete solution would be to add language support for
quasi-numeric types, i.e. something in the spec says "this type is private,
but it has certain properties such that you can treat it as a numeric type".
I think this is do-able within reason.  The scheme would have to involve
certain required attribute definition clauses (e.g. to specify conversion
functions to and from true numeric types).  I haven't really thought this
part through yet.

Here's some other things I've thought about so far on the unit stuff...

1) You have to be able to handle logarithmic units... that's easy, for a
unit U:

    U'Log (B)    -- denotes the log to the base B of U
    U'Exp (B)    -- denotes B to the power U


2) There's a bad problem with generics.  Unit-safe programming totally
destroys the generic contract model.  For example... given this:

    generic
        type T is digits <>;
    function F (X, Y : T) return T;

How can you tell if this is legal?:

    type T is [whatever...];
    for T'Unit use [whatever...];        -- T is a dimensioned type
    .
    .
    .
    function Ft is new F (T);

You can't!  (It's much easier to ID the ends of a CatDog spinning in an
inertial frame of reference :-).  If F looks like this

    function F (X, Y : T) return T is
    begin
        return X + Y;
    end T;

then we're as happy as clams, but if it is this:

    function F (X, Y : T) return T is
    begin
        return X * Y;
    end T;

then we've got trouble!

I think I can see my way through to figuring out how to do the actual proof
checking on the units, but still the idea of a semantic dependency of an
instance on a body is unprecedented.  The Powers That Be would have to
decide that unit-safe programming is Worth It to allow this when generics
are instantiated on dimensioned types.  In terms of the implementation, you
would have a legality check that actually takes place after everything is
compiled!  It would have to be done by the "prelinker" or whatever tool is
first exposed to all the units that are going to compose the partition being
run.

3) Checking that the system of units established by the currently visible
set of unit definitions is self-consistent.

>
> Three further notes need to be made.
>
> (1) I am not sure if the (seven) SI units I have presented are the
complete
> set of basic units required in reality.

Doesn't matter, specific units should not be built in...

>
> (2) Dimensional analysis could extend (from the basic MLT) to temperature,
> amount of matter, and electrical current. But I don't know if it would be
> practical for these 'extra' dimensions (or any others) to be included in
the
> checking.
>

See above :-)

> (3) I have not provided for units that are offset from the SI units' zero
> points (which are presumably all at the corresponding 'physical' zero
> point). I believe some other post suggested that this tends to be a fairly
> cosmetic matter anyway.
>

No problem:

    Unit_B is Unit_A + Bias;


I think you are on the right track though, as far as what we need units to
do for us: fully static, compile-time checking with inference of derived
dimensions, and automatically reversible and composable unit conversions.
Let's keep our thinkin' caps on... :-)

Cheers,
Mark Lundquist

Re: Dimensionality Checking (Ada 20XX)

[James Rogers]

Mark Lundquist wrote:
> 
> Would you not prefer a solution in which no particular set of units was
> built in to the core language?  That is, I think it would be fine if the
> standard library had a package Ada.SI_Units or whatever, written in ordinary
> Ada 20xx (a unit-aware language), just to save everyone the trouble of
> writing it themselves, but I don't think that the core language itself
> should have any intrinsic units.  Please comment!

I agree. The basic language capability of units should not declare any
particular set of units.

The SI_Units package proposed can be useful, but also terribly limiting.
The chosen units would be inappropriate for calculations dealing with
submolecular physics, or astronomy. Neither of these fields should be
systematically ignored by Ada.

Jim Rogers
Colorado Springs, Colorado USA

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:3C141540.96E5EB0D@worldnet.att.net...
> Mark Lundquist wrote:
> >
> > Would you not prefer a solution in which no particular set of units was
> > built in to the core language?  That is, I think it would be fine if the
> > standard library had a package Ada.SI_Units or whatever, written in
ordinary
> > Ada 20xx (a unit-aware language), just to save everyone the trouble of
> > writing it themselves, but I don't think that the core language itself
> > should have any intrinsic units.  Please comment!
>
> I agree. The basic language capability of units should not declare any
> particular set of units.
>
> The SI_Units package proposed can be useful, but also terribly limiting.
> The chosen units would be inappropriate for calculations dealing with
> submolecular physics, or astronomy. Neither of these fields should be
> systematically ignored by Ada.


Perhaps I did not make it clear enough, but the user can declare her own
units using the predefined units as a base, e.g.:


   Parsec:   constant Unit_Type := Ada.Units.Meter * 3.01e16;
   Angstrom: constant Unit_Type := Ada.Units.Meter * 10.0e-10;


User-defined dimensions could be accommodated by making the Ada.Units
package generic, and maybe renaming it, e.g.:


   generic
      type Dimension is (<>);

   package Ada.Dimension_Checking is

      type Dimensionality is array (Dimension) of Integer;

      type Scaling_Factor is digits ...; -- highly accurate

      type Unit_Type is
         record
            Is_Unitless: Boolean := True;
            Dim: Dimensionality := (others => 0);
            Scaling: Scaling_Factor := 1.0;
         end record;

      Unitless: constant Unit_Type := (Is_Unitless => True, Scaling => 1.0);

      -- functions "*", "/", and "**"

   end Ada.Dimension_Checking;


There might then be:


   package Ada.ISO_Units is

      type ISO_Dimension is (Mass, Length, Time, Temperature, Matter,
Current);

      package ISO_Dimension_Checking is new
Ada.Dimension_Checking(ISO_Dimension);

      subtype Unit_Type is ISO_Dimension_Checking.Unit_Type;

      Meter: constant Unit_Type := (Is_Unitless => False,
                                    Dim         => (Length => 1, others =>
0),
                                    Scaling     => 1.0);

      -- etc.

   end Ada.ISO_Units;


This complicates things for the compiler, so it would be nice if it were not
necessary.

--
Best wishes,
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

I should perhaps have put:


   type Dimensionality is array (Dimension) of root_real;


and there would then be a need for functions such as:


   function Log (U: in Unit_Type) return Unit_Type;

   function Log (U: in Unit_Type;
                 Base: in univ_real) return Unit_Type;

   function Exp (U: in Unit_Type) return Unit_Type;

   function "**" (Left:  in Unit_Type;
                  Right: in univ_real) return Unit_Type;


Can't get everything right first go! :-)

--
Best wishes,
Nick 'First Time' Roberts

Re: Dimensionality Checking (Ada 20XX)

[Thomas Koenig]

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

>   function Log (U: in Unit_Type) return Unit_Type;

Please, don't take the log of a unit.  Please.

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

"Thomas Koenig" <Thomas.Koenig@online.de> wrote in message
news:9v4fkq$2bl$1@mvmap66.ciw.uni-karlsruhe.de...
> Nick Roberts <nickroberts@adaos.worldonline.co.uk> wrote:
>
> >   function Log (U: in Unit_Type) return Unit_Type;
>
> Please, don't take the log of a unit.  Please.

I gather this would have nasty consequences. I am, in fact (if it isn't
obvious), pig ignorant about this subject, and I need plenty of guidance.

--
Best wishes,
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Thomas Koenig]

Nick Roberts <nickroberts@adaos.worldonline.co.uk> wrote:
>"Thomas Koenig" <Thomas.Koenig@online.de> wrote in message

>> Please, don't take the log of a unit.  Please.

>I gather this would have nasty consequences.

The logarithm of a unit does not have significance.  Think of
what a logarithm is (for example, the logarithm of base 10):

If 10^x = a, then x is the logarithm of a.

If you look at it that way, it's not hard to tell that no matter
how many times you multiply 10 with itself, you won't get 100 meter.

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Thomas Koenig" <Thomas.Koenig@online.de> wrote in message
news:9v5pmr$ftq$1@mvmap66.ciw.uni-karlsruhe.de...
>
> The logarithm of a unit does not have significance.

Decibels are the logarithm of something (actually, a multiple of a
logarithm), and that something has units, e.g. (typically) sound pressure in
micropascals (a pascal is 1 N/m**2).

The astronomical magnitude scale is logarithmic with respect to brightness.

pH is the negative log of the moles/L of H+.

The Richter magnitude scale is logarithmic.

Optical transmission density is logarithmic (don't know the units though).

-- mark

Re: Dimensionality Checking (Ada 20XX)

[Wilhelm Spickermann]

--On Mittwoch, Dezember 12, 2001 00:58:38 +0000 Mark Lundquist 
<mlundquist2@attbi.com> wrote:

>
> "Thomas Koenig" <Thomas.Koenig@online.de> wrote in message
> news:9v5pmr$ftq$1@mvmap66.ciw.uni-karlsruhe.de...
>>
>> The logarithm of a unit does not have significance.
>
> Decibels are the logarithm of something (actually, a multiple
> of a logarithm), and that something has units, e.g.
> (typically) sound pressure in micropascals (a pascal is 1
> N/m**2).

That something is a ratio of for instance currents or powers - a 
number without unit.

>
> The astronomical magnitude scale is logarithmic with respect
> to brightness.

It's a scaled logarithm of a *ratio* of brightnesses. The 
argument of the logarithm is a pure number.

>
> pH is the negative log of the moles/L of H+.

pH is the negative logarithm of the concentration of H+ divided 
by the concentration of H20 -- a pure number again.

>
> The Richter magnitude scale is logarithmic.

Logarithm of an energy ratio IIRC.

>
> Optical transmission density is logarithmic (don't know the
> units though).

I know nothing about that one... But there is no way to define 
taking the logarithm of something with a unit other than 1. Note 
that requiring the unit of something to be something predefined 
is just the obsolete way of taking a ratio.

Wilhelm

Re: Dimensionality Checking (Ada 20XX)

[Stephen Leake]

"Mark Lundquist" <mlundquist2@attbi.com> writes:

> "Thomas Koenig" <Thomas.Koenig@online.de> wrote in message
> news:9v5pmr$ftq$1@mvmap66.ciw.uni-karlsruhe.de...
> >
> > The logarithm of a unit does not have significance.
> 
> Decibels are the logarithm of something (actually, a multiple of a
> logarithm), and that something has units, e.g. (typically) sound pressure in
> micropascals (a pascal is 1 N/m**2).

Actually, Decibels are the log of a _ratio_ of sound pressure levels:

Db = 10 log P/P_0

where P_0 is a reference sound pressure. I don't have my physics book
handy (it's at home so my daughter can use it; wow!), so I don't
remember what the standard reference is.

> The astronomical magnitude scale is logarithmic with respect to
> brightness.

Again, log of a ratio, relative to some standard brightness.

> pH is the negative log of the moles/L of H+.

Hmm, that sounds right, but my chemistry book is at home also.

> The Richter magnitude scale is logarithmic.
> 
> Optical transmission density is logarithmic (don't know the units though).

The basic point is that it is fundamentally meaningless to pass a
value with non-unit dimensions to a transcendental function. All of
these examples must define some standard value, take a ratio, and then
take a log. Math is the language of physics, and it doesn't lie!

Hmm, this is getting a bit far from Ada :).

-- 
-- Stephe

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

In an effort to get back to Ada a bit ;-) I'll describe what I see logs and
exponentiations of units meaning, and how I see them working.

In my view of the proposed scheme, a 'unit' has two essential attributes: a
dimensionality; a scaling factor.

A 'dimensionality' is a factor (a real number) for each of a set of
dimensions.

For a certain dimensionality, a 'scaling factor' is the factor (also a real
number) by which a value in the unit must be multiplied to convert it to
some (actual or notional) canonical unit for that dimensionality.

Supposing our set of dimensions is {Mass, Length, Time}. The unit 'Meter'
would have the dimensionality (0, 1, 0), and let us choose for it the
scaling factor 1. The unit 'Foot' would then have the same dimensionality,
and a scaling factor of 0.3048 (approx.). A certain measurement, let us call
it 'NJRH' (my height), might be 5.95 foot. I intend that the Ada conversion
Meter(NJRH) would be predefined, and have the value 1.813 (approx.), as well
as the conversion Foot(Meter'(1.813)), having the value 5.95 (approx.).

We could imagine a unit (and I don't know whether this corresponds to custom
in physics) called, say 'Log_Foot', which is intended to represent the
natural logarithm of feet. It would have the dimensionality (0, 1/e, 0) and
a scaling factor of our choosing, let us choose 1. The value of NJRH in log
feet would be 1.783 (approx.).

I do not intend that the Ada conversion Log_Foot(NJRH) would be permitted,
nor Foot(Log_Foot'(1.783)). To achieve these conversions, it would be
necessary to use Log and Exp functions explicitly. Thus, instead of
Log_Foot(NJRH) we write Log(NJRH), and instead of Foot(Log_Foot'(1.783)) we
write Exp(Log_Foot'(1.783)).

Assuming (and this may be an assumption that has to be dropped) units are
built into Ada by means of -- having added an extra 'unit' attribute (in the
notional sense as well as actually adding the attribute 'Unit) to all scalar
types -- permitting the unit to be specified for fixed point types, it would
be necessary to provide a package such as this:


   generic
      type Proportional_Type is delta <>;
      type Logarithmic_Type is delta <>;
      Base: constant some_real_type := e;

   package Ada.Numerics.Generic_Logarithmic_Functions is

      function Log (X: in Proportional_Type) return Logarithmic_Type;
      function Exp (X: in Logarithmic_Type) return Proportional_Type;

   end;


This package would check, upon instantiation, that the dimensionalities of
Proportional_Type and Logarithmic_Type -- (Mp,Lp,Tp) and (Ml,Ll,Tl)
respectively, let's say -- are related in the correct way: Mp=Ml/e; Lp=Ll/e;
Tp=Tl/e. Typically, it should be possible for this check to be done at
compile time.

According to our example units, this package would be instantiated something
like this:


   package Foot_Log_Functions is
      new Ada.Numerics.Generic_Logarithmic_Functions(Foot,Log_Foot);

   use Foot_Log_Functions;


Now, having discussed this matter with my dad (a physicist), we still
couldn't agree whether this interpretation is correct, so I'd be really
grateful for any kind of (more) authoritative comment.

--
Best wishes,
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Stephen Leake]

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

> In an effort to get back to Ada a bit ;-) I'll describe what I see logs and
> exponentiations of units meaning, and how I see them working.

Ok!

> In my view of the proposed scheme, a 'unit' has two essential
> attributes: a dimensionality; a scaling factor.
> 
> A 'dimensionality' is a factor (a real number) for each of a set of
> dimensions.

Hmm. In physics, dimensionality is an integer. 

> For a certain dimensionality, a 'scaling factor' is the factor (also
> a real number) by which a value in the unit must be multiplied to
> convert it to some (actual or notional) canonical unit for that
> dimensionality.

Ok.

> Supposing our set of dimensions is {Mass, Length, Time}. The unit
> 'Meter' would have the dimensionality (0, 1, 0), and let us choose
> for it the scaling factor 1. The unit 'Foot' would then have the
> same dimensionality, and a scaling factor of 0.3048 (approx.). A
> certain measurement, let us call it 'NJRH' (my height), might be
> 5.95 foot. I intend that the Ada conversion Meter(NJRH) would be
> predefined, and have the value 1.813 (approx.), as well as the
> conversion Foot(Meter'(1.813)), having the value 5.95 (approx.).

Ok, but I'm not clear how to declare these in your new Ada.

> We could imagine a unit (and I don't know whether this corresponds
> to custom in physics) called, say 'Log_Foot', which is intended to
> represent the natural logarithm of feet. 

Nothing like this in physics; there is no need for it. But I'll keep
reading :).

> It would have the dimensionality (0, 1/e, 0) and a scaling factor of
> our choosing, let us choose 1. The value of NJRH in log feet would
> be 1.783 (approx.).

I'm not clear why a "dimensionality" of 1/e corresponds to the log of
feet, but then I don't know what log of feet means, so I guess you get
to define it. 

> I do not intend that the Ada conversion Log_Foot(NJRH) would be
> permitted, nor Foot(Log_Foot'(1.783)). To achieve these conversions,
> it would be necessary to use Log and Exp functions explicitly. Thus,
> instead of Log_Foot(NJRH) we write Log(NJRH), and instead of
> Foot(Log_Foot'(1.783)) we write Exp(Log_Foot'(1.783)).

But, how does the poor compiler know which conversions to allow, and
which to (pre)define?

> Assuming (and this may be an assumption that has to be dropped)
> units are built into Ada by means of -- having added an extra 'unit'
> attribute (in the notional sense as well as actually adding the
> attribute 'Unit) to all scalar types -- permitting the unit to be
> specified for fixed point types, 

Why are we still stuck on fixed point types? 

> it would be necessary to provide a package such as this:
> 
> 
>    generic
>       type Proportional_Type is delta <>;
>       type Logarithmic_Type is delta <>;
>       Base: constant some_real_type := e;
> 
>    package Ada.Numerics.Generic_Logarithmic_Functions is
> 
>       function Log (X: in Proportional_Type) return Logarithmic_Type;
>       function Exp (X: in Logarithmic_Type) return Proportional_Type;
> 
>    end;
> 
> 
> This package would check, upon instantiation, that the dimensionalities of
> Proportional_Type and Logarithmic_Type -- (Mp,Lp,Tp) and (Ml,Ll,Tl)
> respectively, let's say -- are related in the correct way: Mp=Ml/e; Lp=Ll/e;
> Tp=Tl/e. Typically, it should be possible for this check to be done at
> compile time.

Ok, sounds like you could make it consistent.

> According to our example units, this package would be instantiated
> something like this:
> 
> 
>    package Foot_Log_Functions is
>       new Ada.Numerics.Generic_Logarithmic_Functions(Foot,Log_Foot);
> 
>    use Foot_Log_Functions;
> 
> 
> Now, having discussed this matter with my dad (a physicist), we still
> couldn't agree whether this interpretation is correct, so I'd be really
> grateful for any kind of (more) authoritative comment.

Well, "correct" is a loaded term. I still maintain that, in physics,
log (meters) is _meaningless_, and _never_ occurs in a real-world
problem. So attempting to define its meaning in Ada is simply not
useful. You can define something that is self-consistent, but it won't
match physics.

I don't think you'll find a physics text that actually states "log
(meters) is meaningless and forbidden", because it seems obvious, but
I'll look in mine tonight. Maybe a high school text, where they
introduce the notion of measurement, would discuss this (I only have
my college text).

-- 
-- Stephe

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:u4rmv6ix4.fsf@gsfc.nasa.gov...
> "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:
>
> > In my view of the proposed scheme, a 'unit' has two essential
> > attributes: a dimensionality; a scaling factor.
> >
> > A 'dimensionality' is a factor (a real number) for each of a set of
> > dimensions.
>
> Hmm. In physics, dimensionality is an integer.

Yes indeed. As you were, gentlemen.

> > Supposing our set of dimensions is {Mass, Length, Time}. The unit
> > 'Meter' would have the dimensionality (0, 1, 0), and let us choose
> > for it the scaling factor 1. The unit 'Foot' would then have the
> > same dimensionality, and a scaling factor of 0.3048 (approx.). A
> > certain measurement, let us call it 'NJRH' (my height), might be
> > 5.95 foot. I intend that the Ada conversion Meter(NJRH) would be
> > predefined, and have the value 1.813 (approx.), as well as the
> > conversion Foot(Meter'(1.813)), having the value 5.95 (approx.).
>
> Ok, but I'm not clear how to declare these in your new Ada.

Something like this:


   type Basic_Dimension is (Mass, Length, Time);

   package Basic_Units is new Ada.Units(Basic_Dimension);

   Meter: constant Basic_Units.Unit_Type := (Dim     => (0, 1, 0),
                                             Scaling => 1.0);

   Foot: constant Basic_Units.Unit_Type := (Dim     => (0, 1, 0),
                                            Scaling => 0.3048);

   type Arm_Length is digits 5 range 0.0 .. 20.0 unit Meter;

   type Person_Height is delta 1.0/12 range 3.0 .. 9.0 unit Foot;

   NJRH: Person_Height := 5.95;


Then we can use normal type conversion to automatically convert between feet
and meters:


   Just_Long_Enough_to_Clip_Round_Ear: Arm_Length := Arm_Length( NJRH/2 );


> > It would have the dimensionality (0, 1/e, 0) and a scaling factor of
> > our choosing, let us choose 1. The value of NJRH in log feet would
> > be 1.783 (approx.).
>
> I'm not clear why a "dimensionality" of 1/e corresponds to the log of
> feet, but then I don't know what log of feet means, so I guess you get
> to define it.

It doesn't. This was a deliberate mistake to see who was still alert.

;-)

> > I do not intend that the Ada conversion Log_Foot(NJRH) would be
> > permitted, nor Foot(Log_Foot'(1.783)). To achieve these conversions,
> > it would be necessary to use Log and Exp functions explicitly. Thus,
> > instead of Log_Foot(NJRH) we write Log(NJRH), and instead of
> > Foot(Log_Foot'(1.783)) we write Exp(Log_Foot'(1.783)).
>
> But, how does the poor compiler know which conversions to allow, and
> which to (pre)define?

Conversions between units of the same dimensionality (of the same dimension
set) are predefined. No other conversions are predefined. Some other
conversions may be provided by predefined library units (generic ones).

> > Assuming (and this may be an assumption that has to be dropped)
> > units are built into Ada by means of -- having added an extra 'unit'
> > attribute (in the notional sense as well as actually adding the
> > attribute 'Unit) to all scalar types -- permitting the unit to be
> > specified for fixed point types,
>
> Why are we still stuck on fixed point types?

Oh shut up. :-) We're no longer stuck on fixed point types, okay?

> > it would be necessary to provide a package such as this:
> >
> >
> >    generic
> >       type Proportional_Type is delta <>;
> >       type Logarithmic_Type is delta <>;
> >       Base: constant some_real_type := e;
> >
> >    package Ada.Numerics.Generic_Logarithmic_Functions is
> >
> >       function Log (X: in Proportional_Type) return Logarithmic_Type;
> >       function Exp (X: in Logarithmic_Type) return Proportional_Type;
> >
> >    end;
> >
> >
> > This package would check, upon instantiation, that the dimensionalities
of
> > Proportional_Type and Logarithmic_Type -- (Mp,Lp,Tp) and (Ml,Ll,Tl)
> > respectively, let's say -- are related in the correct way: Mp=Ml/e;
Lp=Ll/e;
> > Tp=Tl/e. Typically, it should be possible for this check to be done at
> > compile time.
>
> Ok, sounds like you could make it consistent.

The above package would NOT do the check mentioned, it would do the
following simple check: squeal if the dimension sets of the units of the two
types are the same (i.e. ensure they are different).

In the above package, I suspect both types should be floating point, rather
than fixed point.

> I still maintain that, in physics,
> log (meters) is _meaningless_, and _never_ occurs in a real-world
> problem. So attempting to define its meaning in Ada is simply not
> useful. You can define something that is self-consistent, but it won't
> match physics.
>
> I don't think you'll find a physics text that actually states "log
> (meters) is meaningless and forbidden", because it seems obvious, but
> I'll look in mine tonight. Maybe a high school text, where they
> introduce the notion of measurement, would discuss this (I only have
> my college text).

You may be quite right. This is an area where I happily concede a disgusting
ignorance.

> --
> -- Stephe

--
Best wishes,
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

> You may be quite right. This is an area where I happily concede a
disgusting
> ignorance.

Well, no, this is an area where I UNhappily concede a disgusting ignorance.

:-(


--
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:ulmg8jz7r.fsf@gsfc.nasa.gov...

Stephe, thanks to you and also to Wilhelm Spickermann for jogging my memory.
Yes, of course... there always has to be an arbitrary reference point, to
correspond with a quantity of zero in the logarithmic unit (log(1) = 0; 1
what?)

>
> Actually, Decibels are the log of a _ratio_ of sound pressure levels:
>
> Db = 10 log P/P_0
>
> where P_0 is a reference sound pressure. I don't have my physics book
> handy (it's at home so my daughter can use it; wow!), so I don't
> remember what the standard reference is.
>
> > The astronomical magnitude scale is logarithmic with respect to
> > brightness.
>
> Again, log of a ratio, relative to some standard brightness.
>
> > pH is the negative log of the moles/L of H+.
>
> Hmm, that sounds right, but my chemistry book is at home also.

i.e. log of concentration, which is also a ratio (molarity in a given
solvent can also be expressed in w/w, ppm or whatever, which makes it more
obvious)

I get it now :-)...

Unit-safety/conversions would still have to support logarithmic units, but
it would define Log only for "dimensionless" in the sense we've been using
it (the sense that Nick, et al, finally got me to understand).

Cheers,
Mark

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

"Mark Lundquist" <no.spam@getalife.com> wrote in message
news:iRuS7.48801$wL4.360008@rwcrnsc51...

> ...
> I get it now :-)...
>
> Unit-safety/conversions would still have to support logarithmic units, but
> it would define Log only for "dimensionless" in the sense we've been using
> it (the sense that Nick, et al, finally got me to understand).

Some texts on the subject got me to understand this, too. The wonderful
Dmitry Kazakov even produced a proof for it. Cool huh?

I'm going to try to write up a detailed proposal for this idea, now. (In my
spare time, hah!)

--
Best wishes,
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Thomas Koenig]

James Rogers  <jimmaureenrogers@worldnet.att.net> wrote:

>The SI_Units package proposed can be useful, but also terribly limiting.
>The chosen units would be inappropriate for calculations dealing with
>submolecular physics, or astronomy. Neither of these fields should be
>systematically ignored by Ada.

In principle, this could be handled by declaring a certain variable
to be of type length and dimension of parsec (for example).

It should be allowed to add parsecs to angstrom; a reasonable
default would be to make the result of a+b to be the type of a.

Of course, assignment should then convert the value to whatever
the left hand side operator is.

People who like to specify thermal conductivity in
BTU/ft^2/(�F/in)... well, there's literature data out there which
specifies this.  I might just be tempted to draw the line there,
though :-)

Re: Dimensionality Checking (Ada 20XX)

[Wes Groleau]

Mark Lundquist wrote:
> > I don't believe unit specification (and therefore dimension checking) is
> > applicable to floating-point types.
> 
> Why in the world not?

Yeah, why not?

> 2) There's a bad problem with generics.  Unit-safe programming totally
> destroys the generic contract model.  For example... given this:
> 
>     generic
>         type T is digits <>;
>     function F (X, Y : T) return T;
> 
> How can you tell if this is legal?:

I've seen generics that were legal (in the sense of compiling)
but where the compiler was capable of rejecting particular
instantiations.  I've also seen instantiations where the illegality
was detected at run-time.  My memory is fuzzy on the details, though.

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

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Wes Groleau" <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote in message
news:3C14EF19.76C85864@sparc01.ftw.rsc.raytheon.com...
> Mark Lundquist wrote:
>
> > 2) There's a bad problem with generics.  Unit-safe programming totally
> > destroys the generic contract model.  For example... given this:
> >
> >     generic
> >         type T is digits <>;
> >     function F (X, Y : T) return T;
> >
> > How can you tell if this is legal?:
>
> I've seen generics that were legal (in the sense of compiling)
> but where the compiler was capable of rejecting particular
> instantiations.

Oh sure, that happens... it's as common as rocks, actually.

But the compiler only has to look at the generic *spec* to determine this.
What you *never* see today, and what we'd really like to avoid in any
language revision, is this: you make a change to the generic *body*, the
change is legal (the generic body compiles), but suddenly one or more
*instantiations* become illegal as a result.  That is the problem I'm
talking about with units.

Obviously, a solution would be to bring the unit specifications into the
contract, i.e. the generic formal part.

>  I've also seen instantiations where the illegality
> was detected at run-time.  My memory is fuzzy on the details, though.

Not by a conforming implementation :-).  RM 1.1.5(3) prohibits an illegality
from being detected at "run-time", i.e. by the execution (as defined in
10.2) itself.  Certain illegalities can be detected after compilation but
before execution (again in the strict sense), but only if they are covered
by "post-compilation rules" (1.1.5(4)).  But none of the "instatiation
errors" you usually see are due to post-compilation rules (there really are
not very many post-compilation rules in the standard).

-- mark

Re: Dimensionality Checking (Ada 20XX)

[Wes Groleau]

Mark Lundquist wrote:
> > I've seen generics that were legal (in the sense of compiling)
> > but where the compiler was capable of rejecting particular
> > instantiations.
> 
> Oh sure, that happens... it's as common as rocks, actually.
> 
> But the compiler only has to look at the generic *spec* to determine this.
> What you *never* see today, and what we'd really like to avoid in any
> language revision, is this: you make a change to the generic *body*, the
> change is legal (the generic body compiles), but suddenly one or more
> *instantiations* become illegal as a result.  That is the problem I'm
> talking about with units.

That is undesirable, but it did exist in Ada-83.


> >  I've also seen instantiations where the illegality
> > was detected at run-time.  My memory is fuzzy on the details, though.
> 
> Not by a conforming implementation :-).  RM 1.1.5(3) prohibits an illegality
> from being detected at "run-time", i.e. by the execution (as defined in

I think it was the case I mentioned earlier.  The generic body was legal
for some instantiations but not for others.  Since the instantiation
had already happened, only needing the spec per LRM, the problem raised
an exception at run-time instead of forcing a recompile of all
instantiations.

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

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Wes Groleau" <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote in message
news:3C151381.245413EB@sparc01.ftw.rsc.raytheon.com...
>
>
> Mark Lundquist wrote:
> > But the compiler only has to look at the generic *spec* to determine
this.
> > What you *never* see today, and what we'd really like to avoid in any
> > language revision, is this: you make a change to the generic *body*, the
> > change is legal (the generic body compiles), but suddenly one or more
> > *instantiations* become illegal as a result.  That is the problem I'm
> > talking about with units.
>
> That is undesirable, but it did exist in Ada-83.

You're right, there was one case of this in Ada83.
-- mark

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

Sorry not to reply to this in full sooner.

"Mark Lundquist" <mlundquist2@attbi.com> wrote in message
news:haTQ7.21816$wL4.49551@rwcrnsc51...

> I think that units should be their own entity in the language, not fudged
up
> with a magic type and magic quasi-values.  The language in the RM defining
> the semantics of names, values, types and objects is pretty carefully
> constructed, and it seems like your syntax would really gum it up :-).
That
> is, he definitions of type, value, and constant object, and just about
> everything else in the RM that these things touch, would all have to be
> qualified and special-cased to accomodate the quasi-type, quasi-values and
> quasi-constant-objects that support your magic.

That's actually a bit of a vague argument. Could you be a bit more specific,
please? I would be grateful!

> You'd rather want to write something like this:
>
>     unit Meter;    -- a base unit
>
>     unit Meters_Squared is Meter ** 2;    -- a derived unit

Maybe, but then maybe this would be overkill. Is it really necessary?

> > I don't believe unit specification (and therefore dimension checking) is
> > applicable to floating-point types.
>
> Why in the world not?
>
> > They may be used for various purposes
> > (perhaps often when a fixed-point type ought to be used), but a
> > floating-point number is conceptually a ratio, and therefore implicitly
> > unitless (and dimension-indeterminate).
>
> whaaaaaaahhhh?
>
> Nick, did you drop a little too much acid, back in the hippie days? :-)
>
> Bet seriously... you're gonna have to explain that one to me (your theory
> about numbers -- not about the acid! :-)

It's easier to demonstrate than to actually explain. Show me a piece of
(genuine) Ada code that uses a floating point type to hold values that would
be usefully made unit-specific, and I'll show you how they certainly could,
and probably should, be held by a fixed point type instead.

I'm not actually trying to argue that floating point types should never be
used for non-unitless quantities. All I'm suggesting is that there is no
practical need to add the unit-specific facility to floating point types.
Furthermore, I think it would be horribly painful trying to do so (consider
Ada.Numerics).

> > There's the question of private types. I feel that the requisite
> conversions
> > and other mixed operations should be provided for a private type
> explicitly
> > (in its package spec), and that these operations should do the requisite
> > conversion and checking, which may well be more complicated than mere
> > scaling and dimensionality. The unit facilities would, of course, be
> > applicable to those components which were of unit-specific (fixed-point)
> > types.
>
> I'm not sure quite what you're getting at there, but it sounds like it
might
> be related to an issue I've been thinking about, which is that these units
> currently would not be able to work with "quasi-numeric" abstractions such
> as people define for things like rational numbers, infinite-precision
> arithmetic, etc.
> ...

Correct. (The example presented to me was Ada.Calendar.Time).

> Here's some other things I've thought about so far on the unit stuff...
>
> 1) You have to be able to handle logarithmic units... that's easy, for a
> unit U:
>
>     U'Log (B)    -- denotes the log to the base B of U
>     U'Exp (B)    -- denotes B to the power U

Or alternatively, sticking closer to my design, the package Ada.Units could
have functions Log and Exp. This presumably means that the dimensions of a
unit could be non-integral?

> 2) There's a bad problem with generics.  Unit-safe programming totally
> destroys the generic contract model.  For example... given this:
>
>     generic
>         type T is digits <>;
>     function F (X, Y : T) return T;

Can we assume:

   generic
      type T is delta <>;
   function F (X, Y : T) return T;

please? I don't think it is actually significant to this point, but just in
case!

> How can you tell if this is legal?:
>
>     type T is [whatever...];
>     for T'Unit use [whatever...];        -- T is a dimensioned type
>     .
>     .
>     .
>     function Ft is new F (T);
>
> You can't!

I think, at worst (for a shared-code generic), this means a dynamic check
would have to be performed at the instantiation.

> (It's much easier to ID the ends of a CatDog spinning in an
> inertial frame of reference :-).

You may laugh, but the geneticists are slowly getting there ;-) What does
puzzle me is ... um, how do I put it? ... how does poor CatDog perform
certain vital bodily functions?

> 3) Checking that the system of units established by the currently visible
> set of unit definitions is self-consistent.

Could you expand on this, please?

> > Three further notes need to be made.
> >
> > (1) I am not sure if the (seven) SI units I have presented are the
> complete
> > set of basic units required in reality.
>
> Doesn't matter, specific units should not be built in...

Right, see my other post introducing a generic dimensionality package.

> > (3) I have not provided for units that are offset from the SI units'
zero
> > points (which are presumably all at the corresponding 'physical' zero
> > point). I believe some other post suggested that this tends to be a
fairly
> > cosmetic matter anyway.
> >
>
> No problem:
>
>     Unit_B is Unit_A + Bias;

I suspect there is a problem. If we stick to just scaling, it means that we
can be certain conversion requires only one multiplication (plus another
one, for a view conversion, on the way back). Adding biasing to the scaling
would mean that such conversions could become arbitrarily complex; I think
that's unacceptable (and I know Prof. Dewar would have a fit ;-)

> I think you are on the right track though, as far as what we need units to
> do for us: fully static, compile-time checking with inference of derived
> dimensions, and automatically reversible and composable unit conversions.
> Let's keep our thinkin' caps on... :-)

Cool!

> Cheers,
> Mark Lundquist

--
Best wishes,
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Wes Groleau]

> It's easier to demonstrate than to actually explain. Show me a piece of
> (genuine) Ada code that uses a floating point type to hold values that would
> be usefully made unit-specific, and I'll show you how they certainly could,
> and probably should, be held by a fixed point type instead.

Five million lines of AN/BSY-2 submarine control system ?

> I'm not actually trying to argue that floating point types should never be
> used for non-unitless quantities. All I'm suggesting is that there is no
> practical need to add the unit-specific facility to floating point types.
> Furthermore, I think it would be horribly painful trying to do so (consider
> Ada.Numerics).

Ada was less than five years old when BSY-2 started,
so there were undoubtedly Ada features underused.
(There certainly were Ada features OVERused.)  So
likely some of the floating-point should have been
fixed point.  But don't forget the principal of
orthogonality. One feature shouldn't be artificially
tied to another.  If one numeric type allows units,
all should.

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

Re: Dimensionality Checking (Ada 20XX)

[Stephen Leake]

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

> It's easier to demonstrate than to actually explain. Show me a piece of
> (genuine) Ada code that uses a floating point type to hold values that would
> be usefully made unit-specific, and I'll show you how they certainly could,
> and probably should, be held by a fixed point type instead.

http://users.erols.com/leakstan/Stephe/Ada/Sal_Packages/index.htm,
file sal-gen_math-gen_dof_6.ads

This is part of the math library I used to implement robotics control
systems and satellite simulators.

The core type is a 6 dimensional "pose", consisting of a 3 dimensional
position vector (x, y, z) and a 3 dimensional rotation, represented by
a unit quaternion. The position vector should be in meters (or feet,
if you are a barbarian :), the quaternion is unitless.

For robotics, the position is computed by the forward kinematics
function; V = F (theta), where V is the (x, y, z) vector, and 'theta'
is the vector of joint angles.

The joint angles are properly represented by fixed point numbers,
since they have constant error. A joint angle is measured by hardware
with a fixed precision; the value is known to plus or minus 0.001
radians, for example. When you run that thru the function F, which
contains Sin, Cos, multiply, and add, you get a relative error; 'x' is
known to 1 percent. Thus x is properly represented by floating point.

More practically, most computers used for robotics and satellite
simulations support fast floating point, often faster and more precise
than integer. So there is no reason to use fixed point.

> I'm not actually trying to argue that floating point types should
> never be used for non-unitless quantities. 

Good

> All I'm suggesting is that there is no practical need to add the
> unit-specific facility to floating point types. 

I disagree. I started one, and gave up when I hit the combinatorial
explosion others have alluded to. It would be useful to find bugs
during unit test. 

The most practical implementation I've seen stores a count of the
order of the three basic dimensions (mass, length, time) with each
value. Multiply and divide add and subtract those counts; addition and
assignment check them. This is good for finding bugs, but it is too
much overhead for bug-free real-time execution.

> Furthermore, I think it would be horribly painful trying to do so
> (consider Ada.Numerics).

It is horribly painful, but not because of Ada.Numerics.

It is simply wrong to try to define units for trig and exponential
functions. Remember the Taylor expansion for Sin:

Sin (x) = x - 1/6 x**3 ...

If x has dimensions of meters (shudder :), then what are the
dimensions of Sin (x)? This is why angles must be dimensionless, as
radians are.

If you don't take the stored counts approach, you have zillions of
routines to write just sticking with SI units (meters * time,
meters**2 * time, (meters**2 * kg) * time**2, etc). Adding unit
conversion makes it far worse.

-- 
-- Stephe

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:upu5ln22l.fsf@gsfc.nasa.gov...
> "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:
>
> > It's easier to demonstrate than to actually explain. Show me a piece of
> > (genuine) Ada code that uses a floating point type to hold values that
would
> > be usefully made unit-specific, and I'll show you how they certainly
could,
> > and probably should, be held by a fixed point type instead.
>
> http://users.erols.com/leakstan/Stephe/Ada/Sal_Packages/index.htm,
> file sal-gen_math-gen_dof_6.ads
>
> This is part of the math library I used to implement robotics control
> systems and satellite simulators.
>
> The core type is a 6 dimensional "pose", consisting of a 3 dimensional
> position vector (x, y, z) and a 3 dimensional rotation, represented by
> a unit quaternion. The position vector should be in meters (or feet,
> if you are a barbarian :), the quaternion is unitless.
>
> For robotics, the position is computed by the forward kinematics
> function; V = F (theta), where V is the (x, y, z) vector, and 'theta'
> is the vector of joint angles.
>
> The joint angles are properly represented by fixed point numbers,
> since they have constant error. A joint angle is measured by hardware
> with a fixed precision; the value is known to plus or minus 0.001
> radians, for example. When you run that thru the function F, which
> contains Sin, Cos, multiply, and add, you get a relative error; 'x' is
> known to 1 percent. Thus x is properly represented by floating point.

This example, in fact, actually illustrates my point, I believe.

My point is that, because dimension checking could not be performed
statically inside the function F, and it would probably be unacceptably slow
to implement it dynamically, you lose nothing by not having the dimension
checking. Since you use radians throughout inside the function F, internal
unit conversion (scaling) is also not required.

Nevertheless, you get both dimension checking and unit conversion outside
function F. All non-unit-specific scalar types will be assumed to have a
scaling factor of 1.0. So, e.g.:


   type Joint_Angle is delta 0.001 range ... unit Angular_Degree;

   -- Angular_Degree has scaling factor pi/180

   function F (A: Float) return Float; -- in radians

   A1, A2: Joint_Angle;

   ...

   Read(Detector(D),A1);
   A2 := Joint_Angle( F( Float(A1) ) );


The conversion Float(A1) will multiply A1 by the scaling factor pi/180, thus
rendering it in radians, and the conversion Joint_Angle( ... ) will divide
the result by pi/180, hence converting it back into degrees. A1 and A2 will
both be specifically dimensionless (their dimensions are all 0), and for
calculations between them and other unit-specific (fixed point) types
dimension checking will be performed.

> More practically, most computers used for robotics and satellite
> simulations support fast floating point, often faster and more precise
> than integer. So there is no reason to use fixed point.

But nothing prevents a compiler from implementing fixed point
operations/representations using the hardware's floating point unit/format.
(Am I wrong?)

> > I'm not actually trying to argue that floating point types should
> > never be used for non-unitless quantities.
>
> Good
>
> > All I'm suggesting is that there is no practical need to add the
> > unit-specific facility to floating point types.
>
> I disagree. I started one, and gave up when I hit the combinatorial
> explosion others have alluded to. It would be useful to find bugs
> during unit test.
>
> The most practical implementation I've seen stores a count of the
> order of the three basic dimensions (mass, length, time) with each
> value. Multiply and divide add and subtract those counts; addition and
> assignment check them. This is good for finding bugs, but it is too
> much overhead for bug-free real-time execution.

I am suggesting that the proposed facility is designed so that most or all
checks could, in practice, be performed at compile-time. I suspect the
facility would have to be specified in the standard in terms of dynamic
semantics (because making it formally static would be just too nasty), but
this wouldn't prevent compilers from doing (most) things at compile-time in
practice.

Compilers should (be recommended to) provide a three-way switch, I suppose:
dimension checking off; dimension checking on (compile time if possible,
otherwise at run time); dimension checking only at compile time (run-time
checking simply removed, maybe with a warning).

> > Furthermore, I think it would be horribly painful trying to do so
> > (consider Ada.Numerics).
>
> It is horribly painful, but not because of Ada.Numerics.
>
> It is simply wrong to try to define units for trig and exponential
> functions. Remember the Taylor expansion for Sin:
>
> Sin (x) = x - 1/6 x**3 ...
>
> If x has dimensions of meters (shudder :), then what are the
> dimensions of Sin (x)? This is why angles must be dimensionless, as
> radians are.

Angles are dimensionless, as you correctly point out, but so is X (it is a
ratio). Hence, suppose we have a declaration such as this:


   generic
      type Ratio is delta <>;
      type Angle is delta <>;

   function Sin (X: in Ratio) return Angle;


Provided the types Ratio and Angle were both dimensionless, the internal
computations would all be dimensionless throughout (X**N is dimensionless,
for all N, if X is dimensionless). Hence the dimension checking would work
perfectly in this case (if either Ratio or Angle were not dimensionless, the
compiler should squeal). I believe it is likely a compiler would be able to
fully unroll the computation loop, and so do all the necessary checking at
compile-time. The instantiator of the function should choose a type for
Ratio which has a scaling factor of 1.0, and a type for Angle which
represents radians (and so also has a scaling factor of 1.0). So, shudder
not!

> If you don't take the stored counts approach, you have zillions of
> routines to write just sticking with SI units (meters * time,
> meters**2 * time, (meters**2 * kg) * time**2, etc). Adding unit
> conversion makes it far worse.

The whole idea of what is being proposed is to do away with all that (or
much of it).

>
> --
> -- Stephe

--
Best wishes,
Nick Roberts


PS: I have quoted at length, as I thought it necessary. Hope nobody minds.

Re: Dimensionality Checking (Ada 20XX)

[Mark Johnson]

Nick Roberts wrote:
> 
> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:upu5ln22l.fsf@gsfc.nasa.gov...
> [snip]
> > More practically, most computers used for robotics and satellite
> > simulations support fast floating point, often faster and more precise
> > than integer. So there is no reason to use fixed point.
> 
> But nothing prevents a compiler from implementing fixed point
> operations/representations using the hardware's floating point unit/format.
> (Am I wrong?)
Its been a while since I've done fixed point arithmetic, but I believe
you are wrong.

A simple example using 32 bit integers and floating point.
 Bam_Lsb : constant := 2.0*(-32);
 type Bam is delta Bam_Lsb range 0.0 .. (1.0 - Bam_Lsb);
About 25 years ago, we used a 16 bit version of this type for "binary
angles". Zero is zero degrees, 0.5 is 180 degrees, and so on. It has a
few other nice characteristics...
 - add and subtract is OK if modular arithmetic is supported [ignore
range checks]
 - multiply a Bam by a fixed point range gets a useful result [work it
out]
 - the error analysis is a lot easier [though most can't figure it out
anyway :-(]
and so on.

You can't represent a Bam in a 32 bit floating point - not enough
precision. Of course, our orbital models are now done in 64 bit floating
point, so the original comment is certainly accurate on a lot of systems
these days.

I would tend to use fixed point for the following cases...
 - interfaces to hardware
 - small target systems
 - where I need absolute control of error
and floating point everywhere else.
  --Mark

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

"Mark Johnson" <Mark_H_Johnson@Raytheon.com> wrote in message
news:3C168DB0.C139DC2@Raytheon.com...

> > But nothing prevents a compiler from implementing fixed point
> > operations/representations using the hardware's floating point
unit/format.
> > (Am I wrong?)

> Its been a while since I've done fixed point arithmetic, but I believe
> you are wrong.
> ...
> You can't represent a Bam in a 32 bit floating point - not enough
> precision. Of course, our orbital models are now done in 64 bit floating
> point, so the original comment is certainly accurate on a lot of systems
> these days.

That's actually exactly what I meant.

> I would tend to use fixed point for the following cases...
>  - interfaces to hardware
>  - small target systems
>  - where I need absolute control of error
> and floating point everywhere else.

With respect, Mark (and in deference to the practicalities of actual Ada
implementations), perhaps you shouldn't.

Or at least, perhaps in many of those cases where you use floating point
(because fixed point offers no great advantage), you would use a fixed point
(unit-specific) type so as to gain the advantage of dimension checking (or
unit conversion). Would it actually be problem to do this?

--
Best wishes,
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Stephen Leake]

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

> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:upu5ln22l.fsf@gsfc.nasa.gov...
> > "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:
> > <snip>
> > http://users.erols.com/leakstan/Stephe/Ada/Sal_Packages/index.htm,
> > file sal-gen_math-gen_dof_6.ads
> >
> > This is part of the math library I used to implement robotics control
> > systems and satellite simulators.
> > <snip>
> 
> This example, in fact, actually illustrates my point, I believe.
> 
> My point is that, because dimension checking could not be performed
> statically inside the function F, and it would probably be unacceptably slow
> to implement it dynamically, you lose nothing by not having the dimension
> checking. 

Well, I would do unit testing of F with dimension checking "turned
on". The equations in F are dimensionally correct, just complex.

> Since you use radians throughout inside the function F, internal
> unit conversion (scaling) is also not required.

Not true; lengths of the robot arm parts in F are in meters, the
result position vector is meters.

> Nevertheless, you get both dimension checking and unit conversion
> outside function F. All non-unit-specific scalar types will be
> assumed to have a scaling factor of 1.0. So, e.g.:
> 
> 
>    type Joint_Angle is delta 0.001 range ... unit Angular_Degree;
> 
>    -- Angular_Degree has scaling factor pi/180

Just a nit; I've learned to think in radians, so Degrees is not
needed. Actually, I require straight SI units, so scaling is _never_
required in my system, except to get from raw hardware readings to SI.

>    function F (A: Float) return Float; -- in radians
> 
>    A1, A2: Joint_Angle;
> 
>    ...
> 
>    Read(Detector(D),A1);
>    A2 := Joint_Angle( F( Float(A1) ) );

F returns a position vector (x, y, z), in meters. So I'm not clear
what this should be.

> The conversion Float(A1) will multiply A1 by the scaling factor
> pi/180, thus rendering it in radians, and the conversion
> Joint_Angle( ... ) will divide the result by pi/180, hence
> converting it back into degrees. A1 and A2 will both be specifically
> dimensionless (their dimensions are all 0), and for calculations
> between them and other unit-specific (fixed point) types dimension
> checking will be performed.

Well, if you want to have non-SI units, a standard scaling convention
would be useful. And you could have some types do dimension checking,
and others not. But tying that to the fixed-point/floating point
choice is not necessary; as someone else pointed out, these three
choices are orthogonal.

> > More practically, most computers used for robotics and satellite
> > simulations support fast floating point, often faster and more
> > precise than integer. So there is no reason to use fixed point.
> 
> But nothing prevents a compiler from implementing fixed point
> operations/representations using the hardware's floating point unit/format.
> (Am I wrong?)

That is true. Yet another reason to keep the choices orthogonal.

> > The most practical implementation I've seen stores a count of the
> > order of the three basic dimensions (mass, length, time) with each
> > value. Multiply and divide add and subtract those counts; addition and
> > assignment check them. This is good for finding bugs, but it is too
> > much overhead for bug-free real-time execution.
> 
> I am suggesting that the proposed facility is designed so that most or all
> checks could, in practice, be performed at compile-time. I suspect the
> facility would have to be specified in the standard in terms of dynamic
> semantics (because making it formally static would be just too nasty), but
> this wouldn't prevent compilers from doing (most) things at compile-time in
> practice.

Ah. I haven't been paying attention to this thread; I missed that you
are talking about a language extension.

> Compilers should (be recommended to) provide a three-way switch, I
> suppose: dimension checking off; dimension checking on (compile time
> if possible, otherwise at run time); dimension checking only at
> compile time (run-time checking simply removed, maybe with a
> warning).

This sounds nice. I still think you'll get an explosion of types, like
Meters, Meters_Squared, Meters_Per_Second, Meters_Per_Second_Squared.
How else do you specify the dimensions? So you'll still have to define
all the inter-type operations. I suppose you define some sort of
automatic operator generation for this, but that's an even bigger change.

> > > Furthermore, I think it would be horribly painful trying to do
> > > so (consider Ada.Numerics).
> >
> > It is horribly painful, but not because of Ada.Numerics.
> >
> > It is simply wrong to try to define units for trig and exponential
> > functions. Remember the Taylor expansion for Sin:
> >
> > Sin (x) = x - 1/6 x**3 ...
> >
> > If x has dimensions of meters (shudder :), then what are the
> > dimensions of Sin (x)? This is why angles must be dimensionless, as
> > radians are.
> 
> Angles are dimensionless, as you correctly point out, but so is X (it is a
> ratio).

Well, you said you would convince me of that, but I don't see any
argument for making X a ratio. I defined it as meters. I could pick
some arbitrary length (say the length of the robot forearm), and
define all other lengths in terms of that. But that would be horribly
confusing! What's wrong with meters for X?

> Hence, suppose we have a declaration such as this:
> 
> 
>    generic
>       type Ratio is delta <>;
>       type Angle is delta <>;
> 
>    function Sin (X: in Ratio) return Angle;

How is this different from Ada.Numerics.Generic_Elementary_Functions?
You can't apply scaling, since you have different powers of X involved.

> Provided the types Ratio and Angle were both dimensionless, the
> internal computations would all be dimensionless throughout (X**N is
> dimensionless, for all N, if X is dimensionless). Hence the
> dimension checking would work perfectly in this case (if either
> Ratio or Angle were not dimensionless, the compiler should squeal).
> I believe it is likely a compiler would be able to fully unroll the
> computation loop, and so do all the necessary checking at
> compile-time. 

If everything is dimensionless, what checking are you talking about?

> The instantiator of the function should choose a type for Ratio
> which has a scaling factor of 1.0, and a type for Angle which
> represents radians (and so also has a scaling factor of 1.0). So,
> shudder not!

If they have scaling of other than 1.0, it's just plain wrong (and the
compiler should complain). And if it is 1.0, you have not added any
functionality over Ada.Numerics.Generic_Elementary_Functions. So I
still shudder :).

> > If you don't take the stored counts approach, you have zillions of
> > routines to write just sticking with SI units (meters * time,
> > meters**2 * time, (meters**2 * kg) * time**2, etc). Adding unit
> > conversion makes it far worse.
> 
> The whole idea of what is being proposed is to do away with all that (or
> much of it).

Well, yes, but I don't see how you accomplish that. You still need one
type per dimensionality, and one type per scaling. 

-- 
-- Stephe

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:u7krtl5u8.fsf@gsfc.nasa.gov...

> > My point is that, because dimension checking could not be performed
> > statically inside the function F, and it would probably be unacceptably
slow
> > to implement it dynamically, you lose nothing by not having the
dimension
> > checking.
>
> Well, I would do unit testing of F with dimension checking "turned
> on". The equations in F are dimensionally correct, just complex.
>
> > Since you use radians throughout inside the function F, internal
> > unit conversion (scaling) is also not required.
>
> Not true; lengths of the robot arm parts in F are in meters, the
> result position vector is meters.

I'll want to investigate this, but it sounds like you have a fair point,
then.

> F returns a position vector (x, y, z), in meters. So I'm not clear
> what this should be.

Something like:


   V := F(...);
   A := ( Joint_Angle(V.X), Joint_Angle(V.Y), Joint_Angle(V.Z) );


That's all.


> as someone else pointed out, these three
> choices are orthogonal.

I'm not arguing about that. It would be nice to provide the facility for
floating point numbers, I don't deny it. I just think it would be hard,
that's all. But if it's needed, then it's needed.

> I still think you'll get an explosion of types, like
> Meters, Meters_Squared, Meters_Per_Second, Meters_Per_Second_Squared.
> How else do you specify the dimensions?

This is correct (you'll get a lot of types, one for each unit, which
encompases a dimensionality and a scaling factor).

> So you'll still have to define
> all the inter-type operations. I suppose you define some sort of
> automatic operator generation for this, but that's an even bigger change.

Many (most?) of the required inter-type operations will be provided as
predefined operations. This in itself is not a big change, since Ada 95
already provides it!

> > Angles are dimensionless, as you correctly point out, but so is X (it is
a
> > ratio).
>
> Well, you said you would convince me of that, but I don't see any
> argument for making X a ratio. I defined it as meters. I could pick
> some arbitrary length (say the length of the robot forearm), and
> define all other lengths in terms of that. But that would be horribly
> confusing! What's wrong with meters for X?

See other posts in this thread. X must be 'dimensionless' in the sense of
having dimensions of all 0.

--
Best wishes,
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Stephen Leake]

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

> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:u7krtl5u8.fsf@gsfc.nasa.gov...
> 
> > F returns a position vector (x, y, z), in meters. So I'm not clear
> > what this should be.
> 
> Something like:
> 
> 
>    V := F(...);
>    A := ( Joint_Angle(V.X), Joint_Angle(V.Y), Joint_Angle(V.Z) );
> 
> 
> That's all.

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

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

Where Cartesian_Position does some scaling. 

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

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

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

> > I still think you'll get an explosion of types, like Meters,
> > Meters_Squared, Meters_Per_Second, Meters_Per_Second_Squared. How
> > else do you specify the dimensions?
> 
> This is correct (you'll get a lot of types, one for each unit, which
> encompases a dimensionality and a scaling factor).
> 
> > So you'll still have to define
> > all the inter-type operations. I suppose you define some sort of
> > automatic operator generation for this, but that's an even bigger change.
> 
> Many (most?) of the required inter-type operations will be provided as
> predefined operations. This in itself is not a big change, since Ada 95
> already provides it!

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

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

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

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

Ada 95 _does_ define the following, which is wrong:

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


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

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

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

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

> > > Angles are dimensionless, as you correctly point out, but so is
X (it is > a > > > ratio).
> >
> > Well, you said you would convince me of that, but I don't see any
> > argument for making X a ratio. I defined it as meters. I could pick
> > some arbitrary length (say the length of the robot forearm), and
> > define all other lengths in terms of that. But that would be horribly
> > confusing! What's wrong with meters for X?
> 
> See other posts in this thread. X must be 'dimensionless' in the sense of
> having dimensions of all 0.

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

-- 
-- Stephe

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:upu5kjzgq.fsf@gsfc.nasa.gov...

> Well, V is _not_ a vector of "angles", it is a vector of "Cartesian
> positions". I guess you should do:
>
> V := F (...);
> M := Cartesian_Position (V);
>
> Where Cartesian_Position does some scaling.
>
> But I repeat, I see no advantage here. I can easily and efficiently
> define F to return a vector of meters.

Hah! That's a comment that O will touch upon further down.

> > I'm not arguing about that. It would be nice to provide the facility for
> > floating point numbers, I don't deny it. I just think it would be hard,
> > that's all. But if it's needed, then it's needed.
>
> Huh? Why would it be harder for float than fixed?

I've mulled this one over. This issue has a lot of subtleties. I think the
basic answer is that floating point types could also have units. However,
questions remain in my mind as to the actual usage of such types.

I won't go through the whole thing in laborious detail here, but the essence
is that unit-specific floating point types may need (or tend to make use of)
the ability to specify and check units dynamically. E.g.:

   ...
   Read(Datafile,Scaling);
   declare
      Length_Unit: constant Unit_Type := (Length_Dim,Scaling);
      type Length is digits 5 unit Length_Unit;
   begin
      while not End_of_File(Datafile) loop
         Read(Datafile,V.X);
         Read(Datafile,V.Y);
         Read(Datafile,V.Z);
         ...

The point of this example is that the scaling factor of the unit to be used
for the floating point type Length is read in (dynamically) from the front
of a data file, enabling the units of the data in the file to be chosen
(feet, meters, whatever). This is acceptable, because the type (being
floating point) has relative error. The dimensions, Length_Dim, are still
static, but the unit, Length_Unit, is not. Would compilers still be able to
perform the dimension checking at compile-time? It is this sort of question
that complicates the issue a bit.

> > Many (most?) of the required inter-type operations will be provided as
> > predefined operations. This in itself is not a big change, since Ada 95
> > already provides it!
>
> Um, no. In Ada 95, I can do:
>
> type Meters is digits ...;
> type Seconds is digits ...;
> type Meters_Per_Second is digits ...;
>
> Ada 95 does _not_ define the following, which is needed:
>
> function "/" (Left : in Meters; Right in Seconds) return
> Meters_Per_Second;

It does if you use fixed point instead of floating point types. This was one
of the reasons why I felt it would be harder to add units to floating point
types.

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

So why did you give it as an example?

>
> --
> -- Stephe

--
Best wishes,
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

> Hah! That's a comment that O will touch upon further down.

I meant: That's a comment that I will touch upon further down.

And I never really did. My point simply is that you can indeed dynamically
convert between feet, meters, inches, angstroms, parsecs, etc. within a
single floating point type (usually) with impunity. You can't generally do
this within one fixed point type; you can convert from one fixed point type
to another, if their deltas and ranges are appropriately set, but these must
be static.

--
Nick

RE: Dimensionality Checking (Ada 20XX)

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Nick Roberts et al.
"you can convert from one fixed point type to another, if their deltas and
ranges are appropriately set, but these must be static."

This is both true and unfortunate. I can understand that because of
backwards compatibility and perhaps safety issues and compiler issues why
the default for the compiler must remain static. However, I believe that a
trap-door should be created, at least for type decimal, to permit the deltas
and digits to be changed at run-time with the obvious proviso that they stay
within the capabilities of the compiler. They could be specified as part of
a generic.

In the pre-calculator period, when I started in science, we used
slide-rules. The exponent was calculated by summing the numerators and
subtracting the sum of the denominators. It would be useful if a 1 Gigahertz
computer had the capabilities of a simple, analog device that consisted of
two pieces of wood and a transparent plastic slider. One other approach is
to support a decimal floating point type.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Nick Roberts
Sent: Thursday, December 13, 2001 2:23 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Dimensionality Checking (Ada 20XX)


> Hah! That's a comment that O will touch upon further down.

I meant: That's a comment that I will touch upon further down.

And I never really did. My point simply is that you can indeed dynamically
convert between feet, meters, inches, angstroms, parsecs, etc. within a
single floating point type (usually) with impunity. You can't generally do
this within one fixed point type; you can convert from one fixed point type
to another, if their deltas and ranges are appropriately set, but these must
be static.

--
Nick

Re: Dimensionality Checking (Ada 20XX)

[Stephen Leake]

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

> > Hah! That's a comment that O will touch upon further down.
> 
> I meant: That's a comment that I will touch upon further down.
> 
> And I never really did. My point simply is that you can indeed dynamically
> convert between feet, meters, inches, angstroms, parsecs, etc. within a
> single floating point type (usually) with impunity. You can't generally do
> this within one fixed point type; you can convert from one fixed point type
> to another, if their deltas and ranges are appropriately set, but these must
> be static.

I see. This is true. 

But for the purposes of verifying the dimensionality of equations
coded in Ada, it is orthogonal. So I'd still like any units facility
to support both float and fixed.

-- 
-- Stephe

Re: Dimensionality Checking (Ada 20XX)

[Stephen Leake]

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

> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:upu5kjzgq.fsf@gsfc.nasa.gov...

> > > Many (most?) of the required inter-type operations will be provided as
> > > predefined operations. This in itself is not a big change, since Ada 95
> > > already provides it!
> >
> > Um, no. In Ada 95, I can do:
> >
> > type Meters is digits ...;
> > type Seconds is digits ...;
> > type Meters_Per_Second is digits ...;
> >
> > Ada 95 does _not_ define the following, which is needed:
> >
> > function "/" (Left : in Meters; Right in Seconds) return
> > Meters_Per_Second;
> 
> It does if you use fixed point instead of floating point types. This was one
> of the reasons why I felt it would be harder to add units to floating point
> types.

Ah. LRM 4.5.5 (19). I had forgotten that. 

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

Well, I guess it was confusing. I was overloading X, and the overload
resolution algorithm was not clear. That's why I like specifying
algorithms in Ada, instead of in Math :).

-- 
-- Stephe

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:upu5ln22l.fsf@gsfc.nasa.gov...
>
> It is simply wrong to try to define units for trig and exponential
> functions. Remember the Taylor expansion for Sin:
>
> Sin (x) = x - 1/6 x**3 ...
>
> If x has dimensions of meters (shudder :), then what are the
> dimensions of Sin (x)?

Hokey smokes, it's the ratio of two sides of a triangle, so its dimensions
are Distance/Distance!  Forget the Taylor series!

> This is why angles must be dimensionless, as
> radians are.

Angles are not dimensionless.  They are the ratio of distance around the
circumference to the radius.  That's why for radian, there's 2 * Pi of 'em
in a circle.  The SI defines the units of radians as (m * m**-1) ('m' stands
for 'meters').  I don't get why people keep saying radians are
dimensionless.

Cheers,
Mark

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

"Mark Lundquist" <mlundquist2@attbi.com> wrote in message
news:30wR7.37507$Yy.396223@rwcrnsc53...
> Angles are not dimensionless.  They are the ratio of distance around the
> circumference to the radius.  That's why for radian, there's 2 * Pi of 'em
> in a circle.  The SI defines the units of radians as (m * m**-1) ('m'
stands
> for 'meters').  I don't get why people keep saying radians are
> dimensionless.

Ow! In this context' dimensionless' means 'having dimensions that are zero'
rather than 'not having any dimensions'. (Fairly common physics textbook
terminology.) So, in this sense, angles are dimensionless (their dimensions
are all zero).

--
Best wishes,
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:9v6cn6$dcfkh$2@ID-25716.news.dfncis.de...
>
> Ow! In this context' dimensionless' means 'having dimensions that are
zero'
> rather than 'not having any dimensions'. (Fairly common physics textbook
> terminology.) So, in this sense, angles are dimensionless (their
dimensions
> are all zero).

I get it.

thx,
-- mark

Re: Dimensionality Checking (Ada 20XX)

[Stephen Leake]

"Mark Lundquist" <mlundquist2@attbi.com> writes:

> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:upu5ln22l.fsf@gsfc.nasa.gov...
> >
> > It is simply wrong to try to define units for trig and exponential
> > functions. Remember the Taylor expansion for Sin:
> >
> > Sin (x) = x - 1/6 x**3 ...
> >
> > If x has dimensions of meters (shudder :), then what are the
> > dimensions of Sin (x)?
> 
> Hokey smokes, it's the ratio of two sides of a triangle, so its
> dimensions are Distance/Distance! Forget the Taylor series!

True. But Sin also appears in places that have nothing to do with
triangles, and other functions in Ada.Numerics are also unrelated to
geometry. So the point about Taylor expansions is more general, and I
think makes it clearer about why it is simply wrong to try to define
Sin (meters).

> > This is why angles must be dimensionless, as
> > radians are.
> 
> Angles are not dimensionless.  They are the ratio of distance around the
> circumference to the radius.  That's why for radian, there's 2 * Pi of 'em
> in a circle.  The SI defines the units of radians as (m * m**-1) ('m' stands
> for 'meters').  I don't get why people keep saying radians are
> dimensionless.

Well, in my book m * m ** -1 == 1, so that's dimensionless. I think
this SI definition is silly, but clearly we have to live with it. We
are arguing over a minor point in the meaning of "dimensionless".

The point is, to be meaningful for Sin, the argument x must have no
dimensions. Another way to say this is that the dimensionality must
resolve to 1 (as in m * m ** -1 == 1). 

Can we agree that any argument passed to Sin (or other transcendental
functions) must have dimensionality that resolves to 1, in the above
sense? Then I promise to not say "radians are dimensionless", instead
I'll say "the dimensions of radians resolve to 1" :).

-- 
-- Stephe

Re: Dimensionality Checking (Ada 20XX)

[Dmitry A. Kazakov]

On 11 Dec 2001 11:39:30 -0500, Stephen Leake
<stephen.a.leake.1@gsfc.nasa.gov> wrote:

>It is simply wrong to try to define units for trig and exponential
>functions. Remember the Taylor expansion for Sin:
>
>Sin (x) = x - 1/6 x**3 ...
>
>If x has dimensions of meters (shudder :), then what are the
>dimensions of Sin (x)? This is why angles must be dimensionless, as
>radians are.

It is true, but the proof is wrong. Consider sqrt (x). It also has a
Taylor expansion in 1, which is also endless, yet sqrt (m**2) exists
and is m.

We just cannot use Taylor expansions before we define which dimension
2+2m could have. Not that it is impossible. Maybe there is a
continiuation of the unit system where sqrt (m) or even exp (m) are
defined. Who knows. 

But definitely, in SI only undimensioned values are allowed for all
"non-trivial" functions.

Regards,
Dmitry Kazakov

Re: Dimensionality Checking (Ada 20XX)

[Stephen Leake]

dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) writes:

> On 11 Dec 2001 11:39:30 -0500, Stephen Leake
> <stephen.a.leake.1@gsfc.nasa.gov> wrote:
> 
> >It is simply wrong to try to define units for trig and exponential
> >functions. Remember the Taylor expansion for Sin:
> >
> >Sin (x) = x - 1/6 x**3 ...
> >
> >If x has dimensions of meters (shudder :), then what are the
> >dimensions of Sin (x)? This is why angles must be dimensionless, as
> >radians are.
> 
> It is true, but the proof is wrong. Consider sqrt (x). It also has a
> Taylor expansion in 1, which is also endless, yet sqrt (m**2) exists
> and is m.

Hmm. Good point. I guess infinite series are trickier than I remember;
it has been a long time :).

-- 
-- Stephe

Re: Dimensionality Checking (Ada 20XX)

[daniele andreatta]

Stephen Leake wrote:

> dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) writes:
>
> > On 11 Dec 2001 11:39:30 -0500, Stephen Leake
> > <stephen.a.leake.1@gsfc.nasa.gov> wrote:
> >
> > >It is simply wrong to try to define units for trig and exponential
> > >functions. Remember the Taylor expansion for Sin:
> > >
> > >Sin (x) = x - 1/6 x**3 ...
> > >
> > >If x has dimensions of meters (shudder :), then what are the
> > >dimensions of Sin (x)? This is why angles must be dimensionless, as
> > >radians are.
> >
> > It is true, but the proof is wrong. Consider sqrt (x). It also has a
> > Taylor expansion in 1, which is also endless, yet sqrt (m**2) exists
> > and is m.
>
> Hmm. Good point. I guess infinite series are trickier than I remember;
> it has been a long time :).
>
> --
> -- Stephe

Taylor series keeps the unit of the function. Basically the series is (as
you recall)
f(x) = f(x_0) + f'(x_0) (x-x_0) +f''(x_0) (x-x_0)**2 + ...
and the unit of the derivatives are (indicating with [] the unit of the
quantity)
[f'(x)] = [f]/[x];    [f''] = [f]/[x]**2;    ....
In the end
[f(x)] = [Taylor expansion]

HTH,
Daniel

Re: Dimensionality Checking (Ada 20XX)

[Stephen Leake]

daniele andreatta <andreatta@mail.chem.sc.edu> writes:

> Taylor series keeps the unit of the function. Basically the series is (as
> you recall)
> f(x) = f(x_0) + f'(x_0) (x-x_0) +f''(x_0) (x-x_0)**2 + ...
> and the unit of the derivatives are (indicating with [] the unit of the
> quantity)
> [f'(x)] = [f]/[x];    [f''] = [f]/[x]**2;    ....
> In the end
> [f(x)] = [Taylor expansion]

Ah. Yes. Of course. Silly of me. 

So in the expansion of Sin (x) = 1 - 1/6 x**3, the "1" and the "1/6"
have units, as does the "x".

Thanks!

> 
> 
> HTH, Daniel
> 
> 

-- 
-- Stephe

Re: Dimensionality Checking (Ada 20XX)

[Dmitry A. Kazakov]

On Thu, 13 Dec 2001 12:02:49 -0500, daniele andreatta
<andreatta@mail.chem.sc.edu> wrote:

>
>
>Stephen Leake wrote:
>
>> dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) writes:
>>
>> > On 11 Dec 2001 11:39:30 -0500, Stephen Leake
>> > <stephen.a.leake.1@gsfc.nasa.gov> wrote:
>> >
>> > >It is simply wrong to try to define units for trig and exponential
>> > >functions. Remember the Taylor expansion for Sin:
>> > >
>> > >Sin (x) = x - 1/6 x**3 ...
>> > >
>> > >If x has dimensions of meters (shudder :), then what are the
>> > >dimensions of Sin (x)? This is why angles must be dimensionless, as
>> > >radians are.
>> >
>> > It is true, but the proof is wrong. Consider sqrt (x). It also has a
>> > Taylor expansion in 1, which is also endless, yet sqrt (m**2) exists
>> > and is m.
>>
>> Hmm. Good point. I guess infinite series are trickier than I remember;
>> it has been a long time :).
>>
>> --
>> -- Stephe
>
>Taylor series keeps the unit of the function. Basically the series is (as
>you recall)
>f(x) = f(x_0) + f'(x_0) (x-x_0) +f''(x_0) (x-x_0)**2 + ...
>and the unit of the derivatives are (indicating with [] the unit of the
>quantity)
>[f'(x)] = [f]/[x];    [f''] = [f]/[x]**2;    ....
>In the end
>[f(x)] = [Taylor expansion]

Right. Taylor series keep the unit just *per definition*, because
otherwise it would be impossible to have f(x)=Taylor expansion (:-)). 

However this fact does not ensure that the function *exists*. In
contrary, IF the function exits AND .. AND .. AND .. THEN there is an
expansion.

Let consider exp(x).

exp(x) * exp(x)=exp(x+x) =>

[exp(x) * exp(x)] = [exp(2x)] =

(surely, we don't want to have units depending on the magnitude)

= [exp(x)]

At the same time:

[exp(x) * exp(x)] = [exp(x)] * [exp(x)] =>

=> [exp(x)] = [exp(x)] * [exp(x)] =>

=> [exp(x)] = [1]

Now for any x, [log (exp (x))] = [x] => for any [x], [log (number)] =
[x]  ?!!

This is why exp of meters is incompatible with the requirement that
for any X, Y (real numbers), [exp (Xm)] = [exp (Ym)]. The same is
valid for sin, of course.

Regards,
Dmitry Kazakov

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

Dmitry, you're an absolute gem! It's worth a thousand "well I reckon"s to
actually produce the proof.

I have been doing a bit of reading up on dimensionsal analysis, and from
what I can tell from 'the texts', any and all exponentiations and logarithms
are dimensionless, and their arguments must be dimensionless (of dimensions
all 0).

So, the expression Exp(X) is dimensionless, and X must be (checked to be)
dimensionless. Ditto for Log(X).

The same is also true for the trigonometric functions. I recall someone
posting in this thread suggesting, in effect, that the same is also true for
square root; I'd like this confirmed.

So, may I first apologise for the confusion I seem to sow in my wake like a
talented double-glazing salesman. Secondly, I suppose the standard package
Ada.Numerics.Generic_Elementary_Functions could and should check (upon
instantiation) that the generic parameter type Float_Type is either
dimensionless or not unit-specific. Am I correct in assuming that the Cycle
parameter must always be dimensionless?

I have accepted the idea of units being applicable to floating point types,
as well as fixed point types, with the concern that unit-specific floating
point types are (more) liable to abuse. Am I right that
Ada.Numerics.Float_Random.Uniformly_Distributed should not be unit-specific?

As a slightly separate issue, is there any merit in the idea of adding
standard packages that provide Log, Exp, sin, Cos, Tan, etc. for fixed point
types?

--
Best wishes,
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Dmitry A. Kazakov]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4239 bytes --]

On Fri, 14 Dec 2001 22:01:23 -0000, "Nick Roberts"
<nickroberts@adaos.worldonline.co.uk> wrote:

>So, the expression Exp(X) is dimensionless, and X must be (checked to be)
>dimensionless. Ditto for Log(X).
>
>The same is also true for the trigonometric functions. I recall someone
>posting in this thread suggesting, in effect, that the same is also true for
>square root; I'd like this confirmed.

The equation X <unitX>*X <unitX> = Y <unitY> has a solution when Y is
not negative and <unitY> has even powers of all base units. Thus we
could define sqrt.

>Secondly, I suppose the standard package
>Ada.Numerics.Generic_Elementary_Functions could and should check (upon
>instantiation) that the generic parameter type Float_Type is either
>dimensionless or not unit-specific. Am I correct in assuming that the Cycle
>parameter must always be dimensionless?
>
>I have accepted the idea of units being applicable to floating point types,
>as well as fixed point types, with the concern that unit-specific floating
>point types are (more) liable to abuse. Am I right that
>Ada.Numerics.Float_Random.Uniformly_Distributed should not be unit-specific?

>As a slightly separate issue, is there any merit in the idea of adding
>standard packages that provide Log, Exp, sin, Cos, Tan, etc. for fixed point
>types?

Let's look at this from slightly other point of view. I believe that
there is a lot of confusion between units and scales. Your wish to
have "logarithmic" units is rightful and IMO there is an answer. It
sounds "logarithmic scale". A scale determines the representation of a
value, but not its dimension. With scales there would be also no fixed
vs. floating point dilemma. Both are *just* different scales of the
same thing *real number*. Same is with units. There is no log(m), but
there can be logarithmically graduated scales of meters. If I dare to
misuse Ada (:-)) it could be something like:

type meters is ...
type log_meters is ...

if x is of meters then

log_meters (x) = log_meters'Val (log (meters'Pos(x)))

From this point of view Celsius degree is of course Kelvin scaled by
s(x)=x+273.15. Foot is a proportionally scaled Meter etc. Happily
there is no need in Cycle parameter for sin/cos, because rad and
degree are of different scales [but of same unit 1 SI]. 

So dimensioned types of values should be characterized by two
attributes, discriminants, tag whatsoever: unit and scale.

[ I played with this idea for a while. It is easy to make unit
discriminant a modular number. Unfortunately an attempt to use access
type discriminants to represent scales is doomed to fail, because then
the type shall be limited. Damn, but there are good reasons why the
type with a discriminant of an access type shall be limited (sigh) ]

Differently scaled values cannot be mixed but can be explicitly
converted. Values of same scale can be added and subtracted [when unit
is same], multiplied and divided.

Now problems (:-():

1. There are different ways to define operations on scaled values. For
instance: s(X+Y) vs. s(X)+s(Y). With �C we are using the first way
[2�C+2�C=4�C], with floating point numbers the second. [for scales
s(x)=ax and additive/multiplicative operations they are equivalent].

2. Multiplicative operations may produce new scales.

3. Scales and units should be matched rather "by-structure" than
by-name.

Last note. If we want to do it consistently then of course there
should be a possibility to assign units to any type. Consider complex
numbers, matrices etc.

a) Let I want to implement fuzzy readings. Then I should have an
ability to write "type Fuzzy_Number is private;" and give some public
specification that it has a dimension.

b) A biz application could treat currency as a unit and different
currencies as fixed point numbers of different scales with no loss of
precision as long all calculations are made in one currency.

c) Let I write a matrix package. I would like to define matrices of
different sizes as ones having different units. For instance NxN and
Nx1 should be two different units, so I cannot add matrices of this
sizes. Yet I can multiple one of NxN to Nx1 and have Nx1 matrix
(vector). Then I leave all checks to the compiler (:-))

Regards,
Dmitry Kazakov

Re: Dimensionality Checking (Ada 20XX)

[Thomas Koenig]

Dmitry A. Kazakov <dmitry@elros.cbb-automation.de> wrote:

>The equation X <unitX>*X <unitX> = Y <unitY> has a solution when Y is
>not negative and <unitY> has even powers of all base units. Thus we
>could define sqrt.

In order to be sufficiently general, dimensions would have to be
factional numbers for intermediate results, at least.  There are
too many cases where square or cubed or other roots turn up in
normal calculations.

For example, one important factor in distillation column design,
the vapor load, is defined as F = w * rho^(1/2), where w is the
speed in (Length/Time) and rho is the density (Mass/Length^3),
so its unit actually is  kg^0.5/m^0.5/s in SI units.  And
yes, people do publish values and correlations for this factor.

Re: Dimensionality Checking (Ada 20XX)

[Dmitry A. Kazakov]

On 17 Dec 2001 13:16:11 +0100, Thomas.Koenig@online.de (Thomas Koenig)
wrote:

>Dmitry A. Kazakov <dmitry@elros.cbb-automation.de> wrote:
>
>>The equation X <unitX>*X <unitX> = Y <unitY> has a solution when Y is
>>not negative and <unitY> has even powers of all base units. Thus we
>>could define sqrt.
>
>In order to be sufficiently general, dimensions would have to be
>factional numbers for intermediate results, at least.  There are
>too many cases where square or cubed or other roots turn up in
>normal calculations.
>
>For example, one important factor in distillation column design,
>the vapor load, is defined as F = w * rho^(1/2), where w is the
>speed in (Length/Time) and rho is the density (Mass/Length^3),
>so its unit actually is  kg^0.5/m^0.5/s in SI units.  And
>yes, people do publish values and correlations for this factor.

Well, I am not a physicist to judge whether it has *physical* sense.
Maybe a dimensioned factor get lost somewhere or the dependency is
empirical. Intuition wispers that it should somehow ram relativity
theory. But mathematically it is no problem to continue units with
natural powers to ones with rational ones.

Regards,
Dmitry Kazakov

RE: Dimensionality Checking (Ada 20XX)

[Steven Deller]

Thomas,
Actually, you are missing a divisor in your computation of vapor load.
It actually is
  Vapor Load = V_l = V_cfs * sqrt( rho_v/(rho_l-rho_v)) 
and this results in length^3/time whole units:
  V_cfs = length^3/time
  rho_* = mass/length^3
  so,  length^3/time * sqrt( mass/length^3 / (mass/length^3 -
mass/length^3))
  = length^3/time

The following site has a full chem eng distillation analysis:
  http://chemeng.uah.edu/courses/che446sp99/spray1.html

Every computation I saw had full units (or unitless ratios).  There did
not seem to be a need for non-integral units.

The line computing V_l states it is Vapor Load, ft/s but is is clearly
cu ft/s (which makes more sense if one is computing a vapor load on a
column).

INMHO, fractional units simply make no sense for any stated value.  They
*might* occur in a partial computation, e.g. sqrt(length1) *
sqrt(length2), though that would more properly be written as
sqrt(length1*length2).  I cannot think of any computation where
fractional units *do* occur, even in partial results.  

It would be nice to have one clear example from the real world where
fractional units occur before building a solution for something that
will never be used.

Regards,
Steve

> -----Original Message-----
...
> 
> In order to be sufficiently general, dimensions would have to 
> be factional numbers for intermediate results, at least.  
> There are too many cases where square or cubed or other roots 
> turn up in normal calculations.
> 
> For example, one important factor in distillation column 
> design, the vapor load, is defined as F = w * rho^(1/2), 
> where w is the speed in (Length/Time) and rho is the density 
> (Mass/Length^3), so its unit actually is  kg^0.5/m^0.5/s in 
> SI units.  And yes, people do publish values and correlations 
> for this factor. _______________________________________________

>

RE: Dimensionality Checking (Ada 20XX)

[Steven Deller]

What is wrong with using Pat Roger's dimensioning system.  It has units
and scaling.  It allows making metric, English, or other dimensional
units, with all "interconversions" straightforward and easy.  For
example, the following user code works with dimension checking and
appropriate scaling conversions:

==================================================================
-- (C) Copyright 1998 by Patrick Rogers of Software Arts & Sciences
-- progers@classwide.com
-- http://www.classwide.com
--
-- Rights to use, distribute or modify this package in any way is hereby
-- granted, provided this header is kept unchanged in all versions.
-- Additionl headers may be added. If you make a valuable addition,
-- please keep us informed by sending a message to progers@classwide.com
--

-- THIS ADA LIBRARY IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
IMPLIED
-- WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
-- MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.

with Float_Units;
with Metric_Float_Units;
with Ada.Text_IO;

procedure Test_Metric is
  use Float_Units, Metric_Float_Units;

  M : Mass := 1.0 * Kilogram;
  E : Erg := M * C**2;
begin
  Ada.Text_IO.Put( Float'Image( Value_of(E) ) );
end Test_Metric;
================================================================

This seems very powerful, easy to use, and readable.  Mass is just a
subtype of Unit with fixed discriminants.  Kilogram is just a Mass with
a specific magnitude.  

"Unit"s are discriminated records with a single float magnitude.  The
"Dimensioned Units" is a generic package (generic with respect to the
magnitude type) and defines all *operations* that units can participate
in (add, multiply, exponent to an integer, and so on).  The "system" of
units (e.g. MKS or CGS or English or ...) is independently defined as a
generic that takes a package that is some instance of the units package.
It is in such a "system" where units are defined.

The whole thing looks like the PERFECT abstraction of the issues and has
appropriate separation of concerns. 

As many people have pointed out, the dimensions in the discriminants (of
the implementation) are constants and the intermixings involve simple
integer operations, so a smart compiler could collapse all discriminant
operations and do all dimension validation during compilation (e.g.
WARNING: This operation will always raise Dimension_Exception).  

A compiler could even do away with any explicit storage of the
discriminants because they are *always* "constant" (when constants are
collapsed) so storing them is just redundant.  Not that any compilers do
so yet ...  but it seems as easy to do as implementing some "units
checking scheme yet to be invented" and the optimizations would have a
more general applicability.

Not sure where to pick up Pat Roger's stuff on the net. If you can't
find it and want it, let me know.  

Of course, for 7 dimensions, you will have 7 discriminants (all
constants of some integer type), but it seems to me that such
information would be needed in any case.  I'd guess that storing
dimensions as 8-bit integers would be more than enough -- I can't think
of any sensible unit's system that needed more than about plus or minus
4 or so multiples of a given dimension.  A 16-byte record could hold up
to 8 dimension discriminants, along with a high-precision float.  Of
course all these should be generic.

The only difficulties I see are getting the RIGHT system of dimensions
for such a package (but then again, not being "built in", it can be
changed is so needed).

Regards,
Steve Deller

Re: Dimensionality Checking (Ada 20XX)

[Dmitry A. Kazakov]

On Sat, 15 Dec 2001 02:07:41 -0500, "Steven Deller"
<deller@smsail.com> wrote:

>What is wrong with using Pat Roger's dimensioning system.  It has units
>and scaling.  It allows making metric, English, or other dimensional
>units, with all "interconversions" straightforward and easy.  For
>example, the following user code works with dimension checking and
>appropriate scaling conversions:
>
>==================================================================
>-- (C) Copyright 1998 by Patrick Rogers of Software Arts & Sciences
>-- progers@classwide.com
>-- http://www.classwide.com
>--
>-- Rights to use, distribute or modify this package in any way is hereby
>-- granted, provided this header is kept unchanged in all versions.
>-- Additionl headers may be added. If you make a valuable addition,
>-- please keep us informed by sending a message to progers@classwide.com
>--
>
>-- THIS ADA LIBRARY IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
>IMPLIED
>-- WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
>-- MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
>
>with Float_Units;
>with Metric_Float_Units;
>with Ada.Text_IO;
>
>procedure Test_Metric is
>  use Float_Units, Metric_Float_Units;
>
>  M : Mass := 1.0 * Kilogram;
>  E : Erg := M * C**2;
>begin
>  Ada.Text_IO.Put( Float'Image( Value_of(E) ) );
>end Test_Metric;
>================================================================
>
>This seems very powerful, easy to use, and readable.  Mass is just a
>subtype of Unit with fixed discriminants.  Kilogram is just a Mass with
>a specific magnitude.  
>
>"Unit"s are discriminated records with a single float magnitude.  The
>"Dimensioned Units" is a generic package (generic with respect to the
>magnitude type) and defines all *operations* that units can participate
>in (add, multiply, exponent to an integer, and so on).  The "system" of
>units (e.g. MKS or CGS or English or ...) is independently defined as a
>generic that takes a package that is some instance of the units package.
>It is in such a "system" where units are defined.
>
>The whole thing looks like the PERFECT abstraction of the issues and has
>appropriate separation of concerns. 
>
>As many people have pointed out, the dimensions in the discriminants (of
>the implementation) are constants and the intermixings involve simple
>integer operations, so a smart compiler could collapse all discriminant
>operations and do all dimension validation during compilation (e.g.
>WARNING: This operation will always raise Dimension_Exception).  
>
>A compiler could even do away with any explicit storage of the
>discriminants because they are *always* "constant" (when constants are
>collapsed) so storing them is just redundant.  Not that any compilers do
>so yet ...  but it seems as easy to do as implementing some "units
>checking scheme yet to be invented" and the optimizations would have a
>more general applicability.
>
>Not sure where to pick up Pat Roger's stuff on the net. If you can't
>find it and want it, let me know.  
>
>Of course, for 7 dimensions, you will have 7 discriminants (all
>constants of some integer type), but it seems to me that such
>information would be needed in any case.  I'd guess that storing
>dimensions as 8-bit integers would be more than enough -- I can't think
>of any sensible unit's system that needed more than about plus or minus
>4 or so multiples of a given dimension.  A 16-byte record could hold up
>to 8 dimension discriminants, along with a high-precision float.  Of
>course all these should be generic.

I used a similar approach. The difference was that I used only one
discriminant - a modular number holding all 7 powers. With
Interfaces.Unsigned_32 it holds powers -8..7. Then I used an
additional field for the offset [to cope with damned Celsius degree
(:-))]

>The only difficulties I see are getting the RIGHT system of dimensions
>for such a package (but then again, not being "built in", it can be
>changed is so needed).

The approach is thinkable and it has a great advantage - an ability to
write "class-wide" subroutines for dimensioned types. But it still
faces several problems.

1. Optimization issues. I saw no compiler able to remove run-time
checks and storage for the dicriminants for constrained subtypes. [I
wrote a small test program which calculated performance penalty. It is
6..20 times when compared with regular float]. I agree with you that
such kind of optimizations could be even more useful than dimensioned
values itself: some sort of user-defined compile-time expressions,
removal of static discriminants as well as tags (the later one might
require revison of tagged types, because of redispatch).

2. Scaled units like Celsius require additional fields which cannot be
made discriminants because the offset is not of a discrete type and an
access type would make the whole type limited.

3. There are still difficulties with different unit systems. One
cannot calculate everything in SI because of precission losses by
conversions (ft vs. m) and range problems (eV vs. J). One could
relatively easily produce another unit system (as you said, with
generics), but then there would be no predefined cross conversions
between it and SI. [ In fact a necessity to use generics always
indicate a language problem (:-)) ] Here we go again.

So I believe, that some sort of compiler support is required.

Regards,
Dmitry Kazakov

Re: Dimensionality Checking (Ada 20XX)

[Thomas Koenig]

Dmitry A. Kazakov <dmitry@elros.cbb-automation.de> wrote:

>2. Scaled units like Celsius require additional fields which cannot be
>made discriminants because the offset is not of a discrete type and an
>access type would make the whole type limited.

This is a small problem, limited to temperature, which can be
handled by conversion functions.

(Yes, there's enthalpy, but if you use enthalpy values with
different reference states in the same program, you're in DEEP
trouble already).

>3. There are still difficulties with different unit systems. One
>cannot calculate everything in SI because of precission losses by
>conversions (ft vs. m)

The foot is defined in terms of meters already (an inch is exactly
2.54 mm).  Also, the conversion factors are well-defined, and
the precision loss is in the range of dividing, anyway.

>and range problems (eV vs. J). One could
>relatively easily produce another unit system (as you said, with
>generics), but then there would be no predefined cross conversions
>between it and SI.

The best way to overcome the range problem would be by defining
new units with respect to the SI system.

Re: Dimensionality Checking (Ada 20XX)

[Dmitry A. Kazakov]

On 17 Dec 2001 14:46:03 +0100, Thomas.Koenig@online.de (Thomas Koenig)
wrote:

>Dmitry A. Kazakov <dmitry@elros.cbb-automation.de> wrote:
>
>>3. There are still difficulties with different unit systems. One
>>cannot calculate everything in SI because of precission losses by
>>conversions (ft vs. m)
>
>The foot is defined in terms of meters already (an inch is exactly
>2.54 mm).  Also, the conversion factors are well-defined, and
>the precision loss is in the range of dividing, anyway.

Sorry for off-topic, but I just cannot resist (:-)). There is a
beautiful historic anecdote. When Americans bombed Tokio they lost 3
or so bombers (B-17, I believe) landed in Russia and China. Stalin got
grip on them and ordered to copy them 1-1. Do you know what the major
problem was? Unit conversions! All that damned inches must have been
converted to mm, rounded, used in calculations and then discovered
that nothing fitted exactly.

Regards,
Dmitry Kazakov

Re: Dimensionality Checking (Ada 20XX)

[Thomas Koenig]

I wrote:

>(an inch is exactly
>2.54 mm).

meaning 25.4 mm, of course :-)

Re: Dimensionality Checking (Ada 20XX)

[Britt Snodgrass]

dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) wrote in message news:<3c1dd328.10829203@News.CIS.DFN.DE>...
> On Sat, 15 Dec 2001 02:07:41 -0500, "Steven Deller"
> <deller@smsail.com> wrote:
> 
> >What is wrong with using Pat Roger's dimensioning system.  It has units
> >and scaling.  It allows making metric, English, or other dimensional
> >units, with all "interconversions" straightforward and easy.  For
> >example, the following user code works with dimension checking and
> >appropriate scaling conversions:

I agree with Steve.  Pat Roger's approach seems pretty elegant to me.

> 
> I used a similar approach. The difference was that I used only one
> discriminant - a modular number holding all 7 powers. With
> Interfaces.Unsigned_32 it holds powers -8..7. Then I used an
> additional field for the offset [to cope with damned Celsius degree
> (:-))]

Can you provide an example of your modular type definition?

> 
> >The only difficulties I see are getting the RIGHT system of dimensions
> >for such a package (but then again, not being "built in", it can be
> >changed is so needed).
> 
> The approach is thinkable and it has a great advantage - an ability to
> write "class-wide" subroutines for dimensioned types. But it still
> faces several problems.
> 
> 1. Optimization issues. I saw no compiler able to remove run-time
> checks and storage for the dicriminants for constrained subtypes. [I
> wrote a small test program which calculated performance penalty. It is
> 6..20 times when compared with regular float]. I agree with you that
> such kind of optimizations could be even more useful than dimensioned
> values itself: some sort of user-defined compile-time expressions,
> removal of static discriminants as well as tags (the later one might
> require revison of tagged types, because of redispatch).
>

Could a large part of the performance penalty be attributed to your
use of a single modular number discriminant for the dimensional
powers?  I think this would require a lot of bit unpacking/repacking. 
Separate discriminants might be faster.

I would probably remove the unit checks in final production code by
redefining the unit types to be reqular floating types, recompiling,
and retesting.

Britt Snodgrass

 <<snip>>
 
> Regards,
> Dmitry Kazakov

Re: Dimensionality Checking (Ada 20XX)

[Dmitry A. Kazakov]

On 17 Dec 2001 13:07:07 -0800, britt@adapower.net (Britt Snodgrass)
wrote:

>dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) wrote in message news:<3c1dd328.10829203@News.CIS.DFN.DE>...
>> On Sat, 15 Dec 2001 02:07:41 -0500, "Steven Deller"
>> <deller@smsail.com> wrote:
>> 
>> I used a similar approach. The difference was that I used only one
>> discriminant - a modular number holding all 7 powers. With
>> Interfaces.Unsigned_32 it holds powers -8..7. Then I used an
>> additional field for the offset [to cope with damned Celsius degree
>> (:-))]
>
>Can you provide an example of your modular type definition?

subtype UnitPower is Interfaces.Unsigned_32;
type Unit is new UnitPower;

function "**" (Left : Unit; Right : Integer) return Unit;
function "*"  (Left, Right : Unit) return Unit;
function "/"  (Left, Right : Unit) return Unit;
function Sqrt (X : Unit) return Unit;
pragma Inline ("**", "*", "/", Sqrt);
...

You can download it from here:
http://www.dmitry-kazakov.de/ada/units.htm

>> >The only difficulties I see are getting the RIGHT system of dimensions
>> >for such a package (but then again, not being "built in", it can be
>> >changed is so needed).
>> 
>> The approach is thinkable and it has a great advantage - an ability to
>> write "class-wide" subroutines for dimensioned types. But it still
>> faces several problems.
>> 
>> 1. Optimization issues. I saw no compiler able to remove run-time
>> checks and storage for the dicriminants for constrained subtypes. [I
>> wrote a small test program which calculated performance penalty. It is
>> 6..20 times when compared with regular float]. I agree with you that
>> such kind of optimizations could be even more useful than dimensioned
>> values itself: some sort of user-defined compile-time expressions,
>> removal of static discriminants as well as tags (the later one might
>> require revison of tagged types, because of redispatch).
>
>Could a large part of the performance penalty be attributed to your
>use of a single modular number discriminant for the dimensional
>powers?  I think this would require a lot of bit unpacking/repacking. 

No unpacking. It is made so that a unit operation is first applied to
the positions 0,2,4,6 (with overflow checks in positions 1,3,5,7).
Then same is made for positions 1,3,5,7. After that the results are
merged.

>Separate discriminants might be faster.
>
>I would probably remove the unit checks in final production code by
>redefining the unit types to be reqular floating types, recompiling,
>and retesting.

Then you loose the major advantage of the approach against ones based
on generics or other kinds of preprocessing - an ability to have
unconstrained (by unit) dimensioned values and thus subroutines that
work for all units. 

Regards,
Dmitry Kazakov

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

Hi Nick, I still have yet to get around to a full reply to this, so I
thought I'd take a whack at the easy bits :-)

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:9v37rs$cdmva$1@ID-25716.news.dfncis.de...
> Sorry not to reply to this in full sooner.
>
> "Mark Lundquist" <mlundquist2@attbi.com> wrote in message
> news:haTQ7.21816$wL4.49551@rwcrnsc51...
>
>
> > > There's the question of private types. I feel that the requisite
> > conversions
> > > and other mixed operations should be provided for a private type
> > explicitly
> > > (in its package spec), and that these operations should do the
requisite
> > > conversion and checking, which may well be more complicated than mere
> > > scaling and dimensionality. The unit facilities would, of course, be
> > > applicable to those components which were of unit-specific
(fixed-point)
> > > types.
> >
> > I'm not sure quite what you're getting at there, but it sounds like it
> might
> > be related to an issue I've been thinking about, which is that these
units
> > currently would not be able to work with "quasi-numeric" abstractions
such
> > as people define for things like rational numbers, infinite-precision
> > arithmetic, etc.
> > ...
>
> Correct. (The example presented to me was Ada.Calendar.Time).

There you go... Calendar.Time is a perfect example.

> > 1) You have to be able to handle logarithmic units... that's easy, for a
> > unit U:
> >
> >     U'Log (B)    -- denotes the log to the base B of U
> >     U'Exp (B)    -- denotes B to the power U
>
> Or alternatively, sticking closer to my design, the package Ada.Units
could
> have functions Log and Exp. This presumably means that the dimensions of a
> unit could be non-integral?

No, you're holding your exponetiator backwards... here, like *this*...
that's more like it :-)
Non-integer exponents signify roots, not log/exp.

Cheers,
Mark

--

--------------
Reply by email to: Mark dot Lundquist at ACM dot org
Consulting services: http://home.attbi.com/~mlundquist2/consulting

Re: Dimensionality Checking (Ada 20XX)

[Nick Roberts]

"Mark Lundquist" <no.spam@getalife.com> wrote in message
news:Nn7S7.44589$ER5.535249@rwcrnsc52...

> > > I'm not sure quite what you're getting at there, but it sounds like it
> > might
> > > be related to an issue I've been thinking about, which is that these
> units
> > > currently would not be able to work with "quasi-numeric" abstractions
> such
> > > as people define for things like rational numbers, infinite-precision
> > > arithmetic, etc.
> > > ...
> >
> > Correct. (The example presented to me was Ada.Calendar.Time).
>
> There you go... Calendar.Time is a perfect example.

Yes. It is important to keep what is being proposed in perspective. If it
has any merit at all, it will be limited. Nevertheless, I do believe it has
merit. (Remember, we are not trying to solve all the world's problems at a
single stroke ;-)

> > > 1) You have to be able to handle logarithmic units... that's easy, for
a
> > > unit U:
> > >
> > >     U'Log (B)    -- denotes the log to the base B of U
> > >     U'Exp (B)    -- denotes B to the power U
> >
> > Or alternatively, sticking closer to my design, the package Ada.Units
> could
> > have functions Log and Exp. This presumably means that the dimensions of
a
> > unit could be non-integral?
>
> No, you're holding your exponetiator backwards... here, like *this*...
> that's more like it :-)
> Non-integer exponents signify roots, not log/exp.

Excellent Mark! I was wondering who would be the first to spot this. You get
the prize*.

It doesn't actually stop us handling logs and exps, in fact. It actually
makes it easier: remember the idea of allowing user-defined dimension sets
(passed as a generic parameter to a standard package)? We simply say that
the log/exp units must belong to a different dimension set (and enforce this
by checking).

--
Best wishes,
Nick Roberts


*a big wet sloppy kiss ... from my cat, Roger (who is a she (really) :-)

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:9vb98r$e9g47$1@ID-25716.news.dfncis.de...
> "Mark Lundquist" <no.spam@getalife.com> wrote in message
> news:Nn7S7.44589$ER5.535249@rwcrnsc52...
>
> > > > I'm not sure quite what you're getting at there, but it sounds like
it
> > > might
> > > > be related to an issue I've been thinking about, which is that these
> > units
> > > > currently would not be able to work with "quasi-numeric"
abstractions
> > such
> > > > as people define for things like rational numbers,
infinite-precision
> > > > arithmetic, etc.
> > > > ...
> > >
> > > Correct. (The example presented to me was Ada.Calendar.Time).
> >
> > There you go... Calendar.Time is a perfect example.
>
> Yes. It is important to keep what is being proposed in perspective. If it
> has any merit at all, it will be limited. Nevertheless, I do believe it
has
> merit. (Remember, we are not trying to solve all the world's problems at a
> single stroke ;-)

Right.  Private numeric types are an orthogonal problem.  Only, if that
feature were added and so were unit-awareness, then it would make sense for
the two features to play together, that's all.  My intuition is that there
are no obstacles to getting unit-awareness to work with private numeric
types that wouldn't already have had to be overcome just to get private
numeric types to work in the language at all.

And I think those obstacles would be considerable... if you can't figure out
how to get literals and constrained subtypes that make sense, then it's
hardly worth talking about.  It would probably take someone smarter than me
to figure those out.  But like I said, I haven't given it a whole lot of
thought...

--mark
--

--------------
Reply by email to: Mark dot Lundquist at ACM dot org
Consulting services: http://home.attbi.com/~mlundquist2/consulting

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Mark Lundquist" <mlundquist2@attbi.com> wrote in message
news:haTQ7.21816$wL4.49551@rwcrnsc51...

I was just looking over what I wrote in a post from yesterday:
>
>     type Length is range 0.0 .. whatever;
>     for Length'Units use Meter;
>
Yikes, where did that come from?  I meant to write (for the first line)

    type Length is digits something range 0.0 .. whatever;

Hopefully I didn't confuse anyone by writing junk... my point was supposed
to be that this is an ordinary type definition just like in Ada95!

-- mark

Re: Dimensionality Checking (Ada 20XX)

[Ian]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<9v0crt$bo2bi$1@ID-25716.news.dfncis.de>...
> I'm liking this idea a lot!
 
> Three further notes need to be made.
> 
> (1) I am not sure if the (seven) SI units I have presented are the complete
> set of basic units required in reality.

The standard reference was "H.S. Hvistendahl, Engineering Units and
Physical Quantities,Macmillan, 1964. Anyone have something more up to
date

There were only 6 fundamental Units in MKS are
Length                    L
Mass                      M
Time                      T
Thermodynamic Temperature Big-Theta
Electric Current          I
Luminous Intensity        ?

He also uses Free Energy  LF
What is nr 7 I forgot.

Also Angle                [L]-superscript-o so it really is related to
length.

> (2) Dimensional analysis could extend (from the basic MLT) to temperature,
> amount of matter, and electrical current. But I don't know if it would be
> practical for these 'extra' dimensions (or any others) to be included in the
> checking.

Ian

Re: Dimensionality Checking (Ada 20XX)

[Wes Groleau]

Ian wrote:
> There were only 6 fundamental Units in MKS are
> Length                    L
> Mass                      M
> Time                      T
> Thermodynamic Temperature Big-Theta
> Electric Current          I

Some would argue that current is a derived unit: Charge / Time

But where does Resistance and Electromotive Force fit in?

> Luminous Intensity        ?
> 
> He also uses Free Energy  LF


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

Re: Dimensionality Checking (Ada 20XX)

[Britt Snodgrass]

Ian0Kerr@my-deja.com (Ian) wrote in message news:<eb48e9c0.0112100557.51184bda@posting.google.com>...
> "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<9v0crt$bo2bi$1@ID-25716.news.dfncis.de>...
> > I'm liking this idea a lot!
>  
> > Three further notes need to be made.
> > 
> > (1) I am not sure if the (seven) SI units I have presented are the complete
> > set of basic units required in reality.
> 
> The standard reference was "H.S. Hvistendahl, Engineering Units and
> Physical Quantities,Macmillan, 1964. Anyone have something more up to
> date

"Units and Conversion Charts" by Theordore Wilde, published by IEEE
press. I have the very useful 1991 edition but there is apparently an
updated 1994 edition available from Fatbrain.com at
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0780310500&vm=

> 
> There were only 6 fundamental Units in MKS are
> Length                    L
> Mass                      M
> Time                      T
> Thermodynamic Temperature Big-Theta
> Electric Current          I
> Luminous Intensity        ?
> 
> He also uses Free Energy  LF
> What is nr 7 I forgot.

Amount of substance (SI unit is the "mole")

> 
> Also Angle                [L]-superscript-o so it really is related to
> length.
> 
> > (2) Dimensional analysis could extend (from the basic MLT) to temperature,
> > amount of matter, and electrical current. But I don't know if it would be
> > practical for these 'extra' dimensions (or any others) to be included in the
> > checking.
> 
> Ian

Re: Dimensionality Checking (Ada 20XX)

[Mike Brenner]

Mark Lundquist said: 
> But the compiler only has to look at the generic *spec* to determine this.
> What you *never* see today, and what we'd really like to avoid in any
> language revision, is this: you make a change to the generic *body*, the
> change is legal (the generic body compiles), but suddenly one or more
> *instantiations* become illegal as a result.  That is the problem I'm
> talking about with units.

Is this the reason why non-generic packages have been forbidden as generic parameters? 

It seems that the benefits of a fully orthogonal implementation of generic (making them second-class objects by permitting passing object to objects) outweigh the benefits of keeping compatibility with all existing bodies. 

In particular, permitting non-generic package parameters would give a way to switch implementations without rewriting the code. In particular, a configuration manager could simply swap the spec and body of the package being used as a non-generic parameter to a generic, and that would change the device driver from being Linux-compatible to being COM-compatible. 

Now, a line of code has to be changed in order to swap devices supported, so it requires a PROGRAMMER rather than a CONFIGURATION MANAGER to make that kind of change to a large Ada system.

The disadvantage would be that certain programs might no longer compile, for example, if they used a feature of Linux that COM-objects did not implement.

It seems to me that this disadvantage, detected at compile time, might make up for the advantage?

Also, of course, making packages second class objects like that would be the penultimate step towards eventually making package first-class objects.

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Mike Brenner" <mikeb@mitre.org> wrote in message
news:mailman.1008076322.18644.comp.lang.ada@ada.eu.org...
> Mark Lundquist said:
> > But the compiler only has to look at the generic *spec* to determine
this.
> > What you *never* see today, and what we'd really like to avoid in any
> > language revision, is this: you make a change to the generic *body*, the
> > change is legal (the generic body compiles), but suddenly one or more
> > *instantiations* become illegal as a result.  That is the problem I'm
> > talking about with units.
>
> Is this the reason why non-generic packages have been forbidden as generic
parameters?

I don't think that's so much "forbidden" as it is "nonsensical" :-)

What exactly would such a construct look like, and what exactly would it
mean?

>[...]
> In particular, permitting non-generic package parameters would give a way
to switch implementations without rewriting the code. In particular, a
configuration manager could simply swap the spec and body of the package
being used as a non-generic parameter to a generic, and that would change
the device driver from being Linux-compatible to being COM-compatible.

Well, why can't you just "swap the spec and body" of a package today?  Why
do you need an enhancement to generics for this?

Maybe I don't understand the problem you're trying to solve... can you make
your example more specific, e.g. by including a source code example for the
feature you're envisioning?

Are you aware of the generic "signature" idiom?  Also, library-level
renames?  Perhaps those devices would help with what you're after...?

It could be that your Linux/COM example is not particulary illustrative,
since mulitplatform development is typically conducted by maintaining
multiple variants, not by "switching" something back and forth...

>
> Now, a line of code has to be changed in order to swap devices supported,
so it requires a PROGRAMMER rather than a CONFIGURATION MANAGER to make that
kind of change to a large Ada system.

Since I haven't seen how your feature would work, I can't see that this is
true :-)... but I can see how a configuration manager might select a
configuration with a different variant of a package spec and body, then
rebuild to create a different system.  This is in today's Ada, and it
wouldn't take a programmer to do that...

> Also, of course, making packages second class objects like that would be
the penultimate step towards eventually making package first-class objects.
>

Have you been sharing LSD with Nick Roberts?  Please, stop before it's too
late!  Also, you should know that Nick isn't even from our planet, he's
really a Tenet from the planet Contar.  He's the Distar of Contar, actually.
You should never, ever share mind-altering substances with a Tenet, it is
just too risky.

Now then... please study the relationships between the concepts of type,
value, and object in Ada.  That is the penultimate step towards eventually
understanding why your suggestion is bonkers :-).

http://www.ada-auth.org/~acats/arm-html/RM-3-2.html
http://www.ada-auth.org/~acats/arm-html/RM-3-3.html
http://www.na.org

Good luck... with everything :-)
-- mark

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

[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

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

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