Re: Engineering types hierarchy

Re: Engineering types hierarchy

[Marin David Condic]

David Kristola wrote:

> I am trying to put together a robust and easily usable
> hierarchy of types packages to support a collection of
> engineering units (kilograms, meters, seconds, etc.)
> in scalar, vector, and matrix forms.
>

This sounds like a very worth while project and I wanted to suggest that
you look into the Ada Standard Component Library Working Group
(http://www.suffix.com/Ada/SCL/) as both a source of
information/inspiration and as a place you may care to share your work.

Someone sent me some useful unit conversions you may want to consider
:-))

2000 mockingbirds = 2 kilomockingbirds
1/2 lavatory = 1 demijohn
2.71828 grams if a turd = 1 natural log
1000 grams of wet socks = 1 litre hossen
1 trillion grams of brown marijuana = 1 terracotta pot
2 wharves = 1 paradox

MDC
--
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Engineering types hierarchy

[Matthew Heaney]

In article <t73dwpckha.fsf@calumny.jyacc.com> , Hyman Rosen 
<hymie@prolifics.com>  wrote:


> Although this is an Ada group, I am moved to demonstrate a C++ solution
> which is applicable when all units are known at compile time. It's from
> Barton & Nackman's excellant "Scientific and Engineering C++", and is
> quite beautiful. Perhaps it can be transformed into Ada by someone who
> knows more about the language than I do.

This is indeed very similar to an approach that has already been written in
Ada.  It appeared in Do While Jones' book, and was an IEEE standard (I
think) which was spear-headed by Bill Whitaker (I think).

I still prefer the approach I showed in another post, but YMMV.

Matt

Engineering types hierarchy

[David Kristola]

Hello,

I am trying to put together a robust and easily usable
hierarchy of types packages to support a collection of
engineering units (kilograms, meters, seconds, etc.)
in scalar, vector, and matrix forms.

So far, i have a list of the base types and combined
types (meters per second and so on) that are going to
be used on this project.

There is an explosion of operators that i have to
implement.  "/" for meters and second returning
meters per seconds, and on, and on, and on.
Of course, there is nothing special about these
operators beyond the typing they do.

With a few "use type" statements, coding up algorithms
has been a breeze, and unit problems show up when i
try to compile (kg*m^2 being the same as N*m*s^2 was
only a minor nuisance).

So far, the plan is to set up the hierarchy of child
packages as such:

Numeric_Types
Numeric_Types.Vectors
Numeric_Types.Matrices
Numeric_Types.Quaternions
Numeric_Types.Double
Numeric_Types.Double.Vectors
Numeric_Types.Double.Matrices
Numeric_Types.Double.Quaternions

Is there a better way?

(No, this is not a class project)

Thanks,
--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Work: david dot j dot kristola at lmco dot com
Spam: goto.hades@welovespam.com

Re: Engineering types hierarchy

[Pat Rogers]

David Kristola <dkristol@see-my.sig> wrote in message
news:7r50i7$e893@svlss.lmms.lmco.com...
> Hello,
>
> I am trying to put together a robust and easily usable
> hierarchy of types packages to support a collection of
> engineering units (kilograms, meters, seconds, etc.)
> in scalar, vector, and matrix forms.
>
> So far, i have a list of the base types and combined
> types (meters per second and so on) that are going to
> be used on this project.
>
> There is an explosion of operators that i have to
> implement.  "/" for meters and second returning
> meters per seconds, and on, and on, and on.
> Of course, there is nothing special about these
> operators beyond the typing they do.

I have free code for dimensioned unit that avoids the combinatorial
explosion, supporting metric units or any other system of measurment.
The URL is http://www.classwide.com/products/freecode.htm, and then look
for "dimensioned units".  It might be useful as a starting point.

One thing to keep in mind is that the overhead of maintaining
dimensionality may not ultimately be acceptable.  In that case a design
allowing you to transparently substitute a different implementation of
the same interface after unit testing might be appropriate. (Such a
change after testing may not be acceptable practice; certainly not in
safety-critical software!)  This other implementation would not maintain
dimensionality and would therefore not have the overhead.  The point is
that the interface needs to be considered up front so that the
substitution works easily.  I make no representation that the code above
provides such an interface -- it might, I just haven't looked at it for
that purpose.

