Re: Announce: The Ultimate SI Units Cracker

Re: Announce: The Ultimate SI Units Cracker

[Grein, Christoph]

From: Jeffrey Creem <jeff@thecreems.com>

> 50 Hz...Luxury  :)
> I've yet to work on anything slower than 100Hz and some are 3.2 KHz..

Cool... But let me nitpick: Kilo is abbreviated with lower case k: 3.2 kHz

Re: Announce: The Ultimate SI Units Cracker

[Grein, Christoph]

From: Wes Groleau <wesgroleau@despammed.com>
> 
> Since Ada has a 'special' meaning for attribute, perhaps
> 'component' or 'discriminant' would be better.

Perhaps 'component', but not 'discriminant', since only one variant really uses 
discriminants.
I decided against component, because the type is private and you do not see 
components. I used attribute since the OO community likes to call what Ada does 
with components, instance attributes.

> Anyway, looks nice.  I once implemented a package with
> the 'derived types' approach, and I agree that creating
> all the operations is a pain.  I had a generic for each operator,
> but it was Ada 83, so the instantiations had to be in the spec,
> making the spec over 4,000 lines long.  Someone with a little
> authority thought a 4,000 line spec was unacceptable, so he
> rewrote it non-generic, reducing the spec down to "only" 3,000
> lines (and increasing the body from less than 50 to over 5,000).

And what's most unsatisfactory is that despite all these overloadings, you 
cannot get

  function "**" (Base: SI_Unit; Exp: Rational) return SI_Unit;

> I like the discriminant approach, but it does have another
> disadvantage in that a lot of numeric operations are lost.
> 
> You can't query 'First, 'Last, 'Small, etc.  But maybe when
> dealing with physical units those don't really matter much.
> And of course the package can provide substitutes.
> 
> You also can't provide such a type as a generic formal
> where a float or fixed is expected.  (Speaking of which,
> perhaps a fixed-point version of SI would be useful to someone.)
>
> ... [text omitted]
> 
> What I'm getting at is the ability to define a private type
> so that it has all the attributes and operations of a numeric
> type and can be use as a generic parameter to a numeric package.

That would be really cool, perhaps with some Ada0Y features...
But then it's not clear what e.g. a generic should do with the non-numeric 
components. It could just ignore them. But then how should a function know what 
to return if the actual for the formal T is SI_Unit?

generic
  type T is digits <>;
function F (X, Y: T) return T;

Perhaps this could work only for a private type that is tagged. Would this be a 
proposal for Ada0Y? If so, we would need a convincing example for the ARG of a 
problem that can be solved with such a new feature that cannot be solved nicely 
without it...

Re: Announce: The Ultimate SI Units Cracker

[Ira Baxter]

> And what's most unsatisfactory is that despite all these overloadings, you
> cannot get
>
>   function "**" (Base: SI_Unit; Exp: Rational) return SI_Unit;
>  <other complaints edited out>

The solution  being discussed here appears to be a runtime solution,
with runtime space consumption and time for checking.
(These are probably modest).  And, no errors will
be detected unless the actual erroring computation is exercised.
The comp.fortran.lang newsgroup had quite a nice
discussion about this kind of mechanism for Fortran90 in the last
year.   One issue that came up was that there were
limits to the check that could be done, as their scheme
was to add a 32-bit tag word to each value containing
an encoded version of the SI type for each value.
Since a code word of fixed size can't encode every
possible polynomial over SI units, they couldn't check
every computation (however, they could check
the most common ones, which is a pretty good
engineering solution).

It strikes me that the "ultimate" SI Units Checker (Cracker? odd name)
is one that is implemented as a static analysis rather
than a dynamic analysis.   Advantages would be
no runtime impact, full diagnosis of errors
before runtime, without exercising the code,
and no constraints on what could be checked.

To do this, you need what amounts to the Ada compiler front end,
munged to include unit declarations on data, complete
with units checking.  One might be able to implement
this with ASIS and a pile of procedural code.

