From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,2078dddcdcd8d83
X-Google-Attributes: gid103376,public
From: "John G. Volan" <johnvolan@sprintmail.com>
Subject: Re: Tangent to Religious naming convention discussion ......
Date: 1997/05/15
Message-ID: <337B4695.FA6@sprintmail.com>#1/1
X-Deja-AN: 241748958
References: <33779E0D.61F8@sprintmail.com> <3378BBD2.7BBA@this.message>
 <3379606E.413E@sprintmail.com> <5lcefp$riu$1@ash.ridgecrest.ca.us>
 <3379EC80.6C9B@sprintmail.com> <337B1D8B.4474@this.message>
Reply-To: johnvolan@sprintmail.com
Newsgroups: comp.lang.ada
Date: 1997-05-15T00:00:00+00:00
List-Id: <comp.lang.ada>


W. Wesley Groleau (Wes) wrote:
> 
> John G. Volan wrote:
> >   with Unitless;
> >   package Angles is
> >
> >     type Angle_Type is private;
> 
> This is an excellent approach (though in itself it doesn't
> support the "_Type" concept--to lessen :-) the "tangent").
> Just make sure you provide the clients with something like
> 
>   function Degrees ( From : Angle[_Type] ) return Float;
>   -- or at least
>   function Degrees_Image ( From : Angle[_Type] ) return String;

Float may not be very appropriate if Angle_Type isn't implemented with
Float.  I was assuming that Unitless.Quantity_Type was a floating-point
type with some connection to Angle_Type's implementation.

Technically speaking, the functionality you suggest is already provided
by "/":

  Degrees_Quantity : Unitless.Quantity_Type :=
    Some_Angle / Degree;  -- angle / angle = unitless
  -- Since we're reducing this to a unitless coefficient with
  -- the "angle" dimension stripped off, we now have to keep
  -- track of what units we used to reduce it, hence the 
  -- encoding of "Degrees" in the name.

The reverse operation is "*":

  Some_Angle : Angle_Type := Degrees_Quantity * Degree; 
    -- unitless * angle = angle

For efficiency reasons, however, I can see the rationale for avoiding
division as the method for doing the reduction (especially if the
internal units happen to be degrees), but if you're going to include
functions like the one you suggested, they should be written in terms of
Unitless.Quantity_Type:

   function In_Degrees
     (Angle : Angle_Type)
      return Unitless.Quantity_Type;
      --     ^^^^^^^^^^^^^^^^^^^^^^

   Degrees_Quantity : Unitless.Quantity_Type :=
     In_Degrees (Angle => Some_Angle);


In other words, the Angles package is part of an integrated subsystem of
dimensional units packages, with Unitless providing a floating-point
"unitless" Quantity_Type which acts as the common numeric currency for
the subsystem.  "Unitful" private types such as Angle_Type presumably
use Quantity_Type as their underlying representation, either by being
privately derived from it or perhaps being records with one
Quantity_Type component.

Unitless.Quantity_Type might very well be (an unconstrained subtype of)
Float'Base, or derived from Float'Base, or it might be some user-defined
float, or it might be (hint-hint) derived from some generic formal
floating point type parameter defining the floating-point representation
for the subsystem.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------