SI Units Solicitation - Upgrade from comments

[William A Whitaker <whitaker@erols.com>]

"... a decent respect to the opinions of mankind requires that 
they should declare the causes which impel them ..."

This is an interim report on the responses to the Solicitation
of comments on a SI Units proposal for IEEE P1446, Ada-Based 
Test Program Development.  I wish to thank those who provided comments. 
Addition/further/new comments are invited.


The revised proposal is given, with links to code, in 

http://www.erols.com/whitaker/iss_418.htm
                                         

A full accounting of comments is given in 

http://www.erols.com/whitaker/si_cmts.txt



Two general statements: 

First, the example given was abstracted, with very little modification,
from code used in IEEE P1446, which left a few footprints (e.g., there
was a subtype Number which was left over and has now been removed).

For the P1446 standard, it is important that it be concrete and allow
only
the use of the numeric type Real, defined elsewhere.  As a general
Ada facility, it is proper that it be generic.  A rephrasing of the
example as a generic looks a bit strange, but is given in

http://www.erols.com/whitaker/si_gen.txt

As an Ada facility, it is probably important to group the operations
with the Unit type definition for derivability (deriving is not
encouraged
in P1446, but then "possible" is not "required").  This has been done, 
requiring the additional "use type SI.Unit" in code, although 
I was rather hoping to reduce the number of with/use in code.


Second, the driving force of the proposal was to find a method of 
units checking in Ada that would be acceptable/comfortable to 
ordinary engineers.  If it was not fairly invisible, it would never 
be used.

The gimmick of naming the unit subtypes and the conversion functions
the same is considered important to that goal and drives the 
packaging.  Direct literals are not possible, this was the closest I
came.
The solution of packaging everything together and calling
the conversions To_Meter, To_Second, ... was used 5 years ago and
was rejected by users at that time.

Other changes include:

Spellcheck has been run on the text.

subtype Dimensionless has been redesignated Null_Unit.  There is
possible
confusion surrounding the word "dimension".

Function Nth_Root - a unique need for Unit.

Other observations:

On reflection, many 'Attributes would have no meaning for Unit.
Meter'First could only be an artificial flag.  Unit'First has no meaning 
at all.

Unit_Power could be restricted to 127, or less in some cases.  This was
done 
in 1226.  But the only real advantage would be (following an early
suggestion
by Leif) to encode the whole set of Unit_Powers in a single 32-bit
integer,
thereby allowing a smaller structure and literals for the Power.
Is there any interest in this modification?

Run-time costs are probably minimal in this day, and can be cut off
by using the non-checking version.  But there is one situation
in which this is not true, large compute/memory limited physics 
calculations with large unit-ed arrays.  Straightforward implementation
would make an array of Meter an array of type Meter.  For efficiency,
one could rather have a Meter_Array, a unit-ed type which has as 
Value an array of Real (and the appropriate operations).