<plug>One could also implement this with our DMS
Software Reengineering Toolkit, which can
be obtained with an Ada front-end.
DMS also provides attribute evaluation,
which makes it easy to propagate information
(such as units information) around the abstract syntax tree
and symbolic expression construction/simplification/matching.
which would make it easy to encode and check arbitrary SI units
polynomials.
See http://www.semdesigns.com/Products/DMS/DMSToolkit.html.
</plug>

Left to our own devices long enough, we may do this ourselves.
But we're more likely to do Fortran90 or (heaven help us) C++,
because of their popularity in the supercomputing community.

--
Ira Baxter, Ph.D. CTO Semantic Designs
www.semdesigns.com  512-250-1018

Re: Announce: The Ultimate SI Units Cracker

[Stephen Leake]

"Ira Baxter" <idbaxter@semdesigns.com> writes:

> It strikes me that the "ultimate" SI Units Checker (Cracker? odd name)
> is one that is implemented as a static analysis rather
> than a dynamic analysis.   Advantages would be
> no runtime impact, full diagnosis of errors
> before runtime, without exercising the code,
> and no constraints on what could be checked.
> 
> To do this, you need what amounts to the Ada compiler front end,
> munged to include unit declarations on data, complete
> with units checking.  One might be able to implement
> this with ASIS and a pile of procedural code.

It's been done, and discussed here last May:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=u3cwlbz02.fsf%40FWILSON.i-did-not-set--mail-host-address--so-shoot-me&rnum=1&prev=/groups%3Fas_q%3Dmacks-0.0.1%26safe%3Dimages%26ie%3DUTF-8%26oe%3DUTF-8%26as_ugroup%3Dcomp.lang.ada%26lr%3D%26hl%3Den

Hmm, that's really long! Search Google for "macks-0.0.1". 

There was a similar packag Make_Units, but I didn't find that in
Google; I think I got that via private email.

-- 
-- Stephe

Re: Announce: The Ultimate SI Units Cracker

[Fraser Wilson]

"Ira Baxter" <idbaxter@semdesigns.com> writes:

> To do this, you need what amounts to the Ada compiler front end,
> munged to include unit declarations on data, complete
> with units checking.

See http://www.blancolioni.org/ada/macks/index.html for an
implementation of this very concept.  It's only be tested on GNAT as
far as I know.

Fraser.

Re: Announce: The Ultimate SI Units Cracker

[Wes Groleau]

> > What I'm getting at is the ability to define a private type
> > so that it has all the attributes and operations of a numeric
> > type and can be use as a generic parameter to a numeric package.
> 
> That would be really cool, perhaps with some Ada0Y features...
> But then it's not clear what e.g. a generic should do with the non-numeric
> components. It could just ignore them. But then how should a function know what
> to return if the actual for the formal T is SI_Unit?
> 
> generic
>   type T is digits <>;
> function F (X, Y: T) return T;

This means that the generic body can expect T to have
all the operations that any floating point type has.
It can not expect it to have any operations that are
not common to all floating point types.

The function would have to return whatever the generic
actual is.  And it can only get that by operations that
are inherited or overridden from Float or that it defines
by using such operations.

MAYBE ....

type Clever is private digits 9;

private

   type Clever is ....

end;

Require the body to define ALL operations
that would be available for a true floating
point type.  I know this is difficult--that's
probably why Java chose to have its dichotomy
between primitive types that are actually numbers,
and object-oriented types which, no matter how hard
you try, you _can't_ treat completely as numbers.

Or can you?

If some Java files have

class myInteger extends Integer
{
   ....
}

and

   myInteger WeeksInYear = new myInteger ( 52 );
   myInteger DaysInWeek  = new myInteger (  7 );

does Java allow methods to be defined to support

     myInteger DaysInYear  = WeeksInYear * DaysInWeek + 1;

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Announce: The Ultimate SI Units Cracker

[Grein, Christoph]

> Also note that the page seems to make the somewhat incorrect assumption
> that hard real-time implies "fast".
> 
> Hard real-time just means you can never miss a deadline (where soft
> real-time
> means that you can sometimes miss some deadlines but not often).
> 
> While these terms vary from author to author, it has been my experience that
> these are pretty close to the generally accepted definitions.