--
Pat Rogers                            Training and Consulting in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com       Software Fault Tolerance
(281)648-3165                        Real-Time/OO Languages

Re: Engineering types hierarchy

[Robert Dewar]

In article <7r50i7$e893@svlss.lmms.lmco.com>,
  dkristol@see-my.sig wrote:
> Hello,
>
> I am trying to put together a robust and easily usable
> hierarchy of types packages to support a collection of
> engineering units (kilograms, meters, seconds, etc.)
> in scalar, vector, and matrix forms.

There is quite a literature on how to approach this problem
effectively. You should certainly peruse this literature before
starting a project like this. There are several quite different
approaches, and the problems associated with the various
approaches have been discussed in some detail in the past.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Engineering types hierarchy

[Matthew Heaney]

In article <7r50i7$e893@svlss.lmms.lmco.com> , dkristol@see-my.sig (David 
Kristola) wrote:

> Hello,
>
> I am trying to put together a robust and easily usable
> hierarchy of types packages to support a collection of
> engineering units (kilograms, meters, seconds, etc.)
> in scalar, vector, and matrix forms.

> [snip]

> Is there a better way?


In general, I like to keep it simple, and just name (scalar) types with
their units:

  package Ownship is

     type Heading_In_Deg_Type_Base is
         delta 0.1 range -720.0 .. 720.0;

     for Heading_Type_In_Deg_Type_Base'Small use 0.1

     subtype Heading_In_Deg_Type is
       Heading_In_Deg_Type_Base
       range 0.0 .. Heading_In_Deg_Type_Base'Pred (360.0);


     function Get_Heading_In_Deg return Heading_In_Deg_Type;


     type Speed_In_Knots_Type is <whatever>;

     function Get_Speed_In_Knots return Speed_In_Knots_Type;

     ...

  end Ownship;

Naming selector functions with their units prevents this kind of error:

  declare
    Speed_In_MPH : constant Speed_In_MPH_Type :=
      Speed_In_MPH_Type (Ownship.Get_Speed);
  begin

