Re: Dimensionality Checking (Ada 20XX)

[dmitry@elros.cbb-automation.de (Dmitry A. Kazakov)]

On 17 Dec 2001 13:07:07 -0800, britt@adapower.net (Britt Snodgrass)
wrote:

>dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) wrote in message news:<3c1dd328.10829203@News.CIS.DFN.DE>...
>> On Sat, 15 Dec 2001 02:07:41 -0500, "Steven Deller"
>> <deller@smsail.com> wrote:
>> 
>> I used a similar approach. The difference was that I used only one
>> discriminant - a modular number holding all 7 powers. With
>> Interfaces.Unsigned_32 it holds powers -8..7. Then I used an
>> additional field for the offset [to cope with damned Celsius degree
>> (:-))]
>
>Can you provide an example of your modular type definition?

subtype UnitPower is Interfaces.Unsigned_32;
type Unit is new UnitPower;

function "**" (Left : Unit; Right : Integer) return Unit;
function "*"  (Left, Right : Unit) return Unit;
function "/"  (Left, Right : Unit) return Unit;
function Sqrt (X : Unit) return Unit;
pragma Inline ("**", "*", "/", Sqrt);
...

You can download it from here:
http://www.dmitry-kazakov.de/ada/units.htm

>> >The only difficulties I see are getting the RIGHT system of dimensions
>> >for such a package (but then again, not being "built in", it can be
>> >changed is so needed).
>> 
>> The approach is thinkable and it has a great advantage - an ability to
>> write "class-wide" subroutines for dimensioned types. But it still
>> faces several problems.
>> 
>> 1. Optimization issues. I saw no compiler able to remove run-time
>> checks and storage for the dicriminants for constrained subtypes. [I
>> wrote a small test program which calculated performance penalty. It is
>> 6..20 times when compared with regular float]. I agree with you that
>> such kind of optimizations could be even more useful than dimensioned
>> values itself: some sort of user-defined compile-time expressions,
>> removal of static discriminants as well as tags (the later one might
>> require revison of tagged types, because of redispatch).
>
>Could a large part of the performance penalty be attributed to your
>use of a single modular number discriminant for the dimensional
>powers?  I think this would require a lot of bit unpacking/repacking. 

No unpacking. It is made so that a unit operation is first applied to
the positions 0,2,4,6 (with overflow checks in positions 1,3,5,7).
Then same is made for positions 1,3,5,7. After that the results are
merged.

>Separate discriminants might be faster.
>
>I would probably remove the unit checks in final production code by
>redefining the unit types to be reqular floating types, recompiling,
>and retesting.

Then you loose the major advantage of the approach against ones based
on generics or other kinds of preprocessing - an ability to have
unconstrained (by unit) dimensioned values and thus subroutines that
work for all units. 

Regards,
Dmitry Kazakov