Operators -> unit analysis

Operators -> unit analysis

[Charles Hixson]

Terry Sikes wrote:

> ...
> One thing I'd like to see in both languages is the ability to use a
> set of non-reserved Unicode symbols for operator overloading, to
> disambiguate with the normal operator symbols.
>
> Terry
> --
> tsikes@netcom.com

I don't insist on unicode, but I would also like more operators that could
be overloaded.  How about swiping a leaf from Fortran60 (.le., .eq., ...)
and allowing symbols beginning with a (e.g.) period, then a string of chars
between succ (" ") and char (126) and then another period, with white space
separations  required on each side, to be an overloadable operator?

And some good way to handle units.  So that we could safely say things like:

     speed := 37.miles / 1.5.hours;
I'm not too pleased with the syntax, but the idea is there.  Computer
languages should make unit analysis easy!  This is one of the "promises" of
abstract data types, but I don't feel that it's been truly fulfilled,
largely because it's too difficult to use.  Syntax is part of the problem,
and standard libraries are another part (or perhaps that one's been solved,
and I just don't know).  But standard types should be defined for all the
standard metric units, and most of the more common English units, with
conversion functions between them.  I guess that the standard example
package, Rational, is a good example of how it could be done, but there is
lots of detail work, and it needs to be standardized.

If there is a work group on this, I would like to know about it.  The recent
Mars probe again brought this to my attention.  They may not have been using
Ada (I didn't bother to check), but avoiding this kind of problem is
something that Ada should be for.

I dislike the syntax:
    speed := (37 * mile) / (1.5 * hour);
though I prefer it to:
    speed := miles (37) / hours (1.5);
but that's the best that I know how to do it in Ada.  Is there a better
choice?  (I.e. one that would look more like what a math student would write
in a word problem?)

Of course one could say:
    dist    :    constant Miles    :=    37;
    time   :    constant Hours    :=   1.5;
    speed :  MpH;
    speed    :=    dist / time;

but that seems quite unnecessarily verbose!

Re: Operators -> unit analysis

[Ted Dennison]

In article <387383D0.4EA02E95@earthlink.net>,
  Charles Hixson <charleshixsn@earthlink.net> wrote:
> Terry Sikes wrote:
>
> > ...
> > One thing I'd like to see in both languages is the ability to use a
> > set of non-reserved Unicode symbols for operator overloading, to
> > disambiguate with the normal operator symbols.

> I don't insist on unicode, but I would also like more operators that
> could be overloaded.

How would you decide where to place them in the precidence hierarchy?
Having recently built a couple of packages around overloaded operators,
I found that getting the correct precidence for the various new
operators I defined is at least as important as the appropriateness of
the chosen operator symbol to the task. You don't want to end up in a
situation where you have to use parenthesis in counter-intuitive places
to work around the precidence rules.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Operators -> unit analysis

[Pat Rogers]

Charles Hixson <charleshixsn@earthlink.net> wrote in message
news:387383D0.4EA02E95@earthlink.net...

<snip>

> And some good way to handle units.  So that we could safely say things
like:
>
>      speed := 37.miles / 1.5.hours;
> I'm not too pleased with the syntax, but the idea is there.  Computer
> languages should make unit analysis easy!  This is one of the
"promises" of
> abstract data types, but I don't feel that it's been truly fulfilled,
> largely because it's too difficult to use.  Syntax is part of the
problem,
> and standard libraries are another part (or perhaps that one's been
solved,
> and I just don't know).  But standard types should be defined for all
the
> standard metric units, and most of the more common English units, with
> conversion functions between them.  I guess that the standard example
> package, Rational, is a good example of how it could be done, but
there is
> lots of detail work, and it needs to be standardized.

I have a facility somewhat like that on the "free code page" at my web
site:

http://www.classwide.com/products/freecode.htm

Look for the "dimensioned units" section (at the bottom).

--
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: Operators -> unit analysis

[Charles Hixson]

Pat Rogers wrote:

> Charles Hixson <charleshixsn@earthlink.net> wrote in message
> news:387383D0.4EA02E95@earthlink.net...
>
> ...
> I have a facility somewhat like that on the "free code page" at my web
> site:
>
> http://www.classwide.com/products/freecode.htm
>
> Look for the "dimensioned units" section (at the bottom).
>
> --
> 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

NICE!!
I'm going to have to study that a bit.   I may add coulombs, or some such,
just to make sure I understand what it going on, but it looks pretty
straightforward.  Much more so than I expected, actually.  I still would
prefer a nicer syntax, but that's not enough to worry much about.
(I'll certainly add pounds, feet, and dollars [that last may strain the
system :-) ] )

Re: Operators -> unit analysis

[Matthew Heaney]

In article <387383D0.4EA02E95@earthlink.net> , Charles Hixson 
<charleshixsn@earthlink.net>  wrote:

> And some good way to handle units.  So that we could safely say things like:
>
>      speed := 37.miles / 1.5.hours;
> I'm not too pleased with the syntax, but the idea is there.

You can already do this:

  Speed := Miles'(37.0) / Hours'(1.5);

I always recommend type qualification for literals when units are an
issue.

> I dislike the syntax:
>     speed := (37 * mile) / (1.5 * hour);
> though I prefer it to:
>     speed := miles (37) / hours (1.5);
> but that's the best that I know how to do it in Ada.  Is there a better
> choice?  (I.e. one that would look more like what a math student would write
> in a word problem?)

See above.


> Of course one could say:
>     dist    :    constant Miles    :=    37;
>     time   :    constant Hours    :=   1.5;
>     speed :  MpH;
>     speed    :=    dist / time;
>
> but that seems quite unnecessarily verbose!

Agreed.

Re: Operators -> unit analysis

[Matthew Heaney]

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

> Charles Hixson <charleshixsn@earthlink.net> writes:
>> And some good way to handle units.  So that we could safely say things like:
>>      speed := 37.miles / 1.5.hours;
>
> There is already a very good way to handle units, without any runtime
> overhead if you don't need to determine units dynamically.

Yes, there is, by using type qualification:

  Speed := Miles'(37.0) / Hours'(1.5);

Re: Operators -> unit analysis

[Charles Hixson]

Matthew Heaney wrote:

> ...

> You can already do this:
>
>   Speed := Miles'(37.0) / Hours'(1.5);
>
> I always recommend type qualification for literals when units are an
> issue.
>

That handles the units problem, but the syntax is still backwards for how it needs
to be read.  I suppose there's no way out. (And I'm being picky).  But:
  Speed := Miles'(37.0) / Hours'(1.5);