This is a bug, because ownship speed is in knots.  Compare it to:

  declare
    Speed_In_MPH : constant Speed_In_MPH_Type :=
      Speed_In_MPH_Type (Ownship.Get_Speed_In_Knots .. huh???

and hopefully the programmer realizes immediately that there's a type
conversion issue.

When I need to go a units conversion, I just use a package of named numbers:

package Conversions.Speed is

   Knots_Per_KPH : constant := ...;

   KPH_Per_Knots : constant := 1.0 / Knots_Per_KPH;

   MPH_Per_KPH : constant := ...;

   KPH_Per_MPH : constant := 1.0 / MPH_Per_KPH;

   ...
end Conversions.Speed;


Actually, if you have a similar package for length conversions (and maybe
another for simple time conversions), you won't even really need a dedicated
package for speed conversions.

As you've already discovered, other approaches engender a combinatorial
explosion.  There's no way for you to know up front which conversions you're
going to need, so just declare a minimal set (for length, mass, and time,
say), and leave it up to the client to combine the primitive units
conversions into the complex units he needs locally.

It the time of conversion, I just declare the objects with their units and
units-and-type:

  declare
    Speed_In_Knots : constant Speed_In_Knots_Type :=
      Ownship.Get_Speed_In_Knots;

    Speed_In_Knots_As_MPH : constant Speed_In_MPH_Type'Base :=
      Speed_In_MPH_Type'Base (Speed_In_Knots);

    Speed_In_MPH : constant Speed_In_MPH_Type :=
       Speed_In_Knots_As_MPH * MPH_Per_Knots;
  begin
    Set_Speed (Of_Something, To => Speed_In_MPH);
  end;


I find that this simple approach works best, and is more efficient than
other, more complex schemes.  It may be more verbose, but the conversions
are done using baby steps, and I can tell exactly what's going on.

Matt

Re: Engineering types hierarchy

[Hyman Rosen]

dkristol@see-my.sig (David Kristola) writes:
> I am trying to put together a robust and easily usable
> hierarchy of types packages to support a collection of
> engineering units (kilograms, meters, seconds, etc.)
> in scalar, vector, and matrix forms.
> 
> So far, i have a list of the base types and combined
> types (meters per second and so on) that are going to
> be used on this project.
> 
> There is an explosion of operators that i have to
> implement.  "/" for meters and second returning
> meters per seconds, and on, and on, and on.
> Of course, there is nothing special about these
> operators beyond the typing they do.
> 
> Is there a better way?

Although this is an Ada group, I am moved to demonstrate a C++ solution
which is applicable when all units are known at compile time. It's from
Barton & Nackman's excellant "Scientific and Engineering C++", and is
quite beautiful. Perhaps it can be transformed into Ada by someone who
knows more about the language than I do.

I'll write the code assuming three units - mass, time, distance - but the
technique easily scales to as many as you need. The units are kept track
of by virtue of the type system - the objects themselves carry no data
other than their values. The type system allows multiplication and division
of arbitrary units, while allowing addition and subtraction only of like
units. Type mismatches result in compile-time errors.

The scaffolding is wordy, but the punchline is down in main(), where the
units are used in a very natural way, with the compiler deducing types.

#include <iostream>

template<int M, int T, int D>
struct unit
{
	double value;
	unit(double initial = 0) : value(initial) { }
};

template<int M, int T, int D>
unit<M,T,D> operator+(const unit<M,T,D> &a, const unit<M,T,D> &b)
{ return unit<M,T,D>(a.value + b.value); }

template<int M, int T, int D>
unit<M,T,D> operator-(const unit<M,T,D> &a, const unit<M,T,D> &b)
{ return unit<M,T,D>(a.value - b.value); }

template<int M1, int T1, int D1, int M2, int T2, int D2>
unit<M1+M2, T1+T2, D1+D2>
operator*(const unit<M1,T1,D1> &a, const unit<M2,T2,D2> &b)
{ return unit<M1+M2, T1+T2, D1+D2>(a.value * b.value); }

template<int M1, int T1, int D1, int M2, int T2, int D2>
unit<M1-M2, T1-T2, D1-D2>
operator/(const unit<M1,T1,D1> &a, const unit<M2,T2,D2> &b)
{ return unit<M1-M2, T1-T2, D1-D2>(a.value / b.value); }

template<int M, int T, int D>
ostream &operator<<(ostream &out, const unit<M,T,D> &u)
{
	cout << u.value;
	if (M != 0) { out << " gm";  if (M != 1) out << "^" << M; }
	if (D != 0) { out << " cm";  if (D != 1) out << "^" << D; }
	if (T != 0) { out << " sec"; if (T != 1) out << "^" << T; }
	return out;
}

typedef unit<0,0,0> Scalar;
typedef unit<1,0,0> Mass;
typedef unit<0,1,0> Time;
typedef unit<0,0,1> Distance;
typedef unit<0,-1,1> Herz;
typedef unit<1,-2,2> Energy;
typedef unit<0,-1,1> Velocity;
// etc.

// gram-second-centimeter system
const Mass gram = 1;
const Mass kilogram = 1000;
const Distance centimeter = 1;
const Distance meter = 100;
const Time second = 1;
// etc.

int main()
{
	Distance d = Scalar(3) * meter + Scalar(21) * centimeter;
	Time t = 10;
	Mass m = Scalar(5) * kilogram + Mass(672);
	Energy e = (m * d * d / t / t);
	cout << e << endl;
}

Re: Engineering types hierarchy

[David Kristola]

In article rtci5if71iv12@corp.supernews.com, "Pat Rogers" <progers@NOclasswideSPAM.com> () writes:

>I have free code for dimensioned unit that avoids the combinatorial
>explosion, supporting metric units or any other system of measurment.
>The URL is http://www.classwide.com/products/freecode.htm, and then look
>for "dimensioned units".  It might be useful as a starting point.
>
>One thing to keep in mind is that the overhead of maintaining
>dimensionality may not ultimately be acceptable.

It is not.  I took a look at your code, and it will fit
the bill for something i am doing at home, but it will
not help too much for this project.  Besides the problem
with changing implementations after testing, there would
also be a major conflict with our telemetry system, and
our execution has to be fast, so runtime checking isn't
practical even during testing.

Thanks though.  I think this will be just what i need
for a project i am working on at home!

--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Work: david dot j dot kristola at lmco dot com
Spam: goto.hades@welovespam.com

Re: Engineering types hierarchy

[David Kristola]

In article 37d663dd@news1.prserv.net, "Matthew Heaney" <matthew_heaney@acm.org> () writes:

>In general, I like to keep it simple, and just name (scalar) types with
>their units:
>
>  package Ownship is

Ownship, that brings back memories!  (BSY-2, Seawolf submarine :-)

{snip}
>As you've already discovered, other approaches engender a combinatorial
>explosion.  There's no way for you to know up front which conversions you're
>going to need, so just declare a minimal set (for length, mass, and time,
>say), and leave it up to the client to combine the primitive units
>conversions into the complex units he needs locally.

I am trying to keep it simple, however, the problem domain
is not cooperating ;-).  A number of different packages need
the same subsets of units and operators, and often they
communicate in these units.  I have to pass torques around
(Newton_Meters_Type), and many other combinations.

