Re: Dimensionality Checking (Ada 20XX)

[dmitry@elros.cbb-automation.de (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