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,LOTS_OF_MONEY 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-10 13:01:51 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!ppp-2-15.cvx2.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Dimensionality Checking (Ada 20XX) Date: Mon, 10 Dec 2001 18:56:18 -0000 Message-ID: <9v37rs$cdmva$1@ID-25716.news.dfncis.de> References: <11bf7180.0112070815.2625851b@posting.google.com> <9v0crt$bo2bi$1@ID-25716.news.dfncis.de> NNTP-Posting-Host: ppp-2-15.cvx2.telinco.net (212.1.141.15) X-Trace: fu-berlin.de 1008018109 13032426 212.1.141.15 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:17712 Date: 2001-12-10T18:56:18+00:00 List-Id: Sorry not to reply to this in full sooner. "Mark Lundquist" wrote in message news:haTQ7.21816$wL4.49551@rwcrnsc51... > I think that units should be their own entity in the language, not fudged up > with a magic type and magic quasi-values. The language in the RM defining > the semantics of names, values, types and objects is pretty carefully > constructed, and it seems like your syntax would really gum it up :-). That > is, he definitions of type, value, and constant object, and just about > everything else in the RM that these things touch, would all have to be > qualified and special-cased to accomodate the quasi-type, quasi-values and > quasi-constant-objects that support your magic. That's actually a bit of a vague argument. Could you be a bit more specific, please? I would be grateful! > You'd rather want to write something like this: > > unit Meter; -- a base unit > > unit Meters_Squared is Meter ** 2; -- a derived unit Maybe, but then maybe this would be overkill. Is it really necessary? > > I don't believe unit specification (and therefore dimension checking) is > > applicable to floating-point types. > > Why in the world not? > > > They may be used for various purposes > > (perhaps often when a fixed-point type ought to be used), but a > > floating-point number is conceptually a ratio, and therefore implicitly > > unitless (and dimension-indeterminate). > > whaaaaaaahhhh? > > Nick, did you drop a little too much acid, back in the hippie days? :-) > > Bet seriously... you're gonna have to explain that one to me (your theory > about numbers -- not about the acid! :-) It's easier to demonstrate than to actually explain. Show me a piece of (genuine) Ada code that uses a floating point type to hold values that would be usefully made unit-specific, and I'll show you how they certainly could, and probably should, be held by a fixed point type instead. I'm not actually trying to argue that floating point types should never be used for non-unitless quantities. All I'm suggesting is that there is no practical need to add the unit-specific facility to floating point types. Furthermore, I think it would be horribly painful trying to do so (consider Ada.Numerics). > > There's the question of private types. I feel that the requisite > conversions > > and other mixed operations should be provided for a private type > explicitly > > (in its package spec), and that these operations should do the requisite > > conversion and checking, which may well be more complicated than mere > > scaling and dimensionality. The unit facilities would, of course, be > > applicable to those components which were of unit-specific (fixed-point) > > types. > > I'm not sure quite what you're getting at there, but it sounds like it might > be related to an issue I've been thinking about, which is that these units > currently would not be able to work with "quasi-numeric" abstractions such > as people define for things like rational numbers, infinite-precision > arithmetic, etc. > ... Correct. (The example presented to me was Ada.Calendar.Time). > Here's some other things I've thought about so far on the unit stuff... > > 1) You have to be able to handle logarithmic units... that's easy, for a > unit U: > > U'Log (B) -- denotes the log to the base B of U > U'Exp (B) -- denotes B to the power U Or alternatively, sticking closer to my design, the package Ada.Units could have functions Log and Exp. This presumably means that the dimensions of a unit could be non-integral? > 2) There's a bad problem with generics. Unit-safe programming totally > destroys the generic contract model. For example... given this: > > generic > type T is digits <>; > function F (X, Y : T) return T; Can we assume: generic type T is delta <>; function F (X, Y : T) return T; please? I don't think it is actually significant to this point, but just in case! > How can you tell if this is legal?: > > type T is [whatever...]; > for T'Unit use [whatever...]; -- T is a dimensioned type > . > . > . > function Ft is new F (T); > > You can't! I think, at worst (for a shared-code generic), this means a dynamic check would have to be performed at the instantiation. > (It's much easier to ID the ends of a CatDog spinning in an > inertial frame of reference :-). You may laugh, but the geneticists are slowly getting there ;-) What does puzzle me is ... um, how do I put it? ... how does poor CatDog perform certain vital bodily functions? > 3) Checking that the system of units established by the currently visible > set of unit definitions is self-consistent. Could you expand on this, please? > > Three further notes need to be made. > > > > (1) I am not sure if the (seven) SI units I have presented are the > complete > > set of basic units required in reality. > > Doesn't matter, specific units should not be built in... Right, see my other post introducing a generic dimensionality package. > > (3) I have not provided for units that are offset from the SI units' zero > > points (which are presumably all at the corresponding 'physical' zero > > point). I believe some other post suggested that this tends to be a fairly > > cosmetic matter anyway. > > > > No problem: > > Unit_B is Unit_A + Bias; I suspect there is a problem. If we stick to just scaling, it means that we can be certain conversion requires only one multiplication (plus another one, for a view conversion, on the way back). Adding biasing to the scaling would mean that such conversions could become arbitrarily complex; I think that's unacceptable (and I know Prof. Dewar would have a fit ;-) > I think you are on the right track though, as far as what we need units to > do for us: fully static, compile-time checking with inference of derived > dimensions, and automatically reversible and composable unit conversions. > Let's keep our thinkin' caps on... :-) Cool! > Cheers, > Mark Lundquist -- Best wishes, Nick Roberts