At this point, conversions don't seem to pose a problem
(we will be working in meters, and not have to convert to
millimeters and kilometers and centimeters).  But we are
moving through many different algorithms, and using many
different unit combinations.  Sensors bring in data in one
form, it then gets combined with inertia data and commands
to form torques and eventually currents (and this is just
the subsystem i am worrying about).

The first try at the types package is working out well.
Once the operators are in place, and constants and variables
are properly typed, the algorithms are real clean.  And
units are being checked at compile time.  But if there is
a better way that fits our needs, this is the time to
make the change.

Thanks,
--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Spam: goto.hades@welovespam.com

Re: Engineering types hierarchy

[David Kristola]

In article 5E2E5F73@pwfl.com, Marin David Condic <condicma@bogon.pwfl.com> () writes:
>This sounds like a very worth while project and I wanted to suggest that
>you look into the Ada Standard Component Library Working Group
>(http://www.suffix.com/Ada/SCL/) as both a source of
>information/inspiration and as a place you may care to share your work.

I took a look at the above site and did not see anything
that seemed useful.  There are plenty of ADTs there, but
i did not even see anything along the lines of Pat Rogers'
"dimensioned units"
(http://www.classwide.com/products/freecode.htm).


As for sharing whatever we settle on, i would love to,
but all source code developed here gets stamped
"proprietary" and is usually even kept from other
in-house projects.  :-(


>Someone sent me some useful unit conversions you may want to consider
>:-))
>
>2000 mockingbirds = 2 kilomockingbirds
>1/2 lavatory = 1 demijohn
>2.71828 grams if a turd = 1 natural log
>1000 grams of wet socks = 1 litre hossen
>1 trillion grams of brown marijuana = 1 terracotta pot
>2 wharves = 1 paradox

Thanks!  I might just add these in somewhere and
see if the QA folks actually read the source code
under review!


--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Spam: goto.hades@welovespam.com

Re: Engineering types hierarchy

[David Kristola]

In article 1@nnrp1.deja.com, Robert Dewar <robert_dewar@my-deja.com> () writes:

>There is quite a literature on how to approach this problem
>effectively. You should certainly peruse this literature before
>starting a project like this. There are several quite different
>approaches, and the problems associated with the various
>approaches have been discussed in some detail in the past.

Does anyone have any pointers to web available sources
or books that i might check out?

I have searched through the Home of the Brave Ada
Programmer and AdaIC and DejaNews, and not found too
much other than the discriminant record approach.

Perhaps i did not choose my key words well.  :-(

Thanks for all the help!

--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Work: david dot j dot kristola at lmco dot com
Spam: goto.hades@welovespam.com

Re: Engineering types hierarchy

[Robert Dewar]

In article <7r7dje$sdi5@svlss.lmms.lmco.com>,
  dkristol@see-my.sig wrote:
> Perhaps i did not choose my key words well.  :-(

Perhaps not all literature is on the web, and libraries are
still useful?? :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Engineering types hierarchy

[Robert Dewar]

In article <7r7dje$sdi5@svlss.lmms.lmco.com>,
  dkristol@see-my.sig wrote:
> Perhaps i did not choose my key words well.  :-(

Perhaps not all literature is on the web, and libraries are
still useful?? :-)




Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Engineering types hierarchy

[David Botton]

You may find this article on AdaPower of assitance:

* Dimensional Arithmetics (Units of Measure) in Ada (Grein)
http://www.adapower.com/lang/dimension.html

David Botton

David Kristola wrote in message <7r50i7$e893@svlss.lmms.lmco.com>...
>Hello,
>
>I am trying to put together a robust and easily usable
>hierarchy of types packages to support a collection of
>engineering units (kilograms, meters, seconds, etc.)
>in scalar, vector, and matrix forms.

Re: Engineering types hierarchy

[Matthew Heaney]

In article <7r7dje$sdi5@svlss.lmms.lmco.com> , dkristol@see-my.sig (David 
Kristola) wrote:

> Does anyone have any pointers to web available sources
> or books that i might check out?

Units of Measure As A Data Attribute
Narain Gehani
Computer Languages, Vol 2, p. 93-111 (1977?)

Incorporation of Units into Programming Languages
Michael Karr and David B. Loveman III
CACM, May 1978, Vol 21, No. 5, p385-391

Ada's Derived Types and Units of Measure
N. H. Gehani
Software-Practice and Experience
Vol 15 (6), p555-569 (June 1985)


Bill Whitaker's Units stuff

The following text documents some of the considerations initially
governing the search for a more powerful units capability.

The problem is to provide an Ada 95 method of specifying SI units.
It has philosophical interest in that the units example was the
one used to illustrate the advantages of strong typing in the early
requirements discussions.  It was unfortunate that the resulting Ada
did not provide a convenient solution.  This was brought up to the
Intermetrics Ada 95 team, but was apparently not "object-oriented"
enough to receive consideration.

<http://users.erols.com/whitaker/iss_418.htm>


You should also search the PAL and the ASE.  Maybe Rick Conn can be of some
assistance here, to help you find examples of what you're looking for.

<http://wuarchive.wustl.edu/languages/ada/pal.html>
<ftp://ftp.cdrom.com/pub/ase/index.htm>
<http://xenadu.home.mindspring.com/>


If you find something good, please post the URL etc to this newsgroup.

Hope this helps some,
Matt

Re: Engineering types hierarchy

[Matthew Heaney]

In article <37d7ba7d@news1.prserv.net> , "Matthew Heaney" 
<matthew_heaney@acm.org> wrote:

I forget a couple more references.

1) I think there's an example in D.W. Jones' book, Ada In Action.  I don't
have a URL for the book handy, but why don't you email D.W. and ask him for
the URL?  (And be sure to post it here.)

Do-While Jones <do_while@RIDGECREST.CA.US>


2) The package Dimensioned_Units appears in section 9.3.8 of the Ada83
Rationale.  You can get that book on the web in the usual places, including
the AdaIC and the adahome.

<http://www.adaic.org/>
<htpp:/www.adahome.com/>


> In article <7r7dje$sdi5@svlss.lmms.lmco.com> , dkristol@see-my.sig (David
> Kristola) wrote:
>
>> Does anyone have any pointers to web available sources
>> or books that i might check out?
>
> Units of Measure As A Data Attribute
> Narain Gehani
> Computer Languages, Vol 2, p. 93-111 (1977?)
>
> Incorporation of Units into Programming Languages
> Michael Karr and David B. Loveman III
> CACM, May 1978, Vol 21, No. 5, p385-391
>
> Ada's Derived Types and Units of Measure
> N. H. Gehani
> Software-Practice and Experience
> Vol 15 (6), p555-569 (June 1985)
>
>
> Bill Whitaker's Units stuff
>
> The following text documents some of the considerations initially
> governing the search for a more powerful units capability.
>
> The problem is to provide an Ada 95 method of specifying SI units.
> It has philosophical interest in that the units example was the
> one used to illustrate the advantages of strong typing in the early
> requirements discussions.  It was unfortunate that the resulting Ada
> did not provide a convenient solution.  This was brought up to the
> Intermetrics Ada 95 team, but was apparently not "object-oriented"
> enough to receive consideration.
>
> <http://users.erols.com/whitaker/iss_418.htm>
>
>
> You should also search the PAL and the ASE.  Maybe Rick Conn can be of some
> assistance here, to help you find examples of what you're looking for.
>
> <http://wuarchive.wustl.edu/languages/ada/pal.html>
> <ftp://ftp.cdrom.com/pub/ase/index.htm>
> <http://xenadu.home.mindspring.com/>
>
>
> If you find something good, please post the URL etc to this newsgroup.
>
> Hope this helps some,
> Matt


--
Matt

It is impossible to feel great confidence in a negative theory which has
always rested its main support on the weak points of its opponent.

Joseph Needham, "A Mechanistic Criticism of Vitalism"

Re: Engineering types hierarchy

[Pat Rogers]

Matthew Heaney <matthew_heaney@acm.org> wrote in message
news:37d7d0ef@news1.prserv.net...
> In article <37d7ba7d@news1.prserv.net> , "Matthew Heaney"
> <matthew_heaney@acm.org> wrote:
>
> I forget a couple more references.
>
> 1) I think there's an example in D.W. Jones' book, Ada In Action.  I
don't
> have a URL for the book handy, but why don't you email D.W. and ask
him for
> the URL?  (And be sure to post it here.)
>
> Do-While Jones <do_while@RIDGECREST.CA.US>
>
>
> 2) The package Dimensioned_Units appears in section 9.3.8 of the Ada83
> Rationale.  You can get that book on the web in the usual places,
including
> the AdaIC and the adahome.
>
> <http://www.adaic.org/>
> <htpp:/www.adahome.com/>