As I have always heard the term being used, hard RT meant short cycle times (50Hz), 
soft RT meant long times (weather forecast _is_ time-critical, but the limit is 
one day or so).

I'm in the avionics business and we always call our system hard-real time.
OK, it must not miss a deadline, and it must be fast. So it fulfills both 
definitions.

Re: Announce: The Ultimate SI Units Cracker

[Grein, Christoph]

> On Thu, 12 Sep 2002 10:11:43 +0200 (MET DST), Grein, Christoph wrote:
> > 
> > See <http://home.T-Online.de/home/Christ-Usch.Grein/Ada/SI.html>
> > 
> > It has been released under GMGPL. Enjoy...
> 
> I cannot find any download link in the URL above.
> 

Oops, I'll check it this evening when I'm at home. It should be near to the 
bottom of the page.

Anyway, the download file is

<http://home.T-Online.de/home/Christ-Usch.Grein/Ada/SI.zip>

Announce: The Ultimate SI Units Cracker

[Grein, Christoph]

The ultimate SI Units cracker is there!

There has always been a demand to be able to compute with physical items where 
correctness of dimensions is checked, but to me, all previous attempts seemed 
unsatisfactory (and there were many) - now it's there, in full generality, 
including arbitrary powers and roots.

Yes - it's run-time consuming since the dimension is an attribute
No  - it's not precluded from being used for hard real-time systems
Yes - it can be applied under hard real-time conditions if it's done correctly
Yes - it's easy to switch off dimensions - only pure numerics remains

See <http://home.T-Online.de/home/Christ-Usch.Grein/Ada/SI.html>

It has been released under GMGPL. Enjoy...

                                 o     _      _          _
 --------- __o       __o      /\_    _ \\o   (_)\__/o   (_)
 ------- _`\<,_    _`\<,_    _>(_)  (_)/<_     \_| \    _|/' \/
 ------ (_)/ (_)  (_)/ (_)  (_)         (_)    (_)     (_)'  _\o_
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mein Radunfall
My bike accident


Christoph Grein
Mitglied von Ada-Deutschland
Member of Ada Germany
http:/www.ada-deutschland.de

http://home.T-Online.de/home/Christ-Usch.Grein
eMail: Christ-Usch.Grein@T-Online.de

Re: Announce: The Ultimate SI Units Cracker

[Preben Randhol]

On Thu, 12 Sep 2002 10:11:43 +0200 (MET DST), Grein, Christoph wrote:
> 
> See <http://home.T-Online.de/home/Christ-Usch.Grein/Ada/SI.html>
> 
> It has been released under GMGPL. Enjoy...

I cannot find any download link in the URL above.

Preben

Re: Announce: The Ultimate SI Units Cracker

[Jeffrey Creem]

Sounds like it might be interesting to look at. I do not see a download
link.
Also note that the page seems to make the somewhat incorrect assumption
that hard real-time implies "fast".

Hard real-time just means you can never miss a deadline (where soft
real-time
means that you can sometimes miss some deadlines but not often).

While these terms vary from author to author, it has been my experience that
these are pretty close to the generally accepted definitions.


I believe you really should be saying that there might be a concern about
your
approach (which you believe you have solved) for "time critical"
applications. Or, one could
say that your approach is still ok in applications in which computational
efficiency is important.

My offline MPEG encoding I do at home is by no means hard real-time (it is a
hobby,
perhaps if I was getting paid to do this it would be soft real-time :)
But it is time critical because it is computationally expensive and slow
(with respect to
how long humans want to wait for the data).