is read as:
  Speed := (37.0)'Miles / (1.5)'Hours;
And even there, for a simple statement like this I would prefer:
  Speed := 37.0'Miles / 1.5'Hours;
Actually, this would probably be as near to optimal as is realizable.
But defining each unit separately has problems.  I like the general approach used
by Pat Rogers:

> I have a facility somewhat like that on the "free code page" at my web
> site:
>
> http://www.classwide.com/products/freecode.htm
>
> Look for the "dimensioned units" section (at the bottom).
>
> --
> 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
>
as it feels more "generalizeable".

Re: Operators -> unit analysis

[Hyman Rosen]

Charles Hixson <charleshixsn@earthlink.net> writes:
> And some good way to handle units.  So that we could safely say things like:
>      speed := 37.miles / 1.5.hours;

There is already a very good way to handle units, without any runtime
overhead if you don't need to determine units dynamically.

See Barton & Nackman, _Scientific and Engineering C++_.

Re: Operators -> unit analysis

[Charles Hixson]

> How would you decide where to place them in the precidence hierarchy?
>
> (see bottom)
>
Choices:
1)  Put them at the bottom of the precedence hierarchy, with equal
precedence.  Use parenthesis to do groupings.
2) (too complex) Allow a more verbose declaration form that specifies the
binding level. (Arrange all standard operators in ranked order, and allow
the newly declared operator to be inserted into the list.)
3) (Complex, but NICE)  Arrange for two kinds of operator declaration.  One
that is at the bottom of the hierarchy (as 1).  The other is near the top
(don't break apart parenthesized groups!) but left-binding and taking only
one parameter.  Call this one Unit or some such.  This would be for
declaring things like grams, dynes, years, etc.  So we could have:

UnitFunction grams (scalar : <<Numeric>>) returns Gram is

Custom operators in complex statements are problematic anyway, but I would
like to distinguish between dot product and cross product (and analogous
cases), which are conventionally treated as operators rather than as
functions.  I have never gotten used to the notation that goes:
    z    =    x.dot (y);
even though it *IS* semantically equivalent to, e.g.:
    z := x .*. y
(It would be even nicer if the large centered dot was a legitimate
character [which brings us back to the unicode request earlier in the
thread {it seems to have rolled off my newsServer, so I can't say who made
the request}], but it *is* a bit hard to type).

I frequently find that "common usage" improved the understand ability of
code.  The problem is that it is hard to support in a compiler (or requires
complex implementations).  To take an example from a different thread:
    speed = x miles / y hours;
now if there were "a units operator" (i.e., high priority, left binding,
takes one operator) one could define miles as an operator that multiplied a
scalar by 1 mile and returned a value of type Miles.  But units would need
to aggregate, so that we could specify area, volume, G, etc. So the exact
implementation would need to be carefully thought out.  The customary
syntax, however, has been with us since grade school, and changing it
immediately makes things less intelligible.  We have years of experience
that tell us that units are high priority, left binding, and take one
operator.  Except for traditional exceptions like currency which are high
priority, right binding, and take one operator (although when spoken the
currency units are left binding, just like a normal unit).  Thus $5 is 5
dollars, $5.25 is 5 and 1/4 dollars (or 5 dollars and 25 cents).

A problem is that the names of units occupy the same space as normal
variable names, but conceptually they are a different *kind* of thing.
Thus 5 grams IS 5 * (1 gram) IS Gram'(5), but the versions are each more
difficult to read than the one prior to it.  5'grams, OTOH, is transparent.

Unfortunately, it appears to me that making either: 5 grams or: 5'grams
legal would require changes in the specification of any language that I
know (except for Smalltalk and Forth, which have other problems).

Ted Dennison wrote:

> In article <387383D0.4EA02E95@earthlink.net>,
>   Charles Hixson <charleshixsn@earthlink.net> wrote:
> > Terry Sikes wrote:
> >
> > > ...
> > > One thing I'd like to see in both languages is the ability to use a
> > > set of non-reserved Unicode symbols for operator overloading, to
> > > disambiguate with the normal operator symbols.
>
> > I don't insist on unicode, but I would also like more operators that
> > could be overloaded.
>
> How would you decide where to place them in the precidence hierarchy?
> Having recently built a couple of packages around overloaded operators,
> I found that getting the correct precidence for the various new
> operators I defined is at least as important as the appropriateness of
> the chosen operator symbol to the task. You don't want to end up in a
> situation where you have to use parenthesis in counter-intuitive places
> to work around the precidence rules.
>
> --
> T.E.D.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: Operators -> unit analysis

[Samuel T. Harris]

Ted Dennison wrote:
> 
> In article <387383D0.4EA02E95@earthlink.net>,
>   Charles Hixson <charleshixsn@earthlink.net> wrote:
> > Terry Sikes wrote:
> >
> > > ...
> > > One thing I'd like to see in both languages is the ability to use a
> > > set of non-reserved Unicode symbols for operator overloading, to
> > > disambiguate with the normal operator symbols.
> 
> > I don't insist on unicode, but I would also like more operators that
> > could be overloaded.
> 
> How would you decide where to place them in the precidence hierarchy?
> Having recently built a couple of packages around overloaded operators,
> I found that getting the correct precidence for the various new
> operators I defined is at least as important as the appropriateness of
> the chosen operator symbol to the task. You don't want to end up in a
> situation where you have to use parenthesis in counter-intuitive places
> to work around the precidence rules.
> 

How about a representation clause which defines the precedence
of a custom operator to that of another. Something like ...

for "union"'precedence use "+";
for "intersection"'precedence use "*";

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: Operators -> unit analysis

[Terry Sikes]

In article <850tl9$thu$1@nnrp1.deja.com>,
Robert Dewar  <robert_dewar@my-deja.com> wrote:
>In article <387383D0.4EA02E95@earthlink.net>,
>  Charles Hixson <charleshixsn@earthlink.net> wrote:
>> Terry Sikes wrote:
>>
>> > ...
>> > One thing I'd like to see in both languages is the ability
>to use a
>> > set of non-reserved Unicode symbols for operator
>overloading, to
>> > disambiguate with the normal operator symbols.
>> >
>> > Terry
>> > --
>> > tsikes@netcom.com
>>
>> I don't insist on unicode, but I would also like more
>operators that could
>> be overloaded.
>
>This was an issue discussed at length during the design, and
>the great majority felt it was an unnecessary complexification
>to add such operators. Even a limited proposal to add a single
>operator to be used for "almost implicit" conversions failed.
>I don't see what has changed to make it worth rearguing the
>point.

Was this point argued at length after the decision was made to add the
various annexes?  I'd think that this would be better received if it
was tied to the Numerics annex, since certainly this would be the
major area of use.

Lack of a large number of overloadable operator symbols seems like a
major lack in an otherwise numerics-friendly language.

Unicode support may be a bit over the top ;) but there are alternative
syntax possibilities like:

   --  Cross product
   Mat3 := Mat1 (x) Mat2;