Just to be complete, the version in the Rationale had to come from the
one in Paul Hilfinger's dissertation, published in 1982, and his work
with the Ada 83 design team.  Hilfinger cites a prior version by  John
Nestor in the Red language proposal.

I wrote an article about it in Ada Letters, "Dimensional Analysis In
Ada", Vol. 8 No. 5, Sept/Oct 1988, pp. 92-100, back when people often
wrote article for Ada Letters showing the neat things the language could
express*.  Hilfinger's discussion is much more interesting, as he
examines how to define user-defined assuagement by 'overloading' ":="
and then apply it to the dimensioned units abstraction.

* The other thing people did with Ada in the 1980's was to come up with
design methods.  If you didn't have a design method named after you, or
associated with you, you weren't really trying.  :-)

--
Pat Rogers                            Training and Consulting in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com       Software Fault Tolerance
(281)648-3165                        Real-Time/OO Languages

Re: Engineering types hierarchy

[David Kristola]

In article 1@nnrp1.deja.com, Robert Dewar <robert_dewar@my-deja.com> () writes:
>In article <7r7dje$sdi5@svlss.lmms.lmco.com>,
>  dkristol@see-my.sig wrote:
>> Perhaps i did not choose my key words well.  :-(
>
>Perhaps not all literature is on the web, and libraries are
>still useful?? :-)