"Grein, Christoph" <christoph.grein@eurocopter.com> wrote in message
news:mailman.1031818621.20810.comp.lang.ada@ada.eu.org...
> The ultimate SI Units cracker is there!
>
> There has always been a demand to be able to compute with physical items
where
> correctness of dimensions is checked, but to me, all previous attempts
seemed
> unsatisfactory (and there were many) - now it's there, in full generality,
> including arbitrary powers and roots.
>
> Yes - it's run-time consuming since the dimension is an attribute
> No  - it's not precluded from being used for hard real-time systems
> Yes - it can be applied under hard real-time conditions if it's done
correctly
> Yes - it's easy to switch off dimensions - only pure numerics remains
>
> See <http://home.T-Online.de/home/Christ-Usch.Grein/Ada/SI.html>
>
> It has been released under GMGPL. Enjoy...
>
>                                  o     _      _          _
>  --------- __o       __o      /\_    _ \\o   (_)\__/o   (_)
>  ------- _`\<,_    _`\<,_    _>(_)  (_)/<_     \_| \    _|/' \/
>  ------ (_)/ (_)  (_)/ (_)  (_)         (_)    (_)     (_)'  _\o_
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Mein Radunfall
> My bike accident
>
>
> Christoph Grein
> Mitglied von Ada-Deutschland
> Member of Ada Germany
> http:/www.ada-deutschland.de
>
> http://home.T-Online.de/home/Christ-Usch.Grein
> eMail: Christ-Usch.Grein@T-Online.de

Re: Announce: The Ultimate SI Units Cracker

[Wes Groleau]

> Yes - it's run-time consuming since the dimension is an attribute

Since Ada has a 'special' meaning for attribute, perhaps
'component' or 'discriminant' would be better.

Anyway, looks nice.  I once implemented a package with
the 'derived types' approach, and I agree that creating
all the operations is a pain.  I had a generic for each operator,
but it was Ada 83, so the instantiations had to be in the spec,
making the spec over 4,000 lines long.  Someone with a little
authority thought a 4,000 line spec was unacceptable, so he
rewrote it non-generic, reducing the spec down to "only" 3,000
lines (and increasing the body from less than 50 to over 5,000).

I like the discriminant approach, but it does have another
disadvantage in that a lot of numeric operations are lost.

You can't query 'First, 'Last, 'Small, etc.  But maybe when
dealing with physical units those don't really matter much.
And of course the package can provide substitutes.

You also can't provide such a type as a generic formal
where a float or fixed is expected.  (Speaking of which,
perhaps a fixed-point version of SI would be useful to someone.)

Ada 95 extended the concept of attributes being functions
to letting them be procedures ('Write / 'Read), and allowed
programmers to redefine/override 'Write and 'Read.  I am curious
whether overriding/creating other attributes was considered.
Obviously, like operator overloading, it could easily be
used to obfuscate, but it could be very useful to be able
to define 'first and such for things like SI and Rational.

It would also be nice to be able to define a type conversion.

function Float (T : SI) return Float is ....

What I'm getting at is the ability to define a private type
so that it has all the attributes and operations of a numeric
type and can be use as a generic parameter to a numeric package.

I understand that many packages take advantage of the implementation
of a float for efficiency, but there could be an implementation
permission that allows the compiler to reject an instantiation
where this is the case--or issue a warning.


-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Announce: The Ultimate SI Units Cracker

[Randy Brukardt]

Wes Groleau wrote in message <3D809F51.299A6634@despammed.com>...
>Ada 95 extended the concept of attributes being functions
>to letting them be procedures ('Write / 'Read), and allowed
>programmers to redefine/override 'Write and 'Read.  I am curious
>whether overriding/creating other attributes was considered.
>Obviously, like operator overloading, it could easily be
>used to obfuscate, but it could be very useful to be able
>to define 'first and such for things like SI and Rational.


It was considered for Ada 9x, but was rejected as having insufficient
value for the substantial changes that would be required for compilers.
Most existing Ada compilers do not put attributes in the symboltable;
they do not have visibility, and so on.

>It would also be nice to be able to define a type conversion.
>
>function Float (T : SI) return Float is ....


This was discussed recently, and it was essentially proven to be
impossible without major incompatibilities. See ac-00026
(http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AC-00026.TXT).

>What I'm getting at is the ability to define a private type
>so that it has all the attributes and operations of a numeric
>type and can be use as a generic parameter to a numeric package.