(This approach is borrowed from the jpp Java preprocessor).

Ah well, perhaps it will make it in Ada 200x.  :-)

Terry
--
tsikes@netcom.com

Re: Operators -> unit analysis

[Robert A Duff]

tsikes@netcom.com (Terry Sikes) writes:

> Was this point argued at length after the decision was made to add the
> various annexes?

Yes.

>...I'd think that this would be better received if it
> was tied to the Numerics annex, since certainly this would be the
> major area of use.

Perhaps, but most numerics code is done in Fortran, and it doesn't
bother with all this fancy stuff either.

- Bob

Re: Operators -> unit analysis

[Robert Dewar]

In article <387383D0.4EA02E95@earthlink.net>,
  Charles Hixson <charleshixsn@earthlink.net> wrote:
> Terry Sikes wrote:
>
> > ...
> > One thing I'd like to see in both languages is the ability
to use a
> > set of non-reserved Unicode symbols for operator
overloading, to
> > disambiguate with the normal operator symbols.
> >
> > Terry
> > --
> > tsikes@netcom.com
>
> I don't insist on unicode, but I would also like more
operators that could
> be overloaded.


This was an issue discussed at length during the design, and
the great majority felt it was an unnecessary complexification
to add such operators. Even a limited proposal to add a single
operator to be used for "almost implicit" conversions failed.
I don't see what has changed to make it worth rearguing the
point.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Operators -> unit analysis

[Brian Rogoff]

On Fri, 7 Jan 2000, Ted Dennison wrote:
> In article <853lkg$tgj$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
> > In article <3874D0BE.82F04763@Raytheon.com>,
> 
> > Algol-68 designers regard it as a horrible mistake. One should
> > only rely on precedence of operators where the precedence rules
> > are clear and obvious. This cannot be the case by definition
> > for user defined precedences.
> 
> I think you are saying that in practice it gets to be a mess. I do
> appreciate that. But the above statement would only be true if they are
> truly user-defined. If the operators and precedences are in fact created
> by the user to match existing precedences for established mathematical
> notations, then I think it *would* be clear and obvious to any user. For
> instance, if I make a notation including operators to mimic BNF
> productions (which I am doing, btw), any reasonable user would expect to
> *not* have to put parenthesis around a production's right side just to
> keep the BNF "::=" operator from being evaluated prematurely.

Ted, if this is what you are trying to do, you should take a look at a 
"functional" programming language, like ML or Haskell. These languages 
allow user defined infix operators, and the example you describe is 
well studied in that community. 

-- Brian

Re: Operators -> unit analysis

[Tucker Taft]

Ted Dennison wrote:
> 
> In article <8531v6$6qk$1@nntp3.atl.mindspring.net>,
>   tsikes@netcom.com (Terry Sikes) wrote:
> > In article <850tl9$thu$1@nnrp1.deja.com>,
> > Was this point argued at length after the decision was made to add the
> > various annexes?  I'd think that this would be better received if it
> > was tied to the Numerics annex, since certainly this would be the
> > major area of use.
> 
> Not by far. There are many applications in many realms of study that
> have traditionally been described by some kind of mathematical notation.
> The Gnat Snobol packages are a very good example for pattern matching.
> Possible other applications off the top of my head are: strings, lists,
> sets, database queries, BNF, Music.

For what it is worth, in my view adding lots of operators
is not doing the user any big favor.  Good old function-call syntax,
using named parameters when appropriate, is the clearest for most things.  

The advantage of operators is when a single statement involves many 
operations, and the use of infix operators makes it much easier to "grok"
what is going on.  That advantage disappears quickly if you end
up with unfamiliar operators interspersed within the complex
expression.  Even "familiar" operators are bad news if used
in unfamiliar ways. 