Really?  What a concept.  Paper.  Hmmm.

Actually, i plan on visiting the company library sometime
soon.  Unfortunately, it is "self serve" so i can't bother
a librarian to help locate information.  Fortunately, it
supposedly has a very good collection of journals (it is in
another building on the far side of the campus, and i have
not been there before).  So little time, so many books.  :-(

All this for a little types package.  I must be nuts.

--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Spam: goto.hades@welovespam.com

Re: Engineering types hierarchy

[David Kristola]

In article 1@news.gate.net, "David Botton" <David@Botton.com> () writes:
>You may find this article on AdaPower of assitance:
>
>* Dimensional Arithmetics (Units of Measure) in Ada (Grein)
>http://www.adapower.com/lang/dimension.html
>
>David Botton

Thanks!

Unfortunately, the link to Christoph Grein's web site (where
the solution hinted at in the article exists) seem to be
broken (the server could not find the file).

The reason for using private types was to remove nonsensical
operators.  Meters * meters yields meters squared.  Ada95
allows us to remove those operators using "abstract".


--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Spam: goto.hades@welovespam.com

Re: Engineering types hierarchy

[Ted Dennison]

In article <7ra3pm$gsd3@svlss.lmms.lmco.com>,
  dkristol@see-my.sig wrote:
> In article 1@news.gate.net, "David Botton" <David@Botton.com> ()
writes:
> >You may find this article on AdaPower of assitance:
> >
> >* Dimensional Arithmetics (Units of Measure) in Ada (Grein)
> >http://www.adapower.com/lang/dimension.html