Someone is always dreaming about that, but no one has had anything that
looks remotely like a viable proposal. (Numeric literals are always
trouble, as are the type conversions.)

                Randy.

Re: Announce: The Ultimate SI Units Cracker

[Wes Groleau]

Randy Brukardt wrote:
> Wes Groleau wrote in message <3D809F51.299A6634@despammed.com>...
> >Ada 95 .... allowed
> >programmers to redefine/override 'Write and 'Read.  I am curious
> >whether overriding/creating other attributes was considered.
> >Obviously, like operator overloading, it could easily be
> >used to obfuscate, but it could be very useful to be able
> >to define 'first and such for things like SI and Rational.
> 
> It was considered for Ada 9x, but was rejected as having insufficient
> value for the substantial changes that would be required for compilers.
> Most existing Ada compilers do not put attributes in the symboltable;
> they do not have visibility, and so on.

But they do for 'Write & 'Read, so why not for others?

> >It would also be nice to be able to define a type conversion.
> >
> >function Float (T : SI) return Float is ....
> 
> This was discussed recently, and it was essentially proven to be
> impossible without major incompatibilities. See ac-00026
> (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AC-00026.TXT).

Thanks for the link.

> >What I'm getting at is the ability to define a private type
> >so that it has all the attributes and operations of a numeric
> >type and can be use as a generic parameter to a numeric package.
> 
> Someone is always dreaming about that, but no one has had anything that
> looks remotely like a viable proposal. (Numeric literals are always
> trouble, as are the type conversions.)

I can see where literals would be difficult.  But if you can
declare a local type called Float, why can't you instead call
a local function called Float?  In the case of ambiguities....
I guess I'd better follow the link before I say any more.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Announce: The Ultimate SI Units Cracker

[Randy Brukardt]

Wes Groleau wrote in message <3D820229.E1B1BEC8@despammed.com>...
>> It was considered for Ada 9x, but was rejected as having insufficient
>> value for the substantial changes that would be required for
compilers.
>> Most existing Ada compilers do not put attributes in the symboltable;
>> they do not have visibility, and so on.
>
>But they do for 'Write & 'Read, so why not for others?

Not really. 'Read and 'Write don't have visibility at all (they have to
be redefined before freezing). And, in Janus/Ada, they're not actually
in the symbol table -- they are part of the type. (We don't keep type
information in the symbol table at all, just the names of the types).
Types (in Janus/Ada) don't have visibility; they always exist. And,
finally, these items have hard coded definitions in the types; there is
no mechanism for adding others (particularly user defined ones). Other
compilers may differ of course, but user-defined attributes would take
several months of work to implement in Janus/Ada -- and no one had a
compelling enough example to justify making implementors do that sort of
work.

                    Randy.

Re: Announce: The Ultimate SI Units Cracker

[Dmitry A.Kazakov]

Wes Groleau wrote:

> What I'm getting at is the ability to define a private type
> so that it has all the attributes and operations of a numeric
> type and can be use as a generic parameter to a numeric package.

IMO this is just a part of a far more general problem. The notion of 
subtype in Ada presumes a shared representation. This is inherently flawed, 
when separation of interface and implementation is considered. The rest is 
only the consequences.

What is actually needed is an ability to define subtypes having different 
representation. Then one could define dimensioned values as a subtype of 
float. With the consequence, enforced by the compiler, that 'First, 
'Adjacent etc have to be overridden.

-------------------
Then any discriminant-based solution faces the following problems:

1. There is no way to force the compiler to remove statically known 
discriminants and calculate expressions on them at compile-time.

2. When shifted units (like Celsius degree) are considered, then the value 
of the shift should be also a discriminant. But unfortunately Ada does not 
allow floating-point ones. I made it a component, which is nasty, because 
there is no way to have constrained subtypes of same shift [they form a 
group].

-------------------
When it comes to scales [I considered such an option in my implementation], 
then there is a problem that if a scale is attached to a dimensioned value 
as an access discriminant, then the type has to be limited. Otherwise, 
again there is no way to have subtypes constrained by same scale

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Announce: The Ultimate SI Units Cracker