Furthermore, in many of the cases you mention above, you 
don't really want the operators *executed*
at run-time.  Instead, you want to create some kind of tree
representation, and then interpret it in some special way.
Building these trees at run-time seems like an inefficient way
to do things, which means the contexts where they will be useful
is even more limited.

In my view, operators are great for complex number packages, 
and other numeric-like things (matrices, vectors, bignums, etc.),
but as soon as the meanings of the operators becomes even slightly
obscure or non-standard, the value to the reader drops precipitously.
 
> --
> T.E.D.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Operators -> unit analysis

[Matthew Heaney]

In article <wccln626ily.fsf@world.std.com> , Robert A Duff 
<bobduff@world.std.com>  wrote:

> I would say: If it's not a precedence rule I learned in grade school,
> then it shouldn't be in a programming language (whether it was put there
> by the language designer or by some "clever" programmer).

Oh dear, I'll probably get horribly flamed for saying so, but I disagree
with the Ada(83) decision to require that "and" and "or" operators
appearing within the same statement also require parenthesis.

I think that, as in C, "and" should be given a higher precedence than
"or", analogous to how "*" is given a higher precedence than "+".

--
Evolution is as well documented as any phenomenon in science, as
strongly as the earth's revolution around the sun rather than vice
versa.

Stephen Jay Gould, Time, 23 Aug 1999

Re: Operators -> unit analysis

[Terry Sikes]

In article <wcc9022izjp.fsf@world.std.com>,
Robert A Duff  <bobduff@world.std.com> wrote:

>>...I'd think that this would be better received if it
>> was tied to the Numerics annex, since certainly this would be the
>> major area of use.
>
>Perhaps, but most numerics code is done in Fortran, and it doesn't
>bother with all this fancy stuff either.

Which is why so many people are searching for something better, and
why so much numerical code is being translated into C++ (despite its
obvious deficiencies).

By coincidence, I received the following from the advanced-java list
today, I'll include it so you can ask yourself "Why not Ada Grande?".
(BTW, while operator overloading is not part of Java today, it will be
in the future according to Gosling.)

It seems to me that Ada is better suited to this problem space than
Java since it has a) _optional_ GC and b) static data structures.

Perhaps what Ada needs most is a Java-like syntax front-end.  ;-)

Terry

--begin quoted message--
To: advanced-java@xcf.berkeley.edu
Subject: ACM 2000 Java Grande Conference (10 days, 2 weekends left)
Date: Fri, 7 Jan 2000 07:55:29 +0100

Dear Colleague,

Please find attached the Call for Papers for the ACM 2000 Java Grande
Conference.  I would appreciate it if you would help ensure the wide
publicity of this event by forwarding the call to colleagues who you
think might be interested in submitting a paper.

Please note: Due to NSF ITR proposal deadline the due dates for JG2000
have been changed.  See below.

We look forward to your submission.

Thanks, 

	   Michael Philippsen.

---------------------------------------------------------------------------

                    CALL FOR PAPERS

           ACM 2000  Java Grande Conference

(NOTICE:  Due to NSF ITR proposal deadline the due dates for JG2000
 have been changed.  See below.)
                                                       
               Sponsored by ACM SIGPLAN 

       San Francisco, California, June 3-4, 2000 

             http://www.extreme.indiana.edu/java00


The Java Grande Conference focuses on the use of Java in the broad area of 
high-performance computing; including engineering and scientific
applications, simulations, data-intensive applications, and other 
emerging application areas that exploit parallel and distributed computing or
combine communication and computing. A day of tutorials will be held on the 
day following the conference. The conference precedes the JavaOne
2000 conference, which would enable the Java Grande attendees to expose 
themselves to the latest in basic Java Technology. 

Authors are invited to submit manuscripts that demonstrate timely results, 
technologies, or experiences that are most likely to have impact on the
use of Java in high performance computing systems. 

Topics of interest include but are not restricted to: 

     Java use for scientific and engineering applications 
     Java frameworks and libraries for high-performance computing 
     Implementation techniques for Java on high-performance systems 
     Java numerics and Java extensions for high-performance computing 
     Java compilation and optimization for high-performance computing 
     Java development tools and environments for high-performance computing 
     Java performance and benchmarking 

SUBMISSION

Papers should report new research and should not exceed 5000 words 
(approximately 10 pages typeset on 16 point spacing, or 15 typewritten
double-spaced pages). The program committee will review each submission 
and select papers based on originality, timeliness, relevance, and
clarity. All accepted papers will be presented at the conference, and 
published in the conference proceedings. 

Electronic submission is strongly encouraged. Please e-mail a Postscript 
or PDF copy of your submission to java00@icase.edu or send  15 hard copies 
to the program chair. Submissions must be received by January 17, 2000. 
Authors will be notified by Feb 25, 2000. 

Authors of accepted papers will be expected to sign a copyright release form. 
Proceedings will be distributed at the conference and will
subsequently be available from ACM. Papers published in proceedings are 
eligible for subsequent publication in refereed ACM journals at the
discretion of the editor of the particular journal. Papers describing 
essentially the same work must not have been published elsewhere or be
simultaneously under consideration for publication elsewhere. 

People interested in contributing a tutorial (.5 or 1 day) should contact 
the program chair by Jan 31, 2000.  The tutorials will be held on June 5,
2000. 
  

IMPORTANT DATES

Papers due:  Jan 17, 2000. 
Tutorial Proposals due:  Jan 31, 2000. 
Acceptance notice:  Feb. 25, 2000 
Final Papers due: March 24, 2000 


CONFERENCE CHAIR

Dennis Gannon 
Department of Computer Science 
Indiana University 
Bloomington, IN 47401 
and 
NAS Division 
NASA Ames Research Center 
MS 258-5 
Moffet Field, CA 94035 
Phone: (650) 604 1934 
gannon@cs.indiana.edu 


