Math on dimensioned quantities

Math on dimensioned quantities

[W. Wesley Groleau (Wes)]

I once had to design and code capabilities for numeric types with
dimensions.  Did it two ways: for support code, each number was a record
with its value and the units (enumerated).  Efficiency was not a problem,
but the lack of the 'usual' attributes was an irritation.

The deliverable code used derived floats, not for the sake of attributes,
but because of the (unfounded?) fear of size and time degradation.  What
turned out to be a nuisance here was redefining all the operators.
A generic "operator with conversion factor" was easy enough though
tedious for the legal operations such as
   "+"(L:feet;R:inch)return inch -> inch(L)*12+R
Had to instantiate it in the spec in Ada-83, but now it can be
instantiated in the body and then renamed.

But it was a nuisance to have to declare Units_Mismatch : exception
and redefine MANY multipliers and dividers to raise it.  [For example
"*"(L,R:inch)return inch]

Some compilers will warn you "xxx exception will be raised at run-time"
but it would be a nice language "feature" to extend type checking to
this.  I realize that for a compiler to know all the options, it would
also have to know all the units, which is not feasible.  But--compiler
writers listening?--how about a pragma similar to

   pragma Disallow ( Operation => "*", For_Type => Inch );

If I'm repeating anyone (I don't get "Ada Letters") please forgive me.


---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Magnavox - Mail Stop 10-40                               Home: 219-471-7206
Fort Wayne,  IN   46808              elm (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Math on dimensioned quantities

[progers]

In <9607091345.AA03915@most>, "W. Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM> writes:
>I once had to design and code capabilities for numeric types with
>dimensions.  Did it two ways: for support code, each number was a record
>with its value and the units (enumerated).  Efficiency was not a problem,
>but the lack of the 'usual' attributes was an irritation.
>
>The deliverable code used derived floats, not for the sake of attributes,
>but because of the (unfounded?) fear of size and time degradation.  What
>turned out to be a nuisance here was redefining all the operators.
>A generic "operator with conversion factor" was easy enough though
>tedious for the legal operations such as
>   "+"(L:feet;R:inch)return inch -> inch(L)*12+R
>Had to instantiate it in the spec in Ada-83, but now it can be
>instantiated in the body and then renamed.
>
>But it was a nuisance to have to declare Units_Mismatch : exception
>and redefine MANY multipliers and dividers to raise it.  [For example
>"*"(L,R:inch)return inch]
>
>Some compilers will warn you "xxx exception will be raised at run-time"
>but it would be a nice language "feature" to extend type checking to
>this.  I realize that for a compiler to know all the options, it would
>also have to know all the units, which is not feasible.  But--compiler
>writers listening?--how about a pragma similar to
>
>   pragma Disallow ( Operation => "*", For_Type => Inch );
>
>If I'm repeating anyone (I don't get "Ada Letters") please forgive me.


You could make those undesirable operations abstract, which
would make them uncallable....


>
>
>---------------------------------------------------------------------------
>W. Wesley Groleau (Wes)                                Office: 219-429-4923
>Magnavox - Mail Stop 10-40                               Home: 219-471-7206
>Fort Wayne,  IN   46808              elm (Unix): wwgrol@pseserv3.fw.hac.com
>---------------------------------------------------------------------------



pat
---------------
Patrick Rogers
progers@acm.org

Re: Math on dimensioned quantities

[progers]

In <DuB08H.2HI@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
>In article <9607091345.AA03915@most>,
>W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:
>>writers listening?--how about a pragma similar to
>>
>>   pragma Disallow ( Operation => "*", For_Type => Inch );
>
>How about:
>
>    function "*"(X, Y: Inches) return Inches is <>;
>
>?  Then this particular "*" is abstract and therefore can't be called,
>and this is checked at compile time.  You can still multiply
>inches*inches to get square-inches.  It's annoying that you might have
>to declare lots of "is <>" functions, but I think it does solve the
>problem.

Bob's memory is too good :) The "<>" syntax was changed to use the 
reserved word "abstract".


pat
---------------
Patrick Rogers
progers@acm.org

Re: Math on dimensioned quantities

[Jon S Anthony]

In article <DuB08H.2HI@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:
> >writers listening?--how about a pragma similar to
> >
> >   pragma Disallow ( Operation => "*", For_Type => Inch );
> 
> How about:
> 
>     function "*"(X, Y: Inches) return Inches is <>;
                                                  ^^ abstract

> ?  Then this particular "*" is abstract and therefore can't be called,
> and this is checked at compile time.  You can still multiply
> inches*inches to get square-inches.  It's annoying that you might have
> to declare lots of "is <>" functions, but I think it does solve the
                     ^^^^^^^ abstract

Ooops!  Does this mean you favored the preliminary box notation?

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Math on dimensioned quantities

[Robert A Duff]

In article <JSA.96Jul10135751@organon.com>,
Jon S Anthony <jsa@organon.com> wrote:
>> to declare lots of "is <>" functions, but I think it does solve the
>                     ^^^^^^^ abstract
>
>Ooops!  Does this mean you favored the preliminary box notation?

Oops indeed!

No, I definitely prefer the "is abstract" notation.  The above "typo"
was just an embarrassing slip.  I also like the fact that abstract types
are marked explicitly by syntax, whereas in the old "is <>" version of
the language, a type was abstract based on what operations it had
(specifically, if it was tagged, and had some abstract ops, then it was
abstract).  And finally, at the time these changes were made, the rules
for generic formal abstract types were improved.

Interesting, that a minor syntax change from "is <>" to "is abstract"
would trigger some deeper changes as well.

By the way, there was a lot of argument about new reserved words added
for Ada 9X, which I thought was rather silly.  Norman Cohen was the
master of producing new semi-sensible syntax, without introducing new
reserved words.  I was never quite sure how tongue-in-cheek he was
being, but I believe he did suggest "is abs".

- Bob

Re: Math on dimensioned quantities

[Robert Dewar]

Bob said

"By the way, there was a lot of argument about new reserved words added
for Ada 9X, which I thought was rather silly.  Norman Cohen was the
master of producing new semi-sensible syntax, without introducing new
reserved words.  I was never quite sure how tongue-in-cheek he was
being, but I believe he did suggest "is abs"."

Right, we really did not need new keywords

aliased = with seperate access
tagged = select type with use
protected = separate access for all task
delay until = delay terminate at 
requeue = use new entry

:-)
Maybe we should have an Ada keyword poetry contest

Re: Math on dimensioned quantities

[Robert A Duff]

In article <9607091345.AA03915@most>,
W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:
>writers listening?--how about a pragma similar to
>
>   pragma Disallow ( Operation => "*", For_Type => Inch );

How about:

    function "*"(X, Y: Inches) return Inches is <>;

?  Then this particular "*" is abstract and therefore can't be called,
and this is checked at compile time.  You can still multiply
inches*inches to get square-inches.  It's annoying that you might have
to declare lots of "is <>" functions, but I think it does solve the
problem.

Make sure this is declared in the same package as type Inches; otherwise
all kinds of weirdness can happen.

- Bob

Re: Math on dimensioned quantities

[Dale Stanbrough]

Robert Dewar writes:

"aliased = with seperate access"


It _is_ a good thing that Gnat can spell then! :-)

Dale