SI Units - has Ada missed the boat?

SI Units - has Ada missed the boat?

[Martin]

One of my pet hopes for Ada2005 was that it would include some method
of automatically checking systems of units at compilation time or with
minimal run-time checking. Alas it was voted down due to time
pressures and technical issues (see http://www.ada-auth.org/ai-files/minutes/min-0403.html#AI324
and http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00324.TXT?rev=1.3).

C++ now has the Boost library (see http://svn.boost.org/trac/boost/browser/sandbox/units)
with zero-runtime cost (or at least when optimisation is switched on).

And now Java has a proposal for a similar beast (see
https://jsr-275.dev.java.net/files/documents/4333/34956/jsr-275.pdf).

I've been playing around with the C++ Boost library and it seems quite
good - at least for the sort of things I would use it for (embedded
avionics).

Is anyone still working on an Ada solution to this?

Cheers
-- Martin

Re: SI Units - has Ada missed the boat?

[ME]

Yes I have been looking for this.
"Martin" <martin.dowie@btopenworld.com> wrote in message 
news:1183907619.564482.240470@w3g2000hsg.googlegroups.com...
> One of my pet hopes for Ada2005 was that it would include some method
> of automatically checking systems of units at compilation time or with
> minimal run-time checking. Alas it was voted down due to time
> pressures and technical issues (see 
> http://www.ada-auth.org/ai-files/minutes/min-0403.html#AI324
> and http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00324.TXT?rev=1.3).
>
> C++ now has the Boost library (see 
> http://svn.boost.org/trac/boost/browser/sandbox/units)
> with zero-runtime cost (or at least when optimisation is switched on).
>
> And now Java has a proposal for a similar beast (see
> https://jsr-275.dev.java.net/files/documents/4333/34956/jsr-275.pdf).
>
> I've been playing around with the C++ Boost library and it seems quite
> good - at least for the sort of things I would use it for (embedded
> avionics).
>
> Is anyone still working on an Ada solution to this?
>
> Cheers
> -- Martin
> 

Re: SI Units - has Ada missed the boat?

[kevin cline]

On Jul 8, 10:13 am, Martin <martin.do...@btopenworld.com> wrote:
> One of my pet hopes for Ada2005 was that it would include some method
> of automatically checking systems of units at compilation time or with
> minimal run-time checking. Alas it was voted down due to time
> pressures and technical issues (seehttp://www.ada-auth.org/ai-files/minutes/min-0403.html#AI324
> andhttp://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00324.TXT?rev=1.3).
>
> C++ now has the Boost library (seehttp://svn.boost.org/trac/boost/browser/sandbox/units)
> with zero-runtime cost (or at least when optimisation is switched on).

A basic but usable implementation is obvious to anyone who understands
C++ template metaprogramming.  Of course a fully general
implementation is considerably more work.

>
> And now Java has a proposal for a similar beast (seehttps://jsr-275.dev.java.net/files/documents/4333/34956/jsr-275.pdf).

This is rather unwieldy since Java does not allow operator
overloading.  Who wants to read code like:

   time_aloft = sqrt(height.times(2).divide(g))

Nor can Java check the correctness of that computation at compile
time.

>
> I've been playing around with the C++ Boost library and it seems quite
> good - at least for the sort of things I would use it for (embedded
> avionics).


>
> Is anyone still working on an Ada solution to this?

A satisfactory solution seems impossible until Ada allows implicit
generic instantiation, and then it would be relatively simple.

Re: SI Units - has Ada missed the boat?

[Georg Bauhaus]

kevin cline wrote:

> This is rather unwieldy since Java does not allow operator
> overloading.  Who wants to read code like:
> 
>    time_aloft = sqrt(height.times(2).divide(g))

I'd like to know why this programmer's expression of a formula
for use by a computer is inferior, assuming the typical alternative
would be[*]

     time_aloft = sqrt((2 * height) / g))

I see that if you have very few operators in a program,
the chance of a human misreading a possibly ambiguous operator is
fairly low, understanding rather than misunderstanding the formula
might be easy.
So there is some amount of correspondence between uses of {punctuation
characters and symbols} in physics text on the one side and uses of
{punctuation characters} in programming text on the other side.
E.g., "/" usually means division in either case, even when the
semantics do not match 100%.

But in general, will it help to mimic a specific math expression
in larger programs, using (sub-)domain specific symbols?[**]
When I have a package for motion operators and then another operators
package for unrelated uses (since this is about overloading, there
are at least two). I can make one group of operators visible locally.
But is the effect really superior enough in the long run to
warrant all kinds of symbol overloadings? Or is it just the
desire of programmers for some magic spells (possibly improving
productivity due to an increased fun factor)?

I like the idea of concise formulae in a program when the symbols
are well understood and/or stand out (including some Unicode symbols,
at last!)

Imagine having to switch programming languages every now and then.
"Wait, what does '!' stand for, uuh, yesterday I was using C++---no
it was Fortran 90, that was the day before yesterday. Now this is ML,
not APL, ehr, '!' means ..."


 -- Georg 

 [*] assuming that a physicist, being used to the mathematical
expression, will assume commutativity of "*", which might or might
not be a good idea.

 [**] Indeed, typesetting systems have made some texts suffer from what
is criticised as symbolitis, making them more difficult to understand.

Re: SI Units - has Ada missed the boat?

[kevin cline]

On Jul 18, 3:17 am, Georg Bauhaus <bauhaus.rm.t...@maps.futureapps.de>
wrote:
> kevin cline wrote:
> > This is rather unwieldy since Java does not allow operator
> > overloading.  Who wants to read code like:
>
> >    time_aloft = sqrt(height.times(2).divide(g))
>
> I'd like to know why this programmer's expression of a formula
> for use by a computer is inferior, assuming the typical alternative
> would be[*]
>
>      time_aloft = sqrt((2 * height) / g))

With three thousand years of practice writing mathematical
expressions, symbolic operators are universally preferred over prosaic
expressions.  Would you also claim that:

  Let y = a times x times x plus b plus c

is just as easily grasped as:

  Let y = ax^2 + bx + c ?

Re: SI Units - has Ada missed the boat?

[Georg Bauhaus]

On Mon, 2007-07-23 at 05:29 +0000, kevin cline wrote:

> With three thousand years of practice writing mathematical
> expressions, symbolic operators are universally preferred over prosaic
> expressions.  Would you also claim that:

The problem I see is precisely that programming is, in
a sense, not exactly arithmetics. Of course, programming
has important mathematical descriptions, etc.. But there
is danger in considering them to be the same, and this
danger increases when the semantics of "+" is not known.

If programmers infer the semantics of "+" from math,
they are forgetting something: computers.

>   Let y = a times x times x plus b plus c
> 
> is just as easily grasped as:
> 
>   Let y = ax^2 + bx + c ?


Is this identifier "ax" to the power of 2?
This is not as absurd as it might seem. Math syntax,
used by mathematicians, is full of conventions and
highly dependent on context.
Programs also depend on context, e.g. the language
used, and the operator overloading visible. (Consider
# ax^2;;
This expression has type int but is here used with type string)

In fact, I think that many problems in programming
with number types have origins in the tempting
similarity of ASCII symbols for computer arithmetic
and mathematical expressions on paper.
Therefore, the local meaning of _overloaded_ operators
should at least be made explicit near the place where
they are use.

Re: SI Units - has Ada missed the boat?

[Colin Paul Gloster]

On 2007-07-23, Georg Bauhaus <bauhaus+rm.tsoh@maps.futureapps.de>
wrote:

|------------------------------------------------------------------------|
|"[..]                                                                   |
|                                                                        |
| In fact, I think that many problems in programming                     |
| with number types have origins in the tempting                         |
| similarity of ASCII symbols for computer arithmetic                    |
| and mathematical expressions on paper.                                 |
| [..]"                                                                  |
|------------------------------------------------------------------------|

You are too kind. Within the last twelve months, it was revealed in a
two part article in "C Vu" in which given answers to a programming
quiz conducted at a recent conference of the Association of C & C++
Users were summarized, that many (a minority, but still many)
programmers were unaware that * has higher precedence than binary +. I
am not kidding.

Sincerely,
Colin Paul Gloster