PROGRAM CHAIR

Piyush Mehrotra 
ICASE 
MS 132C 
3 West Reid Street - Building 1152 
NASA Langley Research Center 
Hampton, VA 23681 
Phone: (757)-864-2188 
Fax: (757)-864-6134 
pm@icase.edu 
  

PROGRAM COMMITTEE

     Henri Bal, Vrije University 
     Sandra Baylor, IBM 
     Aart Bik, Intel Corporation 
     Siddartha Chatterjee, University of North Carolina 
     Ken Kennedy, Rice University 
     Scott Kohn, Lawrence Livermore National Laboratory 
     Arvind Krishnamurthy, Yale University 
     Timothy Lindohm, Sun Microsystems 
     Satoshi Matsuoka, Tokyo Institute of Technology 
     Roldan Pozo, NIST 
     Vivek Sarkar, IBM 
     Suresh Srinivas, SGI 
     Vaidy Sunderam, Emory University 
     Gregor von Laszewzki, Argonne National Laboratory 
     Martin Westhead, EPCC 
     Kathy Yelick, University of California at Berkeley 


PUBLICITY CHAIR

Michael Philippsen 
Computer Science Department 
University of Karlsruhe 
Am Fasanengarten 5 
76128 Karlsruhe Germany 
Phone: 49-721-608-4067 
Fax: 49-721-608-7343 
phlipp@ira.uka.de 

Re: Operators -> unit analysis

[Brian Rogoff]

On 7 Jan 2000, Terry Sikes wrote:
> In article <wcc9022izjp.fsf@world.std.com>,
> Robert A Duff  <bobduff@world.std.com> wrote:
> 
> >>...I'd think that this would be better received if it
> >> was tied to the Numerics annex, since certainly this would be the
> >> major area of use.
> >
> >Perhaps, but most numerics code is done in Fortran, and it doesn't
> >bother with all this fancy stuff either.
> 
> Which is why so many people are searching for something better, and
> why so much numerical code is being translated into C++ (despite its
> obvious deficiencies).

Yes indeed, I thought that the "well Fortran doesn't do it" excuse sounded 
quite weak. If you strive to be just as good as Fortran then there is no 
reason to switch!

Tucker Taft's explanation that he feels additional operators compromise 
readability is the expected Ada response, but I disagree. Certainly 
overuse of infixes is bad, but I think Ada (or a future Ada-like
language) could use either a few more reusable infixes or a more general 
scheme. Honestly though, while I'm firmly in the "gimme more infixes" camp, 
I think this  is a fairly minor issue. 

I've also noticed that lots of new numerics (and I include DSP and image 
processing here) code is written in C or C++. If you really want to see
some interesting bleeding edge stuff, check out www.fftw.org, the
"Fastest Fourier Transform in the West", which won the Third Wilkinson
Prize for Numerical Software. While the web page describes it as a C
library for computing the DFT, the interesting part is actually  the
codelet generator which outputs the C, and that is written in OCaml, my 
other favorite language.

-- Brian

Re: Operators -> unit analysis

[Robert Dewar]

In article <3874D0BE.82F04763@Raytheon.com>,
  "Samuel T. Harris" <samuel_t_harris@Raytheon.com> wrote:
> How about a representation clause which defines the precedence
> of a custom operator to that of another. Something like ...
>
> for "union"'precedence use "+";
> for "intersection"'precedence use "*";
>
> --
> Samuel T. Harris, Principal Engineer
> Raytheon, Aerospace Engineering Services
> "If you can make it, We can fake it!"


This is of course the Algol-68 approach, and I think even the
Algol-68 designers regard it as a horrible mistake. One should
only rely on precedence of operators where the precedence rules
are clear and obvious. This cannot be the case by definition
for user defined precedences.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Operators -> unit analysis

[Ted Dennison]

In article <853lkg$tgj$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <3874D0BE.82F04763@Raytheon.com>,

> Algol-68 designers regard it as a horrible mistake. One should
> only rely on precedence of operators where the precedence rules
> are clear and obvious. This cannot be the case by definition
> for user defined precedences.

I think you are saying that in practice it gets to be a mess. I do
appreciate that. But the above statement would only be true if they are
truly user-defined. If the operators and precedences are in fact created
by the user to match existing precedences for established mathematical
notations, then I think it *would* be clear and obvious to any user. For
instance, if I make a notation including operators to mimic BNF
productions (which I am doing, btw), any reasonable user would expect to
*not* have to put parenthesis around a production's right side just to
keep the BNF "::=" operator from being evaluated prematurely.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Operators -> unit analysis

[Ted Dennison]

In article <8531v6$6qk$1@nntp3.atl.mindspring.net>,
  tsikes@netcom.com (Terry Sikes) wrote:
> In article <850tl9$thu$1@nnrp1.deja.com>,
> Was this point argued at length after the decision was made to add the
> various annexes?  I'd think that this would be better received if it
> was tied to the Numerics annex, since certainly this would be the
> major area of use.

Not by far. There are many applications in many realms of study that
have traditionally been described by some kind of mathematical notation.
The Gnat Snobol packages are a very good example for pattern matching.
Possible other applications off the top of my head are: strings, lists,
sets, database queries, BNF, Music.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Operators -> unit analysis

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> This is of course the Algol-68 approach, and I think even the
> Algol-68 designers regard it as a horrible mistake. One should
> only rely on precedence of operators where the precedence rules
> are clear and obvious. This cannot be the case by definition
> for user defined precedences.

I would say: If it's not a precedence rule I learned in grade school,
then it shouldn't be in a programming language (whether it was put there
by the language designer or by some "clever" programmer).

- Bob

Operators -> Unit Analysis

[mfeldman]

Hi all,