[Wes Groleau]

"Dmitry A.Kazakov" wrote:
> Then any discriminant-based solution faces the following problems:
> 
> 1. There is no way to force the compiler to remove statically known
> discriminants and calculate expressions on them at compile-time.

I prefer to look at it as
"There's no rule to prevent a compiler vendor from ....
 and no way to prevent a user from selecting that compiler."

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

A pessimist says the glass is half-empty.
An optimist says the glass is half-full.
An engineer says the glass wastes space.
A  salesman says the glass exceeds its requirements.

Re: Announce: The Ultimate SI Units Cracker

[Dmitry A.Kazakov]

Wes Groleau wrote:

> "Dmitry A.Kazakov" wrote:
>> Then any discriminant-based solution faces the following problems:
>> 
>> 1. There is no way to force the compiler to remove statically known
>> discriminants and calculate expressions on them at compile-time.
> 
> I prefer to look at it as
> "There's no rule to prevent a compiler vendor from ....
>  and no way to prevent a user from selecting that compiler."

Is it absolutely true? I mean, ARM precisely defines what is "static" and 
what is not. So an expression involving static discriminants could be 
*formally* non-static, even if its outcome were known at compile-time. Thus 
such an outcome would be not allowed to appear where a static value is 
expected.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Announce: The Ultimate SI Units Cracker

[Mark Biggar]

Dmitry A.Kazakov wrote:
> Wes Groleau wrote:
> 
> 
>>"Dmitry A.Kazakov" wrote:
>>
>>>Then any discriminant-based solution faces the following problems:
>>>
>>>1. There is no way to force the compiler to remove statically known
>>>discriminants and calculate expressions on them at compile-time.
>>
>>I prefer to look at it as
>>"There's no rule to prevent a compiler vendor from ....
>> and no way to prevent a user from selecting that compiler."
> 
> 
> Is it absolutely true? I mean, ARM precisely defines what is "static" and 
> what is not. So an expression involving static discriminants could be 
> *formally* non-static, even if its outcome were known at compile-time. Thus 
> such an outcome would be not allowed to appear where a static value is 
> expected.

Yes, the ARM precisely defines which expressions must be static, but
it also goes on the define a "duck test"* for all expressions that
says that even though the expression is not in a static context
if it only contains static values then it should be statically
evaulated at compile time.  In addition, the optimization "as if" rule
allows a compiler to do all sorts of things like Wes wants.

* Duck Test: if it looks like a duck, has a bill, feathers, quacks, has 
webbed feet, etc., then it's a duck even if it appears where no duck
has ever been seen before.


-- 
Mark Biggar
mark.a.biggar@attbi.com

Re: Announce: The Ultimate SI Units Cracker

[Dmitry A.Kazakov]

Mark Biggar wrote:

> Dmitry A.Kazakov wrote:
>> Wes Groleau wrote:
>> 
>>>I prefer to look at it as
>>>"There's no rule to prevent a compiler vendor from ....
>>> and no way to prevent a user from selecting that compiler."
>> 
>> Is it absolutely true? I mean, ARM precisely defines what is "static" and
>> what is not. So an expression involving static discriminants could be
>> *formally* non-static, even if its outcome were known at compile-time.
>> Thus such an outcome would be not allowed to appear where a static value
>> is expected.
> 
> Yes, the ARM precisely defines which expressions must be static, but
> it also goes on the define a "duck test"* for all expressions that
> says that even though the expression is not in a static context
> if it only contains static values then it should be statically
> evaulated at compile time.  In addition, the optimization "as if" rule
> allows a compiler to do all sorts of things like Wes wants.

Right (*), but it is only a part of the problem. Even if an outcome is 
known, it may not appear in a static context. One cannot heal that without 
redefining the term "static" in ARM 4.9.

* However I saw no compiler capable to do it even in such a straightforward 
case as dimensioned units. Neither GNAT nor Aonix does it.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de