> Unfortunately, the link to Christoph Grein's web site (where
> the solution hinted at in the article exists) seem to be
> broken (the server could not find the file).

It appears that he moved that particular article. It can now be found at
http://home.T-Online.de/home/Christ-Usch.Grein/Ada/Universe.html . If
you can read German, there's a "more elaborate" version at
http://home.T-Online.de/home/Christ-Usch.Grein/Ada/Universum.html .

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Engineering types hierarchy

[David Kristola]

In article 37d7d0ef@news1.prserv.net, "Matthew Heaney" <matthew_heaney@acm.org> () writes:
>In article <37d7ba7d@news1.prserv.net> , "Matthew Heaney" 
><matthew_heaney@acm.org> wrote:
>
>I forget a couple more references.
>
>1) I think there's an example in D.W. Jones' book, Ada In Action.  I don't
>have a URL for the book handy, but why don't you email D.W. and ask him for
>the URL?  (And be sure to post it here.)
>
>Do-While Jones <do_while@RIDGECREST.CA.US>

http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/aia/contents.html

>2) The package Dimensioned_Units appears in section 9.3.8 of the Ada83
>Rationale.  You can get that book on the web in the usual places, including
>the AdaIC and the adahome.
>
><http://www.adaic.org/>
><http:/www.adahome.com/>

Adahome points to AdaIC, which points to:

http://wuarchive.wustl.edu/languages/ada/ajpo/standards/83rat/html/


--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Spam: goto.hades@welovespam.com

Re: Engineering types hierarchy

[Richard D Riehle]

In article <7r75hc$sdi4@svlss.lmms.lmco.com>,
	dkristol@see-my.sig (David Kristola) wrote:

>I took a look at the above site and did not see anything
>that seemed useful.  There are plenty of ADTs there, but
>i did not even see anything along the lines of Pat Rogers'
>"dimensioned units"
>(http://www.classwide.com/products/freecode.htm).

I don't know if it will be helpful to you, but one of our clients
has found it useful to take advantage of Ada's generic formal
package parameter model, starting with a signature package.

generic
  type Item is digits <>;
  with function "+" (L, R : Item) return Item is <>;
  -- repeat for each arithmetic operator
  with function "=" (L, R : Item) return Item is <>;
  -- repeat for each logical operator
package Float_Math_Signature is end Float_Math_Signature;

This can now be instantiated in lots of places where you need to do 
math operations on your own type.  For example, you might write
your own version of "=" or "/" for a particular floating point type.
I have a version of this that even works for private types.

This can be used in conjunction with "use type" too.

with Float_Math_Signature;
generic
   with package Math_Ops is new Float_Math_Signature(<>);
package Some_Computation_Package is 
    ...
end Some_Computation_Package;

This idea can be extended to further generalize your design so the
types can be decoupled from each other more effectively.  You can
use it with discriminants, but it may sometimes eliminate the need
for discriminants in some components.

Richard Riehle
http://www.adaworks.com