From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cc4f25d878383cc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-17 13:07:08 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: britt@adapower.net (Britt Snodgrass) Newsgroups: comp.lang.ada Subject: Re: Dimensionality Checking (Ada 20XX) Date: 17 Dec 2001 13:07:07 -0800 Organization: http://groups.google.com/ Message-ID: <36c6f8dd.0112171307.2a8bf6c4@posting.google.com> References: <3c1dd328.10829203@News.CIS.DFN.DE> NNTP-Posting-Host: 216.253.238.30 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1008623228 14562 127.0.0.1 (17 Dec 2001 21:07:08 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 17 Dec 2001 21:07:08 GMT Xref: archiver1.google.com comp.lang.ada:18024 Date: 2001-12-17T21:07:08+00:00 List-Id: 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" > wrote: > > >What is wrong with using Pat Roger's dimensioning system. It has units > >and scaling. It allows making metric, English, or other dimensional > >units, with all "interconversions" straightforward and easy. For > >example, the following user code works with dimension checking and > >appropriate scaling conversions: I agree with Steve. Pat Roger's approach seems pretty elegant to me. > > 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? > > >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. 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. Britt Snodgrass <> > Regards, > Dmitry Kazakov