I thought I'd jump in and contribute a unit-analysis solution that doesn't use
generics or require the client to define any new operators. Nothing is free,
and this solution uses discriminants to carry the dimensions. Naturally this
uses extra run-time storage, but I think it's a good program model of the
physical
world, in which each physical quantity can be reduced to a scalar value and a
set of physical dimensions (mass/length/time/charge). The various physical
units are declared as subtypes of the resulting variant record type; a client
can,
for convenience, add units just by delcaring new subtypes. The additive and
multiplicative operators are defined in such a way that checking is done at
compilation time where possible, else at run time.

This package is based on a discussion in the Ada 83 Rationale, and is taken
from Chap. 6 in my data structures book. Please excuse the uppercase reserved
words. 
This version uses mass/length/time dimensions; as an exercise one could add a
charge dimension or make it generic. The spec, body, and a test program
follow.

Mike Feldman

PACKAGE Metric_System IS
------------------------------------------------------------------
--| Specification for Metric System Package
--| Author: Michael B. Feldman, The George Washington University 
--| Last Modified: September 1995                                     
------------------------------------------------------------------
 
--  Type definition
 
  TYPE    Metric(Mass, Length, Time : Integer) IS PRIVATE;

  -- constrained subtypes

  SUBTYPE Scalar   IS Metric(0, 0, 0);
 
  SUBTYPE Accel    IS Metric(0, 1, -2);
  SUBTYPE Area     IS Metric(0, 2, 0);
  SUBTYPE Length   IS Metric(0, 1, 0);
  SUBTYPE Distance IS Metric(0, 1, 0);
  SUBTYPE Mass     IS Metric(1, 0, 0);
  SUBTYPE Time     IS Metric(0, 0, 1);
  SUBTYPE Velocity IS Metric(0, 1, -1);
  SUBTYPE Volume   IS Metric(0, 3, 0);

  -- exported exception

  Dimension_Error : EXCEPTION;

  -- exported unit constants; these will be defined in full below

  Gram       : CONSTANT Metric;
  METER      : CONSTANT Metric;
  SEC        : CONSTANT Metric;
  Square_M   : CONSTANT Metric;
  Cubic_M    : CONSTANT Metric;
  M_per_Sec  : CONSTANT Metric;
  M_per_Sec2 : CONSTANT Metric;
 
  FUNCTION "*" (Left : Float; Right : Metric) RETURN Metric;
  -- Pre:  Left and Right are defined
  -- Post: constructor: produces a metric quantity from a Float one

  FUNCTION Value(Left : Metric) RETURN Float;
  -- Pre:  Left is defined
  -- Post: selector: returns the Float (dimensionless) part
  --   of a metric quantity

  FUNCTION "<"  (Left, Right : Metric) RETURN Boolean;
  FUNCTION "<=" (Left, Right : Metric) RETURN Boolean;
  FUNCTION ">"  (Left, Right : Metric) RETURN Boolean;
  FUNCTION ">=" (Left, Right : Metric) RETURN Boolean;
  -- Pre:    Left and Right are defined
  -- Post:   the usual comparison operations
  -- Raises: Dimension_Error if Left and Right 
  --   have different dimensions

  FUNCTION "+" (Right : Metric) RETURN Metric;
  FUNCTION "-" (Right : Metric) RETURN Metric;
  FUNCTION "abs" (Right : Metric) RETURN Metric;
  -- Pre:  Right is defined
  -- Post: the usual monadic arithmetic operations;
  --   the dimensions of Right are, of course, preserved
 
  FUNCTION "+" (Left, Right : Metric) RETURN Metric;
  FUNCTION "-" (Left, Right : Metric) RETURN Metric;
  -- Pre:    Left and Right are defined
  -- Post:   the usual additive operations are performed on the
  --   numeric parts of Left and Right; the dimensions are preserved
  -- Raises: Dimension_Error if Left and Right
  --   have different dimensions

  FUNCTION "*" (Left, Right : Metric) RETURN Metric;
  FUNCTION "/" (Left, Right : Metric) RETURN Metric;
  -- Pre:    Left and Right are defined
  -- Post:   the usual multiplication and division operations 
  --   are performed on the numeric parts of Left and Right; 
  --   the dimensions are added pairwise (multiplication)
  --   or subtracted pairwise (division)
  --   Left and Right need not have the same dimensions.
  
PRIVATE

  -- A Metric quantity is a 3-discriminant variant record,
  -- with no default values. Each object of the type must
  -- therefore be constrained to a subtype, that is, to a
  -- fixed set of dimensions. This is physically realistic.

  TYPE Metric(Mass, Length, Time : Integer) IS RECORD
    Value : Float := 0.0;
  END RECORD;
 
  Gram       : CONSTANT Metric := (1, 0, 0, 1.0);
  Meter      : CONSTANT Metric := (0, 1, 0, 1.0);
  Sec        : CONSTANT Metric := (0, 0, 1, 1.0);
  Square_M   : CONSTANT Metric := (0, 2, 0, 1.0);
  Cubic_M    : CONSTANT Metric := (0, 3, 0, 1.0);
  M_per_Sec  : CONSTANT Metric := (0, 1, -1, 1.0);
  M_per_Sec2 : CONSTANT Metric := (0, 1, -2, 1.0);
 
END Metric_System;

