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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1dd28d5040ded1f8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-15 18:56:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!kibo.news.demon.net!demon!psiuk-p2!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Announce: Grace project site operational Date: Wed, 15 May 2002 11:31:07 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <3CD88FBD.4070706@telepath.com> <3CD91E31.1060004@telepath.com> <3CDBD673.FF452A3D@otelco.net> <4519e058.0205140718.3ddb1b2a@posting.google.com> <3ce1424a$1@pull.gecm.com> <4519e058.0205150657.3b695758@posting.google.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1021476669 28443 136.170.200.133 (15 May 2002 15:31:09 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 15 May 2002 15:31:09 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:24143 Date: 2002-05-15T15:31:09+00:00 List-Id: Not only is there the proliferation of operators as an issue, but one of efficiency as well. Perhaps you can pragma Inline them all or otherwise get the code minimized & avoid all the function calls, but it seems this is still "at risk" to not be very efficient or small if a given compiler is not very good at the optimizations. The point is that even if you want some separation of the types at the abstract, high-level of your program, what you want in the way of machine code is a simple add/subtract/multiply/divide. If you can't make it degenerate to that, then you've got efficiency concerns. Besides, it seems to kind of be working at cross purposes. First you create separate types to avoid the arbitrary mixing of one thing with another, then you invent a bunch of operators that allow you to mix them up again. Yeah, you still have protection from some kinds of errors (assigning Volts to Amps, e.g.) but we ought to ask if these are the most prevalent of errors that strong typing protects against and is it worth the bazillion operators, overhead, & potential obfuscation that results? It might be sufficient and simpler to do something like define a type Electrical_Units_Type (or Physics_Units_Type, or whatever others you think of) out of which you can make Volts and Amps & etc. (or Mass & Acceleration & etc.) That might fall into the category of Good Enough. That would let you do Volts * Amps but not Volts * Mass. Is that sufficient type safety? OTOH, if someone wanted to come up with an all-encompassing set of packages that provided engineering unit calculations & conversions with generic versions for Integer, Fixed, Decimal and Floating Point types, I doubt I'd try to stop them. If it looked good and seemed to be workable on a practical level, I'd be willing to go along with adding it to Grace. Just because I can't imagine such a package that wouldn't be a major pain in the posterior doesn't mean that someone more clever than myself won't come up with one. :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Ted Dennison" wrote in message news:4519e058.0205150657.3b695758@posting.google.com... > > I'm certianly not an engineering math expert, but I've watched enough > of them try to go this route and fail that I'm skeptical. The big > problem was always the geometric explosion of operators required for > every new unit added. Its no biggie when you just have positions and > velocities, but at ((n-1)n * p)/2 custom operators requred (where n = > # of units in your system and p = the average number of operators per > unit combo), you could potentially have to add 45p operators when the > 10th unit is added, 105p operators when the 15th unit is added, and > 190p operators when the 20th unit is added. If p is 2 ("*" and "/"), > then that's 90, 210, and 380 operator subprograms respectively.