PACKAGE BODY Metric_System IS
------------------------------------------------------------------
--| This is the implementation of the package Metric_System.
--| Author: Michael B. Feldman, The George Washington University 
--| Last Modified: September 1995                                     
------------------------------------------------------------------
 
  -- local function to check whether its arguments have the same dimensions

  FUNCTION SameDimensions(Left, Right :Metric) RETURN Boolean IS
  BEGIN
    RETURN (Left.Length = Right.Length) AND
           (Left.Mass = Right.Mass)     AND
           (Left.Time = Right.Time);
  END SameDimensions;

  FUNCTION "*" (Left : Float; Right : Metric) RETURN Metric IS
  BEGIN
    RETURN (Right.Mass, Right.Length, Right.Time, Left * Right.Value);
  END "*";
 
  FUNCTION Value(Left : Metric) RETURN Float IS
  BEGIN
    RETURN Left.Value;
  END Value;

  -- comparison operators

  FUNCTION "<" (Left, Right : Metric) RETURN Boolean IS
  BEGIN
    IF SameDimensions(Left, Right) THEN
      RETURN Left.Value < Right.Value;
    ELSE
      RAISE Dimension_Error;
    END IF;
  END "<";

  FUNCTION "<=" (Left, Right : Metric) RETURN Boolean IS
  BEGIN
    IF SameDimensions(Left, Right) THEN
      RETURN Left.Value <= Right.Value;
    ELSE
      RAISE Dimension_Error;
    END IF;
  END "<=";

  FUNCTION ">" (Left, Right : Metric) RETURN Boolean IS
  BEGIN
    IF SameDimensions(Left, Right) THEN
      RETURN Left.Value > Right.Value;
    ELSE
      RAISE Dimension_Error;
    END IF;
  END ">";

  FUNCTION ">=" (Left, Right : Metric) RETURN Boolean IS
  BEGIN
    IF SameDimensions(Left, Right) THEN
      RETURN Left.Value >= Right.Value;
    ELSE
      RAISE Dimension_Error;
    END IF;
  END ">=";

  --  monadic arithmetic operators
 
  FUNCTION "+" (Right : Metric) RETURN Metric IS
  BEGIN
    RETURN Right;
  END "+";
 
  FUNCTION "-" (Right : Metric) RETURN Metric IS
  BEGIN
    RETURN (Right.Mass, Right.Length, Right.Time, -Right.Value);
  END "-";
 
  FUNCTION "ABS" (Right : Metric) RETURN Metric IS
  BEGIN
    RETURN (Right.Mass, Right.Length, Right.Time, ABS(Right.Value));
  END "ABS";
 
  --  dyadic arithmetic operators
 
  --  "+" and "-" require two variables of the same subtype,
  --  they return a variable of the same subtype passed
 
  FUNCTION "+" (Left, Right : Metric) RETURN Metric IS
  BEGIN
    IF SameDimensions(Left, Right) THEN
      RETURN (Left.Mass, Left.Length, Left.Time, Left.Value + Right.Value);
    ELSE
      RAISE Dimension_Error;
    END IF;
  END "+";
 
  FUNCTION "-" (Left, Right : Metric) RETURN Metric IS
  BEGIN
    IF SameDimensions(Left, Right) THEN
      RETURN (Left.Mass, Left.Length, Left.Time, Left.Value - Right.Value);
    ELSE
      RAISE Dimension_Error;
    END IF;
  END "-";

  --  "*" and "/" require variables of any subtype
  --  of Metric.  The subtype of the variable returned depends on
  --  the types passed and how the operation combines the units.
 
  FUNCTION "*" (Left, Right : Metric) RETURN Metric IS
  BEGIN
    RETURN (Left.Mass + Right.Mass, Left.Length + Right.Length, 
            Left.Time + Right.Time, Left.Value * Right.Value);
  END "*";
 
  FUNCTION "/" (Left, Right : Metric) RETURN Metric IS
  BEGIN
    RETURN (Left.Mass - Right.Mass, Left.Length - Right.Length, 
            Left.Time - Right.Time, Left.Value / Right.Value);
  END "/";
 
END Metric_System;


WITH Ada.Text_IO;
WITH Ada.Float_Text_IO;
WITH Metric_System; USE Metric_System;
PROCEDURE Test_Metric IS
------------------------------------------------------------------
--| Test some of the operations of the metric system package
--| Author: Michael B. Feldman, The George Washington University 
--| Last Modified: September 1995                                     
------------------------------------------------------------------

  V   : Velocity;
  T   : Time;
  D   : Length;
  A   : Area;
  Vol : Volume;

BEGIN -- Test_Metric

  -- these operations should all work correctly

  V := 23.0 * M_per_Sec;
  T := 3600.0 * Sec;

  D := V * T;

  Ada.Text_IO.Put("Distance = Rate * Time works as advertised");
  Ada.Text_IO.New_Line;
  Ada.Text_IO.Put("Distance is ");
  Ada.Float_Text_IO.Put(Item => Value(D), Fore => 1, Aft => 2, Exp => 0);
  Ada.Text_IO.Put(" meters.");
  Ada.Text_IO.New_Line;
  Ada.Text_IO.New_Line;

  D := 3.0 * Meter;
  A := D * D;

  Ada.Text_IO.Put("Area = Distance * Distance works as advertised");
  Ada.Text_IO.New_Line;
  Ada.Text_IO.Put("Area is ");
  Ada.Float_Text_IO.Put(Item => Value(A), Fore => 1, Aft => 2, Exp => 0);
  Ada.Text_IO.Put(" square meters.");
  Ada.Text_IO.New_Line;
  Ada.Text_IO.New_Line;

  Vol := A * D;

  Ada.Text_IO.Put("Volume = Area * Distance works as advertised");
  Ada.Text_IO.New_Line;
  Ada.Text_IO.Put("Volume is ");
  Ada.Float_Text_IO.Put(Item => Value(Vol), Fore => 1, Aft => 2, Exp => 0);
  Ada.Text_IO.Put(" cubic meters.");
  Ada.Text_IO.New_Line;
  Ada.Text_IO.New_Line;

  D := D + D;

  Ada.Text_IO.Put("Distance = Distance + Distance works as advertised");
  Ada.Text_IO.New_Line;
  Ada.Text_IO.Put("Distance is ");
  Ada.Float_Text_IO.Put(Item => Value(D), Fore => 1, Aft => 2, Exp => 0);
  Ada.Text_IO.Put(" meters.");
  Ada.Text_IO.New_Line;
  Ada.Text_IO.New_Line;

  BEGIN -- block for exception handler
    D := D * D;
    Ada.Text_IO.Put("Distance = Distance * Distance worked, but should not");
    Ada.Text_IO.New_Line;
  EXCEPTION
    WHEN Constraint_Error =>
      Ada.Text_IO.Put
        ("Constraint Error Raised on Distance = Distance * Distance");
      Ada.Text_IO.New_Line;
    WHEN Dimension_Error =>
      Ada.Text_IO.Put
        ("Dimension Error Raised on Distance = Distance * Distance");
      Ada.Text_IO.New_Line;
  END; -- exception block

  BEGIN -- block for exception handler
    D := T + D;
    Ada.Text_IO.Put("Distance = Time + Distance worked, but should not");
    Ada.Text_IO.New_Line;
  EXCEPTION
    WHEN Constraint_Error =>
      Ada.Text_IO.Put("Constraint Error Raised on Distance = Time +
Distance");
      Ada.Text_IO.New_Line;
    WHEN Dimension_Error =>
      Ada.Text_IO.Put("Dimension Error Raised on Distance = Time +
Distance");
      Ada.Text_IO.New_Line;
  END; -- exception block

END Test_Metric;
 


     -----  Posted via NewsOne.Net: Free Usenet News via the Web  -----
     -----  http://newsone.net/ --  Discussions on every subject. -----
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net

Re: Operators -> unit analysis

[Robert Dewar]

In article <38762D53.A9B2CC15@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:

> but as soon as the meanings of the operators becomes even
> slightly obscure or non-standard, the value to the reader
> drops precipitously.


An idea that Jean Ichbian and I pushed, but did not manage
to get sufficient support for, was to have one user defined
user operator, using the pillow symbol (also called the
currency conversion operator), to be used to represent un-noisy
"almost implicit" conversion operations (the kind of thing we
use unary plus for now).


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Operators -> unit analysis

[Robert Dewar]

In article <38764aac_2@news1.prserv.net>,
  "Matthew Heaney" <mheaney@banet.net> wrote:
> In article <wccln626ily.fsf@world.std.com> , Robert A Duff
> <bobduff@world.std.com>  wrote:
>
> Oh dear, I'll probably get horribly flamed for saying so, but
I disagree
> with the Ada(83) decision to require that "and" and "or"
operators
> appearing within the same statement also require parenthesis.


Can you really argue that depending on this makes things easier
to read, I don't think so! And it is quite error prone. It is
all too easy to write

  if asdfasdf > oiuyoiuyoiuy or asdfadsfadsf < oiuoiuyoiuyoiuy
    and not junk

and be confused by the indentation. To me this was one of the
sound decisions in Ada. The cost to the writer, extra parens.
The benefit to the writer, avoiding bugs like the above. The
benefit to the reader is clear.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Operators -> unit analysis

[Robert A Duff]

Robert, please be careful with your quotes.  I didn't say the "Oh
dear..." -- Matt did.

- Bob

Robert Dewar <robert_dewar@my-deja.com> writes:

> In article <38764aac_2@news1.prserv.net>,
>   "Matthew Heaney" <mheaney@banet.net> wrote:
> > In article <wccln626ily.fsf@world.std.com> , Robert A Duff
> > <bobduff@world.std.com>  wrote:
> >
> > Oh dear, I'll probably get horribly flamed for saying so, but
> I disagree
> > with the Ada(83) decision to require that "and" and "or"
> operators
> > appearing within the same statement also require parenthesis.
> 
> 
> Can you really argue that depending on this makes things easier
> to read, I don't think so! And it is quite error prone. It is
> all too easy to write
> 
>   if asdfasdf > oiuyoiuyoiuy or asdfadsfadsf < oiuoiuyoiuyoiuy
>     and not junk
> 
> and be confused by the indentation. To me this was one of the
> sound decisions in Ada. The cost to the writer, extra parens.
> The benefit to the writer, avoiding bugs like the above. The
> benefit to the reader is clear.

- Bob

Re: Operators -> unit analysis

[Tucker Taft]

Robert Dewar wrote:
> 
> In article <38762D53.A9B2CC15@averstar.com>,
>   Tucker Taft <stt@averstar.com> wrote:
> 
> > but as soon as the meanings of the operators becomes even
> > slightly obscure or non-standard, the value to the reader
> > drops precipitously.
> 
> An idea that Jean Ichbiah and I pushed, but did not manage
> to get sufficient support for, was to have one user defined
> user operator, using the pillow symbol (also called the
> currency conversion operator), to be used to represent un-noisy
> "almost implicit" conversion operations (the kind of thing we
> use unary plus for now).

For what it's worth, I believe that is the Latin-1 symbol that got morphed
into the Euro currency symbol recently, so we were lucky to avoid
using it.  And we would still have to have decided on the precedence,
even though it was proposed only as a unary operator.  Would it have 
precedence like "+" or like "abs"?  Well of course, anything named 
"pillow" would be like ...

-Tuck
-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Operators -> unit analysis

[Florian Weimer]

Tucker Taft <stt@averstar.com> writes:

> For what it's worth, I believe that is the Latin-1 symbol that got morphed
> into the Euro currency symbol recently, so we were lucky to avoid
> using it. 

IIRC Latin-1 wasn't touched at all (at least the mapping to Unicode
wasn't changed), but Latin-15 was added.  I very much doubt that this
standard will be widely adopted because the modifications compared to
Latin-1 (Euro, addition of some French characters) are incompatible
with the most widespread Latin-1 flavor.

BTW: Do you know any use of the internation currency sign (except the
end-of-file marker in Microsoft Write)?